Spec-problemet är inte nytt – AI gör det bara uppenbart

Det finns en jobbig sanning i agentbaserad utveckling som alltid funnits framför ögonen på oss: chokepointen har aldrig varit att skriva kod. Det har varit att bestämma vad koden ska göra från början.

Fred Brooks pekade ut det här redan 1986 i No Silver Bullet. Han såg att stora programmeringsframsteg – som objektorienterad design eller strukturerad programmering – bara gav små vinster. De fixade accidental complexity, det jobbiga med själva skrivandet. Men essential complexity, det svåra tänkandet, blev kvar. I mjukvaruutveckling handlar det verkliga jobbet om specifikationsfasen: synka intressenter, väga avvägningar och definiera krav för något som inte finns än.

Nu har vi lämnat kodgenerering till AI. Många tror att spec-problemet magiskt försvinner med det. Spoiler: det gör det inte.

Varför "detaljerade specar" inte är samma som "naturligsspråksspecar"

Här blir det knepigt. Många nya verktyg – från AI-drivna PRD-genererare till smarta validerare – utgår från att AI kan ställa rätt frågor och fylla luckor automatiskt.

Det förutsätter att vardagsspråk kan leverera den exakthet som formella system kräver. Fel väg.

Formella notationer uppstod just för att naturligt språk är luddigt. Du kan skriva en snygg produktspec – den flyter, berättar en historia, alla nickar – men den saknar ändå den skärpa AI-agenter behöver för stabil kod. Skillnaden mellan "användare ska se dashboarden på under 2 sekunder" och "P95-latens för analysdashboarden <2000 ms, med 99:e percentilen max 5000 ms" är ingen stylistisk grej. Det är en spec.

Ger du AI:n en vag spec får du inget klarare resultat. Antingen:

1. Otydligheten blir konstig kod. Agenten bygger något som funkar tekniskt men är arkitektoniskt skevt. Du spenderar veckor på omarbete.

2. Agenten gissar tyst. Den drar från träningsdata – tusentals liknande projekt – och kör på antaganden du aldrig tänkt.

Ingen av delarna vinner.

Var agentkod funkar – och var den kraschar

Agentutveckling rockar i smala områden. Landningssidor, CRUD-appar, standardintegrationer, e-handelsflöden. Det funkar för problemen är välkända. Träningsdatan svämmar över av liknande lösningar. Agenten matchar mönster, löser inte nytt.

Det är värdefullt. En ensam grundare boostar kapaciteten tiofalt. Små team bygger adminverktyg på timmar istället för veckor. Ren produktivitet.

Men: framgången kommer från kristallklar spec, inte trots den. Området är så utmejslat att specen nästan är självklar.

Allt annat – unik affärslogik, nya integrationer, arkitekturval som öppnar framtiden – kräver mänskligt tänkande. AI speedar skrivandet. Inte tänkandet. Den kan inte säga nej till en idé för att en annan är bättre. Den kör bara vad du säger.

En utvecklare sa det så här: "AI skriver kod, men vägrar inte skriva den utan att först få veta varför X är smartare." Det är produkttänk som ser ut som kod. Oersättligt.

Den riktiga flaskhalsen: friktion mellan människor

Om spec är det svåra och AI inte löser det, vad gör det då?

Svaret är simpelt: minska gnisslet i kommunikationen mellan människor.

När en PM lämnar över en brief till en ingenjör och det tar en vecka med möten för att reda ut edge cases och kompromisser – spec-problem. När designermockups krockar med osagda backend-gränser – spec-problem. När AI:n bygger på gissningar som avviker från affärsbehov – spec-problem.

Lösningen är inte bättre agenter eller spec-validerare. Det är att tvinga fram precision i människosnacket före agenten startar.

Så här:

• Spec som central grej. Inte ett extradokument, utan kontraktet som kodberoendet hänger på.
• Dokumentera avvägningar tydligt. Varför eventual consistency istället för strong? Varför den datamodellen? Skriv ner det.
• Formella verktyg för kritiska delar. SQL-scheman, API-kontrakt, prestandabudjetter – verktyg som tvingar klarhet.
• Tidiga feedback-loopar med agenten. Generera en liten kodbit mot specen, justera baserat på vad som avslöjar luckor.

Vad det betyder för din workflow

Bygger du produktionssystem med AI-hjälp? Glöm inte agenterna. Satsa hårdare på spec, inte mindre.

Låter bakvänt i "move fast"-eran. Men fort med dålig spec betyder bara snabbare felmål. Team som vinner med agenter har tänkt klart först och använder AI för att skala utförandet.

För startups och småteam: er edge ligger inte i kodgenerering. Den ligger i spec-klarhet. Om du kan beskriva affärslogiken så AI:n bygger rätt, har du knäckt det tuffa. Kodningen är bagatellen nu.

Slutkläm

Fred Brooks hade rätt 1986, och det håller 2025. Mjukvarans kärnsvårighet ligger i idégenereringen, inte byggandet. AI har inte ändrat det – den har bara gjort klyftan mellan luddigt tänkande och skarp kod omöjlig att missa.

Nästa produktivitetsvåg kommer inte från bättre agenter. Den kommer från team som skärper spec-praktiker, gör kravhantering till ingenjörskonst och använder AI för att förstärka klarhet, inte dölja kaos.

Det är den stora chansen där AI möter utveckling. Och det kräver det enda AI inte kan: djupt tänkande om vad du egentligen bygger.