Fremveksten av vibekoding: Kan det være nyttig for prosjektledere?
Veksten innen vibekoding: Vibekoding har utviklet seg fra et nisjekonsept til noe som får stadig mer oppmerksomhet i teknologi- og forretningskretser.
Prosjektledere: Prosjektledere, som er dyktige til å kommunisere tydelig, viser seg overraskende godt egnet til å lykkes med vibekoding.
Eksempler fra virkeligheten: Praktiske anvendelser av vibekoding viser potensialet for å bygge verktøy for nisjebehov.
Utfordringer: Selv om vibekoding fremskynder den innledende utviklingen, er skalering og kvalitetsstyring fortsatt utfordrende.
Bevissthet om risiko: Ikke-tekniske utviklere kan møte risikoer, blant annet skaleringsproblemer og sikkerhetssårbarheter, når de bruker vibekoding.
Det siste året eller to har «vibecoding» gått fra å være et nisjebegrep som sirkulerer i AI-entusiastkretser på internett, til et konsept som begynner å nå ut til et bredere publikum – i hvert fall innen teknologi, næringsliv og produktivitet. Etter å ha brukt utallige timer på å snakke om AI med eksperter, og selv vært dypt oppslukt av vibecoding, har jeg lagt merke til et mønster: Vibecoding ser ut til å være neste steg for personer som har nådd grensen for hva eksisterende AI-verktøy kan gjøre for dem. Hvis du ikke finner det du leter etter, hvorfor ikke bare lage det selv?
Utfordringen er at de fleste jeg snakker med, fortsatt ikke har hørt om det. Det er fortsatt et genuint nisjekonsept, og et som sjelden diskuteres spesifikt i prosjektlederkretser. Derfor lette jeg etter personene som faktisk holder på med dette: ekte prosjektledere og driftsledere som i stillhet har bygget vibecodede verktøy inn i de daglige arbeidsflytene sine, og spurte dem hvordan det går.
Enten du er en prosjektleder som er nysgjerrig på hvor AI kan ta deg videre, eller en leder som prøver å ligge i forkant av det teamet ditt allerede eksperimenterer med, kan du se på dette som din introduksjon til vibecoding – del inspirasjon, del advarsel.
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
Hva er egentlig vibecoding?
Selv om det ennå ikke finnes en formell definisjon av «vibecoding», siden det er et nytt begrep, definerer vi det slik: programmering gjennom å gi en LLM instruksjoner på naturlig språk, som deretter produserer kode.
For denne artikkelens formål vil jeg også presisere at «vibecoding» (i hvert fall slik jeg bruker begrepet) skiller seg fra AI-assistert programmering – der en teknisk dyktig utvikler bruker verktøy som GitHub Copilot for å gjøre arbeidet raskere, arbeid som utvikleren allerede vet hvordan skal utføres.
Hvorfor prosjektledere overraskende nok egner seg godt til dette
Ved første øyekast kan vibecoding virke som et verktøy for gründere eller hobbyister med tilknytning til teknologi. Men jo flere personer jeg snakket med, desto tydeligere ble et annet bilde: Personen som lykkes med vibecoding, er ikke nødvendigvis den mest tekniske i rommet. Det er personen som er best til å vite hva de ønsker, og til å formulere det tydelig – noe som, når man tenker over det, beskriver en god prosjektleder nesten perfekt.
Tim Fisher, VP for AI hos The Digital Project Manager, formulerte det slik: «Det er en måte å kommunisere på som ikke fantes før.» Han ser på vibecoding mindre som en teknisk ferdighet og mer som et nytt medium for å gjøre ideer håndgripelige. «Verdien av disse verktøyene for personer som ikke programmerer, er at de kan hoppe over ting som å skape enighet rundt en idé, og komme forbi fasen der man spør: «Kommer dette til å fungere?»»
Vibecoding er en måte å kommunisere på som ikke fantes før.
Det Tim beskrev, passer godt med ferdighetene til en prosjektleder: å skrive krav, oversette forretningsbehov til tydelige spesifikasjoner og kommunisere på tvers av tekniske og ikke-tekniske team – dette er ting prosjektledere gjør hver dag, og det viser seg at det er nettopp dette vibecoding belønner.
Aniket Ghonge, senior leder for forsyningskjeden hos Amazon, beskrev sin egen vei til vibecoding på en måte mange prosjektledere vil kjenne seg igjen i. Flere år før agentisk AI eksisterte, hjalp han et utviklingsteam med å lage et internt verktøy ved å skrive krav og beskrive hva han trengte. «Jeg bygde ingenting. Jeg skrev ingen kode. Jeg sa bare: «Her er det vi trenger. Slik bør det fungere.» Og de bygde det basert på kravene mine. Men det var der reisen min begynte. Nå, med agentisk AI, gjør jeg det samme. Jeg skriver kravene mine, men AI gjør programmeringen.»
Den eneste forskjellen nå? Han trenger ikke et utviklingsteam.
Hva er det folk faktisk bygger?
Det mest overbevisende beviset på vibecodings potensial er ikke teoretisk – det er de konkrete, praktiske tingene folk i stillhet har lansert, mens resten av oss fortsatt diskuterte om det var verdt å prøve.
Her er et øyeblikksbilde av hva fire ikke-tekniske praktikere har bygget:
Dixie Willard, grunnlegger og sjefstrateg for prosjekter i Poised and Plumb, arbeider hovedsakelig med interiørdesignere og bygget en arbeidsomfangsbygger helt på egen hånd. Appen lar en designer gå gjennom en kundekonsultasjon på et nettbrett, krysse av for rom, valg og prosjektfaser i sanntid, og genererer et ryddig arbeidsomfangsdokument på stedet – noe som tidligere krevde notater, hukommelse og timesvis med administrativt arbeid etter møtet. Hun bygget den fordi det ikke fantes noe lignende. «Det finnes bare ikke. Og det finnes mange verktøy som designere kunne ha brukt, men som rett og slett ikke eksisterer.» Hennes syn på hvorfor vibekoding er viktig i bransjer som hennes: «Jeg tror de nisjepregede bruksområdene sannsynligvis er den viktigste grunnen til å bruke vibekoding. Det gjør livet så mye enklere.»
Jeg tror de nisjepregede bruksområdene sannsynligvis er den viktigste grunnen til å bruke vibekoding. Det gjør livet så mye enklere.
Aniket Ghonge brukte 16 til 18 timer hver uke på å behandle data for etterspørselsprognoser manuelt for hundrevis av avsendere i Amazons logistikknettverk – kopiere tall mellom regneark, utføre beregninger for hånd og gjøre alt på nytt uken etter. «Det er en manuell prosess. Det tok meg omtrent 16 til 18 timer hver uke. Jeg kan ikke fortsette å gjøre dette manuelt og samtidig gjøre feil, for hver gang et menneske håndterer noe i stor skala, vil det være utsatt for feil.» Derfor vibekodet han en komplett nettapplikasjon som nå automatiserer det meste av arbeidet. Sammenligningen med det som kom før, er slående: «For et par år siden måtte jeg samarbeide med en webutvikler, en UX-designer, en produktsjef, en teknisk programleder og mange andre personer for å bygge et produkt basert på konseptet mitt. I dag har jeg ingen flaskehalser, og på to uker bygget jeg en applikasjon. En lignende applikasjon som jeg tidligere støttet, tok to år.»
Michael Gold, fraksjonert leveransesjef og grunnlegger av Gold Project Management, bygget et tilpasset CRM-system i Lovable som kobler seg til selskapets nettsted og integreres med Fireflies, verktøyet hans for møtetranskripsjon. Hver morgen går han og forretningspartneren gjennom salgspipelinen på en samtale, og når de er ferdige, gjør ett enkelt knappetrykk resten: «Jeg kan bare klikke på oppdater fra transkripsjon, så går den automatisk gjennom transkripsjonen og tildeler det til riktig person. Og den legger til notater og oppgaver og tildeler dem til oss.» Siden har han tatt vibekoding videre og samarbeidet med en utvikler om å bygge et komplett verktøy for automatisering av profesjonelle tjenester, som nå nærmer seg en offentlig lansering.
Harry Max, en fraksjonert leder og forfatter av Prioritering, så forretningspartneren sin vibekode en avansert plattform for prioritering fra grunnen av over ni måneder ved hjelp av Claude Code – uten utviklingsteam og uten ekstern investering. Sammenligningen Harry ga mellom før og nå, var vanskelig å overse: «På ni måneder bygget én person noe som var like sofistikert som programvaren vi bygget for 20 år siden med 14 personer og 2 millioner dollar.»
På ni måneder bygget én person noe som var like sofistikert som det vi bygget for 20 år siden med 14 personer og 2 millioner dollar.
Den ærlige sannheten: Det går ikke alltid knirkefritt
Alle jeg snakket med, var oppriktig begeistret for vibekoding. De var også, uten unntak, ærlige om når det blir vanskelig.
Den vanligste erfaringen ser ut til å være en variant av det Michael beskrev: «Du kan gå fra null til 60 raskere enn noen gang, men jeg synes fortsatt at det er virkelig krevende å gå fra 60 til 100. Hvis du virkelig vil få det helt i mål, trenger du fortsatt ekspertise.»
Harry Max pekte på en mer subtil felle – tiltrekningen ved selve prosessen. «Det er veldig fristende å fortsette å endre ting, og hver gang du endrer noe, går noe i stykker. Og du oppdager ikke hva som er ødelagt, med mindre du virkelig har tenkt gjennom hvordan du skal håndtere kvalitets- og testprosessene dine.» Han kom også med en tankevekkende kommentar om resultater som ser bedre ut enn de er: «At du kan vibekode ting som ser vakre ut, betyr ikke at de er nyttige. Det betyr ikke at de fungerer. Det betyr ikke at de løser et problem, men de ser flotte ut.»
[Med vibe-programmering] kan du gå fra null til 60 raskere enn noen gang, men jeg synes fortsatt at det å gå fra 60 til 100 er virkelig utfordrende.
Aniket Ghonge lærte en av de vanskeligere leksjonene på den harde måten. I iveren etter å fortsette å bygge funksjoner hoppet han over et teststeg som kostet ham dyrt: "Jeg mistet plutselig 50 % av arbeidet mitt, og det skremte meg. Det var min harde leksjon. Du må teste en funksjon i et testmiljø før du gjør en endring i et produksjonsmiljø." Han kom seg videre, men det tok flere timer – og førte til betydelig uro.
More Articles
- 3 alternativer til å erstatte dine menneskelige prosjektledere med KI-agenter
- Prosjektleder og underviser med kunstig intelligens deler en enkel arbeidsflyt for kunstig intelligens som fundamentalt endrer hvordan prosjekter drives
- Verktøystakken jeg ville brukt hvis jeg startet et byrå
- De praktiske KI-arbeidsflytene som brukes av leveransesjefen i et Asana-implementeringsbyrå
- Det ene prosjektstyringsverktøyet jeg aldri ville gitt opp
Risikoene ikke-tekniske utviklere ikke alltid ser komme
Entusiasmen blant brukerne er ekte, men det samme gjelder de strukturelle risikoene – og det var her jeg bestemte meg for å få inn Tim for å få en ærlig teknisk vurdering.
Da jeg spurte Tim hva han syntes om at prosjektledere bruker vibe-programmering til å lage sine egne verktøy, handlet perspektivet hans mindre om å fraråde folk å gjøre det og mer om å sørge for at de går inn i det med åpne øyne. Hans viktigste observasjon var: "Generelt sett kan du ikke anta at den agentbaserte programmereren vil fortelle deg det du ikke vet at du ikke vet."
Dette gjelder særlig skalerbarhet. "Generelt sett er ingen vibe-programmerte prosjekter skalerbare, hovedsakelig fordi du ikke ber agenten om å ta hensyn til skalering. Ikke-utviklere ber sannsynligvis ikke engang om ting som feilhåndtering." Et vibe-programmert verktøy kan fungere perfekt for fem brukere og stille bryte sammen ved femti – og personen som bygde det, har kanskje ingen måte å vite hvorfor på.
Generelt sett er ingen vibe-programmerte prosjekter skalerbare, hovedsakelig fordi du ikke ber agenten om å ta hensyn til skalering.
Så har vi spørsmålet om ansvarlighet, som blir særlig aktuelt når verktøyet blir populært i en organisasjon. "Hvis du bygger noe som folk er avhengige av, må det bli mer enn bare et vibe-programmert prosjekt; det må overtas av folk som jobber profesjonelt med dette og vet ting du ikke engang vet at du bør spørre om." Fisher beskrev et konkret scenario som føltes svært realistisk: "Hvis noen spør denne personen: «Er informasjonen jeg får fra verktøyet ditt, korrekt?» og personen ikke vet nok om hvordan det fungerer fordi de lot agenten gjøre alt arbeidet, kan de ikke svare på spørsmålet."
Selv Dixie Willard, som aktivt bygger verktøy hun har tro på, innrømmet uroen som ligger under begeistringen: "Det er det som alltid gjør meg nervøs, for jeg tenker: Hva om det finnes et sikkerhetsproblem?"
Det er verdt å merke seg at sikkerhetssårbarheter – eksponerte API-nøkler, usikrede brukerdata og verktøy som utilsiktet håndterer personopplysninger uten tilstrekkelige sikkerhetstiltak – er blant de vanligste fallgruvene Tim trakk frem i samtalen vår. Dette er ting en utvikler håndterer rutinemessig, men som en vibe-programmerer ganske enkelt ikke nødvendigvis vet at må tas tak i.
Så, bør du prøve det?
Det ærlige svaret er: Det kommer an på hva du bygger, og hva du planlegger å gjøre med det.
Vibe-programmering er virkelig kraftfullt som et verktøy for prototyping og kommunikasjon. Hvis du har en idé, vil teste om den fungerer eller trenger å vise interessenter noe konkret før du investerer i faktisk utvikling, er mulighetene store og risikoene håndterbare. Tim formulerer det godt: Hovedverdien ligger i å komme forbi fasen «kommer dette til å fungere?» raskere enn det noen gang tidligere har vært mulig.
Det blir mer komplisert når et vibe-programmert verktøy går fra å være en prototype til noe folk er avhengige av. På det tidspunktet begynner hullene innen skalerbarhet, feilhåndtering og sikkerhet – som det var greit å ignorere i starten – å få betydning, og personen som bygde det, har kanskje ikke det tekniske ordforrådet som trengs for å vite hvor de skal lete.
Brukerne i denne artikkelen håndterer denne balansegangen i sanntid. Noen overlater arbeidet til utviklere. Noen lærer underveis. Alle finner ut, én forespørsel om gangen, nøyaktig hvor grensene for denne teknologien går.
For prosjektledere er muligheten reell – men det samme gjelder ansvaret som følger med. Den gode nyheten er at det å vite hva du ønsker, stille de riktige spørsmålene og forstå når du bør hente inn hjelp, er ting dyktige prosjektledere allerede gjør. Vibe-programmering er på sitt beste bare en ny kontekst for de samme ferdighetene.
Vil du ha flere innsikter som dette? Opprett en gratis DPM-konto for å høre fra flere eksperter som disse.
