Prompt engineering for koding: 7 mønstre vi bruker daglig i Claude Code og Cursor (2026)

Prompt engineering for koding er forskjellen mellom en agent som leverer en fungerende pull request, og en som stille ødelegger noe i produksjon. Vi lærte det på den dyre måten: én vag instruks i vår egen pipeline klarte en gang å lage 54 dupliserte, live sider før noen oppdaget det. I dag skriver, oversetter og publiserer et oppsett med 16 Claude Code-agenter innholdet vårt, og promptene som styrer det ligner ingenting på 50-mal-listene på førstesiden til Google. Her er de 7 mønstrene vi skriver hver dag, hver med et ekte før-og-etter.

Kort svar: Gode kodeprompter deler én form. Du sier målet og definisjonen av "ferdig", navngir de eksakte filene som er i omfang, tvinger frem en plan før noen redigering, gir fra deg testene, og krever bevis i stedet for et "ser bra ut". Gjør det, og en moderne agent (Claude Code, Cursor, GitHub Copilot) skriver kode som består gjennomgangen på første forsøk langt oftere. Hopp over det, og du får selvsikkert, plausibelt sludder.

De 7 mønstrene, i rekkefølgen vi griper til dem:

1. Oppgaveramme: mål, begrensninger og "ferdig" tidlig
2. Kontekstvalg: navngi filene, sperr av resten
3. Plan først: få den til å foreslå før den redigerer
4. Test først: legg akseptansetestene i prompten
5. Feilsøking: feil pluss reproduksjon pluss forventet resultat, rotårsak før fiks
6. Refaktorering: endre strukturen, behold oppførselen, vis diffen
7. Gjennomgang: en sjekkliste å greppe mot, pluss bevis

Prompt engineering for koding vs. konfigurasjonsfiler: hva hører hjemme hvor

Konfigurasjonsfiler og prompter per oppgave gjør forskjellige jobber, og å blande dem er den vanligste feilen i dette feltet. En CLAUDE.md- eller .cursor/rules-fil er stående policy som agenten leser hver økt: stacken din, navnekonvensjonene dine, testkommandoen din. En prompt er den konkrete jobben du gir den akkurat nå. Varige regler hører hjemme i konfigurasjonen; oppgaven hører hjemme i prompten.

De fleste "kodeprompt"-oversiktene visker ut dette skillet og ber deg lime en gigantisk personaprompt inn i .cursorrules. Det blåser opp konfigurasjonen agenten laster inn på hver eneste oppgave, og løser fortsatt ikke å ramme inn den ene jobben foran seg. Hold de to atskilt:

Hvis du vil ha konfigurasjonssiden gjort skikkelig, dekker vi den i dybden i CLAUDE.md-beste praksis og Cursor-regelguiden. Denne artikkelen er den andre halvparten: promptene du skriver ferskt hver gang. Begge hører hjemme under den bredere prompt engineering-guiden vår, hvis du vil ha grunnlaget først.

Prompt engineering for koding: de 7 mønstrene vi bruker daglig

Hvert mønster under har den svake versjonen folk faktisk skriver, og den sterke versjonen som gir fungerende kode. Gapet fra svak til sterk er nesten alltid det samme grepet: bytt ut et ønske med en spesifikasjon.

1. Oppgaveramme: si målet, begrensningene og hva "ferdig" betyr

Oppgaveramme betyr å skrive målet, begrensningene og hvordan "ferdig" ser ut før agenten rører en eneste linje. En agent optimerer for akkurat det du bokstavelig talt ba om, så en uklar forespørsel gir en uklar patch. Navngi filen, oppførselen du vil ha, akseptansesjekken og tingene den ikke får lov til å endre.

Dette er mønsteret som kostet oss 54 sider. Den gamle oversettelsesinstruksen vår var i praksis bare et ønske:

Svak: Oversett dette innlegget til tysk på nytt, og behold merkenavnene.

Ingenting der sier hva en slug har lov til å gjøre. Så på en ny kjøring "forbedret" agenten URL-slugen, og fordi en ny slug betyr et nytt dokument, endte vi opp med to live tyske sider for samme innlegg. Gang det opp over språk og gamle innlegg, og du får 54 duplikater og en haug med duplicate-content-ekskluderinger. Løsningen var en spesifikasjon, ikke et penere ønske:

Sterk: Oversett dette innlegget til tysk på nytt.
- Hvis en tysk fil allerede finnes, kopier den eksisterende sluggen ordrett.
  Aldri utled den på nytt eller "forbedre" den.
- Før du oppretter noe dokument, slå opp det eksisterende via dets
  kanoniske referanse og gjenbruk den posten.
- Hvis sluggen du ville generert avviker fra den live versjonen, STOPP og si
  fra. En endret slug skaper en ny live URL for samme side.

Den sterke prompten sier feilmodusen høyt. Denne ene vanen, å si hva som ikke får skje og hvorfor, er den mest verdifulle endringen de fleste team kan gjøre. Vi avslutter også hver oppgaveprompt med en eksplisitt output-kontrakt ("den siste meldingen din må rapportere ordantallet, valideringsscoren og eventuelle filer som er berørt"), slik at agenten vet hva "ferdig" skal produsere, ikke bare hva den skal gjøre.

2. Kontekstvalg: navngi filene, sperr av resten

Kontekstvalg betyr å fortelle agenten nøyaktig hvilke filer den skal lese og hvilke den skal la være, i stedet for å la den greppe rundt og fylle vinduet sitt med støy. Anthropics egen veiledning er rett på sak om hvorfor: kontekstvinduet fylles fort, og kvaliteten faller etter hvert som det fylles, så de fleste beste praksisene finnes for å beskytte det (Claude Code beste praksis).

Svak: Fiks feilen i checkout-flyten.

Sterk: Les kun src/checkout/cart.ts og src/checkout/tax.ts. Skatteavrundingen
er feil for bestillinger over $1,000 (den runder av hver linjepost i stedet
for ordretotalen). Fiks avrundingen. Ikke rør noe utenfor
src/checkout/.

Vi sperrer strengt. En ekte linje fra agentpromptene våre lyder: "ikke skriv til url-mapping.json, pipeline.md eller config.json, og rør aldri en fil utenfor scratchpad-mappen din." Den ene setningen har forhindret mer utilsiktet skade enn noen mengde opprydding i etterkant. Når oppgaven virkelig trenger levende dokumenter eller ekstra verktøy, legger vi dem til bevisst gjennom MCP-servere i stedet for å håpe agenten snubler over riktig fil. Og hvis noe av denne konteksten kommer utenfra repoet ditt, behandle den som ubetrodd: se vår notis om forebygging av prompt injection før du limer en skrapet side inn i en kodeagent.

3. Plan først: få den til å foreslå før den redigerer

Plan-først-prompting får agenten til å gi deg en tilnærming før den redigerer noe som helst. I Claude Code er Plan Mode en hard, håndhevet skrivebeskyttet tilstand, ikke en høflig "tenk først" som modellen kan vandre forbi, så den kan bokstavelig talt ikke skrive før du godkjenner planen. Å skille research og planlegging fra utførelse er den enkeltpraksisen Anthropic lener seg mest på for å unngå å løse feil problem.

Svak: Legg til rate limiting på API-et.

Sterk: Før du skriver noe kode, gi meg en nummerert plan: hvilken
middleware, hvor tellerne skal ligge, hvordan du håndterer 429-responsen
og headerne, og hvilke tester du vil legge til. Vent på godkjenningen min
før du redigerer.

Hvorfor det virker: planen er billig å lese og billig å rette. Å fikse en feil plan koster én setning; å fikse feil kode koster en hel gjennomgangsrunde. Dette går naturlig hånd i hånd med å be modellen resonnere steg for steg først (se chain-of-thought-prompting), og det er ryggraden i de flertrinns Claude Code-arbeidsflytene vi kjører for alt som ikke er trivielt.

4. Test først: legg akseptansetestene i prompten

Test-først-prompting legger akseptansekriteriene inn i prompten som konkrete input og output, slik at agenten skriver kode mot et mål du har definert, i stedet for ett den har gjettet seg til. Lim inn den feilende testen, eller en liten tabell med forventede resultater, og si "få denne til å bestå uten å endre testen."

Svak: Skriv en funksjon som parser ISO 8601-datoer.

Sterk: Få denne feilende testen til å bestå uten å endre testen:

  parseIso("2026-07-20T15:00:00Z")   -> Date på nøyaktig det UTC-tidspunktet
  parseIso("2026-07-20")             -> Date på 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> kaster RangeError
  parseIso("")                       -> kaster RangeError

Returner kun funksjonen og importene dens.

Konkrete eksempler slår adjektiver hver gang. "Håndter edge cases" er et håp; fire input-til-output-rader er en spesifikasjon modellen faktisk kan oppfylle, og du kan kjøre dem i det sekundet koden lander.

5. Feilsøking: feil, reproduksjon, forventet resultat, rotårsak før fiks

En feilsøkingsprompt gir agenten feilteksten, inputen som utløser den, og hva du forventet, og ber deretter om årsaken før noen fiks. Hopp over det, og agenten patcher symptomet, slik at buggen bare flytter seg et roligere sted.

Svak: Dette kaster en feil, fiks den.

Sterk: Dette kaster feil ved checkout. Her er stack-tracen: [lim inn]. Det
skjer bare når handlekurven har en rabattkode OG et gavekort (reproduksjon:
legg til begge, gjennomfør så checkout). Forventet: begge gjelder, gavekort
sist. Finn rotårsaken og forklar den i én setning før du endrer noe. Ikke
pakk den inn i en try/catch som skjuler feilen.

Linjen "forklar årsaken i én setning først" gjør faktisk en jobb. Den tvinger modellen til å forplikte seg til en diagnose du kan fornuftssjekke, i stedet for å levere en fiks hvis logikk du aldri får se. Linjen "ikke skjul den i en try/catch" stenger den vanligste rømningsveien.

6. Refaktorering: endre strukturen, behold oppførselen, vis diffen

En refaktoreringsprompt begrenser omfanget strengt: endre strukturen, behold oppførselen identisk, og vis diffen. Uten en sperre "rydder" agenter i ting du aldri ba om, og du mister muligheten til å gjennomgå endringen som faktisk betydde noe.

Svak: Rydd opp i denne filen.

Sterk: Trekk ut valideringslogikken fra submitOrder() til en ren funksjon
validateOrder(). Behold alle offentlige signaturer og all oppførsel
identisk. Ikke endre noe annet i denne filen. Vis meg en før/etter-diff og
én linje om hvorfor hver endring bevarer oppførselen.

Dette er baksiden av konfigurasjon-versus-prompt-skillet fra tidligere: de stående stilreglene dine hører hjemme i Cursor-reglene, men omfanget av denne refaktoreringen hører hjemme i prompten. "Ikke endre noe annet" er frasen som holder refaktoreringer gjennomgåbare.

7. Gjennomgang: en sjekkliste å greppe mot, pluss bevis

En gjennomgangsprompt gir agenten en sjekkliste å greppe mot og krever bevis, ikke en dom. "Ser bra ut" er verdiløst; kommandoen den kjørte og resultatet den fikk, er det ikke. Anthropic sier det rett ut: la agenten vise bevis (testresultatet, kommandoen og resultatet dens) i stedet for å påstå suksess, fordi det er raskere å lese bevis enn å verifisere det selv på nytt.

Svak: Gjennomgå PR-en min.

Sterk: Sjekk denne diffen mot akkurat disse fem punktene:
1. Ingen hemmeligheter eller API-nøkler er lagt til
2. Hver ny funksjon har en test
3. Ingen atferdsendring utenfor src/checkout/
4. Feilveier returnerer typede feil, ikke strenger
5. Ingen console.log er glemt igjen
For hvert punkt, siter linjen som oppfyller eller bryter det. Kjør deretter
testsuiten og lim inn resultatet. Ikke si "ferdig"; vis meg.

Vår egen gjennomgangsport er bygget nøyaktig slik. Før en agent får lov til å rapportere et innlegg som publisert, grepper den utkastet mot en liste over forbudte ord (en hard sperre, null toleranse) og kjører en spørring for å bekrefte at dokumentkroppen ikke er tom. Agenten får ikke påstå suksess; den må produsere sjekkresultatet. For reviewer-roller du gjenbruker ofte, forfrem sjekklisten til en lagret persona, som er der system prompt-eksempler kommer inn.

Claude Code vs. Cursor vs. Copilot: hvor hvert mønster lever

Alle de tre store 2026-agentene støtter hvert mønster over, men overflaten skiller seg. Claude Code lener seg på Plan Mode og underagenter, Cursor på Agent mode og Agents-vinduet sitt, og GitHub Copilot på agent mode pluss instruksjonsfiler. Velg verktøyet teamet ditt lever i; mønstrene overføres rent.

Noen aktuelle detaljer verdt å kjenne til. Claude Codes Plan Mode er en ekte skrivebeskyttet lås, og underagentene kjører hver i en isolert kontekst med sine egne verktøy (dokumentasjon for underagenter). Cursors 2026-linje la til et Agents-vindu som spinner opp parallelle agenter, hver i sin egen git-worktree (Cursor 2.0). GitHub Copilots agent mode leser egendefinerte instruksjoner fra .github/copilot-instructions.md, i tillegg til stibaserte .instructions.md-filer med et applyTo-felt (Copilots egendefinerte instruksjoner). Hvis Cursor er hovedverktøyet ditt, se innlegget vårt om å bruke Cursor mer effektivt.

Slik prompter vi kodeagentene våre hos Techsy

Vi kjører en innholdspipeline som et team på 16 Claude Code-agenter: en researcher, en brief-forfatter, en innholdsforfatter, ni oversettere, en validator og en publisher, koordinert gjennom oppgavemeldinger. To konvensjoner fra det systemet overføres til ethvert kodeteam.

For det første avsluttes hver oppgaveprompt med en output-kontrakt. Siste linje er alltid en versjon av "den siste meldingen din må rapportere X, Y og Z." En agent som kjenner den nøyaktige formen på "ferdig", vandrer langt mindre enn en som bare er fortalt hva den skal starte med.

For det andre lar vi aldri en agent vurdere sin egen hjemmelekse i prosa. Generering og verifisering er separate steg, og verifiseringen er en kommando med resultat, ikke en mening. Dette skillet mellom bygging og sjekk er kjernen i hvordan Anthropic rammer inn å bygge pålitelige agenter, og det er derfor gjennomgangsporten vår grepper og spør i stedet for å stole på et "ser bra ut".

Dette er også dagjobben vår. Hos Techsy bygger vi AI-agenter og automatisering for B2B-team, og promptdisiplin som dette er det meste av det som skiller en demo fra noe du kan sette foran en kunde. Hvis du vil ha en kode- eller agent-arbeidsflyt satt opp skikkelig, er AI-integrasjonstjenesten vår der vi gjør akkurat det, og du kan bestille en gratis konsultasjon for å snakke gjennom stacken din.

En kopier-lim-inn-promptmal du kan tilpasse

Her er skjelettet vi starter fra for enhver ikke-triviell kodeoppgave. Slett seksjonene du ikke trenger, men behold rekkefølgen, fordi den speiler de syv mønstrene.

MÅL
Én setning: hva skal være sant når du er ferdig.

KONTEKST
Les kun: <eksakte filer>. Ignorer alt annet.
Relevante fakta: <begrensninger, versjoner, det som utløser buggen>.

PLAN FØRST
Før du redigerer, gi meg en nummerert plan og vent på godkjenning.

TESTER / FERDIG
Ferdig betyr: <lim inn feilende test eller input->output-rader>.
Ikke endre testene.

BEGRENSNINGER
Behold alle offentlige signaturer og all oppførsel identisk med mindre
annet er sagt. Ikke rør <filer/områder>. Navngi enhver antakelse du gjør.

OUTPUT
Vis en før/etter-diff, kjør testene, og lim inn resultatet.
Ikke si "ferdig"; vis bevisene.

Lagre den som en snippet, eller enda bedre: del den opp. De stående begrensningene hører hjemme i konfigurasjonsfilen din, og målet, konteksten og testene hører hjemme i prompten. Det skillet er hele poenget.

Ofte stilte spørsmål

Hva er prompt engineering for koding?

Prompt engineering for koding er praksisen med å skrive instrukser som får en AI-agent til å produsere korrekt, gjennomgåbar kode. I praksis betyr det å si målet og definisjonen av "ferdig", navngi filene som er i omfang, tvinge frem en plan før redigering, gi tester, og kreve bevis. Det ligger nærmere det å skrive en spesifikasjon enn det å skrive en smart setning.

Hvordan skiller det seg fra å skrive en CLAUDE.md- eller .cursor/rules-fil?

Konfigurasjonsfiler holder stående policy agenten leser hver økt: stacken din, konvensjonene og testkommandoen. En prompt per oppgave er den konkrete jobben du gir den akkurat nå. Legg varige regler i konfigurasjonen og oppgaven i prompten. Å lime hele oppgaveprompter inn i en konfigurasjonsfil blåser opp hver eneste økt og løser fortsatt ikke å ramme inn den enkelte oppgaven.

Hva er den beste promptstrukturen for AI-kodeagenter?

Bruk merkede seksjoner i stedet for én sammenhengende tekst: MÅL, KONTEKST, PLAN, TESTER, BEGRENSNINGER og OUTPUT. Agenter tolker strukturerte prompter mer pålitelig enn tekstvegger. Si suksesskriteriene tidlig, gi ett til tre konkrete eksempler i stedet for adjektiver, og spesifiser det eksakte outputformatet du vil ha tilbake.

Hvordan skriver jeg en god feilsøkingsprompt?

Gi agenten fire ting: den eksakte feilen eller stack-tracen, inputen som reproduserer den, hva du forventet, og en forespørsel om rotårsaken før noen fiks. Legg til "forklar årsaken i én setning før du endrer noe", slik at du kan sjekke diagnosen, og "ikke skjul den i en try/catch", slik at den fikser i stedet for å maskere buggen.

Bør jeg inkludere tester i kodepromptene mine?

Ja, når du kan. Å lime inn den feilende testen eller en liten tabell med input-til-output-rader gjør en vag forespørsel om til et mål modellen faktisk kan treffe, og du kan kjøre resultatet umiddelbart. Si til agenten at den skal få testene til å bestå uten å endre dem, slik at den ikke kan flytte målstolpene for å få sin egen kode til å se riktig ut.

Fungerer disse promptene også i Cursor og GitHub Copilot?

Ja. Mønstrene er verktøyagnostiske. Claude Code eksponerer dem gjennom Plan Mode og underagenter, Cursor gjennom Agent mode og Agents-vinduet sitt med en worktree per agent, og GitHub Copilot gjennom agent mode pluss .github/copilot-instructions.md. Overflaten endrer seg; oppgaveramme, kontekstvalg, plan først og bevisbasert gjennomgang gjør det ikke.

Hvor lang bør en kodeprompt være?

Lang nok til å være en spesifikasjon, kort nok til å holde fokus. Resonneringskvaliteten forringes etter hvert som konteksten fylles, så favoriser struktur over volum: en merket prompt på 150-300 ord med riktige filer og tester slår en springende en. Flytt alt som gjelder for hver oppgave over i konfigurasjonsfilen din i stedet for å gjenta det.

Hvordan stopper jeg en AI-agent fra å endre kode jeg ikke ba om?

Sperr omfanget i prompten. Si nøyaktig hvilke filer den har lov til å redigere, legg til "ikke endre noe annet", og krev "behold alle offentlige signaturer og all oppførsel identisk med mindre jeg sier noe annet". For refaktoreringer, be om en før/etter-diff med én linje om hvorfor hver endring bevarer oppførselen, slik at enhver ubedt endring blir tydelig i gjennomgangen.

Er kopier-lim-inn-promptbiblioteker verdt det?

Som et utgangspunkt, noen ganger. Som et ferdig verktøy, sjelden. Et bibliotek med 50 prompter gir deg formuleringer, men det kan ikke kjenne filene dine, testene dine eller begrensningene dine, som er der korrektheten faktisk ligger. Lær mønstrene, behold én tilpassbar mal, og fyll inn detaljene for oppgaven foran deg.