Craft · Technique
How to prompt for code that actually works
Most of what changes the output isn’t a magic phrase — it’s giving the model a checkable contract instead of a description, asking for small changes instead of big rewrites, and naming the failure you’re trying to avoid. The ledger below is sortable and filterable by the failure each technique closes off.
What you’re browsing for vs. what you need to know: you probably came here for a phrase to paste in. What actually moves the needle is closer to engineering discipline than wording — a contract, a boundary, a named edge case. The phrasing in the examples below is illustrative; the structure is the point.
The ledger
Eight techniques, what they prevent
Click a column header to sort; click a failure-type chip to filter. Every row pairs a technique with a real before/after phrasing.
| Before → after | |||
|---|---|---|---|
| Give the contract, not prose | A contract is checkable; prose leaves gaps the model fills with a guess. | Ambiguity — a plausible but wrong reading of a vague ask. | Before: “Make a signup function.” After: parseSignup(input:{email,age}) → {ok:true,user} | {ok:false,error}. Reject age under 13; reject malformed email. |
| Name the exact library and version | Models are trained on a mix of library versions and will blend APIs across them if you don’t pin one. | Version drift — a real function called with an older release’s signature. | Before: “Use the usual chart library.” After: “Use Chart.js v4 — target the v4 scales.x object, not the v3 scales.xAxes array.” |
| Treat unfamiliar package names as unverified | Independent testing of production models finds they invent plausible package names at a measurable rate — sounding real isn’t evidence. | Hallucination — installing a package that doesn’t exist, or was registered afterward by someone else. | Before: installing whatever import/require line the model wrote.After: search the exact name on the real registry (PyPI, npm) before installing — every time. |
| Iterate in small, reviewable diffs | A full regeneration re-derives the whole file, so a change in one place can silently break something you’d already checked. | Scope creep — unrequested changes riding along with the one you asked for. | Before: “Rewrite the page to add search.” After: “Only add a search input and its handler; don’t change anything else on the page.” |
| Ask for tests and name the edge cases | A test is a second, independent statement of intent — if code and test agree, the interpretation is at least self-consistent. | Untested edges — code that looks right but mishandles empty, zero, huge or unicode input. | Before: “Write a function to split a full name.” After: “…and test: empty string, one word only, multiple middle names, leading/trailing spaces.” |
| Paste the actual error, not a description of it | An error message is a specific contract violation; without it the model debugs blind and often fixes the wrong thing. | Confident wrong fix — a plausible patch for a cause that was never the real one. | Before: “It’s broken, fix it.” After: paste the full error text or stack trace plus the exact input that triggered it. |
| Ask it to flag assumptions instead of picking one silently | Makes a guess visible instead of invisible, so you can correct it before it ships rather than after. | Silent default — a choice made without telling you, discovered later. | Before: no instruction given; model silently assumes UTC. After: “State any assumption about timezone, currency or units before writing the code.” |
| Constrain scope explicitly | “Improve this” is an open invitation; a stated boundary makes the edit surface predictable. | Scope creep — an unrelated refactor riding along with the fix you asked for. | Before: “Clean this up.” After: “Fix only the date-parsing bug in formatDate(); don’t rename anything or touch other functions.” |
Showing 8 of 8 techniques.
A prompt that follows every technique above still doesn’t make the output ready for real users — that’s a separate, larger question.
Named plainly
The four failure modes, by name
These are the specific ways AI-generated code goes wrong that the ledger above is built to counter. Naming them makes them easier to catch:
- Silent hallucinated APIs. The model calls a function, method or package that doesn’t exist, written with total confidence and no hedge. For package names specifically, this has a name — slopsquatting — and it’s a real supply-chain risk: a 2026 preprint testing nearly 200,000 code-generation responses across five frontier models measured package-hallucination rates of roughly 4.6%–6.1%, and researchers found dozens of the invented names were still unregistered (and therefore squattable by an attacker) on the real registries. See Sources 5–7 below.
- Confident wrong versions. The code is syntactically fine and would have worked — on a different release of the library than the one you’re actually using.
- Plausible-but-broken edge cases. The happy path works; an empty string, a zero, a huge number or a non-ASCII character breaks it silently.
- Scope creep. You asked for one change and got that change plus an uninvited rewrite of something nearby.
Sources
- Anthropic, “Be clear and direct” — Claude Docs. docs.claude.com/en/docs/build-with-claude/prompt-engineering/be-clear-and-direct. Accessed 27 Jul 2026.
- Anthropic, “Effective context engineering for AI agents.” anthropic.com/engineering/effective-context-engineering-for-ai-agents. Accessed 27 Jul 2026.
- GitHub Docs, “Prompt engineering for GitHub Copilot Chat.” docs.github.com/en/copilot/concepts/prompting/prompt-engineering. Accessed 27 Jul 2026.
- GitHub Docs, “Best practices for using GitHub Copilot.” docs.github.com/en/copilot/get-started/best-practices. Accessed 27 Jul 2026.
- arXiv:2605.17062, “The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort” (preprint, not yet peer-reviewed). arxiv.org/abs/2605.17062. Accessed 27 Jul 2026.
- Socket, “New Study Identifies 53 Slopsquatting Targets Across 5 Frontier LLMs.” socket.dev/blog/slopsquatting-targets-across-frontier-llms. Accessed 27 Jul 2026.
- Wikipedia, “Slopsquatting” (background definition only). en.wikipedia.org/wiki/Slopsquatting. Accessed 27 Jul 2026.
FAQ
Good to know
Does a longer, more detailed prompt always produce better code?
No — length and specificity aren’t the same thing. A short prompt shaped like a contract (exact inputs, outputs and error cases) usually beats a long narrative one, because the model spends its attention on the constraints that matter instead of parsing prose.
Should I trust code when the model itself says it’s “production ready”?
No. That phrase from a model is not verification. Treat it the way you’d treat unverified marketing copy, then work through what production readiness actually requires — see the From Prompt to Production checklist.
What if the model invents a library or package that doesn’t exist?
This is a documented, measured phenomenon in current models, not a rare fluke — check the exact package name on the real registry (PyPI, npm, etc.) yourself before installing anything a model wrote, every time. See the Sources above for the research.
Is asking for tests overkill for a quick prototype?
For a true throwaway you can skip it. But since the model can usually write the tests as fast as the code, asking costs little and is the fastest way to see whether it actually understood your contract — there’s rarely much downside beyond a little extra time.