De største feilene i ethvert prosjekt gjør man gjerne de første fem minuttene, fordi man tar forutsetninger og sementerer misforståelser man ikke vet at man har. AI og vibe coding kan kanskje gjøre noe med det.

I Comunita-nettverket har vi som regel møter hos en bedrift, der temaet er noe verten ønsker hjelp med. Men i neste møte har vi endret dette, og gjort et lite eksperiment: To bedrifter har gått sammen om å utforske noe nytt, og rapportere erfaringene.

Den ene bedriften har et problem: Bedriften leverer assistanse til kunder, både sine egne og for ulike partnere, hver av dem med ulike avtaler om hva slags ytelse sluttkundene kan forvente.

Den andre bedriften er et softwarehus som leverer ulike typer IT-tjenester, og som står overfor et teknologiskifte (fra tradisjonell til AI-støttet systemutvikling) som kommer til å ha nokså store konsekvenser for både hvordan man utvikler systemer for kunder og hvordan man tar betalt for dem.

Og hva er det vi har utforsket? Jo, vibe coding.

Vibe coding

Innenfor IT kan vi produsere buzz words fort, men vibe coding må være en eller annen rekord: Andrej Karpathy, en av grunnleggerne av OpenAI, introduserte begrepet for 11 måneder siden, og nå er det altså noe som brukes av helt vanlige bedrifter.

Vibe coding betyr at man skriver dataprogrammer ved å fortelle en språkrobot (eller, om du vil språkmodell) hva slags program man vil ha, hvorpå roboten skriver programmet for deg. Tanken er at alle skal kunne programmere – forøvrig noe som har vært et mål for enhver softwareleverandør siden programvare ble en vare: COBOL, av alle ting, var ment som noe ikke-programmerere skulle kunne gjøre.

Uansett: Hva tilfører Vibe coding som man ikke kunne gjøre før?

Det kanskje viktigste momentet er at man kan bruke svært kort tid (i dette tilfellet, en utvikler og ca. 25 timer) på å utvikle en prototype (eller, i alle fall, POC) som er god nok til at man har en omforent oppfatning av hva systemet skal gjøre og hva resultatet, sånn nogenlunde, kommer til å se ut som. Så liten ressursinnsats i en tidlig fase gjør at man slipper å spesifisere systemer før man begynner – utover korte møter – og man slipper å gjøre feil fordi folk forholder seg til en dynamisk beskrivelse i stedet for en mer statisk spesifikasjon.

Et annet aspekt er at diskusjonen om hva man skal gjøre føres mellom folk som er høyt nok oppe i organisasjonen til å ha overblikk – og foreslå løsninger ut over ren systemdesign. For å ta en parallel fra arkitektur: Snøhætta, et arkitektfirma med en rekke enestående bygninger på merittlisten, tar ikke oppdrag fra bedrifter med mindre bedriftsledelsen setter seg med med arkitektene en hel dag, der de klipper og limer og byggeklosser seg frem til hva slags bygg man skal ha. Dette gjør at mange misforståelser blir ryddet av veien tidlig – “å, var det det du mente” – mens de fremdeles er svært billige å korrigere, både hva gjelder penger og støtte mansjetter.

Om å velge riktig nivå

Nesten alle systemer som lages, må forholde seg til tre ulike dimensjoner: Grensesnitt, logikk og datastrukturer. (Også kalt “UI, forretningslogikk og dataaksess” hvis man kommer fra tradisjonell IT-utvikling, eller Model-View-Controller hvis man har studert informatikk.) Grensesnittet handler om hvordan systemet skal se ut og hvordan det passer inn i forhold til andre systemer, inkludert det mennesket som skal bruke det. Logikken handler om hvilke regler og rammebetingelser som gjelder. Datastrukturer handler om hvordan dataene er organisert og hvordan man kan komme til dem.

Et vanlig prosjekt ville måttet ha konstruert et grensesnitt (det begynner å bli mer og mer standardisert), legge inn forretningsregler (“ikke tilby kunder en tjeneste som ikke er i kontrakten deres”) og datatilgang (kanskje ved å konstruere en matrise av ulike tjenester og ulike kontrakter, og slå opp i den omtrent som indeksen til en søkemotor.) Ved å bruke vibe coding får man et kjapt system, der man bruker en variant av RAG til å lese kontraktene og tolke dem. Rent logisk vil dette si at brukergrensesnittet (og muligens grensesnitt mot andre systemer) blir formulert i naturlig språk (“hvilke rettigheter har denne kunden”), forretningslogikken – i alle fall i prinsippet – uttrykt ved en “reward function” der språkroboten belønnes for riktige svar, og datatilgangen ordnet ved at språkroboten tolker kontraktene opp mot et multidimensjonelt semantisk koordinatsett.

Hovedfordelen med vibe coding og RAG er hastighet, hovedulempen er, som med så mange ting der språkroboter er involvert, mangelen på presisjon. En annen utfordring er oppdatering – hva skjer om det kommer en ny partner og, med det, en ny kontrakt? Da må man kanskje gjøre hele tolkningsøvelsen om igjen – og kan risikere at systemet ikke er konsistent over tid.

Suksesskriterier

Så langt har vi sett at vibe coding og språkroboter fungerer utmerket i en testfase – kan vi bygge et kjapt system, sjekke ut et konsept kjapt og billig, så vi blir enige om hva vi vil ha. Dette er ikke ulikt 3D-printing, som startet som noe man brukte til å bygge prototyper av bygninger, maskinkomponenter og annet. Etterhvert har 3D-printing blitt en produksjonsteknikk – kan vibe coding og språkroboter gå den samme veien?

Det finnes faktisk en måte å gjøre dette på uten å måtte manuelt sjekke ut den underliggende logikken i systemet – og det involverer god gammeldags statistikk og eksperimentering. Man kan ganske enkelt teste systemet opp mot det man gjør nå – og se om kunderådgivere med dette systemet til hjelp tar bedre beslutninger enn kunderådgivere som opererer alene.

Statistisk sett er dette riktig måte å gjøre det på – samtidig vil jeg tro at en ansvarlig leder ville følt seg nokså nervøs ved oppstart. Vi har en naturlig tendens til å vurdere nye ting ikke opp mot hva man allerede gjør – ofte manuelle prosesser fulle av ikke-innrømte feil – og i stedet insistere på at ethvert nytt system skal være 100% sikkert, feilfritt og etterrettelig.

Som så meget annet mennesker gjør, er ikke dette mulig, og heller ikke ønskelig. Som Daniel Kahneman har skrevet i sin eminente bok Thinking, Fast and Slow: Et menneske som skal gjennomvurdere alle beslutninger i stedet for å være følelsesstyrt, vil aldri klare å ta noen beslutninger. Slikt sett er den effektive omtrentligheten til en språkrobot kanskje en mulig løsning på den backlog’en enhver organisasjon med gamle systemer sliter med.

Og dialogen før man starter vil i alle fall hjelpe med de feilene man gjerne gjør i løpet av de første fem minuttene.