Slik skriver du Claude Code-agenter som ikke lyver til deg

Du ba Claude Code om å implementere dette designet og verifisere at det stemmer med Figma-mockupen. Den kom tilbake med: Ferdig. Alle seksjoner stemmer, spacing er riktig, farger er riktige. Du åpnet siden. Halvparten av spacingen var gal. Hover-tilstanden fantes ikke. Knappene var en nyanse ved siden av. Modellen løy ikke med vilje — den predikerte at du ville høre verifisert, og produserte nøyaktig den tokensekvensen. Det var ingen verifiseringssteg. Det kunne aldri ha vært det — verifisering krever sammenligning mot ground truth, og én enkelt agent i én enkelt kontekst har ingen mulighet til å tre ut av sitt eget svar og sjekke det.

To regler har gjort hallusinasjonspregede arbeidsflyter om til pålitelige pipelines for meg: én agent, én spesialisering, og alt som kan kjøres som en shell-kommando må kjøres som en shell-kommando. Dette er ikke teori. Dette er hva jeg gjør hver dag med Claude Code, og det er disse mønstrene som faktisk gjør en forskjell.

Hvorfor generalistagenter lyver

LLM-er er next-token-prediktorer. Når en prompt ber om to roller — bygg X og verifiser X — fullfører modellen den første rollen, og predikerer deretter hvordan utdataene fra den andre rollen ville sett ut, uten å faktisk utføre den. Selvverifisering er strukturelt svak: samme kontekst, samme modell, samme blinde flekker. Bestått på verifisering korrelerer med bestått på bygging — de feiler sammen.

Modellen vet ikke at den lyver. Fra dens perspektiv er jeg verifiserte alt nøye en koherent fortsettelse av å ha skrevet koden. Dette er den samme grunnen til at er du sikker?-prompts ikke fanger opp hallusinasjoner: modellen er like sikker på andre gjennomgang. Selvtillit korrelerer ikke med korrekthet — den korrelerer med hvor plausibelt neste setning høres ut.

Løsningen er ikke bedre prompts. Vær forsiktig, dobbeltsjekk, ikke hallusinér — disse instruksjonene gjør ingenting. Løsningen er strukturell: spesialiser agenten slik at den fysisk ikke kan late som, og rut kvantitativt arbeid gjennom shell-en så svaret kommer fra reell tilstand, ikke fra token-sannsynlighet.

Regel 1: én agent, én spesialisering

Del arbeidet inn i separate agenter med separate kontekster. Hver agent har ett enkelt ansvar og et begrenset verktøysett. Hele arbeidsflyten blir et stafettløp i stedet for én agent som løper runder:

• Builder-agent: tar spekken, skriver koden. Det er hele jobben dens. Den har Read, Edit, Write, Bash.
• Reviewer-agent: tar spekken pluss diff-en, sjekker akseptansekriterier. Frisk kontekst. Ingen kunnskap om hvordan koden ble skrevet, bare hva som kom ut. Den har Bash, Read, Grep, Glob — ingen skriveverktøy overhodet.
• Analytics-agent: svarer på dataspørsmål ved å konstruere og kjøre queries. Kun Bash. Kan ikke nå svaret uten å kjøre en ekte kommando.
• Orchestrator: hovedsesjonen som sender ut hver agent etter tur og aldri ber én agent gjøre en annens jobb.

Konkret eksempel: UI-implementasjon pluss en visuell sjekk mot en Figma-mockup. Builder-en skriver komponentene og committer diff-en. Orchestrator-en kaller deretter Reviewer-en med design-URL-en, diff-en og eksplisitte akseptansekriterier. Reviewer-en kjører Playwright, tar skjermbilder, differ dem mot referansen og returnerer PASS eller FAIL med de faktiske skjermbildebanene og piksel-diff-ene. Builder-en kommer aldri i nærheten av verifiseringssteget — og det er nøyaktig derfor verifiseringen er ekte.

Anti-mønsteret er mega-agenten: én enkelt prompt som sier bygg dette UI-et og pass på at det stemmer med mockupen. Jeg garanterer deg at den vil rapportere at alt stemmer. Det gjør det ikke. Narrativet om jeg verifiserte er bare den mest sannsynlige tokensekvensen etter jeg bygde det.

Regel 2: shell fremfor prompt, alltid

Alt som er kvantitativt, alt som berører reell tilstand, alt der svaret kan være galt på en måte som ser riktig ut — push det gjennom sh. Agentens jobb er å konstruere og kjøre kommandoen, deretter lese utdataene. Agenten er ikke kilden til sannhet. Shell-utdataene er.

• Telling: wc -l logs.txt er sant. Det er omtrent 47 logglinjer fra en modell er en hallusinasjon.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Ikke estimer volumet.
• Tester: pnpm test --reporter=json | jq '.numFailedTests'. Ikke oppsummer hva som feilet.
• Git-tilstand: git rev-list --count main..HEAD, git diff --stat. Ikke tell committene eller beskriv endringene.

Når du har internalisert dette, begynner du å legge merke til hvert sted der agenten var i ferd med å finne på et tall. Det ser ut til å være rundt 200 poster... — nei. Kjør SELECT count(*). De fleste testene består... — nei. Kjør testsuiten, parse JSON-en. Modellen er utmerket til å konstruere kommandoen. Den er upålitelig som kommandoen.

Feilmodi jeg faktisk har truffet på

Dette er ikke hypotetiske eksempler. Hvert av disse kostet meg reell tid før jeg endret mønsteret:

• Fantomverifisering. Agenten sa jeg sjekket alle 14 seksjoner mot mockupen. Den åpnet ikke mockupen. Den tok ikke et skjermbilde. Sjekken var et hallusinert steg i narrativet.
• Selvsikre gale tall. Spurte om monthly active users fra analysedata. Fikk et tall som var ~3× feil. Modellen interpolerte fra eksempelrader i stedet for å kjøre den faktiske spørringen.
• Oppdiktede filendringer. Agenten sa jeg oppdaterte config/feature-flags.json. Det hadde den ikke. Den hadde bare hatt til hensikt å gjøre det. git diff var tom.
• Falske testkjøringer. Alle tester består. Ingen tester ble kjørt. Agenten kalte aldri testkjøreren — den predikerte hvordan testkjørerens utdata ville ha sett ut.

Alle fire løses av de samme to reglene: del opp agenten, push til shell. Reviewer-en har ikke Write, så den kan ikke fake-redigere filer. Analytics-agenten har bare Bash, så den kan ikke returnere et tall som ikke kom fra en spørring. Strukturell umulighet slår gode intensjoner hver gang.

Slik strukturerer du dette i Claude Code

Claude Code støtter sub-agenter definert i .claude/agents/*.md. Hver agentfil deklarerer et navn, en beskrivelse, et tillatt verktøysett og en systemprompt. Orchestrator-en (din hovedsesjon) sender dem ut med Agent-verktøyet. Her er den typen definisjon jeg bruker for reviewer-en — kort, smal og fysisk ute av stand til å skrive kode:

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

Legg merke til verktøysettet: Bash, Read, Grep, Glob. Ingen Write, ingen Edit, ingen Agent. Reviewer-en kan kjøre kommandoer, lese filer, søke etter mønstre — og ingenting annet. Hvis den prøver å presentere en hallusinert diff som verifisert, gjør formen på verktøykallene det åpenbart: det var ingen ekte sjekker. Du kan auditere verktøykallene og se nøyaktig hva som ble inspisert.

Orkestreringsmønsteret: hovedsesjonen kaller Builder → venter → kjører git diff selv for å fange den faktiske endringen → kaller Reviewer med spekken og diff-en → leser Reviewer-ens kjennelse. Hovedsesjonen ber aldri én agent gjøre begge deler. Verktøybegrensninger er sterkere enn promptinstruksjoner: ikke fake verifiseringen er et ønske. Å ikke ha Write er et faktum.

Anti-mønstre å legge bak seg

Ting jeg ser i prompts som ikke gjør noe — eller verre, gir en falsk følelse av sikkerhet:

• Vær forsiktig og dobbeltsjekk arbeidet ditt. Genererer ingen ekstra atferd. Modellen produserer allerede det som ser ut som forsiktig arbeid.
• Pass på at du faktisk verifiserer. Ordet faktisk tilfører ingen semantikk modellen kan handle på. Den vil faktisk hevde å ha verifisert.
• Ikke hallusinér. En prompt engineering-meme. Hallusinasjon er ikke en bryter modellen kan skru av.
• Å stole på agenten på små tall. Små tall er der den lyver mest selvsikkert. Det finnes ingen nedre grense for ærlighet.
• Å legge til flere regler i prompten for å tvinge ærlighet. Strukturelle fikser (del opp + shell) slår promptjusteringer hver gang. Hvis en regel må håndheves, kode den inn i verktøytilgang, ikke i norsk.

Hvis strategien din for å fange opp hallusinasjoner er mer emfatisk formulering, har du ikke en strategi. Du har et håp.

Den mentale modellen

En agent er ikke en kollega. Det er en funksjon: prompt → tokens. Funksjonen er utmerket til å skrive kode og elendig til å introspektere om den gjorde det riktige. Behandle dens påstander om sitt eget arbeid som en hypotese. Diff-en, exit-koden, skjermbildet, radantallet — det er beviset. Sluttsummeringen er den mest løgnaktige overflaten i hele systemet.

Spesialisering er forsikringen din mot narrativ drift. Shell-en er din eneste ground truth. Builder skriver. Reviewer sjekker. Bash avgjør.

Konklusjon

Hvis du skal huske én ting: ikke la én enkelt agent både produsere og bedømme sitt eget resultat, og ikke la noen agent besvare et kvantitativt spørsmål uten å kjøre en kommando. Alt annet er nedstrøms av disse to reglene. Konfigurer verktøytilgang aggressivt, auditér verktøykall i stedet for oppsummeringer, og hallusinasjonspunkter krymper fra overalt til noen få konkrete steder du allerede vet å sjekke.