Prompt Patterns for Coding Agents That Ship Real Code
Master agentic coding with reusable prompt patterns — decompose, constrain, cite-the-file, and stop-condition shapes that move agents from plausible to correct output.
Coding agents fail in a specific, repeatable way: they produce output that looks correct at a glance, passes a casual review, and breaks the moment it hits your actual codebase. The problem isn't the model. It's the prompt. Vague instructions produce plausible code; precise, structured prompt patterns produce code that actually runs.
Most teams start with something like "write a function that does X" and escalate to frustration when the agent ignores their existing conventions, invents helper utilities that already exist, or stops halfway through a multi-file change. These are prompt failures, not model failures. The model is doing exactly what the prompt implied.
Agentic coding at scale requires a catalogue of reusable prompt shapes, patterns you can reach for by task type. At Laxaar we've converged on four that cover the majority of real engineering work: decompose, constrain, cite-the-file, and stop-condition. Each one addresses a different failure mode, and together they shift the agent from "impressive demo" to "reliable collaborator."
What you'll learn
- Why prompt patterns matter more than model choice
- The decompose pattern
- The constrain pattern
- The cite-the-file pattern
- The stop-condition pattern
- Combining patterns for complex tasks
- Pattern comparison at a glance
- Frequently Asked Questions
Why prompt patterns matter more than model choice
A prompt pattern is a reusable structural template that shapes how an agent interprets a task. It's not a system prompt setting or a model parameter. It's the skeleton of the instruction itself. Same model, different pattern, wildly different output quality.
Teams upgrading from one model version to the next often see marginal gains. Teams who improve their prompt structure on the same model regularly see step-change improvements. This is the uncomfortable truth behind the "just use a better model" reflex: if your patterns are weak, a smarter model will just produce more confident wrong answers.
The four patterns below aren't abstract. Each one comes from a real failure mode we hit in production AI-powered software development work at Laxaar, and each one encodes the fix as a reusable template.
The decompose pattern
The decompose pattern is a prompt shape where you ask the agent to break a task into explicitly enumerated sub-tasks before writing any code. The agent outputs a numbered plan first; you review and optionally edit it; then the agent executes step by step.
Without decomposition, a coding agent treats a complex task as one big generation. It starts writing, discovers mid-generation that the task has dependencies it didn't account for, and improvises. The improvisation is usually plausible but wrong: it invents an interface that doesn't match your existing types, or it handles the happy path and skips the error cases entirely.
You are implementing a new feature in this codebase. Before writing any code:
1. List every file you will need to read to understand the current patterns.
2. List every file you will create or modify.
3. List any types, interfaces, or utilities you'll reuse versus create.
4. Identify any ambiguities that need clarification before starting.
Do not write implementation code until I confirm the plan.
Task: Add rate limiting to the /api/export endpoint using the existing middleware pattern.
The key discipline is the final line: no implementation until the plan is confirmed. Without it, agents hedge by including a partial implementation in the same response, which defeats the purpose. You want the plan as a separable artifact you can review.
Decomposition is especially valuable for tasks that touch more than three files. Single-file changes rarely need it. Cross-cutting changes almost always do.
The honest trade-off: decomposition adds a round-trip to every task. For trivial changes it's overhead. Make it a habit only for tasks where a wrong start would cost more than the planning round-trip.
The constrain pattern
The constrain pattern is a prompt shape where you make your conventions, limits, and non-negotiables explicit as a numbered constraint list at the top of the prompt, before the task description.
Agents are trained on vast codebases and bring strong priors about how code "should" look. Those priors conflict with your codebase's actual patterns. Without explicit constraints, the agent follows its training distribution, not your standards. You end up with a mix of Axios in a codebase that uses fetch, or a new utility that duplicates one already in src/lib.
Constraints — follow these exactly, no exceptions:
1. Use `fetch` with our custom `apiFetch` wrapper from `src/lib/api.ts`, never Axios or raw fetch.
2. All async functions must have explicit return type annotations.
3. Error handling must use our `AppError` class from `src/errors.ts`, not generic `Error`.
4. No new dependencies. Solve this within existing packages.
5. Exports go in the barrel file `src/features/billing/index.ts`.
Task: Implement a `cancelSubscription` function in the billing feature.
Constraints work best when they're short, specific, and verifiable. "Follow our coding standards" is not a constraint. "Use AppError from src/errors.ts, never generic Error" is a constraint: the reviewer can check it mechanically.
We also recommend ordering constraints by likelihood of violation. Put the ones the agent is most likely to ignore first. Agents read prompts like people do: attention degrades toward the bottom.
One opinionated take we hold firmly: the constrain pattern is worth maintaining as a shared team artifact. Keep a AGENT_CONSTRAINTS.md in your repo root that the team updates as new violations appear. Paste the relevant sections into prompts rather than rewriting them each time. Consistency in constraints is more valuable than perfect constraints.
The cite-the-file pattern
The cite-the-file pattern is a prompt shape where you explicitly name the source files the agent must read before generating output, and require it to cite line numbers when it references existing code.
Agents hallucinate existing code. Not maliciously. They interpolate from training data and produce something plausible. The result is a generated function that calls getUserPreferences(), a function that doesn't exist in your codebase but exists in a hundred public repos the model has seen. Your reviewer catches it in code review, but only if they know the codebase well enough to recognize the gap.
The cite-the-file pattern forces grounding. The agent can't assume; it has to look.
Before writing any code, read these files completely:
- src/features/auth/useAuth.ts
- src/lib/api.ts
- src/types/user.ts
When you reference any existing function, type, or constant, cite it with the file path and approximate line number: e.g., "using `useAuth` from `src/features/auth/useAuth.ts:14`".
If a utility you need doesn't exist in these files, say so explicitly rather than inventing it.
Task: Add a `useCurrentUserPreferences` hook that reads the authenticated user's preferences from /api/user/preferences.
The citation requirement does two things. First, it forces the agent to actually read the files rather than generating from memory. Second, it makes hallucinations visible: if the agent cites src/lib/api.ts:88 for a function that isn't there, a reviewer can catch it instantly.
This pattern pairs well with tools in your AI pair programming setup that give the agent real file-read access. A coding agent that can read files directly (rather than relying on a pasted excerpt) grounds far better because it resolves its own uncertainties rather than filling them with plausible guesses.
The stop-condition pattern
The stop-condition pattern is a prompt shape where you tell the agent exactly what "done" looks like, and equally important, what "not done" looks like, before it starts.
Without a stop-condition, agents have no principled place to stop. They sometimes stop too early (a skeleton implementation with TODO comments). They sometimes stop too late (adding unrequested logging, refactoring adjacent code, updating tests you didn't ask about). Both failure modes waste review time.
You are done when:
- The `cancelSubscription` function exists in `src/features/billing/cancelSubscription.ts`
- It passes the three test cases in `src/features/billing/__tests__/cancelSubscription.test.ts` (run them with `pnpm test cancelSubscription`)
- The function is exported from `src/features/billing/index.ts`
You are NOT done if:
- Tests are not passing (do not mark done with failing tests)
- You've made changes outside the billing feature directory
- You've modified existing tests
Stop and report when done. Do not refactor, add documentation, or make speculative improvements.
The "you are NOT done if" section is often more valuable than the positive condition. It explicitly closes the doors agents walk through uninvited. The agent that "helpfully" updates your README or "improves" a related function while working on your task is following an implicit stop-condition that's too permissive.
The instruction to "stop and report" rather than continue is also deliberate. Left to their own devices, agents will keep going after completing the stated task. Explicit termination instructions hand control back to the engineer, which is where it belongs in a custom software development workflow where review is part of the process.
Combining patterns for complex tasks
Each pattern solves a different problem. Real tasks often need more than one.
A good working order is: decompose first, constrain second, cite-the-file third, stop-condition last. Decompose produces the plan; constraints scope how the plan gets executed; cite-the-file grounds the execution in your actual codebase; stop-condition tells the agent when to hand back control.
[CONSTRAINTS]
1. Use `apiFetch` from `src/lib/api.ts`, never raw fetch.
2. All types must be defined in `src/types/` — no inline type definitions.
3. No new npm dependencies.
[PLAN FIRST]
Before writing any code, list:
- Files to read
- Files to create or modify
- Reused types and utilities
Do not proceed past the plan until I confirm.
[GROUNDING]
When referencing existing code, cite file path and line number.
If something doesn't exist, say so — don't invent it.
[DONE WHEN]
- New endpoint handler exists at `src/api/export/rate-limit.ts`
- Handler is registered in `src/api/export/index.ts`
- Existing export tests still pass
[TASK]
Add per-user rate limiting to the export endpoint using the token bucket pattern.
This combined prompt is longer. That's intentional. Longer, structured prompts perform better than shorter, vaguer ones for complex agentic coding tasks. The overhead is writing the prompt, which takes two minutes. The alternative is debugging a half-correct implementation, which takes significantly longer.
For teams working on AI-powered software development at scale, these combined patterns are worth templating. A shared library of task-type templates (add-endpoint, add-hook, refactor-module, add-test) means engineers paste and adjust rather than crafting from scratch each time.
Pattern comparison at a glance
| Pattern | Failure mode it solves | Best for |
|---|---|---|
| Decompose | Agent improvises during generation, misses dependencies | Multi-file changes, new features |
| Constrain | Agent follows training priors, not your conventions | Any task touching shared infrastructure |
| Cite-the-file | Agent hallucates existing utilities, types, or APIs | Feature work in unfamiliar parts of the codebase |
| Stop-condition | Agent over- or under-delivers, keeps going after done | Defined-scope tasks, tasks with test acceptance criteria |
| Combined | All of the above | Complex cross-cutting changes |
The patterns aren't mutually exclusive, and a more complex task warrants combining more of them. Start with the pattern that addresses the most likely failure mode for your specific task, then layer in others if the task warrants it.
Frequently Asked Questions
Do these patterns work with all coding agents?
Yes, with minor syntax adjustments. The structural approach (separate sections, explicit lists, citation requirements) transfers to Claude Code, GitHub Copilot Workspace, Cursor, and any agent that accepts a free-form prompt. Explicit structure beats implicit expectation on every model we've tested.
How much do these patterns slow down the workflow?
The decompose pattern adds one round-trip per task. The others add prompt-writing time, typically one to three minutes. For a task that would take 30 minutes to review and fix if the agent gets it wrong, that's a favorable trade. The friction is front-loaded and the payoff is in review time saved.
Should we apply these patterns to trivial tasks too?
No. For a single-file change with a well-understood scope, a plain instruction is faster. These patterns earn their overhead on tasks that are multi-file, touch shared infrastructure, or have explicit acceptance criteria. Apply the stop-condition pattern more liberally than the others. It's low overhead and prevents the "agent kept going" problem even on simple tasks.
What's the biggest prompt mistake teams make with coding agents?
Describing the solution rather than the problem and constraints. When a prompt says "create a React component that does X using Y pattern," the agent treats that as a spec to fill in, not a problem to solve. Better to describe the problem, the constraints, and the acceptance criteria, then let the agent propose the implementation. You get better results and you can catch misconceptions at the plan stage rather than after the code is written.
How do we keep these patterns consistent across the team?
Maintain a shared docs/agent-patterns.md or equivalent in the repository. Include the four base templates, example prompts for your most common task types, and a running list of codebase-specific constraints. New engineers copy from the shared library and adjust. The Laxaar team treats this file as a living document, updated every time a new violation pattern appears in code review.
The Laxaar team works with engineering teams to build agentic coding workflows: prompt libraries, constraint catalogs, and review processes that make AI pair programming a reliable part of the delivery cycle. If your agents are producing plausible-looking code that breaks on contact with your codebase, that's a solvable problem.
Working on something like this?
Get a fixed scope, timeline, and price within one business day — no obligation.
