Specifikationsdrevet udvikling

Idéen er ældre end kodeagenter. Design by contract, modeldrevet udvikling, behaviour-driven development med Given/When/Then-scenarier og testdrevet udvikling forsøgte alle at lade en eksplicit, kontrollerbar beskrivelse af hensigten komme før eller styre koden. Det, der ændrede sig i 2025, er modtageren af specifikationen: en kodeagent, der hurtigt og selvsikkert implementerer det, den får besked på, så tvetydighed i forespørgslen bliver direkte til troværdig, men forkert software. At skrive specifikationen tvinger beslutninger om omfang, grænsetilfælde, fejlhåndtering og ikke-funktionelle krav frem, før der findes tusindvis af linjer, som indbygger de forkerte.

To værktøjer har formet den nuværende praksis. GitHubs open source-værktøj Spec Kit, annonceret i september 2025, har en CLI ved navn specify og et sæt slash-kommandoer til agenten, der fører gennem en fast rækkefølge: en "constitution" for projektet med ufravigelige principper, en funktionsspecifikation (spec.md) med fokus på hvad og hvorfor, en teknisk plan (plan.md), der vælger arkitektur og stak, en opdeling i opgaver (tasks.md) og implementering opgave for opgave. Amazons IDE Kiro, lanceret i 2025, strukturerer hver funktion som krav (user stories med strukturerede acceptkriterier), et designdokument og en opgaveliste, der kan spores tilbage til kravnumre, plus "steering"-filer med fast kontekst om produkt og teknologi. Begge behandler Markdown-artefakter under versionsstyring som den varige grænseflade mellem mennesker og agent.

Birgitta Böckelers analyse fra oktober 2025 på martinfowler.com skelner mellem tre niveauer. Spec-first skriver en specifikation før arbejdet og kan kassere den bagefter; spec-anchored beholder specifikationen og udvikler den sammen med funktionen; spec-as-source gør specifikationen til det eneste artefakt, mennesker redigerer, mens koden genereres ud fra den. Hun noterede også de vigtigste kritikpunkter: Genererede specifikationer kan være længere og mere trættende at gennemgå end koden, én fast arbejdsgang pålægger en rettelse på én linje samme ceremoni som en ny funktion, agenter ignorerer eller misforstår stadig instruktioner trods udførlige skabeloner, og spec-as-source risikerer at gentage fiaskoerne fra modeldrevet udvikling, nu med ikke-determinisme oveni.

Gjort godt er specifikationen stedet, hvor sikkerheds- og compliancekrav bliver testbare. Resultater af trusselsmodellering, databeskyttelseskrav og acceptkriterier som tokens' levetid eller rate limits kan skrives som eksplicitte krav, som tests verificerer og reviewere tjekker, hvilket flugter med praksissen i NIST SP 800-218 om at definere sikkerhedskrav til softwareudvikling (PO.1). Specifikationen fjerner ikke behovet for kodegennemgang; den giver revieweren en reference, som afvigelser kan måles imod, og den skal selv holdes ajour, for en forældet specifikation vildleder agenten lige så effektivt som en manglende.