Din AI kodeassistent har brug for en brief – ikke bare en hurtig prompt

Pas på med at gætte dig frem

Forestil dig situationen: Du har en klar idé til en feature. Du åbner dit foretrukne AI kodeværktøj, skriver en hurtig besked, og ser selvsikkert til mens det omskriver halvdelen af din kodebase. En time senere stirrer du på en PR, der løser et problem du ikke rigtig mente at løse – på en måde der bryder ting du ikke mente at bryde.

Genkender du det? Du er ikke alene. Efterhånden som AI kodeagenter er blevet bedre til at redigere kode i stedet for bare at svare på spørgsmål, oplever mange udviklere, at den afslappede prompting-strategi der virker fint i chatvinduer, ikke slår til når der virkelig er noget på spil.

Løsningen er ikke mere detaljerede prompts. Det er en fundamental ændring i, hvordan vi tænker over de dokumenter vi giver de her værktøjer.

Prompts versus specs – det er ikke det samme

Problemet med prompts er, at de er designet til at komme i gang. De er gode til hurtige forklaringer, kortsigtede scripts og udforskende samtaler. En prompt lever i en chat-session, kan bruge forkortelser, og antager ofte kontekst som kun afsenderen kender.

Det fungerer fint nok, når du bare stiller spørgsmål.

Men når en AI agent skal redigere delt kode, køre terminalkommandoer og producere branches, som kolleger skal gennemgå? Så bliver din casual prompt til en opgave. Og opgaver kræver mere end god formulering – de har brug for den rigtige kontekst, klare grænser, konkrete eksempler og valideringskriterier.

Her kommer specs ind i billedet.

En spec er ikke bare en pænere prompt. Det er et struktureret dokument der beskriver, hvilket problem du løser, hvilken adfærd der skal ændres, hvad der skal forblive det samme, og hvordan du ved om arbejdet er vellykket. I modsætning til en prompt der forsvinder når agenten går i gang, forbliver en spec synlig gennem hele workflowet – den guider agenten, informerer reviewerne og hjælper fremtidige maintainere med at forstå beslutningerne.

Hvad skal en god AI-agent spec indeholde?

Du behøver ikke et 20-siders dokument. Det handler om fem centrale elementer:

1. Kontekst: Hvorfor laves denne opgave? Hvilket brugerproblem eller teknisk gæld driver den? Hvilke begrænsninger findes i kodebasen som agenten skal kende til?

2. Adfærd der skal ændres: Hvilken specifik funktionalitet skal modificeres, tilføjes eller fjernes? Vær konkret – "brugere skal modtage email når X sker" er bedre end "forbedr notifikationssystemet."

3. Begrænsninger der skal bevares: Hvad må absolut ikke ændre sig? Hvilken eksisterende funktionalitet, API-kontrakter eller performance-karakteristika skal forblive intakte?

4. Eksempler på korrekt adfærd: Konkrete scenarier der viser hvad succes ser ud. Given/When/Then-formatet fungerer godt, men selv et par eksplicitte testcases hjælper agenten med at forstå dine forventninger.

5. Valideringskriterier: Hvordan ved en reviewer at arbejdet er færdigt? Hvad skal de inspicere? Hvilke spørgsmål skal de stille?

Det her framework vil lyde bekendt hvis du har arbejdet med BDD-scenarier, issue-skabeloner med acceptkriterier eller design-dokumenter. Det specifikke format betyder mindre end at have de rigtige informationer i en form der kan deles og gennemgås.

Hvor bor specs i dit workflow?

En af de bedste ting ved specs er deres fleksibilitet. De behøver ikke være separate dokumenter der sinker arbejdet. En spec kan leve mange steder:

• En GitHub issue med eksplicitte acceptkriterier
• En PR-beskrivelse der navngiver den adfærd der ændres
• Et BDD-scenarie i dine feature-filer
• En letvægts design-note før implementering
• Værktøjer som OpenSpec eller GitHub Spec Kit der formaliserer mønsteret

Det afgørende er at kontekst og review-kriterier er synlige og persistente. Din spec skal ikke forsvinde når chat-sessionen slutter. Den skal følge med arbejdet og give kolleger noget konkret at evaluere.

Intentionslaget: Adskil hvad fra hvordan

Her bliver det virkelig interessant.

De stærkeste specs opfører sig som små adfærdskontrakter. De adskiller tre distinkte spørgsmål:

1. Hvilken adfærd skal ændres? (kravet)
2. Hvilke begrænsninger eller eksempler definerer korrekthed? (acceptkriterierne)
3. Hvilken implementeringsvej virker oplagt lige nu? (den tekniske tilgang)

Disse spørgsmål hænger sammen, men de skal ikke kollapse til én samlet bunke instruktioner.

Hvorfor betyder det noget for AI kodeagenter? Fordi når du blander intent og implementering for tidligt, kan agenten optimere efter det forkerte. Den kan loyalt følge et foreslået implementeringsdetail mens den misser den egentlige adfærd du havde brug for. Eller den kan producere kode der er teknisk interessant men ikke løser det faktiske problem.

Et intentionslag holder kravet stabilt mens implementeringen kan udvikle sig. Efterhånden som agenten læser kodebasen, opdager komplikationer og finpudser sin tilgang, forbliver specen det faste holdepunkt: "Løste arbejdet det her?"

Det er særligt værdifuldt for eksisterende kodebaser. De fleste engineering-opgaver er ikke greenfield – du ændrer adfærd der allerede eksisterer. En god spec siger: her er den nuværende adfærd, og her er hvad der skal ændre sig. Reviewere behøver ikke mentalt rekonstruere din intent ud fra implementeringsdetaljer.

Tag springet

Hvis du er vant til at behandle AI kodeagenter som supersøgemaskiner, kan det her føles som over-engineering. Men tænk på alternativet: ukontrollerede ændringer i delt kode, PRs der er svære at gennemgå, og arbejde der ikke helt matcher det du forestillede dig.

Skiftet til spec-drevet AI-samarbejde handler ikke om bureaukrati. Det handler om at give både mennesker og maskiner den klarhed de har brug for til at arbejde effektivt sammen.

Start småt. Næste gang du er ved at slippe en AI kodeagent løs i en repository, så tag fem minutter til at skrive konteksten ned, adfærdsændringen og succeskriterierne. Læg det et sted det er synligt – selv hvis det bare er i PR-beskrivelsen.

Din fremtidige selv (og dine kolleger) vil være taknemmelige.

Konklusionen: AI kodeagenter er kraftfulde samarbejdspartnere. Behandl dem som samarbejdspartnere. Giv dem et ordentligt brief, og du får arbejde der er værd at gennemgå.