Vibekoding for prosjektledere: 6 vibekodede prosjekteksempler laget av ekte prosjektledere
Vibekoding: Prosjektledere bruker instruksjoner på naturlig språk i KI-verktøy for å bygge skreddersydde programvareløsninger.
Nisjeløsninger: Vibekoding gjør det mulig å lage spesialiserte verktøy for bestemte bransjeproblemer som standardprogramvare ikke løser.
Effektivitet: KI-bygde applikasjoner reduserer tidsbruk og ressursbehov betydelig sammenlignet med tradisjonell programvareutvikling.
Kommersielt potensial: Vibekoding utvides fra interne verktøy til å omfatte markedsføringsklare produkter for betalende kunder.
Viktigheten av testing: Det er avgjørende å teste nye funksjoner grundig før de tas i produksjon, slik at applikasjonens funksjonalitet opprettholdes.
Prosjektledere bruker karrieren på å kartlegge arbeidsflyter, identifisere mangler og omsette en rotete virkelighet til ryddige prosesser. Det viser seg at akkurat dette er ferdighetene du trenger for å bygge programvare – selv om du aldri har skrevet en eneste kodelinje i hele ditt liv. Vibekoding, altså å bygge funksjonelle applikasjoner gjennom instruksjoner på naturlig språk til KI-verktøy, gir prosjektledere noe de aldri har hatt før: muligheten til å bygge verktøyet de faktisk trenger, i stedet for å nøye seg med det som nesten passer.
Bruksområdene nedenfor kommer fra fagfolk på tvers av bransjer som gjør nettopp dette – noen bygger interne verktøy for å eliminere manuelt arbeid, andre bygger produkter rettet mot kunder, og noen står på terskelen til å lansere en fullt ut vibekodet plattform i markedet.
Verktøy for arbeidsomfang (interiørdesign og drift)
For Dixie Willard, grunnlegger og sjefstrateg for prosjekter i Poised & Plumb, var beslutningen om å vibekode ikke drevet av nysgjerrighet eller eksperimentering. Den var drevet av at det hun trengte, rett og slett ikke fantes. Willard gir råd til interiørdesignere og relaterte tjenestebedrifter, og hjelper dem med å evaluere programvare, bygge prosjektarbeidsflyter og redusere friksjon i driften. Da hun lette etter et verktøy som kunne hjelpe designere med å lage et arbeidsomfang på stedet under en kundekonsultasjon, fant hun ingenting. «Det finnes ikke», sa hun. «Og det er mange ting designere kunne hatt nytte av, som ganske enkelt ikke finnes.»
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
Det finnes ikke [et verktøy for arbeidsomfang]. Og det er mange ting designere kunne hatt nytte av, som ganske enkelt ikke finnes.
Så hun bygget et selv. Verktøyet hun utvikler nå, er en mobilvennlig nettapp som skal brukes i sanntid under den første kundesamtalen. Willard beskriver det som «noe du kan ha på et nettbrett eller en telefon når du skal i den første konsultasjonen. Mens dere snakker sammen, krysser du av for ting underveis, og når dere er ferdige, har du et godt utarbeidet arbeidsomfang uten å måtte ta notater.»
Et annet prosjekt hun arbeider med, løser et annet driftsmessig problem: en kalkulator for fortjenestemargin, utviklet spesielt for hvordan designere priser og legger påslag på produkter for kunder. Igjen var grunnen til at hun bygget den selv den samme – «Det finnes ikke. Det finnes rett og slett ikke.»
Situasjonen til Willard illustrerer et mønster som stadig dukker opp blant prosjektledere som har begitt seg ut på denne veien. Jo mer nisjepreget bransjen din er, desto større er sannsynligheten for at det ikke finnes et standardverktøy som er utviklet for akkurat ditt problem. Som hun sa: «Jeg tror nisjepregede bruksområder sannsynligvis er den viktigste grunnen til å vibekode verktøy. Det gjør livet så mye enklere.»
Jeg tror nisjepregede bruksområder sannsynligvis er den viktigste grunnen til å vibekode verktøy. Det gjør livet så mye enklere.
Dashbord for fraktetterspørsel (logistikk for store virksomheter hos Amazon)
Aniket Ghonge, senior forsyningskjedesjef i Amazon, brukte 16 til 18 timer hver uke på å generere etterspørselsplaner manuelt for nye transportører som ble tatt opp i Amazons transportørnettverk. Arbeidet innebar å hente data fra flere kilder, gjøre beregninger for hundrevis av kontoer og utarbeide ukentlige prognoser – det eksisterende CRM-systemet var ikke utstyrt for å håndtere noe av dette.
«CRM-teknologien jeg jobbet med, hadde ikke funksjonene jeg trengte», forklarte Ghonge. «Jeg trengte noe som kunne hjelpe meg med å automatisere arbeidet, gi meg en måte å sammenligne flere kilder på og deretter generere en endelig etterspørselsplan for de nye transportørene våre. Derfor bygget jeg dette intelligente innføringsdashbordet. Det reduserte 18 timers arbeid til mindre enn en time for tusenvis av kontoer.»
Jeg bygde et intelligent onboarding-dashbord. Det reduserte 18 timers arbeid til under en time for tusenvis av kontoer.
Det Ghonge bygde, er en komplett webapplikasjon — distribuert inne i Amazons nettverk, med Amazons sikkerhetsgjennomgang, tillatelser på brukernivå, revisjonslogging og et datalag støttet av S3 — utelukkende ved hjelp av agentiske KI-verktøy. Han er ikke programvareingeniør. Bakgrunnen hans er innen mekanisk og industriell ingeniørkunst, med noe SQL-erfaring han har tilegnet seg på jobb. Men det han hadde lært gjennom mange år med å skrive kravdokumenter for teknologiteam, ble direkte overført til hvordan han gikk frem for å bygge med KI: forklar konseptet tydelig, beskriv hva du trenger, og la systemet bygge det.
Forskjellen i hastighet sammenlignet med tradisjonell utvikling var slående for ham. «For et par år siden måtte jeg samarbeide med en webutvikler, en UX-designer, en produktsjef, en teknisk programleder – mange personer for å bygge et produkt», sa Ghonge. «I dag har jeg ingen hindringer. I løpet av to uker klarte jeg å bygge en applikasjon. En tilsvarende applikasjon jeg støttet, tok to år.»
Den ene lærdommen Ghonge fikk erfare på den harde måten, var en som dukket opp i nesten alle samtalene til denne artikkelen: test før du sender noe til produksjon. Halvveis i utviklingen slettet en ny funksjon halvparten av funksjonaliteten i applikasjonen hans. «Jeg bygde og fortsatte å bygge hver dag», sa han. «Men på et tidspunkt mistet jeg plutselig 50 % av arbeidet mitt, og det skremte meg litt. Det var den harde lærepengen min. Du må teste en funksjon i et testmiljø før du gjør en endring i et produksjonsmiljø.»
På et tidspunkt mistet jeg plutselig 50 % av arbeidet mitt, og det skremte meg litt. Det var den harde lærepengen min.
Det tok fire timer med instruksjoner å gjenopprette det som hadde gått tapt, og siden har han ikke hoppet over testtrinnet. Prøving og feiling er en del av det å lære enhver ny ferdighet — og for et økende antall prosjektledere er vibekoding nettopp det.
Tilpasset CRM-system og verktøy for generering av potensielle kunder
Michael Gold, grunnlegger og fraksjonert leveransesjef i Gold Project Management, kom til vibekoding gjennom en enkel kost–nytte-beregning. Han betalte for et CRM-system som kostet ham mer enn det var verdt, og tenkte at han kunne bygge noe bedre selv. «Jeg bygde mitt eget CRM ved hjelp av Replit fordi jeg brukte Close, og det kostet meg 100 dollar i måneden.»
CRM-systemet han bygde, kobler seg til nettstedet hans og inkluderer et verktøy for kvalifisering av potensielle kunder som han er spesielt stolt av: «Jeg laget en helsesjekkdiagnose, slik at personer som går til kontaktskjemaet mitt, kan svare på noen spørsmål og få en rapport.» Det er i praksis en selvdiagnose for potensielle kunder, som fylles direkte inn i salgspipelinen hans.
Dette prosjektet førte til et mye større prosjekt, men mer om det senere.
Assistent for prosjektledelse
Ryan Gilbreath, teknisk prosjektleder hos RTS Labs, valgte en annen tilnærming — han bygde et personlig verktøy for å gjøre sitt eget daglige prosjektlederarbeid raskere og mindre kognitivt krevende. Gilbreath beskriver det slik: «Jeg har laget en prosjektlederassistent ved hjelp av Google AI Studio, og den har en talemodus. Så hvis jeg oppsummerer og bare trenger å tømme hodet, kan jeg slå den på. Jeg kan si: Hei, dette er det som skjedde i løpet av dagen min for XYZ-prosjekter, og så kan den lage en rapport for meg.»
Jeg har laget en prosjektlederassistent ved hjelp av Google AI Studio, og den har en talemodus. Så hvis jeg oppsummerer og bare trenger å tømme hodet, kan jeg slå den på.
Talemoduskomponenten er det som gjør verktøyet virkelig nyttig — friksjonen ved å sette seg ned for å skrive en statusoppdatering forsvinner når du kan snakke gjennom dagen din og få generert en rapport basert på det. Gilbreaths team har også tatt i bruk et separat vibekodet verktøy: «Jeg har en kollega som faktisk laget en generator for medarbeiderstøtte gjennom vibekoding, som vi alle bruker nå.»
Kommersielt klar programvare: Å ta det ett skritt videre
De mest ambisiøse historiene om vibekoding handler ikke om interne verktøy – de handler om produkter. Både Michael Gold og Harry Max, en leder på deltid og forfatter av Prioritering, har gått langt utover personlige produktivitetsverktøy og begynt å bygge programvare for betalende kunder.
AI-drevne profesjonelle tjenester
Etter å ha brukt mye tid på å vibekode interne verktøy, gikk Gold videre til å vibekode prototypen for en helt ny plattform for automatisering av profesjonelle tjenester, som han og forretningspartneren har til hensikt å lansere i markedet. «Vi gikk videre og bygde et verktøy for automatisering av profesjonelle tjenester som vi ønsker skal være en utfordrer i markedet. Den første prototypen ble bygget med Lovable, og selv den var ganske bra.»
Vi gikk videre og bygde et verktøy for automatisering av profesjonelle tjenester som vi ønsker skal være en utfordrer i markedet. Den første prototypen ble bygget med Lovable, og selv den var ganske bra
For Gold innebar overgangen fra personlig prosjekt til kommersielt produkt at han måtte forholde seg til begrensningene ved vibekoding. «Fordi dette er en app rettet mot forbrukere, hentet vi inn en teknisk person. Jeg følte at jeg kunne ta den til et visst nivå, men når folk betaler for den og bruker den i stor skala, ville det vært altfor skummelt å ha ansvaret for den som en ikke-teknisk person.»
Ettersom Gold også er sluttbrukeren som verktøyet er utviklet for, kan evnen hans til å utforme det nøyaktig slik han ser det for seg før han overlater det til en mer teknisk samarbeidspartner for videreutvikling, være det som gjør samarbeidet – og til syvende og sist produktet – så mye sterkere.
AI-drevet programvare for prioritering
Harry Max’ historie nærmer seg kommersiell vibekoding fra en annen vinkel – ved å bruke en eksisterende intellektuell ressurs som grunnlag. Forretningspartneren hans bygde en SaaS-plattform for virksomheter til konsulentvirksomheten deres ved å behandle Max’ utgitte bok om prioritering som produktkravdokumentet.
«Han tok boken min, som heter Prioritering, og sa: ‘Kan jeg trekke ut metoden her og i praksis bygge den inn i en plattform?’ I stedet for å få kundene våre til å lese en bok og lede dem gjennom økter ved en tavle, kan vi gå inn med en plattform som gjør det mulig for oss å gjøre en mye bedre og større jobb med mindre arbeid.»
Han [forretningspartneren hans] tok boken min, som heter Prioritering, og sa: ‘Kan jeg trekke ut metoden her og bygge den inn i en plattform?
Max, som tidligere har vært gjennom den tradisjonelle programvareutviklingsprosessen, undervurderer ikke omfanget av det én enkelt ikke-ingeniør bygde på ni måneder. «På ni måneder, med én person, har han bygget noe som er like sofistikert som det vi bygde for 20 år siden med 14 personer og 2 millioner dollar. Og han gjorde alt på egen hånd.» Denne uttalelsen viser hvor stor innvirkning vibekoding har – og kan få – på utallige bransjer og arbeidsflyter.
Vibekoding og løftet om bedre, tilpassede arbeidsflyter
Vibekoding hjelper ikke bare prosjektledere med å bygge arbeidsflyter som får arbeidet til å gå raskere. I noen tilfeller hjelper det dem med å bygge ting som aldri har eksistert før – verktøy som er for nisjepregede til at noe programvareselskap har brydd seg om å lage dem, for bransjer som er for spesifikke til å ha tiltrukket seg riktig utvikler på riktig tidspunkt. For prosjektledere som arbeider i disse mellomrommene, har terskelen mellom «jeg skulle ønske dette fantes» og «jeg bygde dette» aldri vært lavere.
Koden er ikke den vanskelige delen. Det er det å vite nøyaktig hva du trenger – og å være disiplinert nok til å teste før du ødelegger alt. For prosjektlederne som allerede gjør dette, er det en forskjell de raskt har forstått. For dem som nettopp har begynt, kan det være det viktigste å vite før de setter i gang.
Vil du ha flere innsikter som disse? Registrer deg for en gratis DPM-konto for å høre fra flere eksperter som disse.
