Hvorfor Claude gjør feil: 3 prompter

Du finner mer informasjon om tjenesten i Ailoot-dokumentasjonen.

Hvorfor gjør Claude feil?#

Du skriver: «Legg til filtre på produktsiden.» I hodet ditt betyr det et par avkrysningsbokser og en oppdatert liste. Claude hører det samme og bestemmer seg for å bygge en fullverdig filtreringsmotor: sitt eget tilstandslager, separat logikk for forsinket inndata, synkronisering med URL-en og et dusin hjelpefunksjoner. Hundrevis av linjer der noen få URL-parametere hadde vært nok.

I et tilfelle som dette er konklusjonen klar: Agenten gjorde ingen feil; den løste bare et mye større problem enn nødvendig. Feilen lå i at det ønskede resultatet ikke var beskrevet kort og presist nok.

Nøkkelordet er «hensikt». Du har den i hodet; Claude har den ikke. Det ser teksten i forespørselen din og alt i konteksten fram til den forespørselen. Deretter fyller det hullene med gjetninger. Jo kortere forespørselen er, desto mer gjetter det – og desto lenger unna det ønskede resultatet havner du.

Anthropic sier dette rett ut i Claude Code-dokumentasjonen:

Jeg opplevde dette selv i prosjektet mitt. Jeg ba om en rettelse på én autoriseringsskjerm og fikk en diff som påvirket halve nabomodulen. Claude hadde ikke skylden: Jeg ga det én linje, og det fylte inn resten selv. Siden da har jeg startet alle oppgaver som er større enn en skrivefeil med spørsmål – spørsmål Claude stiller meg.

Er det virkelig modellen – og hvorfor bommer selv de sterkeste?#

Hver uke kommer det en modell som er «smartere» enn den forrige, og hver gang føles det som om dette er øyeblikket da AI endelig vil forstå oss ut fra noen få ord. Det kommer ikke til å skje. En sterkere modell skriver kode raskere og håndterer kompleks logikk bedre, men den kan fortsatt ikke lese tankene dine. Hvis oppgaven er dårlig formulert, får du noe som er vakkert skrevet, men fortsatt feil.

Konklusjonen for deg er enkel. Det er en blindvei å jakte på den nyeste modellen slik at den kan gjette bedre. Det er billigere og mer pålitelig å lære seg å gi den oppgaver som gjør at den slipper å gjette. Det er det som kommer nå.

Hva er grilling, og hvordan løser det misforståelser med AI?#

Det høres kontraintuitivt ut. Vi bruker AI for å få ting gjort raskere, og nå får vi beskjed om å bremse den og få den til å stille spørsmål først. Men fem minutter med spørsmål før koding kan spare deg for en time med rettinger etterpå.

Problemet er ikke bare at du forklarte ting dårlig til Claude. Ofte har du ikke tenkt oppgaven godt nok gjennom selv – hvilke tilfeller du må ta høyde for, hvor grensene går, og hva som er viktigst. Grilling får dette fram gjennom spørsmål. Når samtalen er over, har du ikke bare en oppgave AI-en forstår, men også en detaljert beskrivelse av hva du selv egentlig vil ha.

Slik fungerer kontekstutvikling: Hovedarbeidet skjer før prompten, ikke mens du skriver den. Du leter ikke etter en magisk formulering; du legger fram det Claude trenger på forhånd, helt til det forstår uten ytterligere forklaring.

Hvordan får du Claude til å stille spørsmål først?#

Anthropic tillater ikke bare denne tilnærmingen, men anbefaler den. Dokumentasjonen har et avsnitt med tittelen «La Claude intervjue deg» og en ferdig prompt. Her er en praktisk versjon:

Jeg vil bygge [kort beskrivelse av oppgaven].

Intervju meg grundig før du skriver kode. Still spørsmål om implementering, grensesnitt, kanttilfeller, risikoer og avveininger. Ikke still åpenbare spørsmål – gå i dybden på de vanskelige punktene jeg kanskje ikke har tenkt gjennom.

Still ett spørsmål om gangen og vent på svaret mitt. Foreslå umiddelbart svaret du anbefaler for hvert spørsmål.

Fortsett til vi har gått gjennom alt. Sett deretter sammen en fullstendig spesifikasjon i en fil som heter SPEC.md.

Tre detaljer gjør denne prompten nyttig i stedet for pynt. For det første: «ett spørsmål om gangen». Hvis AI dumper ti spørsmål på deg samtidig, blir du overveldet og svarer overfladisk. For det andre: «foreslå svaret ditt» – du trenger ikke finne på alt fra bunnen; du kan si deg enig eller rette på forslaget. For det tredje: «sett sammen en spesifikasjon i en fil» – hensikten du har fått fram, blir et dokument som ikke går tapt.

Anthropic beskriver gevinsten i form av arbeidsinnsats:

Etter intervjuet åpner du en ny økt og gir Claude den ferdige spesifikasjonen. Ren kontekst og tydelig beskrevet hensikt – da treffer Claude på første forsøk.

Teknikken «bevis at dette er den beste planen»#

Grilling får fram hva du mener. Men AI har en annen uvane: Den velger den første løsningen som virker sannsynlig. Anthropic kaller dette gapet mellom «stol på, men kontroller»: Claude lager en plausibel implementering som ikke holder i kanttilfellene. Løsningen er å be om bevis før koden skrives.

Jeg legger nesten alltid til et «bevis det»-avsnitt i prompten min. Her er den nøyaktige formuleringen:

Analyser oppgaven som en kritiker før du skriver kode.

Finn 2-3 måter å løse den på. Bevis for hver av dem at den faktisk løser oppgaven min i stedet for å legge til kompleksitet for kompleksitetens skyld. Ikke skriv kode bare for å skrive kode.

Velg deretter én løsning og bevis at den er den beste, med flere steg fremover i tankene. Hva vil slutte å fungere etter hvert som prosjektet vokser? Hva overser vi akkurat nå?

Foreslå først deretter en implementering.

Uten dette avsnittet gir Claude deg det første alternativet som fungerer. Med det luker Claude selv bort blindspor, forklarer valget sitt og lar deg se resonnementet før en eneste fil er endret. Du leser en kort tekst som tar to minutter, i stedet for å bruke en time på å finne ut hvorfor den ferdige koden ikke fungerer som forventet.

Premortem: få AI til å finne 10 grunner til at det kan gå galt før du starter#

Dette er favoritteknikken min, og den virker psykologisk. Når du ber AI «gjøre en god jobb», er det innstilt på suksess og hopper over hullene. Be den forestille seg at prosjektet mislykkes, så begynner den å se det den overså før. Prompten er kort:

Se for deg at det er ett år fram i tid. Prosjektet vi planlegger, har mislyktes.

Skriv ned 10 grunner til at det skjedde. Hva unnlot vi å ta høyde for fra starten, hva undervurderte vi, hvor tok vi snarveier, og hvilke antakelser viste seg å være feil?

Fortell meg deretter, for hver grunn, hva vi kan rette opp nå for å håndtere den.

Jeg bruker denne prompten før jeg godkjenner planen. Halvparten av grunnene viser seg å være tull, men den andre halvparten er reelle fallgruver jeg ville ha støtt på en uke senere. Det tar ti minutter å håndtere dem i planleggingsfasen. Å oppdage dem i et ferdig prosjekt koster flere dagers undersøkelser.

Kombinasjonen er enkel: Grilling får fram hensikten, «bevis det» forsvarer beslutningen, og premortem finner hullene. Tre korte tekstbiter du limer inn før du skriver kode. De gjør Claude til en samarbeidspartner som tenker først, i stedet for en som bare setter i gang.

Hvorfor gjør en overfylt kontekst at Claude virker dum?#

Selv en perfekt formulert oppgave faller sammen hvis du jobber med den i en rotete kontekst. Slik fungerer det: Hver nye forespørsel du kommer med, tar hele chathistorikken inn i Claudes arbeidskontekst. Jo lengre økten varer, desto raskere fylles vinduet. Hold det maksimalt halvfullt; etter det begynner AI å oppføre seg dumt og miste viktige ting dere snakket om i starten.

Her er regelen som sparer meg for mest frustrasjon: én oppgave, én chat. Ferdig med en funksjon? Lukk chatten og åpne en ny for neste oppgave. Ja, noen ganger er det mer praktisk å gjøre alt i ett vindu, men prisen er tapt kontekst og svar på siden av temaet.

Anthropic kaller denne feilmodusen en «søppelskufføkt». Løsningen er enkel: Bruk /clear mellom ulike oppgaver for å tømme vinduet og unngå å dra med rot fra forrige oppgave inn i den nye.

Hvis du har lange økter og ikke forstår hvor pengene og oppmerksomheten til AI blir av, skriver jeg om det separat i veiledningen om hvor Claude Code-tokenene tar veien. Jeg har også samlet grunnleggende informasjon om varig kontekst, som Claude leser ved hver oppstart, i veiledningen om å sette opp CLAUDE.md.

Grilling eller Plan Mode – hva er forskjellen, og hvordan passer de sammen?#

Folk forveksler ofte disse to teknikkene eller antar at man bare trenger én av dem. I praksis hører de hjemme på ulike stadier i prosessen.

Anthropic beskriver en vanlig arbeidsflyt med fire faser: Først Explore (Claude undersøker og stiller spørsmål), så Plan (lager en plan uten å gjøre endringer), deretter Implement (skriver kode i tråd med planen), og til slutt Commit (registrerer resultatet). Grilling skjer i den første fasen; Plan Mode i den andre. Se veiledningen om Plan Mode i Claude Code for en full gjennomgang av den andre fasen.

Anthropic selv kommer med et viktig forbehold: Ikke belast små oppgaver med dette.

For en skrivefeil, et navnebytte eller en endring på én linje holder det å si det direkte, uten intervju eller plan. Grilling lønner seg for oppgaver med uklarheter og høy feilrisiko. For trivielle oppgaver gjør det bare prosessen tregere.

5 feil i formuleringen av oppgaver som får AI til å gjøre feil#

Jeg har oppsummert vanlige fallgruver i en tabell. Til venstre står det folk vanligvis gjør og gjør feil; til høyre står det de bør gjøre i stedet.

Se på den siste prompten der AI ga deg feil svar. Nesten helt sikkert var en av disse fem feilene årsaken. Som oftest er det den første: Du ga den en kort setning og forventet at Claude skulle fylle inn resten riktig. Den fylte inn resten – bare ikke slik du hadde sett for deg.

Hva nå: bygg et system som gjør at AI forstår deg ut fra noen få ord#

De tre promptene i denne veiledningen – grilling, «bevis det» og premortem – håndterer den konkrete oppgaven. Det er allerede mye: Du slipper å få en diff som endrer 14 filer når du bare ønsket en endring på én linje.

Men grilling har sine begrensninger. Det tar lang tid å få fram hva du mener fra bunnen av hver gang. Den virkelige endringen kommer når noe av konteksten alltid er tilgjengelig: i en mappe med kunnskap om prosjektet ditt, i en CLAUDE.md-fil som Claude leser ved hver oppstart, og i metodikken din, kodet i skills. Da kommer AI til oppgaven med kunnskap om virksomheten, målene og stilen din – og forstår deg ut fra noen få ord fordi du har lagt fram halve konteksten på forhånd.

En nylig analyse fra Anthropic viser hvor mye arbeid som gjenstår: Utviklere bruker AI i omtrent 60% av arbeidet sitt, men kan stole fullt på den i bare 0-20% av oppgavene. Resten krever din forståelse, oppfølging og evne til å forklare hva som skal bygges. Det er den ferdigheten det er verdt å utvikle, ikke å jakte på den smarteste modellen.

Bli kjent med Ailoot.