Developer & Tech
Prompting for Code That Fits Your Codebase
By Jim Vernon, Editor, AI Intelligence International · Published 27 March 2026 · Reviewed against our editorial standards · About the author
The gap between generated code that needs rewriting and generated code that merges is almost entirely context. The model is not guessing badly; it is guessing without the information that would let it guess well.
This article covers exactly what context is worth supplying, in what order, and what makes no difference.
Key takeaways
- Supply an example, not a description: One existing file that does something similar is worth more than three paragraphs describing your conventions.
- State the constraints that are not visible: Runtime, framework version, language target, and any platform limitation.
- Specify the interface, let it fill the body: Write the function signature, the types and the doc comment yourself.
- Ask for the approach before the code: For non-trivial tasks, ask for two or three approaches with trade-offs, pick one, then ask for the implementation.
Supply an example, not a description
One existing file that does something similar is worth more than three paragraphs describing your conventions. The model infers naming, structure, error handling and idiom from it directly.
Choose the example carefully — it will be imitated including its flaws. A file you are happy with is the right one; the file that happens to be open is not.
For anything non-trivial, two examples are better than one, because a single example is ambiguous about which properties are conventions and which are incidental.
State the constraints that are not visible
Runtime, framework version, language target, and any platform limitation. Code that assumes a Node server in an edge runtime is a common and entirely avoidable failure.
Also state the things you will not accept: no new dependencies, no changes outside this file, must be synchronous, must not allocate in the hot path.
Constraints stated up front cost one line each and remove most of the rework.
Specify the interface, let it fill the body
Write the function signature, the types and the doc comment yourself. This pins down exactly the part where a wrong guess is expensive and delegates the part where it is cheap.
It also makes review trivial, because you already know what the code is supposed to accept and return.
For anything involving your domain model, supplying the type definitions is the single highest-value piece of context available.
Ask for the approach before the code
For non-trivial tasks, ask for two or three approaches with trade-offs, pick one, then ask for the implementation. This costs thirty seconds and prevents a long generation in the wrong direction.
It also surfaces assumptions early. Frequently the proposed approaches reveal that your specification was ambiguous.
Skip this for small, obvious tasks; the overhead is not worth it below about twenty lines.
What does not help
Politeness, urgency, and claims about the stakes make no measurable difference to code quality and add noise.
Very long context dumps of unrelated code reduce quality rather than improving it. Relevance beats volume.
Asking for best practices without saying whose is close to meaningless — practices conflict, and the model will pick one arbitrarily.
Making context reusable
Keep a short project context block — stack, versions, conventions, forbidden patterns — and paste it at the start of any substantial session.
Where the tool supports project-level instructions or rules files, put it there so it applies automatically.
Update it when a convention changes. A stale context block produces confidently wrong code that matches conventions you abandoned.
Worked example: the same task, two prompts
Prompt one: write a function to fetch a user's invoices. Result was a plausible standalone function using a fetch client the project does not use, with its own error type, no pagination, and no tenancy filter.
Prompt two supplied the signature, the two relevant type definitions, one existing repository file as an example, and three constraints: use the existing db client, all queries scoped by tenant, cursor pagination as in the example.
Result matched the codebase closely enough to merge with one comment. Generation time was identical; prompt writing took about ninety seconds.
The measurable difference was in rework: roughly forty minutes on the first version against two minutes on the second.
Show, then ask
The single most effective prompt change is including one existing file that already does something similar. Description is a weak signal for style; a real example carries naming, error handling, testing conventions and import layout at once.
State the constraints the example cannot show: which libraries are permitted, which patterns are banned, and the version of the language or framework in use. Models default to whatever was most common in training, which is often two versions behind your codebase.
Ask for the smallest change that satisfies the requirement. Left unconstrained, assistants add configuration options, abstractions and defensive branches nobody asked for, and all of it needs reviewing.
A reusable prompt skeleton
Context: the module, what it does, and the file that resembles the target. Task: one sentence describing the behaviour change. Constraints: language version, allowed dependencies, error-handling convention, and testing expectation. Output: the changed file or a diff, nothing else.
Keeping that skeleton in a snippet file removes the temptation to improvise a prompt under time pressure, which is when vague prompts and long review cycles happen.
When output misses repeatedly, fix the skeleton rather than arguing with the model in follow-ups. A corrected constraint helps every future request; a follow-up helps once.
Frequently asked questions
How much context is too much?
When you are pasting files the task does not touch. Relevant examples improve output; unrelated volume dilutes attention and degrades it.
Should I keep a rules file for the project?
Yes, if your tool supports one. A short file covering stack, versions, conventions and prohibitions removes the need to restate context every session and keeps output consistent across a team.
Does asking for the approach first really help?
For anything above about twenty lines, consistently. It is the cheapest available way to catch a misunderstanding before it becomes a hundred lines of code you have to read.
Why does generated code use dependencies I do not have?
Because nothing told it what you do have. Stating the allowed dependencies explicitly, or supplying a representative file, resolves it almost entirely.
How much code should be pasted as context?
One representative file plus the interface being changed. More context dilutes attention and increases the chance of irrelevant edits.