Prompt Engineering for Code: Patterns That Actually Work

Most developers interact with AI coding tools the same way they’d type a Google search — a vague sentence and hope for the best. After months of daily use, I’ve found specific patterns that consistently produce better code output. The difference between a mediocre prompt and a good one isn’t length — it’s structure.

Pattern 1: Structured Output Specification

Instead of asking “write me a function to validate emails,” specify exactly what you need. Constraints eliminate ambiguity.

Weak prompt:

Write a function to validate email addresses in TypeScript.

Strong prompt:

Write a TypeScript function called `validateEmail` that takes a string and returns `{ valid: boolean; reason?: string }`. It should check for: @ symbol presence, domain with at least one dot, no spaces, minimum 3 chars after the last dot. Don’t use regex — use string methods for readability. Include JSDoc.

The strong version produces exactly what you need on the first try. The weak version produces something generic that you’ll spend time modifying.

Pattern 2: Few-Shot Examples

When you need output that matches a specific style or format, show the model what you want. One or two examples beat a paragraph of instructions.

Convert these API responses to TypeScript interfaces. Follow the naming convention in my examples:

Input: { "user_name": "john", "is_active": true }
Output: interface User { userName: string; isActive: boolean; }

Input: { "order_id": 123, "line_items": [{"sku": "A1", "qty": 2}] }
Output: interface Order { orderId: number; lineItems: LineItem[]; } interface LineItem { sku: string; qty: number; }

Now convert this: { "product_id": 5, "price_cents": 1999, "tags": ["sale", "featured"], "created_at": "2026-01-01" }

The model picks up on your camelCase convention, the separate interface pattern for nested objects, and the naming style — all without you explicitly stating those rules.

Pattern 3: Chain-of-Thought Debugging

When you paste an error and ask “fix this,” the model often patches the symptom rather than the cause. Force it to reason through the problem:

I’m getting this error: TypeError: Cannot read properties of undefined (reading 'map') on line 42 of my component.

Before suggesting a fix:
1. List three possible causes for this error in this context
2. For each cause, explain what evidence would confirm it
3. Then suggest the most likely fix with an explanation

This produces a diagnostic process rather than a blind ?.map() band-aid. You learn something, and the fix is usually more robust.

Pattern 4: The “Act As Reviewer” Pattern

Instead of asking the model to write code, give it code and ask it to critique. This consistently produces more useful output than generation.

Review this React component for performance issues, accessibility problems, and potential bugs. For each issue found, rate it as Critical/Medium/Low and provide a specific fix.

[paste your component]

I use this before every PR. It catches things I miss — missing key props, uncancelled fetch requests, missing ARIA labels. It’s not a replacement for human review, but it’s a great first pass.

Pattern 5: Constraint Specification

Tell the model what NOT to do. This is surprisingly effective at preventing common AI code patterns that look clean but cause issues:

Write a custom React hook called `useDebounce` that debounces a value.

Constraints:
– No external dependencies (don’t use lodash)
– Must clean up the timeout on unmount
– Must be generic (work with any type)
– Don’t use `any` — use proper TypeScript generics
– Include the return type annotation

Without constraints, you’ll get lodash imports, any types, and missing cleanup. With them, you get production-ready code:

import { useState, useEffect } from "react";

function useDebounce<T>(value: T, delay: number): T {
  const [debouncedValue, setDebouncedValue] = useState<T>(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

Pattern 6: Incremental Complexity

Don’t ask for a complete system in one prompt. Build it up:

1. “Write the type definitions for a task management system with projects, tasks, and users”
2. “Now write the CRUD operations for tasks using those types. Use an in-memory store for now”
3. “Add input validation to the create and update functions using Zod”
4. “Replace the in-memory store with Prisma queries using this schema: [paste schema]”

Each step builds on verified, working code from the previous step. The alternative — asking for the whole thing at once — gives you a monolith that’s harder to debug when something’s wrong.

The Meta-Pattern

All of these patterns share one principle: reduce ambiguity. Every decision you don’t make in the prompt is a decision the model makes for you — and it might choose wrong. The more specific you are about types, constraints, naming conventions, and expected behavior, the more useful the output. Prompting is just another form of specification writing, and the same rules apply: vague specs produce vague results.