Fire spørsmål som motvirker smiger i Claude Code

Hva er AI-smiger i Claude Code?#

Psykologien har lenge hatt et begrep for dette: smiger. En smigrer sier det du vil høre, bare for å holde samtalen i gang. Da store språkmodeller kom, ble ordet også en del av AI-forskningen, og i en offisiell analyse innrømmet Anthropic åpent at modellen regelmessig ofrer nøyaktighet for å være raskt enig.

I programmering ser det slik ut. Du skriver til Claude Code: «Rett denne feilen i authMiddleware; magic links har sluttet å virke.» Smigreren stiller ikke oppklarende spørsmål. Den ber ikke om logger. Den spør ikke hvilken versjon av biblioteket du bruker. Den foreslår en løsning med en gang fordi den er trent til å være raskt hjelpsom. Og løsningen kommer til å se riktig ut: importer, feilhåndtering, kommentarer. Men det vil være en løsning på en annens problem, funnet på ut fra konteksten Claude har satt sammen av fragmenter.

Claude er ikke årsaken. Årsaken er hvordan forespørselen er formulert. Når du spør «Hvordan løser jeg dette?», har du allerede tatt for gitt at problemet kan løses. Smigreren tar over den innrammingen og kommer med en «løsning», selv om det egentlige problemet ligger i arkitekturen, bibliotekversjonen eller i at symptomet du beskrev, bare er en følge av en helt annen grunnleggende feil.

En enkel test på en smigrende forespørsel: Hvis jeg ikke kan svare på spørsmålet «Hva er det egentlig som er ødelagt?» med tre setninger, er jeg ikke klar til å løse det. Jeg trenger en diagnose. Løsningen kommer etterpå. Det er akkurat der syklusen i 4 trinn begynner.

Et eksempel fra praksis: 8 commits rullet tilbake på en time#

Et konkret tilfelle fra april 2026. Jeg jobbet med magic-link-autentisering i src/lib/auth/. Symptomet: Tokenene ble validert, men økten ble ikke lagret. Brukeren klikker på lenken i e-posten, kommer til nettstedet og sendes tilbake til /login fem sekunder senere.

Jeg åpnet Claude Code og skrev: «Økten lagres ikke etter magic-link; se i src/lib/auth/ og rett det.» Claude stilte tre oppklarende spørsmål og laget deretter en plan med én gang. Den sa: «Jeg oppdaterer callback-behandleren, skriver om JWT-serializeren, legger til eksplisitt lagring i Redis og retter en race condition i middleware.» Det hørtes plausibelt ut. Jeg godkjente planen.

Atten minutter senere hadde jeg en diff på tvers av 14 filer. Magic link virket fortsatt ikke. Men nå virket heller ikke refresh token, passordinnlogging var ødelagt, og det var en merkelig 500-feil på betalingsruten. Tester feilet. Jeg begynte å rulle tilbake endringene.

Jeg rullet tilbake 8 commits med git reset --hard origin/main. En times arbeid rett i sluket. Hvis du vil vite hvordan du ruller tilbake på riktig måte uten å miste noe nyttig, har jeg skrevet om det separat i veiledningen om å angre endringer i Claude Code.

Jeg satte meg ned og undersøkte saken ordentlig. Jeg åpnet src/lib/auth/magic-link.ts:42, leste den selv, åpnet loggene og sjekket Redis. Etter tjue minutter fant jeg feilen. Problemet var én linje: set-cookie-headeren manglet attributtet SameSite=lax, og Safari avviste informasjonskapselen da den ble omdirigert fra e-postdomenet tilbake til nettstedet. Ingen JWT, ingen Redis, ingen middleware. Én linje.

Da jeg ba Claude rette problemet, så den aldri på nettleserloggene. Den hadde ingen kontekst om Safari. Den bygget en hypotese ut fra mønsteret «økten lagres ikke = serialiseringsproblem», fordi det er det vanligste svaret i treningsdataene. Smigreren produserte en statistisk plausibel løsning som ikke hadde noe med oppgaven min å gjøre.

Jeg skrev ned lærdommen som en regel: Aldri spør «Hvordan løser jeg dette?» Spør alltid «Fastslå fakta.» Det eneste som gjensto, var å formalisere dette som en fungerende syklus.

Hvor smiger kommer fra: Opus 4.8 ved lanseringen og mai 2026#

I april undersøkte Anthropic separat i en teknisk postmortem hvordan en hurtigbufferfeil i Claude Code fikk modellen til å «glemme» resonnementet sitt mellom turer.

Når en modell glemmer resonnementskjeden sin, er det lettere for den å «gjette» et svar ut fra et mønster — med andre ord å bli enda mer smigrende.

Hva bør du gjøre etter lanseringen av 4.8? Ikke velg en «enklere» modell. Ikke gå tilbake til 4.7. Tilpass forespørslene dine til fakta: Modellen er mer tilbøyelig til å være enig, så vær tydeligere på at den skal «fastslå fakta». Hvis du ennå ikke har funnet ut nøyaktig hva som endret seg i Opus 4.8, sammenlignet jeg den grundig i anmeldelsen av Opus 4.8 i Claude Code.

Når trengs de 4 trinnene, og når er de bortkastet tid?#

Konkrete eksempler. Endre teksten i en velkomstmelding: gjør det direkte. Legg til en ny CTA-knapp på et nettsted: Plan Mode uten syklusen. Migrer et prosjekt fra MySQL til Postgres: Syklusen i 4 trinn er nødvendig. En merkelig 500-feil i produksjon som ikke kan gjenskapes lokalt: Syklusen i 4 trinn med et ekstra «nulltrinn»: «la oss først lage et minimalt reproduksjonseksempel».

En vanlig feil når man bruker syklusen, er å bruke den på trivielle oppgaver. Det dreper tempoet og får raskt folk til å miste lysten på metoden. Syklusen trengs akkurat når kostnaden ved en feil er høyere enn kostnaden ved 15 minutter med planlegging.

Før du innfører syklusen, må du huske at alle fire promptene fungerer i én og samme Plan Mode-økt. Hvis du ikke har brukt denne modusen før, bør du først lese veiledningen til Plan Mode i Claude Code og deretter komme tilbake.

Trinn 1. Forby løsninger — få Claude til å fastslå fakta#

Det viktigste trinnet. Det er her den første impulsen — «her er løsningen» — blokkeres. Prompten:

Jeg støtte på følgende: [symptom].

Oppgaven din nå er å fastslå fakta. Alle
løsninger, ideer og råd er forbudt. Bare:
- hva jeg observerer (den nøyaktige formuleringen av symptomet)
- trinn som kan gjenskapes (et minimalt scenario)
- hvilke data som er tilgjengelige (logger, versjoner, miljø)
- hvilke data som mangler (hva som må samles inn)

Absolutt stoppvilkår: ikke foreslå løsninger; bare
registrer diagnosen. Hvis du vil foreslå noe,
formuler et spørsmål til meg i stedet.

Hva dette gjør. Når løsninger uttrykkelig er forbudt, kan ikke Claude ta snarveier. Den må fylle ut fire felt: hva jeg ser, hvordan det kan gjenskapes, hva jeg vet, og hva jeg ikke vet. Det siste feltet er det mest verdifulle. Det viser seg ofte å være: «Jeg vet ikke hvilken versjon av biblioteket som brukes, hva loggene inneholder, eller om symptomet oppstår i produksjon.» Dette er utgangspunktet for neste trinn.

Fallgruven i trinn 1. Hvis symptomet formuleres for vagt («autentiseringen fungerer ikke»), begynner Claude likevel å gjette. Løsningen ligger i prompten: Beskriv det nøyaktige symptomet med én setning, og gi et minimalt scenario på tre trinn. Hvis du ikke kan gjøre det, betyr det at du ennå ikke forstår nøyaktig hva som er ødelagt, og Claude-svaret blir uansett ubrukelig.

Trinn 2. Eksempler fra internett i stedet for hallusinasjoner fra hukommelsen#

Dette blokkerer den andre impulsen: «finn på en løsning fra hukommelsen». Prompten:

Nå som diagnosen er fastslått, finn eksempler på
hvordan lignende problemer er løst på internett.

Minst 3 ulike tilnærminger. For hver av dem:
- en lenke til primærkilden (issue, artikkel, dokumentasjon)
- en kort beskrivelse av tilnærmingen
- fordeler og ulemper for vår situasjon
- kjente fallgruver

Lenker som bygger på din egen kunnskap uten bekreftelse
fra en lenke, er forbudt. Hvis du ikke finner et eksempel,
si det uttrykkelig.

Effekten i praksis. Claude går ut i verden og kommer tilbake med etterprøvbare tilnærminger. Det dukker opp lenker til GitHub-issues og dokumentasjon. Hvis Claude ikke finner eksempler, er det et tegn på at oppgaven er uvanlig eller at symptomet er feil formulert. Gå tilbake til trinn 1.

Her svikter det. Claude kan vise til en lenke som ikke finnes. Det er en hallusinasjon, som når den sier «her er issue nummer 4291 i repository X», mens issue 4291 egentlig handler om noe annet. Løs dette ved å legge inn en tydelig regel i CLAUDE.md: «Åpne alltid lenken med WebFetch før du viser til den.» Se veiledningen for riktig oppsett av CLAUDE.md for mer informasjon.

Trinn 3. En detaljert plan i plans/ med risikoer kartlagt på forhånd#

Nå fungerer Plan Mode som tiltenkt. Prompten:

Velg det beste alternativet fra trinn 2, og skriv en detaljert
plan i filen plans/YYYY-MM-DD-fix-[name].md:

- hvilke konkrete filer vi skal endre (fullstendige baner og linjenumre)
- hva vi skal legge til, og hva vi skal fjerne
- hvilke tester vi skal skrive, og hvilke eksisterende tester som må bestå
- risikoer to til tre trinn fram i tid (hva som kan gå galt for brukerne)
- en plan for å rulle tilbake hvis noe går galt

Gjør hvert trinn til en avkrysningsboks [ ]. Filen må få plass på én skjerm.
Hvis planen er lengre enn 200 linjer, deler du den inn i faser.

Resultatet. Planen blir et artefakt i stedet for et midlertidig notat i chatten. Du kan lese den to uker senere, gi den til en annen agent eller bruke den som vilkår for kommandoen /goal. En planfil varer lenger enn samtalen i Claude Code.

Den viktigste delen er risikoene to til tre trinn fram i tid. Det blokkerer enda et smigrende mønster: en optimistisk plan uten bivirkninger. Når du ber Claude liste opp risikoer uttrykkelig, finner den ting den ellers ville ha oversett i stillhet i en vanlig plan.

Trinn 4. Kontroller planen selv — fang opp smigrende antakelser#

Det siste filteret. Prompten:

Utfør nå en obligatorisk egenkontroll. Les planen din på nytt, helt ærlig.

Er det steder i den der du har funnet på ting uten grunnlag og ikke bekreftet dem med:
- kode du har lest;
- dokumentasjon du viste til i trinn 2;
- et eksempel fra trinn 2?

Hvis ja, marker dem tydelig, revider dem eller fjern dem.

Sjekk også:
- om planen nevner biblioteker som ennå ikke er installert
  i package.json;
- om den nevner miljøvariabler jeg ikke har oppgitt;
- om noen trinn i planen er beskrevet generelt
  i stedet for konkret.

Hva dette gjør. Claude må kontrollere sitt eget resonnement på nytt. I forfatterens utvalg på rundt 50 sykluser blir minst to eller tre planpunkter revidert spesielt i trinn 4. Dette er steder der smigreren prøvde å snike seg gjennom i trinn 3, men blir tatt i trinn 4.

Etter de fire trinnene er planen klar for godkjenning. Du kan gå videre til implementeringen uten å bekymre deg for «Hva om jeg må rulle tilbake 8 commits?»

Hvorfor akkurat 4 trinn, ikke 2 eller 7?#

Her er begrunnelsen, basert på metoden Anthropic bruker for å veilede Claude i den offisielle dokumentasjonen.

Dokumentasjonen anbefaler en arbeidsflyt med fire faser: Explore, Plan, Implement, Commit.

Syklusen min i 4 trinn er en spesialisering av Plan-fasen for å motvirke smiger. Av Anthropic sine fire faser deler jeg én opp i fire mikrotrinn: forby løsninger, finne eksempler, skrive planen og kontrollere den selv. Dette er en detaljert plan som deretter sendes videre til fasene Implement og Commit.

Dette går galt hvis du hopper over ett av de fire trinnene:

Tabellen gjør det tydelig: Hvert trinn blokkerer sin egen klasse av feil. Du trenger alle fire fordi hvert trinn fanger opp en forskjellig kategori. Hvis oppgaven virker liten nok til at to trinn holder, er den faktisk liten — og da trenger du ikke Plan Mode i det hele tatt.

Hvordan plans/, kommandoen /goal og de neste trinnene henger sammen#

Syklusen fungerer i et system med:

1. Plan Mode aktivert (trykk Shift+Tab to ganger i Claude Code).
2. En mappe plans/ i repositoryet der du lagrer planer.
3. Eventuelt kommandoen /goal for autonom gjennomføring av lange planer.

Om mappen plans/. Etter trinn 3 får du filen plans/2026-05-27-fix-magic-link.md med faser og avkrysningsbokser. Den er et artefakt. Åpne den en uke senere, så husker du hvorfor du valgte den tilnærmingen. Om tre måneder finner du en lignende oppgave og bruker den på nytt. Om seks måneder viser du den til en kollega og sparer dem for to ukers innkjøring. Mappen plans/ er en del av konseptet med en «second brain» i Claude Code.

Om /goal. Når du har fullført de fire trinnene og godkjent planen, går du ut av Plan Mode og skriver inn:

/goal complete all phases from plans/2026-05-27-fix-magic-link.md,
all tests in test/auth pass, or stop after 30 turns

I en lokal Claude Code-økt må terminalen kjøre, datamaskinen holdes våken og nettverket være tilgjengelig. Ikke lukk lokket med mindre du uttrykkelig har satt opp en støttet løsning som holder maskinen våken. Se i økthistorikken når du kommer tilbake. Den kan vise fullføring, en turgrense, et tillatelsesspørsmål eller en feil. Et mål garanterer ikke fremdrift mens vertsmaskinen sover. Uten syklusen i 4 trinn bruker /goal tokens på unyttige iterasjoner. Med syklusen i 4 trinn tar /goal en ferdig plan fram til beståtte tester.

Hva du kan gjøre videre. Hvis du nettopp har begynt med Claude Code, kan du prøve syklusen på din neste ikke-trivielle oppgave. Ikke en skrivefeil. Noe som berører 3+ filer eller innebærer atferd du ikke forstår fullt ut. Ta promptene ovenfor, kopier dem og fyll inn dine egne detaljer. Du vil merke hvordan antallet tilbakerullinger endrer seg.

Hvis du allerede bruker Plan Mode, kan du legge til en mappe plans/ i repositoryet. Bli enig med deg selv om et filnavnformat: YYYY-MM-DD-feature-name.md. Om en måned har du 20–30 filer; om seks måneder mer enn hundre. Slik bygges prosjektets second brain opp — en levende historikk over beslutninger. Hvis du vil gå dypere inn i håndtering av kontekst før prompten, har jeg behandlet context engineering i Claude Code som et eget fagområde.

Hvis du allerede har både Plan Mode og plans/, kan du prøve /goal på én autonom oppgave. Velg en oppgave du vanligvis ville gjort for hånd på 30–40 minutter. Kjør den gjennom de 4 trinnene, lagre planen, start /goal og hold den lokale terminalen og datamaskinen våken. Skal arbeidet fortsette med avslått maskin, må du først bruke en uttrykkelig konfigurert fjern- eller skykjøring og kontrollere at oppgaven faktisk kjører der.