Sådan skriver du AI-prompts der virker til kodning, debugging og læring

Det korte svar: sådan får du AI til faktisk at hjælpe dig

Gode AI-prompts til kodning, debugging og læring har seks faste byggesten: rolle (hvem AI skal være), mål (hvad du vil opnå), kontekst (sprog, miljø, niveau), constraints (begrænsninger), outputformat (hvordan svaret skal se ud) og kvalitetstjek (tests, forklaringer osv.). Kombinér dem, iterér på formuleringen, og få AI til at stille spørgsmål, når noget er uklart. Så går du fra generiske svar til konkret brugbar hjælp.

Hvad er en prompt – og hvorfor betyder den så meget i kodearbejde?

En prompt er den instruktion, besked eller det spørgsmål, du skriver til en AI-model for at styre svaret. Den er ikke bare “et spørgsmål”, men din fjernbetjening til modellen: du bestemmer opgave, vinkel og format.

I tekniske opgaver fungerer en prompt bedst, når den:

• er konkret om sprog, miljø og mål
• afgrænser hvad der er vigtigst (fx “fokusér kun på performance”)
• fortæller, hvordan du vil have svaret præsenteret (kodeblok, trin-for-trin osv.)

Hvis du vil have en blød intro til begrebet, kan du læse mere i den praktiske guide til prompts for kodning og læring. Her går vi direkte efter de tekniske workflows.

De seks byggesten i en stærk teknisk prompt

Du kan tænke en god prompt som en lille kravspec til AI. De samme komponenter går igen, uanset om du vil have genereret kode, finde en fejl eller lære et emne.

Hvis du får styr på de seks, er du 80 % af vejen til prompts, der faktisk virker.

Hvilken rolle skal AI have?

En tydelig rolle hjælper AI med at vælge det rigtige niveau, den rigtige tone og den rigtige faglige vinkel. Til tekniske prompts bør rollen afspejle, om du vil have hjælp til at udvikle, finde fejl eller lære.

Tre roller der fungerer ekstremt godt i praksis:

• “Senior developer” – når du vil have løsningsforslag, refactoring og best practices.
• “Debugging assistant” – når fokus er fejlfinding, hypotese og næste skridt.
• “Tålmodig underviser” – når du vil have forklaringer, hints og quizspørgsmål.

Eksempler:

• “Du er en senior Python-udvikler. Hjælp mig med at optimere denne funktion til at håndtere store datamængder.”
• “Du er en debugging-assistent for et Node.js API. Din opgave er at finde den mest sandsynlige årsag til fejlen og foreslå konkrete tests.”
• “Du er en tålmodig lærer, der hjælper en begynder med at forstå asynkrone funktioner i JavaScript.”

Det lyder banalt, men forskellen på “hjælp mig” og “du er en erfaren code reviewer, der peger på de vigtigste problemer først” er ofte forskellen på småsnak og reel hjælp.

Hvilken kontekst skal du give?

God kontekst gør AI langt mere præcis. I tekniske prompts bør du altid beskrive miljø, sprog, version, mål og begrænsninger, så modellen kan give et svar, der passer til dit konkrete setup.

Til kode og debugging er konteksten typisk:

• Programmeringssprog og evt. version (fx “Python 3.11”)
• Framework og relevante biblioteker (React, Express, Django osv.)
• Miljø: browser, Node, serverless, mobil osv.
• Udsnit af den relevante kode eller API-kontrakt
• Målgruppe: er koden til undervisning, produktion, et internt værktøj?
• Constraints: performance, sikkerhed, backwards compatibility

En enkel kontekst-skabelon du kan genbruge:

Mit miljø: [sprog + version], [framework], [runtime].
Formål: [hvad koden skal bruges til].
Særlige krav: [fx performance, ingen nye dependencies, skal være læsbart for begyndere].

Eksempel:

Mit miljø: TypeScript, React 18, kører i en Next.js 14-app i browseren.
Formål: Jeg vil have en genanvendelig hook til at håndtere søgning med debouncing.
Særlige krav: Ingen eksterne dependencies udover React, skal være let at forstå for en junior-udvikler.

Jo oftere du tænker “ville en kollega kunne løse opgaven med den her beskrivelse?”, jo bedre prompts ender du med.

Hvornår skal du bruge eksempler (few-shot vs. zero-shot)?

Eksempler hjælper AI med at ramme stil, format og forventet output mere præcist. Brug dem især, når du vil have kode i en bestemt struktur, fejlfinding i en bestemt rækkefølge eller undervisning på et bestemt niveau.

To begreber er gode at kende:

• Zero-shot: du giver ingen eksempler, bare en opgavebeskrivelse.
• Few-shot: du giver et eller flere små eksempler på det ønskede output.

Eksempel uden eksempler (zero-shot):

“Skriv en unit test til denne funktion i Jest.”

Eksempel med eksempel (few-shot):

“Skriv Jest-unit tests til denne funktion.
Brug samme stil som i eksemplet herunder:
[indsæt 1-2 korte tests fra projektet]
Følg samme navngivning, struktur og assertions. Fokuser især på edge cases.”

I praksis:

• Brug zero-shot, når opgaven er simpel eller velkendt (fx “skriv en simpel for-løkke i Python”).
• Brug few-shot, når stil, struktur eller domæne betyder meget (fx samme teststil i et eksisterende projekt).

Hold eksemplerne korte. Et par linjer god kode gør mere gavn end at klistre hele repoet ind i prompten.

Hvordan styrer du format og omfang på svaret?

Når du styrer format og omfang, bliver output mere brugbart og mindre generisk. Til tekniske prompts bør du altid sige, om du vil have kode, forklaring, tests, tabel eller trin-for-trin.

Nogle nyttige formater:

• Kodeblok: når du vil copy-paste (men husk at læse koden først)
• Step-by-step: når du vil forstå en løsning eller et debug-flow
• Liste eller tabel: når du vil have overblik, fx over edge cases eller API-endpoints
• “Kode + kort forklaring”: god standard til læring og review
• Diff-format: når du kun vil se ændringer til eksisterende kode

Eksempel på præcis formatstyring:

“Svar i to dele:
1) En komplet TypeScript-funktion i én kodeblok.
2) En punktliste med max 5 punkter, der forklarer de vigtigste designvalg.
Til sidst: foreslå 3 Jest-tests i en separat kodeblok.”

Når du beder om tests, er det en god idé også at have en basal testopsætning klar. Hvis du vil styrke dine testvaner generelt, er den her artikel om Node-tests et godt supplement.

Prompt-formel til kodning: sådan skriver du prompts der genererer brugbar kode

Den bedste prompt til kodning er konkret og teknisk afgrænset: fortæl hvilket sprog du bruger, hvad koden skal gøre, hvilke begrænsninger der gælder, og i hvilket format du vil have svaret.

Kodningsformlen: ROLE – GOAL – CONTEXT – CONSTRAINTS – OUTPUT – QUALITY

Her er en skabelon, du kan copy-paste og tilpasse:

Rolle: Du er en erfaren [sprog]-udvikler.
Goal: Skriv [funktion/klasse/komponent], der gør: [beskriv formålet kort].
Context: Vi bruger [framework/biblioteker], kører i [miljø]. Denne kode skal passe ind i [kort beskrivelse af modul/projekt].
Constraints: [ingen nye dependencies / fokus på læsbarhed / skal være O(n) / kun moderne browser-support osv.].
Output: Giv kun koden i én kodeblok, ingen ekstra tekst.
Quality: Nævn til sidst 3 edge cases, koden skal kunne håndtere.

Dårlig vs. god kodningsprompt

Dårlig:

“Skriv noget JavaScript der laver pagination.”

Bedre:

“Du er en erfaren JavaScript-udvikler.
Goal: Skriv en ren funktion paginate(items, pageSize, currentPage) som returnerer de items, der hører til den givne side.
Context: Koden skal bruges i en React-app, men funktionen skal være framework-agnostisk (ingen DOM-adgang).
Constraints: Ingen mutation af input-arrayet, håndter hvis currentPage er uden for rækkevidde.
Output: Giv funktionen i én kodeblok, og forklar derefter kort, hvordan du håndterer out-of-range pages.
Quality: Foreslå 3 unit tests, jeg bør skrive for at sikre, at funktionen virker korrekt.”

Hvis du vil arbejde mere systematisk med AI som “medprogrammør”, er denne guide om AI som medprogrammør et godt næste skridt.

Og uanset hvor god prompten er: lad være med bare at copy-paste koden direkte i produktion. Her er en nøgtern gennemgang af hvorfor.

Prompt-formel til debugging: sådan bruger du AI som fejlsøgningsmakker

En god debugging-prompt beskriver fejlen præcist, giver den relevante kode og miljøet, og beder AI om at finde den mest sandsynlige årsag og foreslå en testbar løsning.

Debugging-protokollen: ERROR – ENV – STEPS – EXPECTATION – CODE – ASK

Brug denne faste rækkefølge:

1. Error: Den konkrete fejlmeddelelse eller adfærd (gerne stack trace).
2. Env: Miljø og versioner (sprog, framework, runtime).
3. Steps: Hvad du gjorde for at fremprovokere fejlen.
4. Expectation: Hvad du forventede skulle ske.
5. Code: Det relevante kodeudsnit (så lille som muligt, men nok til at give mening).
6. Ask: Hvilken type hjælp du vil have (årsag, næste tests, refactor osv.).

Skabelon:

Du er en debugging-assistent for [sprog/framework].
Error: [fejlmeddelelse + stack trace].
Env: [sprog + version], [framework + version], [runtime: browser/Node/server osv.].
Steps: [trin-for-trin hvad jeg gør, før fejlen opstår].
Expectation: Jeg forventede, at [beskriv forventet adfærd].
Code: [indsæt kun den relevante kode, gerne 20-80 linjer].
Ask: 1) Forklar den mest sandsynlige årsag. 2) Foreslå 2-3 konkrete ting jeg kan teste eller logge for at bekræfte hypotesen. 3) Hvis muligt, vis en rettet version af koden og forklar forskellen.

Dårlig vs. god debugging-prompt

Dårlig:

“Min Node-server crasher, hvad gør jeg?”

Bedre:

“Du er en debugging-assistent for Node.js/Express.

Error:
Serveren crasher med denne fejl:
TypeError: Cannot read properties of undefined (reading 'userId')
Stack trace:
[indsæt stack trace]

Env:
Node 20, Express 4, kører lokalt på macOS.

Steps:
1) Jeg sender en POST-request til /api/orders med en JSON-body.
2) Middleware til auth burde sætte req.user.
3) Fejlen opstår i controlleren, når jeg prøver at læse req.user.userId.

Expectation:
Hvis brugeren er logget ind, forventer jeg at kunne læse req.user.userId. Hvis ikke, burde der komme en 401.

Code:
[indsæt auth-middleware + relevant del af controlleren]

Ask:
1) Hvad er den mest sandsynlige årsag til fejlen?
2) Hvilke 3 ting bør jeg logge eller teste for at bekræfte det?
3) Vis en rettet version af koden, og forklar kort, hvad du har ændret.”

Hvis du vil blive bedre til systematisk fejlfinding generelt (med eller uden AI), er den her artikel om at debugge uden at famle i blinde værd at læse, ligesom samlesiden om logs og stack traces giver flere konkrete eksempler.

Vigtigt: Indsæt aldrig API-nøgler, adgangskoder eller følsomme data i dine prompts. Hvis du er i tvivl, så kig forbi guiden om API-nøgler eller artiklen om tokens og secrets.

Prompt-formel til læring: få AI til at undervise dig i stedet for bare at give svaret

En god læringsprompt beskriver dit niveau, dit mål og den type hjælp, du vil have. Hvis du vil lære noget rigtigt, skal AI ikke bare give svaret, men også forklare, teste og give hints.

Læringsformlen: LEVEL – GOAL – FOCUS – STYLE – INTERACTION

Fem felter er ekstra vigtige:

• Level: dit nuværende niveau (total begynder, lidt øvet, vant til et andet sprog osv.).
• Goal: hvad du vil kunne bagefter (ikke bare “forstå promises”, men fx “skrive en simpel fetch-funktion uden callback-helvede”).
• Focus: koncept, syntaks, fejlfinding, designvalg osv.
• Style: forklaringsstil (analogi, trin-for-trin, med/uden kode først).
• Interaction: hvordan AI skal tjekke din forståelse (quiz, små opgaver, hints først).

Skabelon:

Du er en tålmodig underviser i [emne].
Level: Jeg er [beskriv dit niveau og evt. hvad du allerede kan].
Goal: Jeg vil kunne [konkret mål].
Focus: Forklar især [koncept/typiske fejl/brugsscenarier].
Style: Forklar først konceptet med en simpel analogi, derefter med et lille kodeeksempel. Undgå for meget jargon.
Interaction: Giv mig 3 små spørgsmål/opgaver til sidst for at teste, om jeg har forstået det. Hvis jeg svarer forkert, så giv et hint i stedet for løsningen med det samme.

Eksempel til asynkron JavaScript:

“Du er en tålmodig underviser i asynkron JavaScript.
Level: Jeg kan basal JavaScript og har brugt fetch, men jeg forstår ikke rigtigt async/await og promises.
Goal: Jeg vil kunne skrive en funktion, der henter data fra et API med fetch og håndterer fejl korrekt.
Focus: Forklar især forskellen på at returnere data direkte og at returnere et promise.
Style: Brug først en analogi fra hverdagen, derefter et kort kodeeksempel. Undgå at vise for mange varianter på én gang.
Interaction: Når du har forklaret det, så giv mig 3 små opgaver, hvor jeg skal omskrive kode fra callbacks til async/await. Giv hints, hvis jeg går i stå.”

Hvis du vil i gang med at lære at kode mere generelt, er kategorien lær at kode et godt sted at få flere øvelser og projekter, og projektbaseret læring viser, hvordan du kan koble prompts til små, konkrete projekter.

Sådan forbedrer du en prompt iterativt (uden at gætte i blinde)

Du forbedrer en prompt ved at teste den, vurdere svarene og justere én ting ad gangen. Det er bedre at ændre kontekst, outputkrav eller eksempler systematisk end at omskrive alt på én gang.

Mini-scorecard til prompts

En simpel måde at vurdere en prompt på er at give svaret en uformel score 1-5 på fem kriterier:

• Relevans: svarer det faktisk på opgaven?
• Præcision: er detaljer og begreber korrekte?
• Fuldstændighed: mangler der vigtige dele (edge cases, tests, fejlhåndtering)?
• Fejlhåndtering: nævner svaret, hvad der kan gå galt?
• Læsbarhed: kan du eller en kollega forstå og bruge det hurtigt?

Når noget halter, så:

• mangler relevans → præcisér mål og kontekst
• mangler præcision → tilføj sprog/version og miljø
• mangler fuldstændighed → bed eksplicit om tests, edge cases eller fejlscenarier
• mangler fejlhåndtering → bed AI om at fokusere på fejl og grænsetilfælde
• mangler læsbarhed → justér format og tone (kortere, punktform, step-by-step)

En typisk iterativ besked kan være:

“Det her er et godt første udkast, men du mangler at tage højde for cases, hvor API’et returnerer en fejlstatus. Tilpas koden, så den håndterer non-2xx responses, og vis en opdateret version. Behold samme stil.”

Hvis du bruger AI til dokumentation, kan du kombinere denne tilgang med rådene i guiden til at skrive en README der faktisk bliver læst.

Hvornår skal du bede AI om at stille spørgsmål først?

Når en opgave er uklar, er afklarende spørgsmål bedre end et hurtigt gæt. Det giver mere præcise svar, færre fejl og et bedre udgangspunkt for kode, debugging eller læring.

Tre situationer, hvor det næsten altid hjælper:

• større refactorings eller redesigns (“gør min arkitektur bedre”)
• uafklarede krav (“lav et API til ordrer” uden flere detaljer)
• læringsmål, hvor du selv er usikker på niveau og forudsætninger

Standardlinje du kan bruge:

“Hvis der mangler vigtig kontekst, så stil mig 3 afklarende spørgsmål, før du svarer.”

Eller endnu mere specifikt:

“Før du foreslår en løsning, så stil mig 3-5 konkrete spørgsmål om krav, miljø og begrænsninger, så vi undgår misforståelser.”

Det føles lidt som at skrive en prompt til en meget grundig kollega: du giver dem lov til at sige “vent, jeg skal lige forstå problemet først”. Resultatet er sjældent dårligere af den grund.

Prompt-library: mønstre du kan genbruge

Et lille prompt-library sparer tid, fordi du ikke skal opfinde en ny formulering hver gang. Brug et mønster, tilpas konteksten, og genbrug strukturen til kode, fejlfinding og læring.

Standardmønstre

• Generate code
  “Du er en erfaren [sprog]-udvikler. Skriv [funktion/komponent] der [mål]. Kontekst: [miljø]. Constraints: [begrænsninger]. Giv kun koden i én kodeblok, og nævn til sidst 3 edge cases.”
• Refactor & explain
  “Du er en code reviewer. Refaktorer denne kode for læsbarhed og testbarhed uden at ændre adfærden. Forklar kort, hvad du har ændret, og hvorfor. [indsæt kode]”
• Debug
  “Du er en debugging-assistent for [sprog/framework]. Error: [fejl]. Env: [miljø]. Steps: [trin]. Code: [uds nit]. Find mest sandsynlige årsag og foreslå 3 ting, jeg kan teste eller logge.”
• Generate tests
  “Du er test engineer i et [sprog]-projekt. Skriv [testframework]-tests til følgende funktion. Fokuser på både normale cases og edge cases. Forklar kort, hvorfor hver test er vigtig. [indsæt funktion]”
• Explain code
  “Forklar denne kode trin for trin til en [begynder/let øvet]. Brug korte afsnit og evt. en analogi fra hverdagen. Peg på eventuelle risici eller svagheder. [indsæt kode]”
• Teach me a concept
  “Du er en tålmodig underviser. Level: [mit niveau]. Goal: Jeg vil forstå [koncept]. Forklar først med en analogi, derefter med et kort kodeeksempel. Quiz mig til sidst med 3 spørgsmål.”
• Compare options
  “Sammenlign 2-3 mulige løsninger på [problem] i en tabel med fordele, ulemper, kompleksitet og performance. Anbefal én løsning til et projekt med [kontekst og constraints].”

Gem de varianter, der virker godt for dig, fx i dit notesystem eller repo. Det er præcis den vane, der gør, at AI går fra “sjov chatbot” til et reelt værktøj i din værktøjskasse. Hvis du vil se flere konkrete hverdagscases, er der gode eksempler i guiden om ChatGPT i hverdagen som udvikler eller studerende.

Opsummering: tjekliste til gode tekniske AI-prompts

Som afslutning får du en kort tjekliste, du kan bruge næste gang du åbner ChatGPT, Copilot eller et andet LLM-værktøj:

• Har du givet AI en rolle (udvikler, debugger, lærer)?
• Har du formuleret et klart mål for opgaven?
• Har du beskrevet kontekst (sprog, version, framework, miljø)?
• Har du nævnt vigtige constraints (performance, dependencies, sikkerhed)?
• Har du bedt om et konkret outputformat (kodeblok, step-by-step, tests, tabel)?
• Har du tilføjet kvalitetstjek (tests, edge cases, forklaring af valg)?
• Har du bedt om afklarende spørgsmål, hvis noget mangler?
• Har du overvejet at tilføje et lille eksempel (few-shot), hvis stil og format betyder meget?
• Og sidst men ikke mindst: har du en plan for at læse, forstå og teste den kode, AI foreslår?

Hvis du kan sætte hak ved det meste af listen, er du foran rigtig mange, der stadig bare skriver “hjælp mig” og håber på det bedste.