Spec-problemet er ikke nyt – AI har bare gjort det synligt

Der er en grim sandhed om AI-drevet udvikling, som har ligget og luret: det største hinder er ikke at skrive koden. Det er at beslutte, hvad koden skal gøre.

Fred Brooks pegede på det allerede i 1986 i No Silver Bullet. Han så, at store fremskridt som objektorienteret programmering eller struktureret kode kun gav små gevinster. De løste accidental complexity – det irriterende ved selve skrivningen. Men essential complexity – det svære ved at tænke – blev stående. I software er det spec-fasen, der tæller: at samle interessenter, vælge mellem kompromiser og definere krav til noget, der endnu ikke findes.

Nu lader vi AI generere kode, og folk tror, at spec-problemet forsvinder med. Det gør det ikke.

Detaljerede spec'er er ikke det samme som naturligt sprog

Mange værktøjer – fra AI til PRD-skrivere til spec-tjekkere – bygger på en fejltagelse: hvis AI stiller de rigtige spørgsmål, fylder hullerne sig selv.

Det holder ikke. Formelle notationer opstod netop, fordi naturligt sprog er tvetydigt. Du kan skrive en flot produktbeskrivelse, der lyder perfekt og får alle til at nikke. Men mangler den den præcision, AI-agenter kræver for at lave pålidelig kode? Så er det stadig en spec.

"Brugere skal se dashboardet på under 2 sekunder" lyder fint. Men "P95-latency under 2000 ms med 99-persentil på max 5000 ms" er en rigtig spec. Fodrer du AI med det vague? Du får enten:

1. Underlig kode, der virker teknisk, men kræver refaktorering i sprint efter sprint.

2. AI udfylder huller med mønstre fra træningsdata – antagelser, du aldrig mente.

Begge er tab.

Hvor agent-baseret kodning virker – og hvor den ikke gør

Agent-udvikling rocker i simple områder. Landingssider, CRUD-apps, standard integrationer, e-handelsflows. Her er problemerne kendte. Træningsdataen bugner af lignende eksempler. Agenten matcher mønstre, ikke opfinder hjulet.

Det er super værdifuldt. En solo-gründer kan øge kapaciteten ti gange. Et lille team bygger admin-værktøjer på timer i stedet for uger. Ren produktivitet.

Men succesen kommer af klar spec, ikke trods den. Området er så veldefineret, at spec'en næsten er implict.

Til det andet – custom logik, nye integrationer, arkitekturvalg til fremtiden – gælder det stadig: du tænker for mennesker. AI fremskynder skrivningen. Den fremskynder ikke tænkningen. Den kan ikke sige nej til en idé, fordi en bedre findes. Den laver kun, hvad du siger.

En udvikler sagde det godt: "AI skriver kode, men nægter ikke at skrive den, før du har forklaret, hvorfor X er bedre først." Det er produkt-tænkning forklædt som kode. Uundværligt.

Den ægte flaskehals: friktion mellem mennesker

Hvis spec er det hårde, og AI ikke løser det, hvad så?

Svaret er enkelt: mindre gnidning i kommunikationen mellem folk.

PM giver en brief til dev, der bruger en uge på klarlægningsmøder om edge cases. Spec-problem. Designermockups kræver backend-kompromiser, ingen nævnte. Spec-problem. AI laver kode på forkerte antagelser. Spec-problem.

Løsningen er ikke smartere agenter eller bedre validering. Det er præcision i samtalen før agenten kører.

Sådan:

• Spec som centralt dokument. Ikke noget ekstra, men kontrakt for kodegen.
• Dokumentér kompromiser eksplicit. Hvorfor eventual consistency fremfor strong? Hvilken datamodel og hvorfor?
• Formelle værktøjer til præcision. SQL-schemas, API-kontrakter, performance-krav.
• Tidlig feedback fra agenten. Generér en lille bid kode, se hvad tvetydigheder afslører, og rett spec'en.

Sådan ændrer det din workflow

Ved produktionssystemer med AI: brug agenter mere, men invester hårdere i spec, ikke mindre.

Det lyder modsat "move fast". Men hurtigt med dårlig spec rammer du forkerte mål hurtigere. Vinderne er dem, der tænker hårdt først og bruger AI til at booste udførelsen.

Til startups og små teams: jeres fordel er ikke kodegen. Det er spec-klarthed. Kan du beskrive business-logik så præcist, at AI rammer hver gang? Så har du knækket det svære. Koden er let nu.

Konklusionen

Brooks havde ret i 1986 – og i 2025. Software-kompleksitet ligger i opfattelsen, ikke byggeriet. AI har gjort kløften mellem løs tænkning og præcis kode hørligt klar.

Næste produktivitetsbølge kommer ikke fra bedre agenter. Den kommer fra teams, der skærper spec-praksisser, gør krav-engineering til kerne-disciplin og bruger AI til at forstærke klarhed, ikke skjule kaos.

Det er chancen ved AI og software. Og det kræver det ene, ingen agent kan: dyb tænkning om, hvad I bygger.