Hur jag undviker att en AI-agent bygger något elegant men…

Ett av de svåraste problemen med coding agents är inte ful kod. Det är välskriven kod som löser fel problem. Ju bättre modellerna blir på implementation, desto viktigare blir spårbarheten tillbaka till intention och acceptance criteria.

Det farligaste felet är en snygg lösning på fel problem

Coding agents kan bygga något som ser professionellt ut, har typer, tests och ren arkitektur — och ändå bryter mot produktintentionen. Jag försöker därför skydda mig mot "elegant men fel" på tre nivåer: spec, plan och convergence review.

Arkitektur får inte ersätta krav

När en agent hittar ett tekniskt mönster den gillar kan den börja optimera för det: event sourcing, microservices, abstractions, caching. Jag vill att varje större designbeslut ska kunna peka tillbaka på ett faktiskt requirement eller constraint. Annars är det potentiell överbyggnad.

Plan review testar mappingen

Före implementation gör jag en requirement→plan mapping. Varje materiellt krav måste ha ett planerat steg, och varje större plansteg ska ha en kravmotivering. Tomma rader på båda håll är signaler: missat krav eller scope creep.

Tests måste härledas från acceptance criteria

En agent kan skriva tests som verifierar sin egen implementation snarare än produktbeteendet. Därför vill jag att viktiga tests härleds från Given/When/Then-scenarier som definierades före koden. Det minskar risken att testen bara bevisar att lösningen gör det den råkade byggas för att göra.

Convergence review efter implementation

Efter kod vill jag åter läsa spec, plan och tasks och jämföra mot det som faktiskt finns. Spec Kit beskriver samma idé i sitt convergence-flöde (funktionens exakta namn i verktyget kan ändras över tid, principen är densamma): bedöm nuvarande implementation mot krav och acceptance criteria och skapa spårbart återstående arbete. Det är en stark motvikt mot snygg men felaktig kod.

Ge modellen rätt att säga att planen är fel

En coding agent ska inte behöva försvara planen bara för att den fick den som input. Om repo-inspektionen visar att ett antagande var fel ska agenten stoppa, visa evidensen och föreslå planändring. Det är bättre än att tvinga en felaktig plan genom en verklighet som inte matchar.

När agenten ska fråga och när den ska välja en rimlig default

Samma spårbarhet avgör när en agent bör fråga i stället för att bara besluta. En agent som frågar om allt känns säker men blir långsam; en agent som aldrig frågar kan fatta fel beslut. Jag reserverar frågor för de fall där ett val är irreversibelt eller väger tungt mot en preferens — där två rimliga val ger olika publik UX, raderar data eller låser en dyr arkitektur. Är valet lokalt och lätt att ändra väljer agenten i stället en rimlig default: befintlig projektkonvention om den finns, annars den enklaste lösningen som uppfyller kravet.

Agenten ska heller inte fråga om information den kan hämta själv. Kan den läsa repot, dokumentationen eller schemat ska den göra det innan den frågar användaren — frågor ska lösa genuin ambiguity, inte ersätta retrieval. Och när agenten fattar ett sådant beslut själv ska antagandet synas i plan eller diff, så att det går att korrigera utan att varje litet val förhandlas i realtid.

Definition of done är produktmässig

Jag räknar inte "tests green" som done. Done betyder att acceptance criteria är uppfyllda, inga blockerande deviations är öppna, migration/rollback är hanterad där det behövs och reviewn kan förklara hur resultatet uppfyller intentionen. Då är teknisk elegans en bonus — inte definitionen av framgång.

Min praktiska tumregel

Krav→plan→kod→test måste vara spårbart åt båda håll. Annars kan teknisk kvalitet dölja produktmässigt fel.

Hur jag undviker att en AI-agent bygger något elegant men fel