The turtle wins the race: spec-driven development med AI-agenter

En oppfølger til "AI i utviklingsteam: nytte, fallgruver og refleksjoner"

I september skrev jeg om erfaringene mine med AI i utviklingsteam. Jeg delte noen refleksjoner rundt agenter, eierskap, flyt og arbeidsglede og en sunn dose skepsis til hvor produksjonsklar den agentgenererte koden egentlig var. Mye har skjedd siden den gang.

Photo by Igor Omilaev on Unsplash‍ ‍

Noe endret seg

Rett før jul ble det virkelig fart på sakene. For meg var det Opus 4.5 og Claude Code som endret alt. Plutselig var agentic coding så effektivt og så presist at jeg måtte tenke helt nytt. Skepsisen til kvaliteten på det agentene produserer? Den er borte. Problemene som gjenstår handler nå i mye større grad om brukerfeil enn om verktøyets begrensninger.

Gjennom julen og vinteren brukte jeg mye av fritiden på å utforske nye arbeidsmetoder. Som mange andre satte jeg i gang en haug med greenfield-prosjekter for å teste grensene. Og det var nettopp her det gikk opp et lys for meg.

Mer output er ikke alltid bedre

Når man plutselig kan produsere ti ganger raskere enn før, er det fristende å bare kjøre på. Men det jeg oppdaget var at det ikke er produktivt å bare jobbe som før med høyere output. Da ender man i praksis opp med masse WIP (work in progress) og en flaskehals der mennesker skal verifisere og godkjenne alt som er laget. Feature etter feature, klar til å shippes, men køen for gjennomgang vokser fortere enn teamet klarer å følge opp.

10x output er ikke et mål i seg selv.

Snu prosessen på hodet

De siste par månedene har jeg derfor tatt i bruk spec-driven development. I stedet for å prompte frem og tilbake i en coding-sesjon, eller vibe nye features rett ut av løse lufta, bruker jeg nå mer tid i forkant på å lage menneskelig lesbare spesifikasjoner.

Specen skriver jeg sammen med en agent i en dedikert planning-sesjon. Prosessen er overraskende behagelig og effektiv. Resultatet er en markdown fil (feature_navn.md) som legges i en `specifications/`-mappe i prosjektet.

Så kommer det viktigste: jeg leser specen nøye. Fikser feil, fyller inn mangler, og sørger for at den beskriver det som faktisk skal bygges. Først da starter jeg en ny agent-sesjon med foretrukket modell og setter i gang implementasjonen. Til slutt lages en co-authored commit som tydeliggjør at endringen er spec-driven og kodet av agenten.

Skilpadden vinner løpet. Ikke hast fremover med en coding-sesjon, bruk heller god tid på å lese specen og gjøre den riktig. Det er mye mer effektivt, og etter min mening langt mer behagelig, enn å prompte frem og tilbake i en implementasjonsdialog.

Hva vi vinner på dette

Denne måten å jobbe på adresserer flere av bekymringene jeg tok opp i forrige artikkel.

Eierskap forankres i teamet. Specen er lesbar for alle, og den gir en tydelig plan for hva som skal gjøres og hvorfor. Det er ikke lenger bare én utvikler pluss en agent som vet hva som foregår, hele teamet kan lese, diskutere og ta eierskap til løsningen.

Den kognitive lasten ved review blir lavere. Når jeg allerede har en detaljert oversikt over hva og hvordan en feature skal lages, er det langt enklere å gå gjennom de faktiske kodeendringene etterpå. Jeg vet hva jeg ser etter.

Spesifikasjonen committes sammen med koden og fungerer som dokumentasjon. Den blir arkeologisk materiale, noe fremtidige utviklere kan grave frem for å forstå ikke bare hva som ble bygget, men hva intensjonen var.

Det store bildet

Selv om det alltid har vært viktig, tror jeg de som nå virkelig kommer til å briljere er de som er gode til å se det store bildet. De som kan ta til seg input fra flere nivåer i organisasjonen, fra forretningsbehov og brukerperspektiv til teknisk arkitektur, og omsette det til funksjonalitet.

Når agenten håndterer stadig mer av implementasjonsdetaljene, blir evnen til å forstå hva som skal bygges og hvorfor den virkelig verdifulle ferdigheten. Det er her menneskelig dømmekraft, erfaring og kommunikasjon gjør forskjellen.

Og utviklergleden?

I forrige artikkel skrev jeg om at agentic coding brøt flyten min og reduserte arbeidsgleden. Det har endret seg. Med spec-driven development har jeg klart å få tilbake følelsen av flyt og eierskap. Prosessen føles meningsfull. Jeg tenker, planlegger, og kvalitetssikrer, i stedet for å småkrangle med en språkmodell.

Det hender fortsatt at jeg plukker noen oppgaver og koder for hånd. Men det skjer mye sjeldnere enn før, og kanskje mest av vane, eller for å holde på nostalgien. Jeg tror det forsvinner helt om ikke så lenge, men det er ikke lett å spå fremtiden nå for tiden.

Bruk tiden der det teller

Budskapet mitt er det samme som sist, men med en viktig tilleggsdimensjon: nå som vi kan produsere raskere enn noensinne, bør vi ikke bare bruke den frigjorte tiden til å produsere enda mer. Vi bør bruke den til å lage bedre løsninger. Til å lese. Til å øke kunnskapen vår. Til å bygge godt samhold med de vi jobber sammen med.

Skilpadden vinner i det lange løp.