Problemet med å bare kjøre på

Tenk deg dette: Du har en klar idé om en funksjon. Du åpner favoritt-AI-verktøyet ditt, skriver en rask forespørsel, og ser hvordan det selvsikkert omskriver halve kodebasen din. En time senere sitter du og stirrer på en PR som løser et problem du egentlig ikke mente å løse – på en måte som knekker ting du ikke mente å knekke.

Kjenner du deg igjen? Du er ikke alene. Etter hvert som AI-kodingsassistenter har utviklet seg fra spørreverktøy til kodeeditorer, oppdager mange utviklere at den samme løse prompting-stilen som fungerer for chatboter, ikke strekker til når virkelige kodebaser står på spill.

Løsningen er ikke flere detaljerte prompter. Det er et grunnleggende skifte i hvordan vi tenker om dokumentene vi sender til disse agentene.

Prompter versus spesifikasjoner: En viktig forskjell

Her er greia med prompter: de er laget for å starte arbeid. De fungerer bra for raske forklaringer, kaste-vekk-skript og utforskende samtaler. En prompt lever i en chatøkt, kan bruke forkortelser, og forutsetter ofte kontekst som bare forfatteren forstår.

Det fungerer helt fint når du bare stiller spørsmål.

Men når en AI-agent skal redigere delt kode, kjøre terminalkommandoer og produsere branches som kolleger skal vurdere? Da blir din løse prompt en oppgave. Og oppgaver trenger mer enn god formulering – de trenger rett kontekst, klare grenser, konkrete eksempler og valideringskriterier.

Her kommer spesifikasjoner inn i bildet.

En spesifikasjon er ikke en penere prompt. Det er et strukturert dokument som fanger opp hvilket problem du løser, hvilken oppførsel som skal endres, hva som skal forbli uendret, og hvordan du vet om arbeidet var vellykket. Til forskjell fra en prompt som forsvinner når agenten starter, forblir en spesifikasjon synlig gjennom hele arbeidsflyten – den veileder agenten, informerer reviewerne, og hjelper fremtidige vedlikeholdere å forstå hvorfor beslutninger ble tatt.

Hva skal med i en god AI-agent-spesifikasjon

Du trenger ikke et 20-siders dokument. Det du trenger er fem nøkkelelementer:

1. Kontekst: Hvorfor oppstår denne oppgaven? Hvilket brukerproblem eller teknisk gjeld driver den? Hvilke begrensninger finnes i kodebasen som agenten bør forstå?

2. Oppførsel som skal endres: Hvilken spesifikke funksjonalitet skal modifiseres, legges til eller fjernes? Vær konkret – "brukere skal motta e-postvarsler når X skjer" slår "forbedre varselsystemet."

3. Begrensninger som må bevares: Hva må absolutt ikke endres? Hvilken eksisterende funksjonalitet, API-kontrakter eller ytelsesegenskaper må forbli intakte?

4. Eksempler på korrekthet: Konkrete scenarier som viser hva godt resultat ser ut. Given/When/Then-format fungerer bra her, men selv noen få eksplisitte testtilfeller hjelper agenten å forstå forventningene dine.

5. Valideringskriterier: Hvordan vil en reviewer vite om arbeidet er fullført? Hva skal de inspisere? Hvilke spørsmål bør de stille?

Dette rammeverket bør føles kjent hvis du har jobbet med behavior-driven development (BDD)-scenarier, issue-malmer med akseptansekriterier eller designdokumenter. Det spesifikke formatet betyr mindre enn å ha rett informasjon i en delbar, vurderbar form.

Hvor spesifikasjoner hører hjemme i arbeidsflyten

En av de beste tingene med spesifikasjoner er fleksibiliteten. De trenger ikke være separate dokumenter som bremser deg. En spesifikasjon kan leve hvor som helst som gir mening for teamet ditt:

• En GitHub-issue med eksplisitte akseptansekriterier
• En PR-beskrivelse som navngir oppførselen som endres
• Et BDD-scenario i feature-filene dine
• En lettvekts designnotat før implementering
• Verktøy som OpenSpec eller GitHub Spec Kit som formaliserer dette mønsteret

Poenget er å gjøre kontekst og vurderingskriterier synlige og varige. Spesifikasjonen din skal ikke forsvinne når chatøkten avsluttes. Den skal følge med arbeidet, og gi kolleger noe konkret å evaluere.

Assignement-laget: Å skille intensjon fra implementering

Her blir det virkelig interessant.

De sterkeste spesifikasjonene fungerer som små adferdskontrakter. De skiller tre distinkte spørsmål:

1. Hvilken oppførsel skal endres? (Kravet)
2. Hvilke begrensninger eller eksempler definerer korrekthet? (Akseptansekriteriene)
3. Hvilken implementasjonsvei virker hensiktsmessig akkurat nå? (Den tekniske tilnærmingen)

Disse spørsmålene henger sammen, men de bør ikke kollapse til én usammenhengende instruks.

Hvorfor betyr dette noe for AI-kodingsagenter? Fordi når du blander intensjon og implementering for tidlig, kan agenten optimalisere for feil ting. Den kan lojalt følge et foreslått implementasjonsdetalj mens den bommer på den faktiske oppførselen du trengte. Eller den kan produsere kode som er teknisk interessant men ikke løser det oppgitte problemet.

Et assignment-lag holder kravet stabilt samtidig som implementasjonen får utvikle seg. Etter hvert som agenten leser kodebasen, oppdager komplikasjoner og foredler tilnærmingen, forblir spesifikasjonen referansepunktet: "Løste arbeidet dette?"

Dette er spesielt verdifullt for eksisterende kodebaser. Det meste av teknisk arbeid er ikke greenfield – du endrer oppførsel som allerede eksisterer. En god spesifikasjon sier: her er nåværende oppførsel, og her er hva som må endres. Reviewere trenger ikke mentalt rekonstruere intensjonen din fra implementasjonsdetaljer.

Å ta steget

Hvis du er vant til å behandle AI-kodingsagenter som supereffektive søkemotorer, kan dette føles som overtenking. Men tenk på alternativet: ukontrollerte endringer i delt kode, PR-er som er vanskelige å vurdere, og arbeid som ikke helt matcher det du forestilte deg.

Skiftet til spesifikasjonsdrevet AI-samarbeid handler ikke om byråkrati. Det handler om å gi både mennesker og maskiner den klarheten de trenger for å jobbe effektivt sammen.

Start lite. Neste gang du er i ferd med å slippe en AI-kodingsagent inn i en kodebase, ta en pause på fem minutter og skriv ned konteksten, adferdsendringen og suksesskriteriene. Legg det et sted synlig – selv om det bare er i PR-beskrivelsen.

Din fremtidige versjon av deg selv (og kollegene dine) vil sette pris på det.

Konklusjonen: AI-kodingsagenter er kraftfulle samarbeidspartnere. Behandl dem som samarbeidspartnere. Gi dem en skikkelig briefing, så får du arbeid verdt å vurdere.