Prompt-divergens: Når teamets viktigste verktøy ikke er standardisert

Begge svar havner i samme kodebase

Vi standardiserer alt. Formatering håndheves av verktøy, logging følger konvensjon, API-design har retningslinjer. Men det verktøyet teamet bruker mest i løpet av en dag – samtalen med AI – er ofte det minst standardiserte.

Én utvikler spør: «Hvordan burde vi strukturere dette, gitt at vi bruker vertical slices?»
En annen spør: «Gi meg en rask løsning.»

Begge får gode svar. Begge svar er forskjellige. Og begge havner i samme kodebase. Dette er prompt-divergens, og den er mer kostbar enn den ser ut.

To seniorer + to AI-svar = fire retninger

I Tech lead i AI-alderen beskrev jeg hvordan AI forsterker forskjellene mellom erfarne utviklere. Prompten er mekanismen bak.

En prompt bærer med seg:

• kontekst (eller mangel på den)
• preferanser
• ambisjonsnivå
• antagelser om systemet

Når konteksten varierer, varierer svarene. Ikke litt. Mye. Og fordi hvert svar kan se faglig forsvarlig ut, kan divergensen gli gjennom review: ingen enkelt-PR er problemet, summen er det. Det er samme mønster som i Teknisk gjeld som et teamfenomen – summen av mange små beslutninger som aldri ble samkjørt.

Kontekst er den nye standarden

Å diktere hvordan folk formulerer seg ville vært både umulig og meningsløst. Men konteksten AI-en får, lar seg standardisere. I praksis:

1. Kontekstfiler i repoet

En kort fil – gjerne i roten av prosjektet – som beskriver:

• arkitekturprinsippene («vi bruker vertical slices, ikke lagdelt arkitektur»)
• konvensjonene («strukturert logging med korrelasjons-ID, alltid»)
• det som ikke skal gjøres («ingen nye mapping-biblioteker uten TDR»)

Poenget er at dette ikke er en fil dere må finne opp fra bunnen av for hvert verktøy, og at dere sannsynligvis bare trenger én felles kilde til kontekst. Mot slutten av 2025 hadde flere store verktøy sine egne konvensjoner for instruksjoner: .github/copilot-instructions.md for GitHub Copilot, .cursor/rules/ for Cursor, CLAUDE.md for Claude Code, .windsurf/rules/ for Windsurf. Å holde den samme veiledningen flere steder kan skape et nytt divergensproblem.

Denne fragmenteringen er nå i ferd med å løse seg. AGENTS.md ble lansert av OpenAI i august 2025 og lagt inn under Linux Foundations nyopprettede Agentic AI Foundation i desember samme år, sammen med Model Context Protocol og goose – det er da den ble leverandørnøytral på ordentlig. Den leses nå av Copilot, Cursor, Codex, VS Code og flere (Gemini CLI trenger én innstilling, Claude Code én linje: @AGENTS.md i CLAUDE.md), og nettstedet selv telte over 60 000 prosjekter med åpen kildekode i desember 2025. Det praktiske rådet er derfor:

• Skriv én AGENTS.md i roten. Det er der arkitekturprinsippene, konvensjonene og forbudene hører hjemme.
• Legg til en verktøyspesifikk fil bare når dere faktisk trenger noe det formatet kan og AGENTS.md ikke kan.
• Og la filen reviewes som all annen kode. Den beskriver standardene deres; den fortjener samme terskel som koden som følger dem.

Da får alle på teamet – og alle deres assistenter – samme utgangspunkt, fra én kilde. Thoughtworks satte i Technology Radar vol. 34 fra april 2026 «kuraterte, delte instruksjoner for team» på Adopt, med AGENTS.md som ett av formatene: at hver utvikler skriver prompts fra bunnen, kaller de et voksende antimønster. Samme utgave advarer mot «agent instruction bloat», kontekstfiler som vokser til instruksjonene begynner å motsi hverandre.

Hva som skal stå der – og hva målingene sier

Det er lett å tro at mer kontekst gir bedre svar. Målingene sier noe annet. Gloaguen og kolleger ved ETH Zürich testet i februar 2026 kodeagenter med og uten kontekstfil på ekte oppgaver: filene ga i snitt ingen høyere løsningsrate, men over 20 prosent høyere kostnad, og forfatternes råd er at en håndskrevet kontekstfil bare bør inneholde det som ikke allerede står i README – konkrete konvensjoner, ikke-funksjonelle krav – og testes før den tas i bruk. En oppfølging i juli 2026 fant det samme for Claude Code og Codex over 288 kjøringer: agentene feiler på implementasjonsvalg, ikke på manglende kunnskap om repoet.

Det er ikke et argument mot filen. Det er et argument for hva den er til. Den gjør ikke agenten flinkere; den gjør svarene deres, og divergens er det den fjerner. Det forklarer også hva som skal stå der. Anthropics egen veiledning for CLAUDE.md sier under 200 linjer, fordi lengre filer følges dårligere, og stryk alt modellen kan lese ut av koden selv – mappestruktur, avhengigheter, arkitekturoversikt. Behold fallgruvene, begrunnelsene og konvensjonene som avviker fra verktøyets standard. Det er listen fra forrige avsnitt: prinsippene, konvensjonene og forbudene. Ikke en kopi av README.

2. Delte prompts for gjentakende oppgaver

Noen oppgaver gjentas: generere tester, skrive migrasjoner, lage API-klienter. Legg de gode promptene i repoet, og behandle dem som verktøy. docs/prompts/generate-integration-tests.md er samme tankegang som maler og eksempelkode, ikke byråkrati.

3. Lenk, ikke kopier

Prinsippet fra Hvordan etablere tekniske standarder som faktisk etterleves gjelder her også: én kilde til sannhet. Kontekstfilen bør peke på standardene, ikke duplisere dem.

Det handler ikke om kontroll

Det er fristende å lese dette som enda et regelverk. Poenget er det motsatte: å gjøre det lett å få svar som passer systemet. En utvikler som spør uten kontekst, får generiske svar og må tilpasse dem selv. Den tilpasningen er friksjon. Er teamets kontekst allerede innebygget i spørsmålet, kommer svarene nesten ferdig tilpasset, og det er støtte.

Standarder fungerer når de oppleves som hjelp, ikke tvang. Prompts er ikke annerledes.

Tech leadens jobb

Du skal ikke skrive alle promptene selv. Jobben er å sørge for at de finnes, deles og vedlikeholdes:

• ta prompt-praksis inn i retrospektiver: hva fungerer, hva gir dårlige svar?
• når noen får et spesielt godt resultat, be dem dele prompten, ikke bare koden
• behandle kontekstfilen som levende dokumentasjon: utdatert kontekst gir utdaterte svar

Ingen bestemte at dere skulle sprike

Teamet ditt har fått et nytt verktøy som former kodebasen hver eneste dag. Spørsmålet er ikke om dere skal standardisere bruken av det. Spørsmålet er om divergensen skal være bevisst eller tilfeldig.

Prompts er blitt en del av utviklingspraksisen. Da hører de hjemme i repoet, med en reviewer, som resten av den.