Prompt Engineering til kodning: 7 mønstre, vi bruger dagligt i Claude Code og Cursor (2026)

Prompt Engineering til kodning: 7 mønstre, vi bruger dagligt i Claude Code og Cursor (2026)

Prompt engineering til kodning er forskellen mellem en agent, der leverer en fungerende pull request, og en, der stille og roligt ødelægger noget i produktionen. Vi lærte det på den hårde måde: En vag instruktion i vores egen pipeline skabte engang 54 duplikerede live-sider, før nogen lagde mærke til det. I dag skriver, oversætter og publicerer en opsætning med 16 Claude Code-agenter vores indhold, og de prompts, der driver det, ligner slet ikke de lister med 50 skabeloner, man finder på første side af Google. Her er de 7 mønstre, vi taster ind hver dag, hver med et ægte før-og-efter eksempel.

Kort svar: Gode kodningsprompts har én fælles form. Du angiver målet og definitionen af "færdig", navngiver de præcise filer, der er i scope, tvinger en plan frem før enhver ændring, overdrager testene og kræver beviser i stedet for et "ser godt ud". Gør du det, vil en moderne agent (Claude Code, Cursor, GitHub Copilot) oftere skrive kode, der består review første gang. Undlader du det, får du selvsikkert, plausibel vrøvl.

De 7 mønstre, i den rækkefølge vi griber efter dem:

1. Opgaveformulering: mål, begrænsninger og "færdig" fra starten
2. Kontekstvalg: navngiv filerne, afskærm resten
3. Plan-først: få den til at foreslå, før den redigerer
4. Test-først: læg accepttestene ind i prompten
5. Fejlfinding: fejl plus reproduktion plus forventet resultat, rodårsag før fix
6. Refaktorering: ændr strukturen, behold adfærden, vis diff'en
7. Review: en tjekliste at søge i, plus beviser

Prompt Engineering til kodning vs. konfigurationsfiler: Hvad hører hvor hen

Konfigurationsfiler og prompts pr. opgave har forskellige jobs, og sammenblanding af dem er den mest almindelige fejl i dette felt. En CLAUDE.md eller en .cursor/rules-fil er stående politik, som agenten læser hver session: din stack, dine navngivningskonventioner, din testkommando. En prompt er det specifikke job, du giver den lige nu. Holdbare regler hører til i config; opgaven hører til i prompten.

De fleste rundups af "kodningsprompts" slører dette og fortæller dig, at du skal indsætte en kæmpe persona-prompt i .cursorrules. Det oppuster den config, agenten indlæser ved hver eneste opgave, og det lykkes stadig ikke at formulere rammen for det ene job, der ligger foran den. Hold de to adskilt:

Hvis du vil have config-delen gjort rigtigt, dækker vi det i dybden i vores CLAUDE.md best practices og Cursor rules guide. Denne artikel er den anden halvdel: de prompts, du taster friskt ind hver gang. Begge dele falder under vores bredere prompt engineering guide, hvis du vil have fundamentet på plads først.

Prompt Engineering til kodning: De 7 mønstre, vi bruger dagligt

Hvert mønster nedenfor har den svage version, folk faktisk taster ind, og den stærke version, der giver fungerende kode. Forskellen mellem svag og stærk er næsten altid den samme bevægelse: erstat et ønske med en specifikation.

1. Opgaveformulering: Angiv målet, begrænsningerne og "færdig"

Opgaveformulering betyder at skrive målet, begrænsningerne og hvordan "færdig" ser ud, før agenten rører en linje kode. En agent optimerer efter det, du bogstaveligt talt bad om, så en uklar anmodning giver en uklar patch. Navngiv filen, den adfærd du ønsker, acceptchecket og de ting, den ikke må ændre.

Dette er mønsteret, der kostede os 54 sider. Vores gamle oversættelsesinstruktion var dybest set et ønske:

Weak: Re-translate this post into German and keep the brand names.

Der står intet derinde om, hvad en slug må gøre. Så ved en genkørsel "forbedrede" agenten URL-sluggen, og da en ny slug betyder et nyt dokument, endte vi med to live tyske sider for samme indlæg. Gang det op på tværs af sprog og gamle indlæg, og du får 54 duplikater og en bunke ekskluderinger af duplicate content. Løsningen var en specifikation, ikke et pænere ønske:

Strong: Re-translate this post into German.
- If a German file already exists, copy its existing slug verbatim. Never
  re-derive or "improve" it.
- Before creating any document, look up the existing one by its canonical
  reference and reuse that record.
- If the slug you would generate differs from the live one, STOP and tell me.
  A changed slug creates a second live URL for the same page.

Den stærke prompt navngiver fejlmåden højt. Den ene vane, at sige hvad der ikke må ske og hvorfor, er den enkeltstående mest værdifulde ændring, de fleste teams kan foretage. Vi afslutter også hver opgaveprompt med en eksplicit output-kontrakt ("din sidste besked skal rapportere ordantallet, valideringsscoren og alle berørte filer"), så agenten ved, hvad "færdig" producerer, ikke kun hvad den skal gøre.

2. Kontekstvalg: Navngiv filerne, afskærm resten

Kontekstvalg betyder at fortælle agenten præcis, hvilke filer den skal læse, og hvilke den skal lade være, i stedet for at lade den greppe rundt og fylde sit vindue med støj. Anthropic's egen vejledning er brutal omkring årsagen: kontekstvinduet fyldes hurtigt, og kvaliteten falder, efterhånden som det fyldes, så de fleste best practices eksisterer for at beskytte det (Claude Code best practices).

Weak: Fix the bug in the checkout flow.

Strong: Read only src/checkout/cart.ts and src/checkout/tax.ts. The tax
rounding is wrong for orders over $1,000 (it rounds each line item instead
of the order total). Fix the rounding. Do not touch anything outside
src/checkout/.

Vi afskærmer hårdt. En rigtig linje fra vores agentprompts lyder: "skriv ikke til url-mapping.json, pipeline.md eller config.json, og rør aldrig nogen fil uden for din scratchpad-mappe." Den ene sætning har forhindret mere utilsigtet skade end al oprydning bagefter tilsammen. Når opgaven genuint har brug for live-dokumentation eller ekstra værktøjer, tilføjer vi dem bevidst via MCP-servere i stedet for at håbe, at agenten snubler over den rigtige fil. Og hvis noget af den kontekst kommer fra uden for dit repo, så behandl det som utroværdigt: se vores note om forebyggelse af prompt injection, før du indsætter en scrapet side i en kodningsagent.

3. Plan-først: Få den til at foreslå, før den redigerer

Plan-først prompting får agenten til at give dig en tilgang, før den redigerer noget. I Claude Code er Plan Mode en hard, håndhævet read-only tilstand, ikke en høflig "tænk først", som modellen kan vandre forbi, så den kan bogstaveligt talt ikke skrive, før du godkender planen. At adskille research og planlægning fra eksekvering er den enkeltstående praksis, Anthropic læner sig mest op ad for at undgå at løse det forkerte problem.

Weak: Add rate limiting to the API.

Strong: Before writing any code, give me a numbered plan: which middleware,
where the counters live, how you handle the 429 response and headers, and
which tests you'll add. Wait for my approval before editing.

Hvorfor det virker: planen er billig at læse og billig at rette. At fixe en forkert plan koster én sætning; at fixe forkert kode koster en review-cyklus. Dette passer naturligt sammen med at bede modellen om at ræsonnere trin for trin først (se chain-of-thought prompting), og det er rygraden i de multi-step Claude Code workflows, vi kører for alt, der er ikke-trivielt.

4. Test-først: Læg accepttestene ind i prompten

Test-først prompting lægger acceptkriterierne ind i prompten som konkrete inputs og outputs, så agenten skriver kode mod et mål, du har defineret, frem for et, den har gættet sig til. Indsæt den fejlene test, eller en lille tabel med forventede resultater, og sig "få denne til at bestå uden at redigere testen".

Weak: Write a function to parse ISO 8601 dates.

Strong: Make this failing test pass without changing the test:

  parseIso("2026-07-20T15:00:00Z")   -> Date at that exact UTC instant
  parseIso("2026-07-20")             -> Date at 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> throws RangeError
  parseIso("")                       -> throws RangeError

Return only the function and its imports.

Konkrete eksempler slår adjektiver hver gang. "Håndter edge cases" er et håb; fire rækker med input-til-output er en specifikation, som modellen faktisk kan opfylde, og du kan køre dem, sekundet koden lander.

5. Fejlfinding: Fejl, reproduktion, forventet resultat, rodårsag før fix

En fejlfindingsprompt giver agenten fejlteksten, det input der udløser den, og hvad du forventede, og beder derefter om årsagen før ethvert fix. Springer du det over, patcher agenten symptomet, så buggen blot flytter sig et sted hen, hvor den er mere stille.

Weak: This is throwing an error, fix it.

Strong: This throws on checkout. Here's the stack trace: [paste]. It happens
only when the cart has a discount code AND a gift card (repro: add both, then
check out). Expected: both apply, gift card last. Find the root cause and
explain it in one sentence before you change anything. Do not wrap it in a
try/catch that hides the error.

Linjen "forklar årsagen i én sætning først" gør reelt arbejde. Den tvinger modellen til at forpligte sig på en diagnose, du kan sanity-checke, i stedet for at levere et fix, hvis logik du aldrig ser. Linjen "skjul det ikke i en try/catch" lukker den mest almindelige flugtvej.

6. Refaktorering: Ændr strukturen, behold adfærden, vis diff'en

En refaktoringsprompt begrænser scope'et hårdt: ændr strukturen, behold adfærden identisk, og vis diff'en. Uden en afskærmning "rydder op" agenter i ting, du aldrig bad om, og du mister evnen til at reviewe den ændring, der betød noget.

Weak: Clean up this file.

Strong: Extract the validation logic from submitOrder() into a pure function
validateOrder(). Keep every public signature and all behavior identical.
Change nothing else in this file. Show me a before/after diff and one line
on why each change is behavior-preserving.

Dette er flipsiden af config-vs-prompt opdelingen fra tidligere: dine stående stilregler lever i Cursor rules, men scope'et for denne refaktorering hører til i prompten. "Ændr intet andet" er frasen, der holder refactoringer review-bare.

7. Review: En tjekliste at søge i, plus beviser

En review-prompt giver agenten en tjekliste at søge i og kræver beviser, ikke en dom. "Ser godt ud" er værdiløst; den kommando, den kørte, og det output, den fik, er det ikke. Anthropic siger det klart: få agenten til at vise beviser (testoutputtet, kommandoen og dens resultat) i stedet for at hævde succes, fordi det er hurtigere at læse beviser end at efterkontrollere selv.

Weak: Review my PR.

Strong: Check this diff against exactly these five items:
1. No secrets or API keys added
2. Every new function has a test
3. No behavior change outside src/checkout/
4. Error paths return typed errors, not strings
5. No console.log left behind
For each item, quote the line that satisfies or violates it. Then run the
test suite and paste the output. Do not say "done"; show me.

Vores egen review-gate er bygget præcis på denne måde. Før en agent får lov til at rapportere et indlæg som publiceret, søger den i kladden mod en liste over forbudte ord (en hard blocker, nul tolerance) og kører en query for at bekræfte, at dokumentets body ikke er tom. Agenten får ikke lov til at hævde succes; den skal producere check-outputtet. For reviewer-roller, du genbruger meget, kan du promovere tjeklisten til en gemt persona, hvilket er hvor system prompt examples kommer ind.

Claude Code vs. Cursor vs. Copilot: Hvor hvert mønster hører hjemme

Alle tre store 2026-agenter understøtter hvert mønster ovenfor, men overfladen er forskellig. Claude Code læner sig op ad Plan Mode og subagenter, Cursor op ad Agent mode og dets Agents-vindue, og GitHub Copilot op ad agent mode plus instruktionsfiler. Vælg det værktøj, dit team lever i; mønstrene porteres rent.

Nogle aktuelle detaljer, det er værd at vide. Claude Codes Plan Mode er en ægte read-only lås, og dens subagenter kører hver i en isoleret kontekst med deres egne værktøjer (subagents docs). Cursors 2026-linje tilføjede et Agents-vindue, der spinner parallelle agenter op, hver i sin egen git worktree (Cursor 2.0). GitHub Copilots agent mode læser custom instructions fra .github/copilot-instructions.md, plus sti-scoped .instructions.md-filer med et applyTo-felt (Copilot custom instructions). Hvis Cursor er din daily driver, se vores indlæg om brug af Cursor mere effektivt.

Hvordan vi promoter vores kodningsagenter hos Techsy

Vi kører en content pipeline som et team af 16 Claude Code-agenter: en researcher, en brief-writer, en content writer, ni oversættere, en validator og en publisher, koordineret gennem task-beskeder. To konventioner fra det system overføres til ethvert kodningsteam.

For det første slutter hver opgaveprompt med en output-kontrakt. Den sidste linje er altid en version af "din sidste besked skal rapportere X, Y og Z." En agent, der ved den præcise form på "færdig", vandrer langt mindre end en, der kun får at vide, hvad den skal starte med.

For det andet lader vi aldrig en agent bedømme sit eget hjemmearbejde i prosa. Generering og verifikation er separate trin, og verifikationen er en kommando med output, ikke en mening. Den adskillelse af build og check er central for, hvordan Anthropic rammer bygning af pålidelige agenter, og det er derfor, vores review-gate searcher og querier i stedet for at stole på et "ser godt ud".

Dette er også vores daglige job. Hos Techsy bygger vi AI-agenter og automation for B2B-teams, og prompt-disciplin som denne er det meste af, der adskiller en demo fra noget, du kan stille foran en klient. Hvis du vil have en kodnings- eller agent-workflow sat ordentligt op, er vores AI integration service stedet, hvor vi gør netop det, og du kan booke en gratis konsultation for at tale igennem din stack.

En copy-paste prompt-skabelon, du kan tilpasse

Her er skelettet, vi starter fra for enhver ikke-triviel kodningsopgave. Slet de sektioner, du ikke har brug for, men behold rækkefølgen, fordi den spejler de syv mønstre.

GOAL
One sentence: what should be true when you're done.

CONTEXT
Read only: <exact files>. Ignore everything else.
Relevant facts: <constraints, versions, the bug's trigger>.

PLAN FIRST
Before editing, give me a numbered plan and wait for approval.

TESTS / DONE
Done means: <paste failing test or input->output rows>.
Don't change the tests.

CONSTRAINTS
Keep all public signatures and behavior identical unless stated.
Do not touch <files/areas>. Name any assumption you make.

OUTPUT
Show a before/after diff, run the tests, and paste the output.
Don't say "done"; show the evidence.

Gem det som et snippet, eller endnu bedre, split det op: de stående begrænsninger hører til i din konfigurationsfil, og målet, konteksten og testene hører til i prompten. Den opsplitning er hele pointen.

Ofte stillede spørgsmål

Hvad er prompt engineering til kodning?

Prompt engineering til kodning er praksissen med at skrive instruktioner, der får en AI-agent til at producere korrekt, review-bar kode. I praksis betyder det at angive målet og definitionen af "færdig", navngive filerne i scope, tvinge en plan frem før edits, levere tests og kræve beviser. Det ligner mere at skrive en specifikation end at skrive en clever sætning.

Hvordan er det anderledes end at skrive en CLAUDE.md eller .cursor/rules fil?

Konfigurationsfiler indeholder stående politik, som agenten læser hver session: din stack, konventioner og testkommando. En prompt pr. opgave er det specifikke job, du giver den lige nu. Put holdbare regler i config og opgaven i prompten. At paste hele opgaveprompts ind i en konfigurationsfil oppuster hver session og lykkes stadig ikke med at formulere rammen for den individuelle opgave.

Hvad er den bedste prompt-struktur for AI-kodningsagenter?

Brug mærkede sektioner i stedet for ét afsnit: GOAL, CONTEXT, PLAN, TESTS, CONSTRAINTS og OUTPUT. Agenter parser strukturerede prompts mere pålideligt end murbrokke af tekst. Angiv succeskriterier fra starten, giv ét til tre konkrete eksempler i stedet for adjektiver, og specificér det præcise output-format, du vil have tilbage.

Hvordan skriver jeg en god fejlfindingsprompt?

Giv agenten fire ting: den nøjagtige fejl eller stack trace, det input der reproducerer den, hvad du forventede, og en anmodning om rodårsagen før ethvert fix. Tilføj "forklar årsagen i én sætning, før du ændrer noget", så du kan tjekke diagnosen, og "skjul det ikke i en try/catch", så den fixer i stedet for at maskere bugen.

Skal jeg inkludere tests i mine kodningsprompts?

Ja, når du kan. At paste den fejlene test eller en lille tabel med input-til-output rækker gør en vag anmodning til et mål, som modellen faktisk kan ramme, og du kan køre resultatet med det samme. Fortæl agenten, at den skal få testene til at bestå uden at redigere dem, så den ikke kan flytte målstolperne for at få sin egen kode til at se korrekt ud.

Virker disse prompts også i Cursor og GitHub Copilot?

Ja. Mønstrene er værktøjs-agnostiske. Claude Code eksponerer dem gennem Plan Mode og subagenter, Cursor gennem Agent mode og dets Agents-vindue med en worktree pr. agent, og GitHub Copilot gennem agent mode plus .github/copilot-instructions.md. Overfladen ændrer sig; opgaveformulering, kontekstvalg, plan-først og evidensbaseret review gør det ikke.

Hvor lang skal en kodningsprompt være?

Lang nok til at være en specifikation, kort nok til at forblive fokuseret. Ræsonneringskvaliteten degraderes, efterhånden som konteksten fyldes, så favoriser struktur over volumen: en mærket prompt på 150-300 ord med de rigtige filer og tests slår en langtrukken en. Flyt alt, der gælder for hver opgave, ind i din konfigurationsfil i stedet for at gentage det.

Hvordan stopper jeg en AI-agent fra at ændre kode, jeg ikke bad om?

Afskærm scope'et i prompten. Sig præcis, hvilke filer den må redigere, tilføj "ændr intet andet", og kræv "behold alle offentlige signaturer og adfærd identisk, medmindre jeg siger andet". For refactoringer, bed om en før/efter diff med én linje om, hvorfor hver ændring bevarer adfærden, så enhver uønsket edit er åbenlys i review.

Er copy-paste prompt-biblioteker det værd?

Som udgangspunkt, nogle gange. Som et færdigt værktøj, sjældent. Et bibliotek med 50 prompts giver dig formuleringer, men det kan ikke kende dine filer, dine tests eller dine begrænsninger, hvilket er hvor korrektheden faktisk lever. Lær mønstrene, behold én tilpasningsdygtig skabelon, og fyld specifika for opgaven foran dig ind.