Prompt Engineering 2026: 10 tekniker som fortfarande fungerar (och 4 som dog med reasoning-modeller)

Prompt Engineering 2026: 10 tekniker som fortfarande fungerar (och 4 som dog med reasoning-modeller)

Prompt engineering dog inte 2026. Det klövs i två. OpenAIs egen dokumentation om reasoning säger nu rakt ut att du ska sluta skriva "think step by step", och en arXiv-artikel från 2024 (2410.21333) mätte en träffsäkerhet som föll med hela 36,3 % när chain-of-thought tvingades in i fel uppgift. Det är den udda detaljen. Den avslappnade halvan av prompt engineering blev enklare, medan produktionshalvan - den som körs på GPT-5 och Claude - blev betydligt mer rigorös. Den här guiden sorterar de 10 tekniker som fortfarande är värda din tid från de 4 vanor som reasoning-modeller pensionerade.

Nyckelpunkter:

• Prompt engineering klövs 2026 i avslappnad prompting (enklare) och produktionsprompting (mer rigorös).
• På reasoning-modeller är det överflödigt att tvinga fram "think step by step", och det kan sänka träffsäkerheten. OpenAI säger uttryckligen: undvik det.
• Fyra vanor pensionerades: CoT-tvingande, reflexmässigt tungt few-shot, response prefilling och manuell justering av budget_tokens.
• Det som fortfarande vinner: tydlighet, structured outputs, uppgiftsnedbrytning och evalueringsdriven iteration.

Vad prompt engineering faktiskt är 2026

Prompt engineering är praktiken att utforma och finslipa de instruktioner du ger en språkmodell för att få träffsäker, relevant output. Kärntekniker omfattar zero-shot, few-shot, chain-of-thought och rollprompting. 2026 delas det upp i två jobb: avslappnad prompting i en chatt, och produktionsprompting inuti ett system.

Det ingen sa högt förrän i år: det är två olika färdigheter. Att få ett bra svar i ChatGPT är numera nästan trivialt, för modellerna förlåter slarvig formulering. Att få ett pålitligt svar från ett system som körs tusen gånger om dagen, på tio språk, utan att någon människa håller ett öga på det - det är inte trivialt. Det andra jobbet är vad den här guiden handlar om.

Vi skriver för produktionsbandet: utvecklare och AI-ingenjörer som behöver instruktioner som håller på GPT-5, Claude Opus 4.8 och Gemini. Introt, den här definitionen och FAQ:n är läsbara för alla andra. Vill du ha den neutrala taxonomin över varje namngiven teknik är dair-ais promptingguide.ai-referens fortfarande det bästa uppslagsverket på nätet. 2026 är prompt engineering inte en färdighet. Det är två.

Prompt engineering kontra context engineering: vad är skillnaden?

Prompt engineering handlar om att utforma instruktionen. Context engineering handlar om att designa allt annat som finns i kontextfönstret runt den: retrieval, minne, verktyg, ordning. Prompt engineering är en delmängd av context engineering. Den här guiden täcker instruktionshalvan; den länkade guiden täcker resten.

Så vilken av dem behöver du? Om din kontext är statisk och ryms i ett enda meddelande räcker prompt engineering gott och väl. I samma stund som din indata ändras per anrop har du klivit in i context engineering, och prompt engineering blir bara ett verktyg inuti den. Vi ritade upp hela bilden i vår kompletta guide till context engineering; det här inlägget håller sig på instruktionssidan av linjen.

En notering för entitetssamlarna: Googles autokomplettering delar numera upp det här i fyra ingenjörsdiscipliner, och vi täcker de två första, prompt och context. Enkelt uttryckt: prompt engineering är att välja rätt ord för frågan; context engineering är att bestämma vad som ligger på skrivbordet innan frågan ens ställs.

De 10 grundläggande teknikerna för att utforma prompter (rankade efter ROI 2026)

De tio teknikerna värda att kunna 2026, ungefär ordnade efter avkastning på ansträngning: zero-shot, few-shot, rollprompting, chain-of-thought, uppgiftsnedbrytning, prompt chaining, self-consistency, structured outputs, promptmallar och meta-prompting. Några är dagliga arbetshästar; två beter sig annorlunda på reasoning-modeller, vilket nästa avsnitt reder ut.

Namnen nedan följer taxonomin i "The Prompt Report", en systematisk genomgång av över 50 prompttekniker. Se det här som en verktygslåda du plockar ur, inte en checklista du kör uppifrån och ner.

1. Zero-shot-prompting

Zero-shot innebär att du ger en tydlig instruktion utan exempel och låter modellen lista ut resten själv. På 2026 års modeller är det här ditt förstahandsval, för en precis, specifik instruktion slår oftast en rörig en. Tricket är inte magiska formuleringar, det är att eliminera tvetydighet: säg vilken output du vill ha, i vilket format, för vem.

# Target: GPT-5 / Claude Opus 4.8
Classify this support ticket as: billing, technical, or account.
Return only the single lowercase label.

Ticket: "My card was charged twice this month."

2. Few-shot-prompting

Few-shot innebär att du inkluderar två till fem exempel för att forma det format eller beteende du vill ha. Det är det snabbaste sättet att låsa fast en output-stil som modellen annars glider ifrån. En brasklapp: på reasoning-modeller säger OpenAIs best practices för reasoning att du ska prova zero-shot först och bara lägga till exempel om de mätbart hjälper. På 2026 års modeller är zero-shot standardvalet och few-shot reservlösningen, inte tvärtom.

# Target: GPT-5
Extract the product and sentiment. Follow the examples.

Input: "The battery dies in an hour." -> product: battery, sentiment: negative
Input: "Setup took two minutes, loved it." -> product: setup, sentiment: positive
Input: "The screen is gorgeous but it's heavy." ->

3. Roll-/personaprompting

Rollprompting fastställer vem modellen är innan den svarar, vilket formar ton, ordval och format mer än det formar det rena resonemanget. "Du är en erfaren skatterådgivare som granskar en deklaration" drar fram andra formuleringar än en tom prompt. Håll det funktionellt, inte teatraliskt. Rollen bör koda in verkliga begränsningar: målgrupp, format, vad som ska uteslutas. Vår kommande samling systemprompt-exempel samlar de mönster vi återanvänder mest.

# Target: Claude Opus 4.8
You are a senior tax accountant. Review the figures below for a
small-business owner who is not an accountant.
Format: 3 bullet points, plain English, flag any number that looks wrong.

4. Chain-of-thought (CoT)

Chain-of-thought ber modellen visa sina resonemangssteg innan det slutgiltiga svaret. På klassiska GPT-stilmodeller är det fortfarande ett av de mest värdefulla knepen för matte, logik och flerstegsproblem. Men på reasoning-modeller kan det vara överflödigt eller till och med skadligt, vilket nästa avsnitt går igenom med riktiga siffror. Vår kommande djupdykning i chain-of-thought-prompting går igenom hela tekniken. Kom ihåg för tillfället: det är inte längre en reflex du applicerar på allt.

5. Uppgiftsnedbrytning

Nedbrytning innebär att du delar upp en stor uppgift i ordnade deluppgifter som modellen hanterar en i taget. Istället för "skriv en lanseringsplan" frågar du efter målgruppen, sedan kanalerna, sedan kalendern. Mindre steg betyder färre ställen där det kan gå fel, och enklare felsökning när det ändå gör det.

# Target: any 2026 model
Task: draft a product launch email.
Work in order and label each step:
1) Identify the audience and their main objection.
2) Write one subject line that answers that objection.
3) Write a 90-word body.
4) End with a single CTA.

6. Prompt chaining

Chaining matar en prompts output in som indata till nästa. Det är nedbrytning omsatt i kod: prompt A extraherar nyckelfakta, prompt B skriver ett utkast utifrån dessa fakta, prompt C kontrollerar utkastet mot en regel. Varje länk är enkel, testbar och utbytbar. När ett steg går bakåt fixar du den länken istället för att reda ut en jättelik monolitprompt.

7. Self-consistency

Self-consistency samplar samma fråga flera gånger och tar sedan majoritetssvaret. Du byter tokens mot tillförlitlighet vid svårt resonemang där en enda körning är opålitlig, men du betalar för tre till fem completions för att få en. På starka reasoning-modeller krymper vinsten ofta, så spara tekniken till genuint tvetydiga uppgifter där att ha rätt väger tyngre än notan.

8. Outputformatering / structured outputs

Structured outputs innebär att du begränsar svaret till ett schema istället för att hoppas att modellen returnerar ren JSON. Det här förtjänar ett eget avsnitt längre ner. Enradsversionen: tigg inte om JSON i prompten - begränsa modellen till ett schema och sluta gissa.

9. Promptmallar och variabler

Mallar förvandlar en bra engångsprompt till en parametriserad, återanvändbar tillgång: fasta instruktioner plus platshållare för de variabla delarna. Så slutar prompter vara ad hoc-text och blir versionerade artefakter du kan testa, vilket är pipeline-historien längre ner. Återanvändbara projektregelfiler, som de cursor rules utvecklare sparar i sina repor, är levande promptmallar under ett annat namn.

10. Meta-prompting

Meta-prompting innebär att du använder en modell för att skriva eller förbättra din prompt. Det har blivit den snabbaste vägen från en tom ruta till ett gediget utkast, och det finns riktig data bakom det, som vi går igenom strax nedan. Kortversionen: börja med ett modellförbättrat utkast, redigera sedan för hand.

Vilka prompttekniker gjorde reasoning-modeller valfria (eller trasiga)?

Fyra vanor som brukade vara bra råd slår nu tillbaka på reasoning-modeller som OpenAIs o-serie, GPT-5 och Claudes thinking-lägen: att tvinga fram explicit chain-of-thought, att som standard stapla tungt few-shot, response prefilling och manuell justering av budget_tokens. Reasoning-modeller tänker redan internt, så att skriptera stegen är överflödigt - och ibland värre än överflödigt.

Var och en dog av en annan anledning.

Att tvinga fram chain-of-thought. OpenAIs best practices för reasoning är raka på sak: "Undvik chain-of-thought-prompter", eftersom de här modellerna resonerar internt, så att be dem "tänka steg för steg" är "onödigt" och "kanske inte förbättrar prestandan (och kan ibland hämma den)." arXiv-artikeln 2410.21333 satte en siffra på nackdelen: upp till 36,3 % lägre absolut träffsäkerhet för o1-preview jämfört med GPT-4o på en uppgift där medvetet steg-för-steg-tänkande faktiskt skadar resultatet. En andra studie, 2412.21187, visar att reasoning-modeller överspenderar beräkningskraft på triviala problem. Vi slutade lägga till "think step by step" i reasoning-modell-prompter för flera månader sedan, och inget blev sämre.

Reflexmässigt tungt few-shot. OpenAIs vägledning är "håll prompter enkla och direkta" och "prova zero-shot först, sedan few-shot om det behövs." Att stapla på exempel som standard kostar numera tokens och kan låsa in en kapabel modell. Lägg till exempel när de mätbart hjälper, inte som en uppvärmningsritual.

Response prefilling. Att lägga ord i munnen på modellen för att tvinga fram ett format brukade vara ett standardknep. På Claude 4.6+, Fable 5 och Mythos 5 stöds inte längre förifyllda assistant-repliker, och de returnerar ett 400-fel, enligt Anthropics best practices för prompting. Använd structured outputs istället, vilket nästa avsnitt täcker.

Manuell mikrostyrning av budget_tokens. Att manuellt sätta en tankebudget i tokens är också avvecklat (ett 400-fel på Opus 4.7+ och nyare). Anthropics modeller använder nu adaptivt tänkande, och du styr ansträngningen med effort-parametern istället för att skriptera ett tal. OpenAI gjorde samma sak: developer messages är de nya system messages, och reasoning effort är en inställning. Det klassiska tricket, "let's think step by step", är nu - på reasoning-modeller - ibland just det som gör dem sämre.

Hur får du pålitlig JSON från en LLM 2026?

Schemabegränsade structured outputs, inte prompt-tiggeri. 2026 är den pålitliga vägen att ge modellen ett JSON-schema och låta API:et garantera giltig output mot det. Att skriva "returnera JSON, tack" i prompten är skört; det avvecklade prefill-knepet är borta. Både OpenAI och Anthropic levererar en structured outputs-funktion för precis det här.

Varför är "returnera giltig JSON, tack" så skört? För att du ber ett probabilistiskt system vara perfekt syntaktiskt på hedersord. En enda felplacerad kommentar eller ett kvarglömt kommatecken och din parser kraschar. Structured Outputs löser det på API-nivå: du skickar med ett schema, och modellen begränsas till att matcha det. Anthropic noterar att nyare modeller "pålitligt kan matcha komplexa scheman när de blir tillsagda."

Här är ett litet, realistiskt svarsschema för en klassificerare av supportärenden:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

Skicka det till OpenAIs eller Anthropics structured outputs och du får tillbaka tolkningsbar JSON varje gång, utan någon retry-loop. För hela mönstret över leverantörsgränserna, inklusive Pydantic- och Zod-validering, se vår guide till att få pålitlig JSON från vilken LLM som helst. 2026 ber du inte en modell om JSON. Du begränsar den till ett schema och slutar hoppas.

Meta-prompting: låt modellen skriva din prompt

Meta-prompting innebär att du använder en LLM för att utforma eller finslipa den prompt du faktiskt ska köra. Det är den snabbaste vägen från en grov idé till en fungerande prompt, och verktygen finns redan inbyggda: Anthropics prompt improver och OpenAIs prompt optimizer skriver båda om ditt utkast enligt best practices. Börja med maskinens version, redigera sedan för hand.

Hjälper det faktiskt, eller är det ett partytrick? Anthropic körde sina egna siffror: deras prompt improver levererade en förbättring på 30 % i träffsäkerhet på ett multilabel-klassificeringstest och 100 % efterlevnad av ordantal på en sammanfattningsuppgift, enligt deras genomgång. OpenAIs prompt optimizer gör samma jobb.

Arbetsflödet vi gillar: beskriv uppgiften, låt verktyget producera ett strukturerat första utkast, finslipa det sedan för hand utifrån din data. Den sista handredigeringen är varför prompter fortfarande behöver en människa och ett test. Det snabbaste sättet till en bättre prompt 2026 är att låta modellen skriva om din, redigera sedan. Inte att stirra på en tom ruta.

Modellspecifik fusklapp för prompting (OpenAI kontra Anthropic kontra Google)

Samma jobb, tre dialekter. OpenAI vill ha developer messages och ingen tvingad chain-of-thought. Anthropic vill ha XML-taggar, adaptivt tänkande och effort-parametern. Googles Gemini vill ha en tankebudget. Reasoning-modeller är dina planerare; klassiska GPT-stilmodeller är dina arbetshästar. Matcha tekniken mot nivån.

Skillnaderna är små men de biter. Hos OpenAI ersatte developer messages det gamla systemmeddelandet för o-serien och uppåt, och dokumentationen styr bort dig från explicit CoT. Hos Anthropic är XML-taggar fortfarande det rekommenderade sättet att strukturera en komplex prompt, och tänkandet är adaptivt som standard. Projektnivåfiler för prompter, som de CLAUDE.md-filer kodteam sparar i sina repor, håller mycket av den här leverantörsspecifika kopplingen. Hos Gemini ger du modellen en tankebudget.

Från prompt till pipeline: mallar, versionering och evaluering

I produktion slutar prompt engineering att handla om ordval och blir en empirisk disciplin. Du versionerar prompter som kod, grindar dem med evals och lägger till regressionstester så att en ändring som tyst förstör outputen fångas upp innan användarna ser den. Det är här prompt engineering möter evaluering, och det är den del som faktiskt avgör om din app fungerar.

Så här ser det ut i ett verkligt system. Den här bloggen körs på en Claude-driven innehållspipeline med 17 specialiserade underagenter, var och en en separat promptad roll: en researcher, en brief-creator, en content-writer, en validator, en language-translator, en sanity-publisher, en image-handler och fler. Över tre av dessa steg - brief, writer och validator - upprätthåller vi 8 skyddsregler mot AI-detektion. Validatorn greppar varje utkast mot en förbjudningslista på 52 fraser, och en enda träff blockerar publicering, understött av ett separat lexikalt kontrollskript. Den pipelinen har levererat runt 194 engelska inlägg över 4 sajter, var och en översatt till upp till 10 språk av parallella per-språk-agenter.

Inget av det kom från smarta formuleringar. Det kom från att behandla prompter som versionerade, eval-grindade artefakter, och två incidenter lärde oss varför.

Den första var en diakritikbugg. Vår översättningsprompt returnerade sporadiskt ASCII istället för Unicode, så det turkiska ordet "karşılaştırma" kom tillbaka som "karsilastirma." Tyst, fult och lätt att missa i stor skala. Fixen var inte en bättre mening, det var en hårdare instruktion plus en grep-grind som räknar äkta specialtecken och kör om översättningen automatiskt om antalet landar på noll. Ett regressionstest, på en prompt.

Den andra var värre. En omöversättningsprompt började mynta något annorlunda lokaliserade slugs, så publiceraren skapade ett splitternytt dokument medan det gamla låg kvar live. Det gav 54 duplicerade live-dokument, vilket utlöste Google Search Consoles dubblettexkluderingar. Fixen var en skyddsregel i prompten som tvingar återanvändning av den befintliga sluggen, plus en regel om att slå upp innan man skapar i publiceraren.

Lärdomen satte sig hårt: prompten som levererade 194 inlägg på tio språk vann inte på formuleringen. Den vann för att en grep-grind körde om den i samma stund den drev iväg. Det är LLM-evaluering i praktiken, och det är därför vi kopplar varje viktig prompt till verktyg för prompthantering för att versionera och rulla tillbaka dem. För ett stabilt prefix som upprepas över tusentals anrop cachar vi det för att skära kostnader. Det här är precis den sortens prompt-och-eval-pipeline vi bygger åt kunder.

Vanliga misstag inom prompt engineering (och 2026 års fixar)

De kostsamma misstagen 2026 är inte stavfel. De är strukturella: vaga instruktioner, överskriptade reasoning-modeller, publicering utan eval-loop, att ignorera modellspecifikt beteende, att stoppa in för mycket i prompten när det verkliga problemet är kontext, och att lita på oäkta indata. Alla har en ren fix, och de flesta kostar inget annat än uppmärksamhet.

Gå igenom listan och var ärlig om vilka du är skyldig till:

• Vaga instruktioner. "Gör den bättre" ger modellen inget att sikta på. Säg vad "bättre" betyder: kortare, vänligare, giltig JSON, under 120 ord.
• Överskriptade reasoning-modeller. Att tvinga fram "think step by step" på en o-seriemodell eller thinking-modell är misstaget som täcktes ovan. Låt den resonera; höj ansträngningen istället.
• Ingen eval-loop. Om du inte kan avgöra om en promptändring hjälpte eller stjälpte gissar du bara. Lägg till testfall och en godkänd/underkänd-kontroll.
• Att ignorera modellspecifikt beteende. Prompten som sjunger på GPT-5 kan behöva XML-taggar på Claude. Läs fusklappen ovan.
• Att proppa prompten full. Att stoppa in mer i en enda instruktion när det verkliga glappet är retrieval eller minne betyder att du behövde context engineering, inte en längre prompt.
• Att lita på oäkta indata. Användarinnehåll och hämtade dokument kan bära dolda instruktioner. Lägg till guardrails runt dem; vår kommande djupdykning i skydd mot prompt injection täcker säkerhetssidan i sin helhet.

Det dyraste promptmisstaget 2026 är inte ett stavfel. Det är att publicera utan en eval som hade fångat regressionen.

Är prompt engineering död? Ett ärligt svar för 2026

Nej. Prompt engineering är inte dött, det klövs i två. Avslappnad prompting blev enklare för att modellerna blev smartare och mer förlåtande. Produktionsprompting blev svårare, för tillförlitlighet, structured outputs och evaluering väger nu tyngre än smarta formuleringar. Ordet "engineering" betyder äntligen vad det säger.

Så varför fortsätter alla att förklara det dött? För att den synliga halvan - att skriva en fråga i ChatGPT - genuint blev trivial. Halvan som inte blev enklare, att leverera en prompt som håller över tusentals anrop och tio språk, gör inga rubriker. Den verkliga 2026-färdigheten är ingen magisk fras. Det är evaluering, val av modellnivå (planerare kontra arbetshäst), och att veta när ett problem har vuxit ur prompten och blivit context engineering. Den enkla halvan blev enklare och den svåra halvan blev svårare, och bara en av dem gör rubriker.

Om det finns en sammanfattande poäng: 10 tekniker förtjänar fortfarande sin plats, 4 gamla vanor kostar dig nu på reasoning-modeller, och evaluering är färdigheten som skiljer en demo från en produkt. Bygger du något där prompterna måste hålla i produktion? Boka en kostnadsfri konsultation så hjälper vi dig sätta upp eval-loopen först.

Vanliga frågor

Vad är prompt engineering i kontexten av generativ AI?

Prompt engineering är praktiken att utforma och finslipa de instruktioner du ger en språkmodell för att få träffsäker, relevant output. Det omfattar tekniker som zero-shot, few-shot, chain-of-thought och rollprompting. 2026 delas det upp i avslappnad chattprompting och rigorös produktionsprompting inuti ett system.

Är prompt engineering dött 2026?

Nej, prompt engineering är inte dött 2026, det klövs i två. Avslappnad prompting blev enklare i takt med att modellerna blev mer förlåtande. Produktionsprompting blev mer rigorös, för structured outputs, evaluering och tillförlitlighet väger nu tyngre än smarta formuleringar. Färdigheten försvann inte; den enkla halvan slutade bara behöva dig.

Vad är skillnaden mellan prompt engineering och context engineering?

Prompt engineering utformar instruktionen; context engineering designar allt annat i kontextfönstret: retrieval, minne, verktyg och ordning. Prompt engineering är en delmängd av context engineering. Du behöver context engineering så fort din indata ändras per anrop, som i agenter och RAG-system.

Behöver du fortfarande chain-of-thought-prompting med reasoning-modeller?

Oftast inte. På reasoning-modeller som OpenAIs o-serie, GPT-5 och Claudes thinking-lägen är det överflödigt att tvinga fram "think step by step" eftersom de resonerar internt, och OpenAI säger att det kan skada prestandan. Chain-of-thought hjälper fortfarande på klassiska GPT-stilmodeller, så matcha tekniken mot nivån.

Kräver prompt engineering kodning?

Nej, inte för att komma igång. Vem som helst kan skriva tydliga instruktioner och få bättre svar från ChatGPT eller Claude. Men produktions-prompt engineering - att versionera prompter, koppla in structured outputs och bygga eval-loopar - är en utvecklardisciplin. Den avslappnade halvan kräver ingen kod; den professionella halvan gör det.

Vad är skillnaden mellan zero-shot- och few-shot-prompting?

Zero-shot-prompting ger en tydlig instruktion utan exempel; few-shot inkluderar två till fem exempel för att forma output-format eller beteende. På 2026 års modeller, börja med zero-shot eftersom de följer instruktioner väl, och lägg bara till few-shot när exempel mätbart förbättrar resultaten. Few-shot är reservlösningen, inte standardvalet.

Hur får jag en LLM att pålitligt returnera JSON?

Använd schemabegränsade structured outputs, inte prompt-tiggeri. Istället för att skriva "returnera JSON, tack", skicka med ett JSON-schema via OpenAIs eller Anthropics Structured Outputs-funktion, som begränsar modellen till giltig, tolkningsbar output. Det gamla prefill-tricket ger nu ett 400-fel på nyare Claude-modeller.

Vad är meta-prompting?

Meta-prompting är att använda en modell för att utforma eller förbättra prompten du ska köra. Verktyg som Anthropics prompt improver och OpenAIs prompt optimizer skriver om ditt utkast enligt best practices; Anthropic mätte en förbättring på 30 % i träffsäkerhet på ett test. Generera ett första utkast, redigera det sedan för hand utifrån din data.

Är prompt engineering ett riktigt yrke eller jobb?

Ja, det är en riktig färdighet, även om den fristående titeln "prompt engineer" håller på att smälta in i bredare AI-ingenjörsroller. Arbetsgivare vill ha personer som kan utforma prompter och designa evals, structured outputs och kontextpipelines. Som karriär är den starkast som en del av en AI-ingenjörs verktygslåda.

Hur skiljer sig prompting mellan ChatGPT, Claude och Gemini?

Jobbet är detsamma; dialekten skiljer sig. OpenAI använder developer messages och styr bort dig från explicit chain-of-thought på reasoning-modeller. Anthropics Claude favoriserar XML-taggar, adaptivt tänkande och effort-parametern. Googles Gemini använder en tankebudget. Reasoning-modeller är planerare; klassiska GPT-stilmodeller är arbetshästar.

Källor

• OpenAI: Reasoning best practices
• OpenAI: Structured Outputs
• OpenAI: Prompt optimizer
• Anthropic: Claude prompting best practices
• Anthropic: Structured Outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Prompt improver announcement
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)