AI-utvikling i praksis: Hva betyr det for din bedrift?

I dag fikset jeg tre bugs i Kiip. Det tok meg til sammen 15 minutter. (1) Jeg forklarte feilene til kodeagenter fra telefonen min, med tale, 2 min. (2) Jeg gikk gjennom de foreslåtte kodeendringene fra hver av agentene. En av dem kunne jeg inkludere som en del av kodebasen med en gang. De to andre ga jeg tilbakemeldinger på, 5 min. (3) Jeg sjekket de to forbedrede kodeendringene; begge var bra nå og ble inkludert som en del av kodebasen, 2 min. (4) Jeg sjekket manuelt at alt funket som det skulle og oppdaterte produksjon, 5 min.

For noen år siden måtte vi, for hver feil, lagt til tid for å finne feilen, rette den, teste feilrettingen og at den ikke ødela noe annet, og ikke minst vente på en kontrollør (en annen utvikler) for å se over koden og gi tilbakemeldinger.

Hva har forandret seg?

Vi kan dele prosessen inn i 5 steg:

finne feilen,
skrive koden som fikser feilen,
automatisk verifisere at feilen er rettet og at ingen nye feil er introdusert,
manuell kodekontroll og kvalitetssikring og
legge den nye koden i produksjon (som regel automatisert allerede).

Steg 1, 2 og 3 tar mye ressurser og består av døtid i form av å vente på prosesser som blokkerer stegene etter. Dermed kan selv små kodeendringer kreve mye ressurser.

Dersom arbeidsflyten for samhandling mellom agent og utvikler settes opp på riktig måte kan steg 1-3 outsources til en AI-agent, og utvikleren kan ta rollen som kontrolløren som ser over koden og gir tilbakemeldinger. Dermed blir kontrollørjobben, som tidligere bestod av rundt 15% av utviklerens tid og fokus, nå hele jobben.

Rent tidsmessig er det ikke sikkert at AI-agenten gjør jobben like fort eller like bra som en god utvikler som kjenner kodebasen godt. Derfor kan kodeendringer nå måtte gå flere ganger gjennom tilbakemelding-forbedringsloopen før koden kan inkluderes i kodebasen. Men samtidig sparer vi inn hele jobben til utvikleren som hadde feilrettingen som hovedfokus. Husk også at de fleste bedrifter ikke trenger perfekt kode. De trenger kode som løser problemet.

Hva blir resultatet i dag?

Utviklere får frigitt mye tid og fokus. Det som tidligere ville hatt mesteparten av dagens fokus og vært dagens hovedaktivitet er flyttet ut i bakgrunnen.

Hvordan skal dette tas ut i gevinst for bedrifter? Skal det ansettes færre utviklere samtidig som produktiviteten beholdes, bør man øke farten eller utvide omfanget av det som utvikles? Her er noen av dagens direkte konsekvenser.

IT er ikke lenger en isolert bestillingsavdeling

I stedet for å sende bestillinger til en IT-avdeling, vil rollen som utvikler knyttes mer inn i forretning, og kompetanse i skjæringspunktet mellom teknologi og forretning blir viktigere. Produktutviklere i stedet for programvareutviklere. Dette betyr samtidig slutten på gigantiske utviklingsteam og tunge koordineringsprosesser mellom utviklere.

Outsourcing mister sin verdi

Det er allerede mange bedrifter som outsourcer akkurat den delen av arbeidet som AI-agenter er gode på. Jeg mener at denne typen outsourcing, med en kontrollør in-house og kodingen er outsourcet, er den mest direkte prosessen som ikke lenger gir mening. Så lenge de rette AI-støttede utviklingsprosessene kommer på plass. Jeg ser på outsourcing av IT-konsulenter som en av de områdene som kommer til å bli hardest negativt rammet av skiftet vi nå står i.

Fremtiden

Det kan godt hende at kontrollørstegene i framtiden kan overtas av AI på en ansvarlig måte. Når dette skjer, blir utviklernes kompetanse overflødig. Man trenger ikke å vite hvordan systemet fungerer under panseret lenger.

Jeg synes en god analogi til dette, som kanskje kan vise oss hva som skjer fremover, er foto. Før var det kun fotografer som kunne ta bilder, og prosessen bestod i stor del av kjemi, teknikk og etterarbeid. I dag har vi smarttelefoner og alle kan ta bilder, uten noe spesiell kunnskap. Alle ble fotografer. Men verdien flyttet seg. Fra teknisk utførelse til: å vite hva som er verdt å fotografere, fortelle en historie, velge riktig øyeblikk. På samme måte flytter verdien seg fra å skrive kode til å vite hva som bør bygges. Alle blir utviklere når koden blir usynlig.

Neste gang du ansetter, ikke se etter dem som er gode til å kode. Se etter dem som er tekniske, men også forstår forretningsproblemet, som har en forståelse av hva som er mulig og kreativiteten til å finne ut hva som skal bygges.