---
title: "Prompt Engineering for Code Generation: Patterns That Work in 2026"
date: 2026-05-23
tags: ["prompt-engineering","code-generation","claude-code","agentic-coding","guides","spec-driven-development"]
categories: ["Guides","Agentic Workflows"]
summary: "Most developers using AI to generate code are leaving significant quality on the table. These seven prompting patterns — grounded in how frontier models actually process context — close the gap between 'it kind of works' and 'it ships to production.'"
---


The average developer prompt for code generation is a sentence or two describing desired behavior with no constraint context, no technology stack specification, no success criteria, and no indication of what already exists. Then they're surprised when the output doesn't fit the codebase.

This isn't a model limitation. It's a prompting problem.

Frontier models in 2026 can implement complex features, architect systems, write tests, and fix bugs autonomously — if you give them the information they need to work with. The developers getting consistently excellent results from Claude Code, GPT-5.5, and Gemini 3.5 Flash are the ones who have internalized how these models process prompts. The gap between "AI kind of helps sometimes" and "AI ships production code" is almost entirely prompting discipline.

Here are the patterns that consistently move the needle.

## Pattern 1: Specification Before Implementation

The most impactful change you can make is writing a specification before asking for code.

Most developers open a chat and say: "Write a function that fetches user orders and formats them for display." This puts the model in a position where it has to invent all the decisions that should be made explicitly: What's the API endpoint structure? What's the data shape? How should errors be handled? What's the output format? What edge cases need coverage?

The model will make those decisions — it has to — and they may not be the decisions you would have made.

Flip the order. Write a spec first:

```
## Order Fetching Component

**Goal:** Fetch a user's orders from `/api/v2/orders?userId={id}` and return them formatted for the OrderList UI component.

**Input:** userId (string, non-empty)

**Output:** Array of OrderSummary objects:
{ orderId: string, date: ISO8601, status: 'pending'|'shipped'|'delivered'|'cancelled', total: number }

**Error handling:** Throw OrderFetchError with code field for: network failure (NET_ERROR), 404 (USER_NOT_FOUND), 5xx (SERVER_ERROR)

**Constraints:** No external dependencies beyond the existing httpClient module. Use existing formatCurrency utility for monetary values.

**Tests required:** Happy path, each error type, empty order array.
```

Now ask for implementation. The model generates code that fits because you've already made the decisions.

This is the core of Spec-Driven Development. The spec file becomes the source of truth. The code becomes a byproduct of the spec.

## Pattern 2: Constraint Framing

Models try to be helpful. Left to their own devices, they'll use the most capable tool for the job, add error handling for edge cases they imagine might exist, and introduce abstractions that might be useful in hypothetical futures.

Most of the time, that's exactly wrong for production code.

Effective constraint framing tells the model what NOT to do:

- "Do not add any new dependencies. Use only what's in package.json."
- "Do not introduce a new abstraction layer. Add this behavior to the existing UserService class."
- "Do not add docstrings or comments. The code should be self-documenting."
- "Do not handle the database migration here. Focus only on the service layer."

Negative constraints are at least as important as positive requirements. The model defaults to comprehensive — you often want targeted.

This pattern matters most when you're adding to an existing codebase. Mention what's already there and explicitly tell the model to work within it rather than around it.

## Pattern 3: Test-First Prompting

Ask the model to write the tests before the implementation.

This sounds counterintuitive — you're adding a step before you get the code you wanted. In practice it does two things:

First, it forces the model to specify the interface before implementing it. A test suite that compiles is a precise specification of inputs, outputs, and behavior. Any ambiguity in your requirements becomes immediately apparent when you read the test assertions.

Second, it gives you a verification mechanism. When the model then implements against its own test suite, failures are surfaced within the same context window. The model sees the test output, understands what's wrong, and fixes it — without you having to read the code to identify where the problem is.

In Claude Code, you can make this explicit: "Write the test suite first. Once I approve it, implement the function to pass it." The /loop command can automate the run-test-fix cycle.

## Pattern 4: Context Provision via CLAUDE.md

The context a model has access to determines the quality of the code it generates. A model that doesn't know your authentication approach will invent one. A model that doesn't know your error handling conventions will apply whatever feels standard. A model that doesn't know your preferred test patterns will use whatever it's seen most.

CLAUDE.md solves this at the project level. Put your architectural decisions, naming conventions, patterns to follow, patterns to avoid, and critical invariants in a CLAUDE.md file at the repo root. Every Claude Code session inherits this context automatically.

The three things that belong in every CLAUDE.md:

**Tech stack and versions.** "This is a React 19 application with TypeScript 5.7. All async code uses async/await, not Promise chains. State management is Zustand 5."

**Critical constraints.** "Never use `any` types. Never catch errors silently. All user inputs must be validated at the boundary before entering service functions."

**Existing patterns to follow.** "Database queries follow the repository pattern in `/src/repositories`. Add new queries there. Service functions are in `/src/services` and should not import from each other."

For teams, maintaining CLAUDE.md is as important as maintaining a style guide. It compounds: every good pattern you add reduces the variance in every future session.

## Pattern 5: Decomposition Over Omnibus Requests

"Build me a user authentication system with OAuth, email/password, password reset, email verification, rate limiting, and JWT refresh tokens" is a bad prompt.

Not because models can't implement authentication — they can — but because the output of a single omnibus prompt is a monolith that's hard to verify, hard to modify, and hard to reason about in a conversation.

Decompose the work:

1. "Design the database schema for user accounts, sessions, and password reset tokens. Don't implement anything yet — show me the schema and I'll approve it."
2. "Implement the registration flow using the schema you designed. Email/password only."
3. "Add email verification to the registration flow."
4. "Now add the password reset flow."

Each step produces a reviewable, testable unit. You approve or redirect before the next step builds on top of it. Mistakes don't propagate. Context stays focused on one problem at a time.

In agentic workflows, this decomposition is often handled by a planning phase. Claude Code's /ultraplan command spins up a dedicated planning session that produces a decomposed implementation plan before any code is written. The plan becomes the spec.

## Pattern 6: Role and Audience Specification

"You are a senior backend engineer" is not just performative. It changes the output.

Models are trained on text from every level of developer — students learning to code, hobbyists making one-off scripts, experienced engineers writing production systems. Without framing, you're sampling from that entire distribution. With a role specification, you're shifting the distribution toward the output style you actually want.

Be specific and load-bearing:

- "You are a senior backend engineer on this team. This code will be reviewed by the team's security-focused lead engineer. Write as though defending every decision in a code review."
- "You are a TypeScript expert. Prioritize type safety and compiler-checkable invariants over runtime validation."
- "You are writing for a junior developer who will maintain this code. Prefer explicit over clever."

Role framing works best when combined with audience framing. "Who will read this output?" changes what the model produces as much as "who are you."

## Pattern 7: Iterative Refinement

Treating AI code generation as a one-shot operation is the most expensive mistake in the pattern.

The output of the first prompt is the start of a conversation, not the end of a task. The most effective workflow:

1. Get the initial implementation.
2. Read it. Find the two or three things that are wrong or that you'd do differently.
3. Be specific in your follow-up: "The error handling in `fetchOrders` is catching too broadly. It should only catch `NetworkError`, not generic `Error`. Fix that and nothing else."
4. Don't accept drift — when you ask for one change and get three, call it out: "You changed the interface signature in addition to the error handling. Revert the interface change."

Models are good at targeted modifications when you give them precise targets. The failure mode is cascade: each imprecise follow-up introduces small wrong changes that compound through successive iterations.

## Putting It Together

The anatomy of a prompt that consistently produces production-ready code:

```
**Role:** You are a senior Go engineer.

**Context:** This is a gRPC service handling payment processing. Existing code is in /src/payments/. The repository pattern is documented in CLAUDE.md.

**Task:** Add a RefundOrder method to PaymentService that calls the payment gateway's /refunds endpoint.

**Spec:**
- Input: orderId (string), amount (cents, int64), reason (enum: DUPLICATE|FRAUD|CUSTOMER_REQUEST)
- Output: Refund{id: string, status: string, processingTime: time.Time}
- Error: PaymentGatewayError with Code field for rate-limit (429), invalid request (400), gateway failure (5xx)

**Constraints:**
- Do not modify existing methods
- Use the existing httpClient from PaymentGateway struct
- Do not add new dependencies
- Follow the error wrapping pattern in the existing code

**Tests required:** Happy path, each error code, amount validation (must be positive).
```

This isn't more work than writing vague prompts and iterating through confusion — it's less work, because the output is closer to correct on the first pass.

The developers producing consistently excellent AI-generated code are the ones who have realized that the prompt is the spec. Time spent on the prompt is time saved on review, debugging, and rework.

---

**Further reading:**
- [The Complete CLAUDE.md Guide — sdd.sh](/posts/the-complete-claude-md-guide-project-configuration)
- [The Spec File as Source of Truth — sdd.sh](/posts/the-spec-file-as-source-of-truth-sdd)
- [What Is Spec-Driven Development? — sdd.sh](/posts/what-is-spec-driven-development)
- [Anthropic Prompt Engineering Documentation](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [Claude Code Documentation](https://code.claude.com/docs)