Introduktion: Koden er ligeglad med dine vibes
Sagen er den med store sprogmodeller og kode: de er utroligt selvsikre og fuldstændig ligeglade med, om dit program kompilerer. Claude Haiku 4.5 vil med glæde skrive et Python-script til dig, der løser dit problem, plus to, den selv har opfundet for sjov. Tricket – det eneste trick, der betyder noget – er at lære, hvordan man prompter Claude Haiku 4.5 til præcis kodegenerering på en måde, der ikke levner plads til vibes og giver maksimalt rum til sandhed. Du ønsker ikke prosa, der lyder som kode. Du ønsker kode, der opfører sig som kode. Der er en forskel.
Folk behandler prompting som mystisk besværgelse – sig de rigtige ord, og få en perfekt app. Det er tankegang fra en fragtkult. Kode er en kontrakt. Hvis du vil have nøjagtighed fra Claude Haiku, skal du skrive kontrakten. “Byg en webapp” er ikke en kontrakt. “Generer et FastAPI-endepunkt i Python 3.12, der accepterer JSON, validerer skema med Pydantic v2 og returnerer 422 ved skemafejl med et specifikt payload-format” er en kontrakt. Sådan prompter du Claude Haiku 4.5 til præcis kodegenerering: du fastlægger kontrakten.
Hvad dette er (og ikke er)
- Det er en how-to-guide til at få pålidelig, testbar kode fra Claude Haiku 4.5.
- Det er ikke en prædiken om, at “AI erstatter udviklere.” Værktøjer erstatter ikke tænkning.
- Det er fokuseret på praktiske prompter, struktur og sikkerhedsforanstaltninger: de kedelige dele, der får magien til at virke.
Hvis du vil have kode, der kører, skal du give Claude en fungerende definition af “kører.” Hvis du vil have præcis kodegenerering, skal du definere nøjagtighed i klare, testbare termer. Det er hele spillet.
Definér nøjagtighed som en advokat, ikke en poet
“Nøjagtig” kode er ikke kode, der “ser plausibel ud.” Nøjagtighed er:
- Syntaktisk gyldighed: den kompilerer eller kører under fortolkeren.
- Semantisk troskab: den gør, hvad specifikationen siger.
- Deterministisk adfærd: samme input, samme output, inden for definerede fejlgrænser.
- Versionskorrekthed: den bruger de rigtige SDK'er, API-versioner og sprogfunktioner.
Claude vil give dig det, du beder om. Hvis du beder om “en funktion, der sorterer en liste,” vil du sandsynligvis få en. Hvis du beder om “en stabil, in-place sortering ved hjælp af Timsort-semantik med O(1) ekstra plads,” er det et andet løfte. “Sådan prompter du Claude Haiku 4.5 til præcis kodegenerering” starter med at skrive disse løfter ind i prompten.
Den minimum viable prompt, opgraderet
Dårlig: “Skriv en Node API til opgaver.”
Bedre: “Skriv en Node 20 Express 4 API med en /tasks POST-rute, der validerer felter {title: string, dueDate: ISO 8601} og svarer 201 med det oprettede objekt eller 400 med fejloplysninger.”
Korrekt: “Generer en Node 20 Express 4-server med et enkelt /tasks POST-endepunkt. Krav: 1) Valider body med [email protected]; 2) Felter: title (ikke-tom streng, maks. 140), dueDate (ISO 8601 fremtidig dato); 3) Ved succes: 201 med {id: ULID, title, dueDate}; 4) Ved ugyldig: 400 med {error: 'VALIDATION', details: array}; 5) Ingen database; in-memory Map; 6) Inkluder Jest 29 testfil, der dækker gyldig, ugyldig (tom titel, tidligere dato); 7) Angiv npm-scripts til test og dev; 8) Brug ESM; 9) Inkluder ikke uvedkommende kommentarer.” Læg mærke til formen: sprogversion, biblioteker, begrænsninger, output, fejl, tests og endda pakkestrukturen. Du har fjernet tvetydighed. Claudes job er at udfylde koden, ikke kravene.
Stilladsmønsteret: System, Specifikation, Tests, Derefter Kode
Hvis du vil have præcis kodegenerering fra Claude Haiku 4.5, skal du give den en landingsbane:
- Systemindramning (den korte snor)
- Dig: “Du skriver TypeScript i produktionskvalitet til Node 20. Output kun kodeblokke med filnavne og intet andet.”
- Hvorfor: Du styrer tone og outputformat. Overlad det ikke til tilfældigheder.
- Specifikation (kontrakten)
- Inkluder sprogversioner, pakkevalg, fejlsemantik, I/O-formater, ydeevnegrænser og sikkerhedsbegrænsninger.
- Bed Claude om at skrive enhedstests først. Tests definerer “nøjagtig” bedre end adjektiver. Hvis en kodelinje ikke tjener en test, er den dekorativ.
- Først efter testene. Ja, det er dybest set TDD, men med en robot, der aldrig bliver træt af at skrive boilerplate.
- Instruktioner til genkørsler
- “Hvis tests mislykkes, eller import stemmer ikke overens, skal du kun opdatere de mislykkede dele. Omskriv ikke hele projektet.”
Claude klarer sig godt, når den har kontekst og rammer. Giv den rammer.
Versionsfastgørelse er ikke valgfri
Claudes træningsdata er fulde af gamle og nye dokumenter. Det er en høflig måde at sige, at den har set mange modstridende råd. “Brug React Router” er vagt. “Brug [email protected] med dataroutere” er retning. Stol ikke på standarder: - Sprog: fastgør til Python 3.12, Node 20, Go 1.22, Java 21 – uanset hvad du rent faktisk kører.
- Frameworks: angiv nøjagtige hovedversioner og eventuelle breaking-change-flag.
- Cloud SDK'er: fastgør versioner; aws-sdk v2 vs v3 betyder noget.
- Linters/formatters: angiv regler for at undgå “style ping-pong”-omskrivninger.
Hvis du ikke fastgør, får du en greatest-hits-medley fra fem års blogindlæg. Nøjagtig kodegenerering er allergisk over for nostalgi.
Skema først, altid
Bed ikke om “brugerprofil”-strukturer. Definer skemaer i prompten, og kræv validering:
- JSON Schema eller Zod/Yup-typer i JS/TS
- Pydantic-modeller i Python
- Protobuf eller Avro til tjenester
Få derefter Claude til at håndhæve skemaer ved grænserne – API-input, databaseskrivninger og beskedkøer. Bed om eksplicitte fejl-payloads og -koder. Nøjagtighed elsker skemaer. Tvetydighed gør ikke.
Gør det observerbart, ellers lad være med at foregive, at det er ægte
Fortæl Claude at tilføje logging, metrics og traces, hvor du har brug for dem – og at holde dem stille, hvor du ikke gør. En god prompt inkluderer:
- Logningspolitik: niveauer, redigering af PII, struktur (JSON-logs, tak)
- Metrics: tid pr. anmodning, antal fejl
- Health-endepunkter: /healthz, der beviser, at afhængigheder er oppe
Claude tilføjer det, du beder om. Hvis du ikke spørger, får du print-statements – hvis du er heldig.
Test-først-prompter slår “Bare stol på mig”
En god måde at prompte Claude Haiku 4.5 til præcis kodegenerering er at gøre tests til sandhedskilden. Eksempel:
“Skriv pytest-tests for en funktion normalize_email(s), der:
- konverterer lokale og domænedele til små bogstaver;
- fjerner prikker i den lokale del kun for gmail.com;
- fjerner subadresser (+tag) kun for gmail.com;
- afviser input uden et enkelt @ eller med mellemrum;
- bevarer unicode-domæne-punycode som-er.
Dæk edge cases. Efter at have skrevet tests, skal du implementere funktionen for at bestå dem.”
Claude vil ofte skrive bedre kode, når den tvinges til at opfylde de tests, du har beskrevet. Hvis den ikke gør det, har du en konkret fejl, ikke et vibe-argument.
Ingen hallucinationer ved konstruktion
Du kan ikke eliminere hallucinationer, men du kan indhegne dem:
- Bed kun om citater eller kilde-URL'er, når der findes kilder. For SDK-metoder skal du kræve dokumentlinks og kræve, at koden matcher disse dokumenter.
- For private API'er skal du indsætte specifikationen i prompten. Forvent ikke, at Claude kender dine interne endepunkter.
- For biblioteker med forvirrende API'er skal du inkludere et eksempeludklip fra de officielle dokumenter og fortælle Claude at overholde det.
Nøjagtig kode er for det meste nøjagtige referencer. Giv Claude referencerne.
Stilguider: Det mindst sexede, mest nyttige
Claude skriver kode i den stil, den infererer. Det er en opskrift på churn. Indsæt din stilguide. Angiv:
- Formatering (Prettier, Black, gofmt standard)
Kræv også en kort begrundelseskommentar til ikke-åbenlyse valg. Fremtidige dig vil takke dig, og nuværende Claude vil producere færre “fix-up” PR'er.
Lange prompter, korte outputs
En anden måde at tænke over, hvordan man prompter Claude Haiku 4.5 til præcis kodegenerering: brug dine ord på prompten, ikke outputtet. Du ønsker:
- Udtømmende begrænsninger i prompten
- Minimal uvedkommende fortælling i outputtet
Bed den om at undertrykke forklaringer og kun returnere kodeblokke med filnavne og en kort README. Hvis du vil have kommentarer, skal du bede om det i en separat kørsel. Sammenfletning af prosa og kode er, hvordan fejl sniger sig ind iført monokel og høj hat.
Forfining: Den stramme loop, der rent faktisk virker
Den hurtigste vej til pålidelig kode er ikke “få det rigtigt første gang.” Det er korte, korrigerende loops:
- Kør lokalt. Indsæt mislykkede testoutput og kompileringsfejl tilbage i Claude verbatim.
- Instruer: “Rediger kun de mindst nødvendige linjer; ændre ikke funktionssignaturer, medmindre det kræves af mislykkede tests.”
Claude er fremragende til at anvende diffs, når du fortæller den præcis, hvad der gik i stykker. Omskriv ikke fejllogge. Indsæt dem. Loggene er sandheden.
Sikkerhed er en funktion, ikke et efterskrift
Fordi modeller er trænet på offentlig kode (god, dårlig og forbandet), vil du gøre sikkerhed til et førsteklasses krav:
- Forbyd eksplicit eval, shell=True og strengt-typede SQL
- Kræv parametriserede forespørgsler, CSRF-beskyttelse og hastighedsbegrænsning
- Bed om versionsfastgørelse af afhængigheder plus en lockfile
- Kræv håndtering af hemmeligheder via miljøvariabler eller en hemmelighedsadministrator
En sikker-som-standard-prompt giver sikrere kode. En “vi patcher det senere”-prompt giver overskrifter.
Ydeevne: Sig hvad “hurtig” betyder
“Gør det hurtigt” oversættes til “gør hvad som helst.” Angiv i stedet metrics:
- Latensmål (p95 < 50ms for in-memory, p95 < 300ms for DB-operationer)
- Hukommelseskapsler (RSS < 150 MB)
- Tidskompleksitet (skal være O(n log n), ikke O(n^2))
Claude vælger algoritmer, der passer til det budget, du har fastsat. Giv den et budget.
Dokumentation: Nok til at onboarde en fremmed
Bed Claude om en README, der inkluderer:
- Opsætningsinstruktioner med nøjagtige versioner
- Kommandoer til test, lint, typecheck, kør
- Eksempel på anmodninger/svar
- Begrænsninger og kendte kompromiser
“Nøjagtig kode” inkluderer nøjagtig dokumentation. De er en del af det, der leveres.
Konkrete prompt-skabeloner, du kan stjæle
Skabelon: Backend-endepunkt
System: Du er en omhyggelig Python 3.12-ingeniør. Output kun kodeblokke med filnavne.
Bruger:
- Byg en FastAPI 0.111-app med et POST /convert-endepunkt.
- Anmodning: {amount: Decimal as string, from: 'USD'|'EUR', to: same}.
- Valider med pydantic v2; returner 422 shape ved skemafejl.
- Brug en ren funktion convert(amount, from, to) med faste satser {USD:1, EUR:1.1}.
- Returner {amount: string, currency: string} med 200.
- Inkluder pytest-tests, der dækker gyldig, ugyldig (dårlig decimal, ukendt kode) og edge (0).
- Angiv pyproject.toml med afhængigheder fastgjort; inkluder ruff og mypy configs.
- Ingen netværkskald, ingen kommentarer.
Skabelon: CLI Utility
System: Du skriver Go 1.22. Output kun kodeblokke med filnavne.
Bruger:
- Opret en CLI ved navn slugify, der læser stdin og udskriver URL-sikre slugs.
- Regler: små bogstaver, kun ASCII, bindestregsseparatorer, fjernelse af whitespace, fjernelse af tegnsætning.
- Angiv main.go og slugify_test.go med tabeltests.
- Inkluder Makefile med test- og build-targets.
Skabelon: Frontend-komponent
System: Du er en pragmatisk React-ingeniør, der er målrettet mod React 18 + TypeScript.
Bruger:
- Implementer en <DebouncedInput>-komponent.
- Props: value: string, onChange(value): void, delay=300.
- Brug useRef/useEffect; ingen tredjeparts hooks.
- Inkluder vitest-tests med falske timere.
- Angiv minimal Storybook-story.
Disse skabeloner demonstrerer, hvordan man prompter Claude Haiku 4.5 til præcis kodegenerering ved at fastgøre versioner, definere adfærd og kræve tests.
Afvisning af at være smart: Hvornår skal man sige “Optimer ikke”
Hvis du ikke vil have for tidlige mikro-optimeringer (og det vil du ikke), skal du sige det:
- “Foretræk læsbarhed frem for smartness; ingen bit-twiddling, medmindre testene kræver det.”
- “Ingen rekursion, hvis iterativ er klarere.”
- “Ingen metaprogrammering; eksplicit > implicit.”
Claude elsker at imponere. Lad den ikke gøre det. Få den til at bestå tests og være læsbar. Det er imponerende nok.
Sider.AI i workflowet, hvor det rent faktisk hjælper Jeg har set folk jonglere prompter i tilfældige chatfaner, som om det er et produktivitetsritual. Brug et arbejdsområde, der forstår kodekontekst. Sider.AI er for eksempel bygget op omkring at holde din specifikation, kode, diffs og testlogge i syne, så “indsæt fejlen, ret linjen”-loopet faktisk er stramt. Det er ikke magi; det er kedeligt stillads, der forhindrer dig i at miste plottet. Hvis dit værktøj holder kontrakten, testene og koden i den samme samtale – uden at plage dig med konfetti – så brug det. Sider gør. Sådan debugger du med Claude som en holdkammerat, ikke et orakel
- Indsæt det mislykkede testoutput nøjagtigt som-er. Undlad at opsummere.
- Bed om en diff: “Svar kun med unified diff mod fil X.”
- For runtime-fejl skal du tilføje det mindste reproducerbare snippet og kræve en forklaring plus en patch.
- For biblioteksfejl skal du indsætte det dokumentuddrag, du mener gælder, og spørge: “Er dette den korrekte API for version X? Hvis ikke, skal du opdatere koden og citere det korrekte uddrag.”
Målet er at få Claude til at argumentere med beviser. Du bringer beviserne.
Pitfalls-paraden (og hvordan man undgår den)
- “Seneste” API-fælden: Sig ikke “brug seneste.” Sig “brug version X.Y” og hold dig til det.
- Den tomme testfil: Hvis du ikke kræver tests, får du dem ikke.
- Den en-skuds-fejlslutning: Planlæg to eller tre korte forbedringer. Det er hurtigere end en oppustet prompt.
- Den tvetydige fejlpolitik: Definer statuskoder og payloads. “Returner en fejl” betyder intet.
- Den ikke-ejede afhængighed: Hvis koden er afhængig af en tjeneste, du ikke kan kontrollere, skal du stubbe den. Bed om fakes.
Din prompt-checklist (sæt dette fast i nærheden af din skærm)
- Sprog- og runtime-version fastgjort
- Biblioteksversioner fastgjort
- Fejlsemantik defineret (koder, former)
- Tests først, derefter kode
- Sikkerhedsbegrænsninger eksplicitte
- Stil og struktur specificeret
- Outputformat begrænset (filnavne, kodeblokke, diffs)
- Kort forbedringsloop med indsatte logge
Hvis du rammer alle ti, producerer Claude Haiku 4.5 generelt præcis kodegenerering, der overlever dagslys.
Et gennemarbejdet eksempel: Fra vag til verificeret
Vag prompt: “Skriv en funktion til at parse CSV sikkert.”
Resultat: Sandsynligvis okay, muligvis forkert, bestemt ikke testet.
Præcis prompt:
“Du skriver Python 3.12. Output kun kodeblokke med filnavne.
Opret csvsafe/init.py og csvsafe/reader.py med en funktion read_rows(path: Path) -> list[dict[str,str]]. Krav: brug csv.DictReader med newline='' og encoding='utf-8'; forbyd null-bytes; afvis filer >10MB; begræns kolonner til 100; fjern BOM; behandl tomme celler som tomme strenge; rejs ValueError med beskedkoder {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Inkluder tests i tests/test_reader.py med pytest, der dækker happy path, null byte, 11MB fil, 101 kolonner og BOM-håndtering. Angiv pyproject.toml med afhængigheder fastgjort og black config.”
Du får kode, tests og edge-håndtering. Derefter kører du tests, indsætter fejl og gentager med minimale diffs. Det er præcis kodegenerering i praksis.
Om “kreativitet” og andre marketingord
Jeg har ikke brug for “kreativ” kode. Jeg har brug for korrekt kode. Gem kreativitet til at navngive din kat. Når du prompter Claude, er kreativitet det naturlige biprodukt af solide begrænsninger. De rigtige tests og klare specifikationer producerer elegante løsninger. Den forkerte prompt producerer “genopfundet base64 med emojis.” Frist den ikke.
Den ikke-hemmelige hemmelighed
Måden at prompte Claude Haiku 4.5 til præcis kodegenerering er kedelig: skriv ned, hvad du har brug for, fastgør versionerne, definer skemaerne, kræv tests, og gentag med faktiske fejl. Det er det. Ingen mysticisme. Bare ingeniørdisciplin, med en model, der kan skrive meget hurtigt og ikke har noget imod at skrive femten næsten identiske testcases.
Og det er tvistet: nøjagtighed er uglamourøs. De prompter, der virker, læses som en TSA-checklist. Den kode, der leveres, læses som om den er skrevet af et menneske, der interesserede sig. Du får begge dele ved at behandle modellen som en junioringeniør, der trives under klare krav og visner under vag retning. Giv den en kontrakt. Få den til at bestå testene. Så, måske, kan du stole på den – med den slags tillid, du giver til et værktøj, ikke en profet.
Konklusion: Mindre trolddom, mere garanti
Hvis du vil have trolddom, skal du gå til et trylleshow. Hvis du vil have software, der kompilerer og opfører sig, skal du skrive prompter, der fungerer som garantier. Hvordan man prompter Claude Haiku 4.5 til præcis kodegenerering handler ikke om blomstrende formuleringer eller hemmelige nøgleord. Det handler om begrænsninger, tests, versioner og feedback-loops. Gør de fire ting, og du får kode, der kører. Spring dem over, og du får smukt formateret fiktion.
Koden er ligeglad med dine vibes. Heldigvis er test det heller ikke.
FAQ
Spørgsmål 1: Hvad er den enkleste måde at prompte Claude Haiku 4.5 for nøjagtig kodegenerering?
Betragt det som en kontrakt: fastgør versioner, definer skemaer, specificer fejlformater, og kræv test først. Jo tydeligere begrænsningerne er, jo mere nøjagtig er koden.
Spørgsmål 2: Hvordan reducerer jeg hallucinationer, når Claude skriver kode?
Indsæt autoritative dokumenter eller specifikationer, og kræv overholdelse af netop disse API'er. For private endpoints skal du inkludere din egen specifikation – forvent ikke, at den gætter.
Spørgsmål 3: Skal jeg bede Claude om test eller skrive dem selv?
Bed Claude om at generere test først, og implementer derefter kode for at opfylde dem. Test definerer nøjagtighed bedre end adjektiver og holder modellen ærlig.
Spørgsmål 4: Hvor specifik skal versionsfastgørelse være i prompter?
Meget specifik: sprog runtime, framework major/minor og SDK-versioner. "Seneste" inviterer til modstridende mønstre; nøjagtighed afhænger af stabile mål.
Spørgsmål 5: Hvor passer Sider.AI ind i prompting for nøjagtig kode?
Brug Sider.AI til at holde specifikationer, kode, diffs og testlogs i én loop. Det udfører ikke magi – det bevarer blot konteksten, så Claudes rettelser sporer dine faktiske fejl. 
