Prompt engineering for developers is less about clever tricks and more about applying a handful of patterns consistently. The same patterns that make a human brief understandable to a colleague make an AI prompt effective. The difference is that with AI, clarity has been paid for in compute costs, latency, and output quality — so the patterns that sharpen your prompts are not just nice to have, they quietly save you money and improve your work. This guide covers fifteen prompt patterns that serious developers use every day in 2026, with before-and-after examples you can copy. None of them are magic. All of them are habits worth building.
Why prompting patterns matter
AI models are increasingly capable of filling in gaps in vague prompts, but the gap between a great prompt and a vague one still translates directly into output quality. A well-structured prompt produces correct code, stays within constraints, and minimises iteration. A lazy prompt produces output that misses the point, requires multiple corrections, and sometimes goes off in wrong directions.
The payoff from good prompting is concrete. An engineer who masters these patterns typically completes AI-assisted tasks 30-50% faster than an engineer who prompts casually, on the same tasks with the same models. The patterns compound; small improvements per prompt add up across thousands of daily interactions.
None of these patterns are exotic. They are essentially writing skills applied to AI. Engineers who write good design docs tend to write good prompts; engineers who never learned to brief clearly struggle with both.
Pattern 1: Spec-first prompting
Write the specification before writing the prompt. State what the code should do, what inputs it takes, what outputs it produces, and what edge cases matter. Only then ask the AI to implement.
Bad: "Write a function to parse dates."
Good: "Write a function parseDate(input: string): Result<Date, DateParseError> that accepts ISO 8601 dates, common US formats (MM/DD/YYYY), and common European formats (DD/MM/YYYY). Ambiguous cases should return an error. Empty strings and obviously invalid inputs should also return an error. Include unit tests for each format plus edge cases."
Spec-first produces much better code because the AI has clear constraints to satisfy.
Pattern 2: Reference existing code
Point at patterns you want the AI to follow. Rather than describing conventions abstractly, reference the files that embody them.
Bad: "Use our standard error handling."
Good: "Use the error-handling pattern from src/services/user-service.ts. Specifically: return Result types, never throw from service methods, include error context in the error object."
References reduce ambiguity dramatically. The AI reads the referenced file and mimics the pattern, often more accurately than if you describe the pattern in prose.
Pattern 3: Output format specification
Tell the AI exactly what format you want the output in, especially for non-code outputs.
Bad: "List the dependencies of this module."
Good: "List the dependencies of this module as a JSON array. Each entry should have: name (string), type ("internal" or "external"), and usage (one-sentence description of what is used). Return only the JSON, no commentary."
Format specification prevents the model from wrapping structured output in prose, which saves parsing effort and reduces errors.
Pattern 4: Chain of thought for complex reasoning
For non-trivial problems, ask the AI to reason before answering.
Bad: "What is the time complexity of this function?"
Good: "Analyse the time complexity of this function. Walk through each loop, each operation, and build up to the overall big-O. Explain your reasoning step by step before stating the final answer."
Chain-of-thought prompting improves accuracy on reasoning-heavy tasks dramatically. Reasoning models (o3, Claude extended thinking) do this internally; asking non-reasoning models to reason explicitly produces similar benefits.
Pattern 5: Negative constraints
Tell the AI what not to do, explicitly, alongside what to do.
Bad: "Refactor this function."
Good: "Refactor this function for clarity. Do not change its public API. Do not add new dependencies. Do not introduce async behaviour. Preserve all existing tests."
Explicit negative constraints save you from rejecting unwanted changes later. The AI is less creative with its side effects when you enumerate what is off-limits.
Pattern 6: Red-team your own prompt
After drafting a prompt, ask yourself: how could this be misinterpreted? What edge cases am I not specifying? What shortcut might the AI take?
This self-review often catches ambiguities before you send the prompt. It is one of the fastest ways to improve prompting without learning any new techniques.
A useful variant: ask the AI itself to critique your prompt before executing it. "Before writing code, tell me what is ambiguous or underspecified about my request." This often surfaces assumptions you did not realise you were making.
Pattern 7: The "explain then code" pattern
For harder problems, ask the AI to explain its approach before writing code. Review the explanation; iterate on it; then ask for code.
Bad: "Implement feature X."
Good: "Explain how you would implement feature X, including the data flow, the main components, and the tradeoffs. Do not write code yet." (Review the explanation, iterate.) "Now implement it."
This pattern is slower per interaction but produces dramatically better results on non-trivial features. Catching misunderstandings at the explanation stage saves 10x the time compared to catching them at the code-review stage.
Pattern 8: Skeleton-of-thoughts for features
For multi-part features, ask for a skeleton outline first, then fill in parts.
Bad: "Implement user registration with email verification."
Good: "Outline the components of user registration with email verification: list the endpoints, the database changes, the email flow, the middleware, and the tests needed. We will then fill in each component separately."
Skeletons make big tasks feel small. Each filled-in component is a small, reviewable change rather than a huge unreadable diff.
Pattern 9: Structured output with schemas
When working with structured outputs, specify a schema — ideally using the API's structured output feature.
Bad: "Extract the fields from this email."
Good: "Extract fields from this email into this JSON schema: {sender_email: string, subject: string, primary_intent: 'question' | 'complaint' | 'inquiry', urgency: 1-5, requires_response: boolean}. Return only the JSON object."
Structured outputs are enforced at the API level by Claude, OpenAI, and others in 2026. Using this feature eliminates parsing errors and reduces hallucination on the structure.
Pattern 10: Few-shot examples
Show the AI two or three examples of the desired input-output pattern before asking it to generate.
Good: "Here are examples of our commit-message style. Example 1: 'feat(auth): add magic-link flow'. Example 2: 'fix(db): correct migration order for foreign keys'. Now write a commit message for the following diff: [diff]."
Few-shot prompting anchors the AI to your specific style. It is dramatically more effective than describing the style abstractly.
Pattern 11: Role framing for specialised knowledge
For domain-specific tasks, frame the AI as an expert in that domain.
Bad: "Is this SQL safe?"
Good: "You are a database security engineer. Review this SQL query for injection risks, performance issues, and deadlock potential. Flag specific line numbers and explain each issue."
Role framing is not magic, but it does shift the model's default behaviour toward the expertise you want. It is especially helpful when the surface request is ambiguous about what lens to apply.
Pattern 12: The anti-hallucination check
For factual work where hallucination matters, ask the AI to verify its own output.
Good: "Implement this using the library's API. After writing the code, list every library function and property you used, and confirm by checking the official documentation that each one exists. If anything is uncertain, note it."
This explicit check catches invented APIs — a common failure mode. The AI will flag its own uncertainties, which you can then verify.
Pattern 13: Bounded experimentation
When exploring, bound the scope of the experiment.
Bad: "What is the best way to do X?"
Good: "Propose three approaches to X. For each: list the main tradeoffs, estimated complexity, and a small code example. Do not commit to any of them; I will review and decide."
Bounded exploration produces comparable alternatives rather than a single opinionated answer that may or may not be the best fit.
Pattern 14: Iterative refinement
Expect to iterate. Build prompts in layers.
First pass: produce a rough version.
Second pass: fix the specific issues you noticed in the first pass.
Third pass: polish specific areas.
This layered approach often converges on high-quality output faster than trying to get everything perfect in one shot. It also produces better prompts for future similar tasks, because you have observed where the AI needed specific guidance.
Pattern 15: Explicit handoff
When a task is done, explicitly hand off. Do not leave the session ambiguous.
State what was completed, what is left, and what the next step is. This clarity matters especially for long-running sessions that might be resumed later, or when handing off to a teammate.
Good: "We've completed the endpoints and tests for recipes. Still remaining: rate limiting, user-profile updates, and the search performance optimization. For the next session, start with rate limiting using the approach we discussed."
Explicit handoffs prevent the "where were we?" problem and make collaboration between multiple AI sessions or team members smoother.
Combining patterns
These patterns stack. A well-crafted prompt might use spec-first structure, reference existing code, specify negative constraints, ask for an explanation before code, and include few-shot examples of expected style — all in one prompt.
The resulting prompt might be 500-1000 tokens, which feels long but is overwhelmingly worth it. A long well-structured prompt that produces the right output in one shot is far cheaper than a short lazy prompt that produces three bad attempts before converging.
Prompt templates worth saving
A few templates that embody multiple patterns. Save these somewhere reusable.
Feature implementation template: "Implement [feature]. Spec: [details]. Reference: [file]. Constraints: [negatives]. Definition of done: [criteria]. Propose a plan first."
Bug investigation template: "Here is a failing test: [test]. Here is the error: [error]. Before proposing a fix, investigate the root cause. Propose hypotheses, test them, and explain your reasoning before suggesting a fix."
Code review template: "Review this PR for: [specific concerns]. Reference the project's conventions in [file]. Flag specific lines with severity (critical/minor/style). Be direct; do not hedge."
Refactor template: "Refactor this code for [goal]. Do not: [negatives]. Preserve: [invariants]. Produce a minimal diff."
Templates like these dramatically reduce the cognitive cost of every prompt and ensure consistency across a team.
How to build your own prompt library
Over time, every developer develops a personal library of prompts that work well. A few pragmatic suggestions for building yours.
Start saving prompts that produced notably good output. When a prompt worked unusually well, copy it into a personal note or a shared team document. Label it with what kind of task it was useful for.
Save prompts that failed too. Understanding why a prompt did not work is often more valuable than understanding why one did. Build a small library of anti-examples.
Refine templates over time. Your first template will be okay. Use it, notice its failures, improve it. After a year of deliberate refinement, your templates will be dramatically better than those of engineers who never thought about it.
Share with your team. A team-wide library of good prompts is one of the highest-leverage pieces of team infrastructure for AI-assisted work. The person who shares their best prompt pays a trivial cost; the team that adopts it gains productivity across everyone.
Prompts by task type: a quick cheat sheet
A compressed guide to which patterns serve which task types.
Implementing a new feature: spec-first, reference existing patterns, skeleton-of-thoughts, definition of done. The explain-then-code pattern for non-trivial features.
Fixing a bug: provide failing test, ask for root cause analysis before the fix, require the fix to be minimal, request a regression test. Chain of thought throughout.
Refactoring: state the goal of the refactor explicitly, specify what must not change (invariants, API, performance), reference the style to follow, require a minimal diff.
Code review: role framing ("you are a security reviewer"), specific concerns enumerated, severity labels required, reference project conventions. Few-shot examples of the level of detail wanted.
Writing tests: list the edge cases to cover, reference the existing test style, require property-based tests where appropriate, specify naming conventions.
Writing documentation: specify the audience, the format (README, API docs, inline comments), the examples required, and any tone constraints. Few-shot examples of existing docs.
Picking the right patterns for the task is half the skill. The other half is execution consistency.
Anti-patterns to avoid
Common prompting mistakes.
Vagueness. "Improve this" or "optimise this" without saying what good looks like. The AI will pick a default that may or may not match your intent.
Over-specification of implementation. Telling the AI exactly how to do something, step by step. This restricts useful creativity; specify goals and constraints, not implementations.
Conflicting constraints. "Keep it simple, handle every edge case, be extensible." These compete. Pick your priorities.
Missing context. Asking for changes without pointing at relevant code. The AI has to guess or explore, wasting tokens and introducing risk.
No review discipline. Accepting the first output without scrutiny. The best prompt in the world does not save you from bad review habits.
A worked before-and-after example
To see the patterns in action, a real before-and-after.
Before (casual prompt): "Write a function to validate email addresses."
Typical output: A function using a regex that handles simple cases but fails on valid edge cases like international domain names or subaddressing with plus signs.
After (applying patterns): "Write a TypeScript function validateEmail(email: string): Result<true, EmailValidationError>. Accept: standard email formats, international characters in the local part (per RFC 6531), international domain names. Reject: empty strings, obvious malformed input, emails longer than 254 characters. Do not use a regex — use a tokenising parser approach because regex-based email validation has well-known edge-case failures. Include a test file with: valid examples (at least 10 including international), invalid examples (at least 10 including common edge cases), and property-based tests using fast-check. Reference the existing validation pattern in src/lib/validation.ts. Propose a plan before writing code."
Resulting output: A parser-based validator that handles edge cases the regex version missed, with 25+ test cases including property-based coverage, implemented in the style of the existing validation library. The upfront prompt investment of 60 seconds produced code that needed no rework versus the casual prompt's output which needed three rounds of correction.
Great prompts start with a spec, constrain the output format, and ask for reasoning before code. Everything else is details — but the details compound.
The short version
Fifteen prompting patterns: spec-first, reference existing code, output format specification, chain-of-thought, negative constraints, red-team your prompt, explain-then-code, skeleton-of-thoughts, structured output, few-shot examples, role framing, anti-hallucination check, bounded experimentation, iterative refinement, and explicit handoff. None are magic; all compound. Developers who apply these habits consistently produce better output with less iteration than developers who prompt casually. Save templates, share them across your team, and treat prompt engineering as a learnable skill that rewards deliberate practice and investment. The ROI over a career of AI-assisted work is large enough that mastering prompting patterns is one of the highest-leverage investments a developer can make in 2026.