There is a common frustration on development teams that have adopted AI coding assistants: the output is technically syntactically correct, but it is generic, ignores project conventions, and needs significant rewriting before it is actually usable. The reaction is usually to blame the tool or the model.
The prompt is almost always the real problem. AI coding assistants like GitHub Copilot and Cursor are capable of generating code that is ready for review without a major rewrite - but only when the prompt gives them enough specific context to work with. When the input is vague, the output reflects that.
This article covers the prompting patterns that consistently produce better results, with specific attention to what information needs to be in the prompt, what constraints the model cannot infer on its own, and the anti-patterns that guarantee mediocre output.
Photo by Lukas Blazek on Pexels
The Quality Problem Is Usually Upstream
AI coding assistants do not fabricate context. They generate code based on what they can see - the prompt, any code snippets you include, and the broader context of the file or project if your tool provides it.
When you write a vague prompt like "write a function to handle user authentication," the model will write a plausible-looking authentication function. It will not know whether you are using JWT or session cookies, whether your project uses a specific ORM, whether error handling should throw or return, or whether there is an existing utility you should be calling instead of reimplementing.
The result is a function that compiles but misses all the things that actually make code fit into your codebase. The fix is to write a prompt that carries the context the model cannot infer.
What a High-Quality Coding Prompt Includes
A prompt that consistently produces usable output tends to include four components: task specification, existing context, constraints, and expected output shape.
Task specification is more precise than it sounds. "Write a function that validates a user session token" is better than "handle authentication." But "Write a function that validates a JWT session token using our existing validateToken utility in utils/auth.ts, returns null on failure instead of throwing, and logs failures to our Logger.warn method" is actually useful.
Existing context means showing the model what already exists. Paste in the relevant interface definitions, the types it needs to work with, or the function signature it is implementing. Most AI coding tools connected to your editor handle some of this automatically, but for complex cases, including it explicitly dramatically improves accuracy.
Constraints tell the model what not to do. "Do not introduce any new dependencies. Do not use global state. Keep this pure and testable." These are things the model has no way to infer from your project if it has not seen your architecture.
Expected output shape closes the loop. "Return a function, not a class. Write it in TypeScript with explicit return types. Include JSDoc comments for the parameters."
How to Frame the Function-Level Context
The most impactful change most developers make when learning to prompt AI coding tools is shifting from a task description to a function-level spec.
Instead of describing what you want in general terms, describe the exact function signature and behavior contract. Start with the inputs and their types. State what the function should return, and what it should return on failure. List any side effects explicitly, whether that is writing to a database, emitting an event, or calling an external service.
When the prompt reads like a contract, the model generates code that honors a contract. When the prompt reads like a vague request, the model fills in assumptions that will not match yours.
This applies at any level of specificity. A one-line function can still benefit from a clear input/output description. A complex class needs a prompt that covers the public interface, the error boundaries, and which behaviors are internal versus exposed.
Photo by César Gaviria on Pexels
Specifying Constraints the AI Cannot Infer
Your codebase has patterns the AI cannot see unless you tell it. Error handling conventions, naming patterns, the specific libraries you use for state management or HTTP requests - none of this is automatic.
A practical habit is to maintain a short "context block" that you paste at the top of prompts for a given feature area. It might look like: "This project uses Zod for validation, Prisma for database access, and a custom ApiError class for error handling. All database calls are async and use the repository pattern. Functions should not throw - return typed Result objects instead."
That block, combined with a specific task description, gives the model enough to generate code that does not immediately conflict with your conventions. It does not need to be long. A few lines that capture the non-obvious constraints will outperform a detailed paragraph that explains what the function does.
The Anthropic research team has written publicly about how providing system-level context shifts model outputs from generic to domain-specific. The same principle applies to coding prompts: the model's capability is sufficient for most tasks, but the quality of your constraints shapes how that capability is applied.
"Most of the teams we onboard spend the first week discovering their AI coding tool was capable of the right answer all along. The bottleneck was always the precision of the instructions." - Dennis Traina, founder of 137Foundry
Giving the Model the Right Scope
One of the more common prompting mistakes is giving the model too much scope at once. "Refactor this entire service class to be more modular" produces worse results than "extract this one method into a separate utility function and make it testable."
AI coding assistants handle bounded, well-defined tasks reliably. They handle open-ended architectural redesigns poorly - not because they lack capability, but because "more modular" is not a specification. It is an intention. The model will make choices that may be inconsistent with yours.
When you need to make a significant change, break it into the smallest steps that can each be verified independently. Each step gets its own prompt. This produces a chain of reviewable changes rather than a large diff you have to audit in one pass.
For teams working on larger codebases, the AI automation services at 137Foundry include workflow design that applies this principle systematically - structuring AI coding tool usage around bounded tasks with human verification gates between them.
Testing Instructions in the Prompt
If you want testable code, ask for it in the prompt. Do not assume the model will generate pure functions and injectable dependencies if you do not say so.
Adding "write this to be unit-testable" at the end of a prompt often changes the output structure significantly. The model will avoid side effects in the primary logic path, pass dependencies in rather than importing them directly, and structure the return values in ways that are easy to assert against.
Better still, include the test interface as part of the prompt: "This function should be testable without a database connection. Mock the repository via constructor injection." Now the model is generating code against a concrete testability constraint, not an abstract aspiration.
Some developers include a brief example of how they want the function called in tests. That framing can produce very accurate output because the model is essentially reverse-engineering an implementation that satisfies a given test structure.
Photo by Daniil Komov on Pexels
Prompt Anti-Patterns That Produce Rewrite-Level Output
A few prompting patterns reliably produce output that needs major work before it is usable.
Single-line prompts without context. "Write a caching layer for API responses" gives the model almost nothing to work with. Caching has at least a dozen valid implementations depending on your infrastructure, consistency requirements, and expiration strategy. The model will pick one and it will probably be wrong for your case.
Prompts that describe the desired behavior in business terms without translating to technical terms. "Make it so users can log back in automatically" does not tell the model anything about token refresh, session management, or the existing auth infrastructure.
Prompts that ask for refactoring without specifying the direction. "Clean this up" produces cosmetic changes. "Extract the database calls into a repository class that implements the following interface" produces a meaningful refactor.
Prompts that do not constrain the scope. "Update this service" could mean anything. A well-scoped prompt names the method, the behavior change, and what should not change.
Prompt engineering as a discipline applies to coding contexts the same way it applies to language generation - specificity, constraints, and output format all shape what the model produces.
Iterating on Prompts Like You Iterate on Code
Treat prompts as first drafts. When the output is wrong, look at the prompt before assuming the model failed. Usually something was ambiguous or underspecified.
Keep a running note of the context blocks and prompting patterns that work well for your codebase. If a certain format reliably produces accurate output for database-layer code, reuse it. If a particular level of specificity consistently produces what you need, replicate it for new features in the same area.
Teams that invest a few hours into building a shared prompt library for their main feature domains report faster iteration cycles than teams where each developer improvises their prompts independently. The upfront work pays back quickly when the model stops generating code that conflicts with your architecture.
For projects that integrate AI coding tools into a larger development workflow, the web development services at 137Foundry cover this workflow design as part of the engagement. Consistent prompting patterns are one component of a larger system that includes code review gates and output validation steps.
Photo by Mizuno K on Pexels
When the Model Gets It Wrong, the Prompt Usually Got There First
AI coding assistants are not oracles. They generate plausible code based on what they see. When the output is wrong in a way that is hard to explain - the function does the wrong thing, the types are off, the error handling is inconsistent - the first diagnostic question is whether the prompt adequately specified those things.
This is not about lowering expectations for the tools. It is about understanding the input-output relationship clearly. A well-specified prompt is a high-quality input. The model's job is to execute against it.
The goal of structured prompting is not to hand-hold the model through obvious tasks. It is to give it the constraints it cannot infer on its own, so that its output fits your codebase the first time rather than requiring a round of corrections to bring it into alignment. That is where the productivity gains from AI coding tools actually live - in reducing the gap between initial output and shippable code.
Start with a single prompting pattern for the next function you write, include the input types, output contract, and one or two constraints the model cannot see. Compare the output to what you would have gotten from a one-line prompt. The difference will be obvious.
