Vibe-kodningens framväxt: Kan det vara användbart för projektledare?
Vibe-kodningens tillväxt: Vibe-kodning har utvecklats från ett nischat koncept till något som väcker allt större uppmärksamhet inom teknik- och affärskretsar.
Projektledare: Projektledare, som är skickliga på tydlig kommunikation, är överraskande väl lämpade för att bli framgångsrika inom vibe-kodning.
Exempel från verkligheten: Praktiska tillämpningar av vibe-kodning visar dess potential att bygga verktyg för nischade användningsområden.
Utmaningar: Även om vibe-kodning påskyndar den inledande utvecklingen, är skalning och kvalitetsstyrning fortfarande utmanande aspekter.
Medvetenhet om risker: Icke-tekniska utvecklare kan möta risker, inklusive skalbarhetsproblem och säkerhetssårbarheter, när de använder vibe-kodning.
Under det senaste året eller de senaste två åren har ”vibecoding” gått från att vara ett nischat begrepp som cirkulerar i AI-entusiastiska hörn av internet till ett koncept som börjar nå den breda massan – åtminstone inom teknik-, affärs- och produktivitetskretsar. Efter att ha tillbringat otaliga timmar med att prata om AI med experter och själv ha fördjupat mig i en vibecoding-obsession har jag lagt märke till ett mönster: vibecoding tenderar att vara nästa steg för personer som har nått gränsen för vad befintliga AI-verktyg kan göra för dem. Om du inte hittar det du letar efter, varför inte bygga det själv?
Haken är att de flesta jag pratar med fortfarande inte har hört talas om det. Det förblir ett genuint nischat koncept, och ett som sällan diskuteras specifikt i projektledningskretsar. Därför började jag leta efter personerna som faktiskt gör det: riktiga projektledare och verksamhetsledare som i tysthet har byggt in vibecodade verktyg i sina dagliga arbetsflöden, och frågade dem hur det går.
Oavsett om du är en projektledare som är nyfiken på vart AI kan ta dig härnäst, eller en ledare som försöker ligga steget före vad ditt team kanske redan experimenterar med, kan du se detta som din introduktion till vibecoding – en del inspiration, en del varning.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Vad är vibecoding egentligen?
Eftersom det ännu inte finns någon formell definition av ”vibecoding”, då det är ett nytt begrepp, definierar vi det så här: att koda genom att instruera en LLM med vanligt språk, som sedan genererar kod.
För den här artikelns skull vill jag också förtydliga att ”vibecoding” (åtminstone så som jag använder begreppet) skiljer sig från AI-assisterad kodning – där en tekniskt kunnig utvecklare använder verktyg som GitHub Copilot för att snabba upp arbete som hen redan vet hur man utför.
Varför projektledare är förvånansvärt väl lämpade för detta
Vid första anblick kan vibecoding verka vara ett verktyg för entreprenörer eller tekniknära hobbyister. Men ju fler personer jag pratade med, desto tydligare framträdde en annan profil: den person som lyckas bäst med vibecoding är inte nödvändigtvis den mest tekniska personen i rummet. Det är personen som är bäst på att veta vad hen vill ha och att uttrycka det tydligt – vilket, om man tänker efter, beskriver en bra projektledare nästan perfekt.
Tim Fisher, VP för AI på The Digital Project Manager, uttryckte det så här: ”Det är ett sätt att kommunicera som inte fanns tidigare.” Han ser vibecoding mindre som en teknisk färdighet och mer som ett nytt medium för att omvandla idéer till något konkret. ”Värdet med de här verktygen för personer som inte kodar är att kunna ta genvägar förbi saker som att skapa samsyn kring en idé och ta sig förbi fasen ’kommer det här att fungera?’”
Vibecoding är ett sätt att kommunicera som inte fanns tidigare.
Det Tim beskrev passar perfekt in på projektledarens kompetensprofil: att skriva krav, översätta verksamhetens behov till tydliga specifikationer och kommunicera mellan tekniska och icke-tekniska team – allt detta är sådant projektledare gör varje dag, och det visar sig vara precis det som vibecoding belönar.
Aniket Ghonge, senior chef för försörjningskedjan på Amazon, beskrev sin egen väg till vibecoding på ett sätt som många projektledare kommer att känna igen sig i. Flera år innan agentisk AI existerade hjälpte han till att leda ett utvecklingsteam i att bygga ett internt verktyg genom att skriva krav och beskriva vad han behövde. ”Jag byggde ingenting. Jag kodade ingenting. Jag sa bara: ’Det här behöver vi. Så här ska det fungera.’ Och de byggde det utifrån mina krav. Men det var där min resa började. Nu, med agentisk AI, gör jag samma sak. Jag skriver mina krav, men AI:n sköter kodningen.”
Den enda skillnaden nu? Han behöver inget utvecklingsteam.
Vad bygger människor egentligen?
Det mest övertygande beviset för vibecodings potential är inte teoretiskt – det är de specifika, praktiska saker som människor i tysthet har lanserat medan resten av oss fortfarande diskuterade om det var värt att försöka.
Här är en ögonblicksbild av vad fyra icke-tekniska yrkesverksamma har byggt:
Dixie Willard, grundare och chef för projektstrategi på Poised and Plumb, arbetar främst med inredningsdesigners och byggde helt på egen hand en omfattningsbyggare. Appen låter en designer gå igenom ett kundmöte på en surfplatta, bocka av rum, val och projektfaser i realtid och genererar direkt ett tydligt dokument över arbetets omfattning — något som tidigare krävde anteckningar, minne och timmar av administrativt efterarbete. Hon byggde den eftersom inget liknande fanns. "Det finns helt enkelt inget. Och det finns många verktyg som designers skulle kunna använda men som helt enkelt inte finns." Hennes syn på varför vibekodning är viktigt i branscher som hennes: "Jag tror att nischade användningsområden förmodligen är den största anledningen att använda vibekodning. Det gör livet så mycket enklare."
Jag tror att nischade användningsområden förmodligen är den största anledningen att använda vibekodning. Det gör livet så mycket enklare.
Aniket Ghonge ägnade 16 till 18 timmar varje vecka åt att manuellt bearbeta data för efterfrågeprognoser för hundratals transportörer i Amazons logistiknätverk — kopiera siffror mellan kalkylblad, göra beräkningar för hand och sedan göra om allt veckan därpå. "Det är en manuell process. Det tog ungefär 16 till 18 timmar varje vecka. Jag kan inte fortsätta göra det manuellt och begå misstag, eftersom allt som en människa hanterar i stor skala kommer att vara felbenäget." Därför vibekodade han en komplett webbapplikation som nu automatiserar det mesta av arbetet. Jämförelsen med det som fanns tidigare är slående: "För ett par år sedan var jag tvungen att arbeta med en webbutvecklare, en UX-designer, en produktchef, en teknisk programchef och många andra personer för att bygga en produkt som mitt koncept baserades på. I dag har jag inga blockeringar, och inom två veckor byggde jag en applikation. En liknande applikation som jag tidigare arbetade med tog två år."
Michael Gold, fraktionerad leveranschef och grundare på Gold Project Management, byggde ett anpassat CRM-system i Lovable som ansluter till företagets webbplats och integreras med Fireflies, hans verktyg för mötestranskribering. Varje morgon går han och hans affärspartner igenom sin säljtratt under ett samtal, och när de är klara gör ett enda knapptryck resten: "Jag kan bara klicka på uppdatera från transkriberingen, så går den automatiskt igenom transkriberingen och tilldelar den till rätt person. Den lägger också till anteckningar och uppgifter och tilldelar dem till oss." Sedan dess har han tagit vibekodningen längre och samarbetat med en utvecklare för att bygga ett komplett automatiseringsverktyg för professionella tjänster, som nu närmar sig en offentlig lansering.
Harry Max, fraktionerad chef och författare till Att hantera prioriteringar, såg sin affärspartner vibekoda en avancerad plattform för prioritering från grunden under nio månader med Claude Code — utan utvecklingsteam och utan extern investering. Jämförelsen mellan före och efter som Harry gav var svår att ignorera: "På nio månader byggde en person något lika sofistikerat som den programvara vi byggde för 20 år sedan med 14 personer och 2 miljoner dollar."
På nio månader byggde en person något lika sofistikerat som det vi byggde för 20 år sedan med 14 personer och 2 miljoner dollar.
Den ärliga sanningen: allt går inte som på räls
Alla jag pratade med var genuint entusiastiska över vibekodning. De var också, utan undantag, ärliga om när det blir svårt.
Den vanligaste erfarenheten verkar vara en variant av det Michael beskrev: "Man kan gå från noll till 60 snabbare än någonsin, men jag tycker fortfarande att det är väldigt svårt att gå från 60 till 100. Om man verkligen vill få det i mål krävs det fortfarande expertis."
Harry Max uppmärksammade en mer subtil fälla — lockelsen i själva processen. "Det är väldigt lockande att fortsätta ändra saker, och varje gång man ändrar något går något sönder. Och man upptäcker inte vad som gått sönder om man inte verkligen har tänkt igenom hur man ska hantera sina kvalitets- och testprocesser." Han gav också en allvarsam påminnelse om resultat som ser bättre ut än de är: "Att man kan vibekoda saker som ser vackra ut betyder inte att de är användbara. Det betyder inte att de fungerar. Det betyder inte att de löser ett problem, men de ser fantastiska ut."
[Med vibekodning] kan du gå från noll till 60 snabbare än någonsin, men jag tycker fortfarande att det verkligen är utmanande att gå från 60 till 100.
Aniket Ghonge fick uppleva en av de svårare lärdomarna på nära håll. I sin iver att fortsätta bygga funktioner hoppade han över ett teststeg som kostade honom dyrt: "Jag förlorade plötsligt 50 % av mitt arbete, och det skrämde mig verkligen. Det var min hårda lärdom. Okej, du måste testa en funktion i en testmiljö innan du gör en ändring i en produktionsmiljö." Han återhämtade sig, men det tog timmar — och orsakade en betydande mängd oro.
Riskerna som icke-tekniska byggare inte alltid ser komma
Entusiasmen bland yrkesverksamma är verklig, men det är även de strukturella riskerna — och det var här jag bestämde mig för att ta in Tim för ett ärligt tekniskt perspektiv.
När jag frågade Tim vad han tyckte om att projektledare kodar sina egna verktyg med vibekodning, handlade hans perspektiv mindre om att avskräcka människor och mer om att se till att de ger sig in i det med öppna ögon. Hans viktigaste iakttagelse: "Generellt sett kan du inte utgå från att den agentbaserade kodaren kommer att upplysa dig om vad du inte vet, om du inte vet vad du inte vet."
Det gäller särskilt skalbarhet. "Generellt sett är alla vibekodade projekt inte skalbara, främst eftersom du inte ber agenten att ta hänsyn till skalning. Icke-utvecklare frågar förmodligen inte ens efter saker som felhantering." Ett vibekodat verktyg kan fungera perfekt för fem användare och obemärkt falla samman vid femtio — och personen som byggde det kanske inte har någon möjlighet att förstå varför.
Generellt sett är alla vibekodade projekt inte skalbara, främst eftersom du inte ber agenten att ta hänsyn till skalning.
Och sedan har vi frågan om ansvar, som blir särskilt tydlig när verktyget blir populärt inom en organisation. "Om du bygger något som människor förlitar sig på måste det bli mer än bara ett vibekodat projekt; det måste tas över av personer som arbetar professionellt med detta och känner till saker som du inte ens vet att du behöver fråga om." Fisher målade upp ett specifikt scenario som kändes mycket verkligt: "Om någon frågar den här personen: 'Är informationen jag får från ditt verktyg korrekt?' och personen inte vet tillräckligt om hur det fungerar eftersom hen lät agenten göra allt arbete, då kan hen inte besvara den frågan."
Även Dixie Willard, som aktivt bygger verktyg som hon tror på, erkände den oro som ligger under entusiasmen: "Det är det som alltid gör mig nervös, för jag tänker: tänk om det finns ett säkerhetsproblem?"
Det är värt att notera att säkerhetssårbarheter — exponerade API-nycklar, oskyddade användardata och verktyg som oavsiktligt hanterar personuppgifter utan lämpliga skyddsåtgärder — hör till de vanligaste fallgroparna som Tim lyfte i vårt samtal. Det är sådant som en utvecklare hanterar rutinmässigt, men som en vibekodare helt enkelt kanske inte vet att hen behöver ta itu med.
Så, borde du prova?
Det ärliga svaret är: det beror på vad du bygger och vad du planerar att göra med det.
Vibekodning är genuint kraftfullt som verktyg för prototypframtagning och kommunikation. Om du har en idé, vill testa om den fungerar eller behöver visa intressenter något konkret innan du investerar i riktig utveckling, är potentialen hög och riskerna hanterbara. Tim uttrycker det väl: kärnvärdet är att snabbare än någonsin tidigare ta sig förbi fasen "kommer det här att fungera?".
Det blir mer komplicerat när ett vibekodat verktyg går från prototyp till något som människor är beroende av. Då börjar bristerna i skalbarhet, felhantering och säkerhet — som det gick bra att ignorera i början — att spela roll, och personen som byggde det kanske inte har det tekniska ordförrådet för att ens veta var hen ska börja leta.
De yrkesverksamma i den här artikeln navigerar alla i den spänningen i realtid. Vissa lämnar över till utvecklare. Vissa lär sig medan de arbetar. Alla försöker, en prompt i taget, förstå exakt var gränserna för den här tekniken går.
För projektledare är möjligheten verklig — men även ansvaret som följer med den. Den goda nyheten är att veta vad man vill, ställa rätt frågor och förstå när man behöver ta in hjälp är sådant som bra projektledare redan gör. Vibekodning är när den fungerar som bäst bara en ny kontext för samma färdigheter.
Vill du ha fler insikter som dessa? Registrera dig för ett kostnadsfritt DPM-konto för att höra från fler experter som dessa.
