Prompt Engineering for Developers: Patterns That Produce Production-Ready Code Every Time

General prompt engineering advice — “be specific”, “give examples”, “break down the task” — is too vague to actually improve your code generation results. Developer-specific prompt engineering is about understanding what information the model needs to match your codebase context, your error handling conventions, your type system, and your testing requirements. These patterns are specifically designed for code generation tasks.

⚡ TL;DR: The highest-impact prompt engineering moves for code: (1) constraint-first prompting, (2) providing existing code as context before asking for new code, (3) chain-of-thought for algorithms, (4) structured JSON output format, (5) explicit quality requirements section. These five patterns alone raise output quality dramatically.

Pattern 1: Constraint-first prompting

// Anti-pattern: describe what you want
// "Write a function to process user orders"
// Result: generic implementation with wrong error handling,
//         wrong types, wrong logging, wrong patterns for your codebase

// Pattern: constraints before description
const GOOD_PROMPT = `
CONSTRAINTS (must satisfy all):
- TypeScript strict mode — no any, no type assertions
- Pure function — no side effects, deterministic output
- Uses existing OrderStatus enum from ./types/order
- Errors: throw OrderProcessingError (from ./errors) not generic Error
- Logging: never use console — use the logger parameter
- Performance: O(n) time, O(1) additional space

TASK:
Write a function processOrders(orders: Order[], logger: Logger): ProcessedOrder[]
that validates each order, calculates totals, and returns processed results.

QUALITY REQUIREMENTS:
- JSDoc with @param, @returns, @throws
- Handle: empty array, null amounts, negative quantities
- Do NOT call any external services — pure transformation only
`;

// The constraint section is parsed first by the model
// It cannot generate code that violates explicit constraints as easily

Pattern 2: Context injection — show before asking

// Anti-pattern: ask without context
// "Write middleware for rate limiting"
// Model generates generic code with wrong error class, wrong response format

// Pattern: show your existing code first
const CONTEXT_PROMPT = `
Here are examples from my existing codebase:

// Existing middleware pattern:
const authMiddleware = (req, res, next) => {
  try {
    const token = req.headers.authorization?.split(' ')[1];
    if (!token) throw new AppError('MISSING_TOKEN', 401);
    req.user = verifyToken(token);
    next();
  } catch (err) {
    next(err); // All errors go to next()
  }
};

// Existing error class:
class AppError extends Error {
  constructor(code, statusCode, details = {}) {
    super(code);
    this.code = code;
    this.statusCode = statusCode;
    this.details = details;
  }
}

Now write rate limiting middleware using EXACTLY the same patterns:
- Same try/catch structure
- Same AppError usage: throw new AppError('RATE_LIMIT_EXCEEDED', 429)
- Same error propagation: next(err)
`;
// Model now generates code that matches your existing patterns exactly

Pattern 3: Chain-of-thought for complex algorithms

// For complex algorithmic code, make the model reason before writing

const COT_PROMPT = `
I need to implement a token bucket rate limiter using Redis.

Before writing any code, think through:
1. What Redis data structure should hold the bucket state?
2. How do you handle the refill calculation without a background timer?
3. What is the race condition between checking tokens and consuming one?
4. How do you make the check-and-consume operation atomic?
5. What happens if Redis is unavailable — fail open or closed?

For each question above, state your answer and why.
Then write the implementation based on your reasoning.
`;

// The reasoning step:
// 1. Forces model to surface assumptions before encoding them in code
// 2. Often reveals that the model's initial approach is wrong
// 3. Produces better code than asking directly
// 4. Makes review easier — you can evaluate reasoning, not just output

Pattern 4: Structured output format

// Request structured output instead of markdown code blocks
const STRUCTURED_PROMPT = `
Generate the implementation. Respond with this exact JSON:
{
  "implementation": {
    "filename": "src/middleware/rateLimiter.ts",
    "content": "",
    "dependencies": ["ioredis"]
  },
  "tests": {
    "filename": "src/__tests__/rateLimiter.test.ts",
    "content": ""
  },
  "notes": [
    "",
    ""
  ]
}
Return ONLY the JSON. No markdown. No explanation outside JSON.
`;

// Then in your code:
const result = JSON.parse(response.content[0].text);
await fs.writeFile(result.implementation.filename, result.implementation.content);
await fs.writeFile(result.tests.filename, result.tests.content);
console.log('Review notes:', result.notes);

The 10 anti-patterns that produce tutorial code

• ❌ “Write a function to [do X]” — no constraints, model uses defaults
• ❌ Asking for code without providing existing patterns to match
• ❌ “Write production-ready code” without defining what that means for your stack
• ❌ Accepting the first response without asking for reasoning
• ❌ Not specifying error handling strategy (throws vs returns result type)
• ❌ Not specifying the type system requirements (any vs strict)
• ❌ Asking for “with tests” in the same prompt as implementation
• ❌ Not giving the model a way to express uncertainty (ask for notes/concerns)
• ❌ Asking for multiple files at once in plain text (use JSON output)
• ❌ Accepting auth/crypto code without explicit security review prompt

The production prompt template

const PRODUCTION_CODE_TEMPLATE = `
STACK: [TypeScript 5.4 strict | Python 3.12 | Go 1.22]
FRAMEWORK: [Express 4 | FastAPI | Gin]
CONVENTIONS: [paste 10-20 lines of existing code to match style]

CONSTRAINTS:
- [list 5-10 specific constraints]

TASK:
[precise description of what to build]

ERROR HANDLING:
[how errors should be thrown/returned]

QUALITY:
- JSDoc required
- Handle edge cases: [list]
- Do NOT call: [list services/functions to avoid]

OUTPUT FORMAT: JSON with files, tests, notes
`;

These prompt engineering patterns power the AI code review bot — the structured JSON output pattern is directly used for parsing review comments. They also underpin the Claude code generation system prompt guide, which extends these patterns into full system prompt templates. External reference: Anthropic prompt engineering documentation.