Prompt patterns for software engineering tasks guide

Effective prompting is a high-leverage engineering skill in 2026. The difference between a prompt that produces working, production-quality code and one that produces buggy scaffolding is not luck — it is pattern. This guide documents the most effective prompt patterns for software engineering tasks, with concrete examples and the reasoning behind each.

Why Prompting Patterns Matter for Engineers

AI coding assistants (Claude, GPT-4o, Gemini, Copilot) have transformed software development workflows. But raw AI capability is only part of the equation — the quality of AI-assisted output is directly proportional to the quality of the prompt. Poorly structured prompts produce hallucinated APIs, incorrect edge case handling, and code that doesn't fit the existing codebase. Well-structured prompts using established patterns produce code you can actually ship.

Pattern 1: Rich Context Setting

The single highest-impact prompting improvement for most engineers: provide full context before asking for code. AI models are stateless — they don't know your tech stack, your coding conventions, your existing interfaces, or your constraints unless you tell them.

❌ Poor:
"Write a function to validate an email address"

✅ Rich context:
"I'm working in TypeScript 5.3 with Zod 3.x for validation.
We use Result types (Ok/Err) for error handling, not exceptions.
Write a Zod schema for email validation that:
- Returns a Result<string, ValidationError>
- Checks RFC 5321 format
- Rejects disposable email domains (provide a hardcoded list of 5 common ones)
Follow the naming pattern of our existing validators:
  export const validateEmail = (input: unknown): Result<string, ValidationError> => {..."

Pattern 2: Decompose Before Implementing

For complex tasks, ask the model to outline its approach before writing code. This serves two purposes: it surfaces misunderstandings early (you can correct the approach before the model writes 200 lines of code going in the wrong direction), and it tends to produce better-structured implementations because the model has "thought through" the design.

// Two-step prompting for complex implementations

// Step 1: Design first
"Before writing code, outline the approach for implementing
a distributed rate limiter using Redis. Cover:
- Data structure choice and why
- Race condition handling
- Token bucket vs sliding window trade-off for our use case
- Edge cases to handle
Don't write code yet — just the design."

// Step 2: Implement the confirmed design
"The sliding window approach with a sorted set looks good.
Now implement it in TypeScript using ioredis. Include
the race condition fix you described using Lua scripting."

Pattern 3: Role and Expertise Assignment

Assigning a specific technical expertise role produces more specialised, nuanced output than a generic request. The role primes the model to apply domain-specific knowledge and conventions.

Pattern 4: Explicit Negative Constraints

Telling the model what NOT to do is as important as telling it what to do. Without negative constraints, models often default to patterns that may be common in training data but wrong for your context.

// Effective negative constraints in prompts:

"Write a React component to fetch and display user data.
Do NOT:
- Use class components (hooks only)
- Use useEffect for data fetching (use React Query)
- Include inline styles (use Tailwind classes only)
- Add error boundaries (handled by parent)
- Use any state for loading (React Query handles it)
DO:
- Handle the loading and error states from useQuery
- Accept userId as a required prop
- Use our existing UserCard component for display"

Pattern 5: Few-Shot Examples from Your Codebase

Providing 1–3 examples of similar code from your actual codebase is the most effective way to ensure style consistency. Models are excellent at pattern-matching — show them the pattern and they will follow it precisely.

"Here is how we currently implement service layer functions in this codebase:

[EXISTING EXAMPLE]
export async function getUserById(id: string): Promise<Result<User, AppError>> {
  return withDB(async (db) => {
    const user = await db.users.findOne({ id });
    if (!user) return Err(new NotFoundError('User', id));
    return Ok(userMapper.toDomain(user));
  });
}

Following this exact pattern, implement getOrderById that:
- Takes an orderId string
- Returns Result<Order, AppError>
- Includes the order's line items (join with order_items table)
- Uses the existing orderMapper.toDomain function"

Pattern 6: Test-First Prompting

Describe the expected behaviour through tests before asking for implementation. This constrains the implementation to exactly the behaviour you need and often produces better-structured code than describing requirements in prose.

"Implement the calculateShipping function that makes all these tests pass:

it('returns free shipping for orders over £50', () => {
  expect(calculateShipping({ total: 50.01, items: 1 })).toBe(0);
});
it('returns £3.99 for standard orders under £50', () => {
  expect(calculateShipping({ total: 49.99, items: 1 })).toBe(3.99);
});
it('adds £1.50 per additional item over 3', () => {
  expect(calculateShipping({ total: 10, items: 5 })).toBe(3.99 + 3.00);
});
it('throws for negative totals', () => {
  expect(() => calculateShipping({ total: -1, items: 1 })).toThrow(ValidationError);
});"

Pattern 7: Iterative Refinement with Anchored Instructions

When refining AI-generated code, reference specific parts of the output rather than describing changes in the abstract. "Change line 23" is clearer than "the part where you validate the email" — and anchoring prevents the model from misidentifying which part you want changed.