Spesifikasjonsfellen: Hvorfor AI-koding trenger krystallklare krav

Spesifikasjonsproblemet er gammelt – AI bare avslører det

I agentbasert utvikling finnes en brutal sannhet som alltid har ligget der: det som bremser deg, er ikke kodingen. Det er å bestemme hva du egentlig skal kode.

Fred Brooks pekte på dette allerede i 1986 i No Silver Bullet. Han så at store fremskritt som objektorientert design eller strukturerte metoder bare ga små gevinster. De løste accidental complexity – rotet rundt selve skrivingen. Men essential complexity – den ekte utfordringen med å tenke klart – sto igjen. I software engineering handler det meste om spesifikasjonsfasen: å samle interessenter, veie alternativer og definere krav for noe som ikke finnes ennå.

Nå lar vi AI generere kode, og folk tror spesifikasjonsproblemet forsvinner med det. Feil. Det står fortsatt i veien.

Detaljerte beskrivelser er ikke det samme som presise spesifikasjoner

Mange nye verktøy – fra AI som lager PRD-er til strenge valideringsrammeverk – bygger på en farlig idé: hvis AI stiller de riktige spørsmålene, fikser spesifikasjonene seg selv.

Problemet er at naturlig språk aldri kan måle seg med formell presisjon. Formelle notasjoner finnes nettopp fordi vanlig tekst er tvetydig. Du kan skrive en flott produktbeskrivelse som flyter perfekt og får alle til å nikke. Likevel mangler den ofte den skarpheten AI trenger for å lage solid kode.

Ta forskjellen mellom "brukere skal se dashboardet raskt, under 2 sekunder" og "P95-latency på analytics-dashboard under 2000 ms, med 99. persentil maks 5000 ms". Det virker som stil, men det er kjernen i en spesifikasjon.

Gi AI en vag beskrivelse, og du får kaos:

1. Tvetydighet blir til rar kode. Agenten lager noe som funker teknisk, men er arkitektonisk svakt. Du bruker uker på å fikse det.

2. Agenten gjetter stille. Den trekker fra treningsdata – tusenvis av lignende prosjekter – og bygger inn antakelser du aldri nevnte.

Begge deler taper du på.

Hvor agentkoding funker – og hvor det rakner

Agentbasert utvikling er gull i trange nisjer. Landingssider, CRUD-apper, standardintegrasjoner, e-handelsflyter – her lykkes det fordi problemene er velkjente. Treningsdataene florerer av eksempler. Agenten matcher mønstre, ikke oppfinnelse.

Det gir reell verdi. En gründer alene kan øke kapasiteten ti ganger. Et lite team fikser admin-verktøy på timer, ikke uker.

Men suksessen kommer fra krystallklar spesifikasjon, ikke til tross for den. Området er så godt utforsket at kravene nesten er implisitte.

Utenfor det – tilpasset business-logikk, nye integrasjoner, arkitekturvalg for fremtiden – må mennesker tenke. AI speeder opp skrivingen. Den fikser ikke tenkingen. Den kan ikke si nei til en idé fordi noe bedre finnes; den gjør bare som du sier.

En utvikler oppsummerte det: "AI koder, men den nekter ikke å kode før du forteller hvorfor noe annet er smartere." Det er produkttenkning forkledd som kode. Uerstattelig.

Den sanne flaskehalsen: kommunikasjonsgniss mellom folk

Hvis spesifikasjon er det tøffe, og AI ikke løser det, hva hjelper da?

Svaret er enkelt: mindre friksjon i menneskelig dialog.

Når en product manager gir en kort brief til en utvikler, og det tar en uke med møter å klarne edge cases og avveielser, har du spesifikasjonsproblemer. Når designermockups krasjer med ubekreftet backend-begrensninger, samme sak. Når AI lager kode basert på feilantakelser om business-krav, ditto.

Løsningen er ikke smartere agenter eller bedre validering. Det er presisjon i samtalen før agenten kjører.

Sånn gjør du det:

• Spesifikasjon som kjerneartefakt. Ikke en fin bonus, men kontrakten kodingen hviler på.
• Dokumenterte avveielser. Hvorfor eventual consistency over strong? Hvorfor denne datamodellen? Skriv det ned.
• Formelle verktøy der det teller. SQL-schemas, API-kontrakter, performance-budsjetter – bruk det som tvinger klarhet.
• Tidlig AI-test. Generer en bit kode mot spesifikasjonen, se hva som avslører hull, og juster.

Hvordan dette endrer din workflow

Bruker du AI i produksjon? Ikke dropp agentene. Invester tyngre i spesifikasjon.

Høres rart ut i "move fast"-tiden? Rask med dårlig spec treffer du feil mål fortere. Vinnerne bruker AI som multiplikator etter grundig tenking på fronten.

For startups og smålag: Fordelen ligger ikke i kodegen. Den er i skarp spec. Hvis du definerer business-logikken så presist at AI nailer det, har du knekt det vanskelige. Kodingen er bonusen.

Konklusjonen

Brooks hadde rett i 1986, og det holder i 2025. Software-kompleksitet ligger i ideen, ikke byggingen. AI har gjort gapet mellom løs tanke og presis kode øredøvende klart.

Neste produktivitetsbølge kommer ikke fra bedre agenter. Den kommer fra team som disiplinerer spesifikasjoner, løfter kravsarbeid til engineering-nivå, og bruker AI til å forsterke klarhet – ikke skjule kaos.

Det er muligheten der AI møter software-utvikling. Og det krever det eneste AI ikke kan: dyp tenking om hva du bygger.