Prompt engineering för kodning är skillnaden mellan en agent som levererar en fungerande pull request och en som tyst förstör något i produktion. Vi lärde oss det på det dyra sättet: en vag instruktion i vår egen pipeline skapade en gång 54 duplicerade, live sidor innan någon märkte det. Numera skriver, översätter och publicerar en uppsättning med 16 Claude Code-agenter vårt innehåll, och promptarna som styr det ser inte ut som 50-mall-listorna på Googles första sida. Här är de 7 mönster vi skriver varje dag, vart och ett med ett riktigt före-och-efter.
Kort svar: Bra kodningsprompter delar en och samma form. Du anger målet och definitionen av "klart", namnger exakt vilka filer som ingår, tvingar fram en plan innan någon redigering, lämnar över testerna och kräver bevis istället för ett "ser bra ut". Gör det, och en modern agent (Claude Code, Cursor, GitHub Copilot) skriver kod som klarar granskningen på första försöket mycket oftare. Hoppa över det, och du får självsäkert, skenbart trovärdigt skräp.
De 7 mönstren, i den ordning vi tar till dem:
- Uppgiftsinramning: mål, begränsningar och "klart" i förväg
- Kontextval: namnge filerna, stäng ute resten
- Plan-först: låt den föreslå innan den redigerar
- Test-först: lägg acceptanstesterna i prompten
- Felsökning: fel plus repro plus förväntat resultat, grundorsak före fix
- Refaktorering: ändra strukturen, behåll beteendet, visa diffen
- Granskning: en checklista att grep:a mot, plus bevis
Prompt Engineering för Kodning vs. Konfigurationsfiler: Vad Hör Hemma Var
Konfigurationsfiler och uppgiftsprompter gör olika jobb, och att blanda ihop dem är det vanligaste misstaget på det här området. En CLAUDE.md- eller .cursor/rules-fil är stående policy som agenten läser varje session: din stack, dina namnkonventioner, ditt testkommando. En prompt är den specifika uppgiften du ger den just nu. Varaktiga regler hör hemma i konfigurationen; uppgiften hör hemma i prompten.
De flesta artiklar om "kodningsprompter" suddar ut den här gränsen och ber dig klistra in en gigantisk personaprompt i .cursorrules. Det blåser upp konfigurationen agenten laddar in vid varje enskild uppgift, och löser fortfarande inte att rama in jobbet som faktiskt ligger framför den. Håll de två åtskilda:
| Konfigurationsfil (CLAUDE.md, .cursor/rules) | Uppgiftsprompt | |
|---|---|---|
| Innehåller | Stående regler: stack, stil, testkommando, skyddsräcken | Den specifika uppgiften: vad som ska byggas eller fixas, just nu |
| Laddas | Automatiskt, varje session | En gång, när du skriver den |
| Ändras | Sällan, granskas som kod | Varje uppgift |
| Exempel | "Kör pnpm test innan du hävdar att det är klart" | "Fixa skatteavrundningen i cart.ts för beställningar över $1,000" |
Om du vill ha konfigurationssidan gjord ordentligt går vi igenom den på djupet i vår CLAUDE.md-guide för bästa praxis och Cursor rules-guide. Den här artikeln är den andra halvan: promptarna du skriver från grunden varje gång. Båda hör hemma under vår bredare guide till prompt engineering om du vill ha grunderna först.
Prompt Engineering för Kodning: De 7 Mönster Vi Använder Dagligen
Varje mönster nedan har den svaga versionen folk faktiskt skriver och den starka versionen som ger fungerande kod. Gapet mellan svag och stark är nästan alltid samma grepp: byt ut en önskan mot en specifikation.
1. Uppgiftsinramning: Ange Målet, Begränsningarna och Vad "Klart" Betyder
Uppgiftsinramning betyder att skriva målet, begränsningarna och hur "klart" ser ut innan agenten rör en enda rad. En agent optimerar för exakt det du bokstavligen bad om, så en luddig förfrågan ger en luddig patch. Namnge filen, beteendet du vill ha, acceptanskontrollen och det som inte får ändras.
Det här är mönstret som kostade oss 54 sidor. Vår gamla översättningsinstruktion var i praktiken bara en önskan:
Svag: Översätt det här inlägget till tyska igen och behåll varumärkesnamnen.Ingenting där säger vad en slug får göra. Så vid en ny körning "förbättrade" agenten URL-sluggen, och eftersom en ny slug betyder ett nytt dokument slutade vi med två live tyska sidor för samma inlägg. Multiplicera det över språk och gamla inlägg och du får 54 dubbletter och en hög med exkluderingar för duplicerat innehåll. Lösningen var en specifikation, inte en snyggare önskan:
Stark: Översätt det här inlägget till tyska igen.
- Om en tysk fil redan finns, kopiera dess befintliga slug ordagrant. Härled
eller "förbättra" den aldrig på nytt.
- Innan du skapar något dokument, slå upp det befintliga via dess kanoniska
referens och återanvänd den posten.
- Om sluggen du skulle generera skiljer sig från den som är live, STOPPA och
säg till. En ändrad slug skapar en andra live-URL för samma sida.Den starka prompten säger felläget rakt ut. Just den vanan, att säga vad som inte får hända och varför, är den enskilt mest värdefulla förändringen de flesta team kan göra. Vi avslutar också varje uppgiftsprompt med ett explicit output-kontrakt ("ditt sista meddelande måste rapportera ordantalet, valideringspoängen och eventuella filer som berörts"), så att agenten vet vad "klart" ska producera, inte bara vad den ska göra.
2. Kontextval: Namnge Filerna, Stäng Ute Resten
Kontextval betyder att tala om för agenten exakt vilka filer den ska läsa och vilka den ska lämna ifred, i stället för att låta den greppa runt och fylla sitt fönster med brus. Anthropics egen vägledning är rakt på sak om anledningen: kontextfönstret fylls snabbt och kvaliteten sjunker allteftersom det fylls, så de flesta bästa praxis finns för att skydda det (Claude Codes bästa praxis).
Svag: Fixa buggen i kassaflödet.
Stark: Läs bara src/checkout/cart.ts och src/checkout/tax.ts.
Skatteavrundningen är fel för beställningar över $1,000 (den avrundar varje
radpost istället för ordertotalen). Fixa avrundningen. Rör ingenting
utanför src/checkout/.Vi stänger av hårt. En riktig rad från våra agentprompter lyder: "skriv inte till url-mapping.json, pipeline.md eller config.json, och rör aldrig en fil utanför din scratchpad-mapp." Den enda meningen har förhindrat mer oavsiktlig skada än all upprensning i efterhand tillsammans. När uppgiften verkligen behöver levande dokument eller extra verktyg lägger vi till dem medvetet via MCP-servrar i stället för att hoppas att agenten snubblar över rätt fil. Och om något av den kontexten kommer utifrån ditt repo, behandla den som obetrodd: se vår notis om prompt injection-skydd innan du klistrar in en skrapad sida i en kodningsagent.
3. Plan-Först: Låt Den Föreslå Innan Den Redigerar
Plan-först-prompting får agenten att ge dig ett tillvägagångssätt innan den redigerar något. I Claude Code är Plan Mode ett hårt, tvingande skrivskyddat läge, inte ett artigt "tänk först" som modellen kan vandra förbi, så den kan bokstavligen inte skriva förrän du godkänt planen. Att skilja research och planering från utförande är den enskilda praxis Anthropic lutar sig mest mot för att undvika att lösa fel problem.
Svag: Lägg till rate limiting på API:et.
Stark: Innan du skriver någon kod, ge mig en numrerad plan: vilken
middleware, var räknarna ska ligga, hur du hanterar 429-svaret och
headers, och vilka tester du kommer lägga till. Vänta på mitt godkännande
innan du redigerar.Varför det fungerar: planen är billig att läsa och billig att rätta till. Att fixa en felaktig plan kostar en mening; att fixa felaktig kod kostar en hel granskningsrunda. Det här går hand i hand med att be modellen resonera steg för steg först (se chain-of-thought-prompting), och det är ryggraden i de flerstegsprocesser med Claude Code-arbetsflöden vi kör för allt som inte är trivialt.
4. Test-Först: Lägg Acceptanstesterna i Prompten
Test-först-prompting lägger acceptanskriterierna i prompten som konkreta indata och utdata, så att agenten skriver kod mot ett mål du har definierat i stället för ett den har gissat sig till. Klistra in det felande testet, eller en liten tabell med förväntade resultat, och säg "få det här att passera utan att ändra testet."
Svag: Skriv en funktion som parsar ISO 8601-datum.
Stark: Få det här felande testet att passera utan att ändra testet:
parseIso("2026-07-20T15:00:00Z") -> Date vid exakt det UTC-ögonblicket
parseIso("2026-07-20") -> Date vid 2026-07-20T00:00:00Z
parseIso("not-a-date") -> kastar RangeError
parseIso("") -> kastar RangeError
Returnera bara funktionen och dess imports.Konkreta exempel slår adjektiv varje gång. "Hantera edge cases" är ett hopp; fyra rader med indata-till-utdata är en specifikation modellen faktiskt kan uppfylla, och du kan köra dem i samma sekund koden landar.
5. Felsökning: Fel, Repro, Förväntat Resultat, Grundorsak Före Fix
En felsökningsprompt ger agenten feltexten, indatan som utlöser den och vad du förväntade dig, och ber sedan om orsaken innan någon fix. Hoppa över det, och agenten lappar ihop symtomet, så att buggen bara flyttar sig någonstans tystare.
Svag: Det här kastar ett fel, fixa det.
Stark: Det här kastar fel vid checkout. Här är stack-tracet: [klistra in].
Det händer bara när kundvagnen har en rabattkod OCH ett presentkort (repro:
lägg till båda, gå sedan till checkout). Förväntat: båda gäller, presentkort
sist. Hitta grundorsaken och förklara den i en mening innan du ändrar
något. Slå inte in det i en try/catch som döljer felet.Raden "förklara orsaken i en mening först" gör verklig nytta. Den tvingar modellen att binda sig till en diagnos du kan förnuftsgranska, i stället för att leverera en fix vars logik du aldrig ser. Raden "dölj den inte i en try/catch" stänger den vanligaste flyktvägen.
6. Refaktorering: Ändra Strukturen, Behåll Beteendet, Visa Diffen
En refaktoreringsprompt begränsar omfattningen hårt: ändra strukturen, håll beteendet identiskt och visa diffen. Utan en avgränsning "städar" agenter saker du aldrig bad om, och du förlorar möjligheten att granska den ändring som faktiskt betydde något.
Svag: Städa upp den här filen.
Stark: Extrahera valideringslogiken från submitOrder() till en ren funktion
validateOrder(). Håll alla publika signaturer och allt beteende identiskt.
Ändra ingenting annat i den här filen. Visa mig en före/efter-diff och en
rad om varför varje ändring bevarar beteendet.Det här är baksidan av uppdelningen mellan konfiguration och prompt från tidigare: dina stående stilregler hör hemma i Cursor rules, men omfattningen av den här refaktoreringen hör hemma i prompten. "Ändra ingenting annat" är frasen som håller refaktoreringar granskningsbara.
7. Granskning: En Checklista Att Grep:a Mot, Plus Bevis
En granskningsprompt ger agenten en checklista att grep:a mot och kräver bevis, inte ett omdöme. "Ser bra ut" är värdelöst; kommandot den körde och resultatet den fick är det inte. Anthropic säger det rakt ut: låt agenten visa bevis (testresultatet, kommandot och dess utfall) i stället för att påstå framgång, eftersom det går snabbare att läsa bevis än att verifiera själv på nytt.
Svag: Granska min PR.
Stark: Kontrollera den här diffen mot exakt dessa fem punkter:
1. Inga hemligheter eller API-nycklar tillagda
2. Varje ny funktion har ett test
3. Ingen beteendeändring utanför src/checkout/
4. Felvägar returnerar typade fel, inte strängar
5. Ingen console.log kvarlämnad
För varje punkt, citera raden som uppfyller eller bryter mot den. Kör
sedan testsviten och klistra in resultatet. Säg inte "klart"; visa mig.Vår egen granskningsgrind är byggd på exakt det här sättet. Innan en agent får rapportera ett inlägg som publicerat, grep:ar den utkastet mot en lista över förbjudna ord (en hård spärr, noll tolerans) och kör en fråga för att bekräfta att dokumentkroppen inte är tom. Agenten får inte påstå framgång; den måste producera kontrollresultatet. För granskarroller du återanvänder ofta, gör checklistan till en sparad persona, vilket är där system prompt-exempel kommer in.
Claude Code vs. Cursor vs. Copilot: Var Varje Mönster Lever
Alla tre stora 2026-agenter stöder varje mönster ovan, men ytan skiljer sig. Claude Code lutar sig mot Plan Mode och underagenter, Cursor mot Agent mode och sitt Agents-fönster, och GitHub Copilot mot agent mode plus instruktionsfiler. Välj verktyget ditt team lever i; mönstren överförs rent.
| Mönster | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| Stående regler | CLAUDE.md | .cursor/rules | .github/copilot-instructions.md, AGENTS.md |
| Plan-först | Plan Mode (tvingande skrivskyddat) | Plan-steg i Agent mode | Förhandsgranska plan före tillämpning |
| Avgränsat/parallellt arbete | Underagenter, egen kontext var | Agents-fönster, worktree per agent | Cloud agent-uppgifter |
| Sökvägsavgränsade regler | Nästlad CLAUDE.md per katalog | Rule globs | .instructions.md med applyTo |
Några aktuella detaljer värda att känna till. Claude Codes Plan Mode är ett äkta skrivskyddat lås, och dess underagenter körs var och en i en isolerad kontext med sina egna verktyg (dokumentation om underagenter). Cursors 2026-linje lade till ett Agents-fönster som startar parallella agenter, var och en i sin egen git-worktree (Cursor 2.0). GitHub Copilots agent mode läser anpassade instruktioner från .github/copilot-instructions.md, plus sökvägsavgränsade .instructions.md-filer med ett applyTo-fält (Copilots anpassade instruktioner). Om Cursor är ditt huvudverktyg, se vårt inlägg om att använda Cursor mer effektivt.
Så Promptar Vi Våra Kodningsagenter på Techsy
Vi kör en innehållspipeline som ett team på 16 Claude Code-agenter: en researcher, en brief-skribent, en innehållsskribent, nio översättare, en validator och en publicerare, koordinerade genom uppgiftsmeddelanden. Två konventioner från det systemet går att överföra till vilket kodningsteam som helst.
För det första avslutas varje uppgiftsprompt med ett output-kontrakt. Sista raden är alltid någon version av "ditt sista meddelande måste rapportera X, Y och Z." En agent som känner till den exakta formen på "klart" vandrar iväg betydligt mindre än en som bara fått veta vad den ska börja med.
För det andra låter vi aldrig en agent betygsätta sin egen läxa i löptext. Generering och verifiering är separata steg, och verifieringen är ett kommando med resultat, inte en åsikt. Den uppdelningen mellan att bygga och att kontrollera är kärnan i hur Anthropic ramar in att bygga pålitliga agenter, och det är därför vår granskningsgrind grep:ar och frågar i stället för att lita på ett "ser bra ut".
Det här är också vårt dagliga jobb. På Techsy bygger vi AI-agenter och automation för B2B-team, och promptdisciplin som den här är det mesta av det som skiljer en demo från något du kan visa upp för en kund. Om du vill ha ett kodnings- eller agentarbetsflöde ordentligt uppsatt är vår AI-integrationstjänst där vi gör precis det, och du kan boka en kostnadsfri konsultation för att gå igenom din stack.
En Kopiera-Klistra-In-Promptmall Du Kan Anpassa
Här är skelettet vi utgår från för varje icke-trivial kodningsuppgift. Ta bort sektionerna du inte behöver, men behåll ordningen, eftersom den speglar de sju mönstren.
MÅL
En mening: vad ska vara sant när du är klar.
KONTEXT
Läs bara: <exakta filer>. Ignorera allt annat.
Relevanta fakta: <begränsningar, versioner, det som utlöser buggen>.
PLAN FÖRST
Innan du redigerar, ge mig en numrerad plan och vänta på godkännande.
TESTER / KLART
Klart betyder: <klistra in felande test eller indata->utdata-rader>.
Ändra inte testerna.
BEGRÄNSNINGAR
Håll alla publika signaturer och allt beteende identiskt om inget annat
sägs. Rör inte <filer/områden>. Namnge varje antagande du gör.
UTDATA
Visa en före/efter-diff, kör testerna och klistra in resultatet.
Säg inte "klart"; visa bevisen.Spara den som en snippet, eller ännu hellre: dela upp den. De stående begränsningarna hör hemma i konfigurationsfilen din, och målet, kontexten och testerna hör hemma i prompten. Den uppdelningen är hela poängen.
Om Skribenten
Mert Batur Gurbuz är medgrundare av Techsy.io, där teamet levererar AI-agenter, automationssystem och röst-/SDR-pipelines för B2B-kunder. Han studerar vid University of Birmingham och skriver om den LLM-verktygsstack Techsy-teamet faktiskt använder i produktion. Anslut på LinkedIn.
Vanliga Frågor
Vad är prompt engineering för kodning?
Prompt engineering för kodning är praktiken att skriva instruktioner som får en AI-agent att producera korrekt, granskningsbar kod. I praktiken betyder det att ange målet och definitionen av "klart", namnge filerna som ingår, tvinga fram en plan innan redigering, tillhandahålla tester och kräva bevis. Det ligger närmare att skriva en specifikation än att skriva en smart mening.
Hur skiljer det sig från att skriva en CLAUDE.md- eller .cursor/rules-fil?
Konfigurationsfiler håller stående policy agenten läser varje session: din stack, dina konventioner och ditt testkommando. En uppgiftsprompt är den specifika uppgiften du ger den just nu. Lägg varaktiga regler i konfigurationen och uppgiften i prompten. Att klistra in hela uppgiftsprompter i en konfigurationsfil blåser upp varje session och lyckas fortfarande inte rama in den enskilda uppgiften.
Vad är den bästa promptstrukturen för AI-kodningsagenter?
Använd märkta sektioner i stället för ett enda stycke: MÅL, KONTEXT, PLAN, TESTER, BEGRÄNSNINGAR och UTDATA. Agenter tolkar strukturerade prompter mer tillförlitligt än textväggar. Ange framgångskriterierna direkt, ge ett till tre konkreta exempel i stället för adjektiv, och specificera det exakta utdataformatet du vill ha tillbaka.
Hur skriver jag en bra felsökningsprompt?
Ge agenten fyra saker: det exakta felet eller stack-tracet, indatan som återskapar det, vad du förväntade dig, och en begäran om grundorsaken innan någon fix. Lägg till "förklara orsaken i en mening innan du ändrar något" så att du kan kontrollera diagnosen, och "dölj den inte i en try/catch" så att den fixar i stället för att maskera buggen.
Bör jag inkludera tester i mina kodningsprompter?
Ja, närhelst du kan. Att klistra in det felande testet eller en liten tabell med indata-till-utdata-rader förvandlar en vag förfrågan till ett mål modellen faktiskt kan träffa, och du kan köra resultatet omedelbart. Säg till agenten att få testerna att passera utan att ändra dem, så att den inte kan flytta målstolparna för att få sin egen kod att se korrekt ut.
Fungerar de här prompterna i Cursor och GitHub Copilot också?
Ja. Mönstren är verktygsagnostiska. Claude Code exponerar dem via Plan Mode och underagenter, Cursor via Agent mode och sitt Agents-fönster med en worktree per agent, och GitHub Copilot via agent mode plus .github/copilot-instructions.md. Ytan förändras; uppgiftsinramning, kontextval, plan-först och bevisbaserad granskning gör det inte.
Hur lång bör en kodningsprompt vara?
Tillräckligt lång för att vara en specifikation, tillräckligt kort för att hålla fokus. Resonemangskvaliteten försämras allteftersom kontexten fylls, så prioritera struktur framför volym: en märkt prompt på 150 till 300 ord med rätt filer och tester slår en svamlig en. Flytta allt som gäller för varje uppgift till konfigurationsfilen din i stället för att upprepa det.
Hur stoppar jag en AI-agent från att ändra kod jag inte bad om?
Avgränsa omfattningen i prompten. Säg exakt vilka filer den får redigera, lägg till "ändra ingenting annat", och kräv "håll alla publika signaturer och allt beteende identiskt om jag inte säger något annat". Vid refaktoreringar, be om en före/efter-diff med en rad om varför varje ändring bevarar beteendet, så att varje obedd ändring blir uppenbar i granskningen.
Är kopiera-klistra-in-promptbibliotek värda det?
Som en startpunkt, ibland. Som ett färdigt verktyg, sällan. Ett bibliotek med 50 prompter ger dig formuleringar, men det kan inte känna till dina filer, dina tester eller dina begränsningar, vilket är där korrektheten faktiskt bor. Lär dig mönstren, behåll en anpassningsbar mall, och fyll i detaljerna för uppgiften framför dig.