10 Production Prompt Design Patterns from Real-World AI Systems

Introduction

In a recent series of articles, the author explained how to write prompts and dissected seven real-world system prompts—Claude chat interface, ChatGPT GPT-5.2 Thinking, Perplexity search agent, Claude Code programming agent, v0 (Vercel) frontend generation agent, and Claude Fable 5.1. This article summarizes those analyses into ten universal design patterns for production-grade prompts.

Pattern 1: Vertical Products = Prohibition Lists, General Products = Principle Manuals

v0 only does frontend generation; its prompt is full of "don't use purple," "don't write config files," "don't draw SVG"—the more vertical the product, the more the prompt resembles a prohibition list . In contrast, general products like Claude and ChatGPT use behavior principle manuals —describing how to think and judge, not what to avoid.

Why? Vertical products need consistency—all generated pages must share the same style, so boundaries are drawn strictly. General products need flexibility—users ask anything, so rules must not block the path. The more vertical the product, the more concrete the constraints; the more general, the more abstract the principles.

Pattern 2: Tool Count Determines Prompt Length, Tool Definitions Are the Bulk

Perplexity has 8 tools, prompt ~1K words; Cursor has 13 tools, prompt 12K words; the 275K extraction version has 38 tools. The real volume isn't identity descriptions like "you are a helpful assistant" but tool JSON schemas, parameter descriptions, usage examples, and error-handling rules .

Key insight: Prompt length isn't designed—it's stacked by tool count. Each added tool requires a definition block: parameter types, required fields, enum values, when to use, when not to use. 38 tools × hundreds of words each—the 68.5K-character extraction shows tool schemas occupy the largest share. This is why modern agents routinely consume hundreds of thousands of context tokens.

Pattern 3: Every Rule Stems from a Real Bug Encountered

Cursor's terminal command rules (non-interactive flags, piping to | cat, background execution, no line breaks) each correspond to a real bug that occurred. Claude Code's "max 3 retries" exists because the model fell into retry loops burning user API quota. v0's "don't use indigo-blue" came from all AI-generated sites looking identical, causing user aesthetic fatigue.

Production-grade prompts aren't designed—they're iterated from bugs —ship, hit issues, add rules, ship again. No product's system prompt was perfect from day one; they evolved through dozens or hundreds of iterations.

Pattern 4: Brand Identity Written into the System Prompt

Cursor insists on identifying as "Composer" not Claude—users shouldn't know the underlying model. v0 refuses without explanation, just "I can't do that"—maintaining product mystique. ChatGPT's persona says "don't flatter the user"—OpenAI's brand tone. Anthropic's "warm and empathetic"—Anthropic's brand tone.

Prompts define not just behavior but brand —how users perceive the AI is largely shaped by identity declarations and tone rules in the system prompt. Different companies' AI "personalities" are essentially different persona rules in their prompts.

Pattern 5: Layered Architecture = Foundation of Maintainability

ChatGPT's Developer Messages layer and Anthropic Agent SDK's four-layer system—base behavior (safety, identity, tone) stays stable, while product feature rules (search, images, code execution) are modularly stacked. Changing style doesn't touch base prompt; changing product rules doesn't touch safety policy.

Layering enables maintainability: Each layer iterates independently without ripple effects. If all rules are in one block, changing a punctuation mark risks breaking something else. Modularization lets teams work in parallel—security team owns safety layer, product team owns feature layer, UI team owns style layer.

Pattern 6: Constraints > Guidance—Correcting Model Default Tendencies

Claude Code's anti-over-engineering rules (don't proactively refactor, don't abstract prematurely) correct the model's "default tendencies." Models naturally tend to do more, aim for perfection, write docs and comments. Production needs just enough .

v0's "don't use indigo-blue"—models love blue because training data has mostly blue sites. Anthropic's "don't use lists"—models love bullet points because training data is full of lists. Telling the model "what not to do" works better than "what to do" —because the model already has defaults; you're hitting the brakes, not the gas.

Pattern 7: Honesty Is the Highest Design—Acknowledging Weaknesses

Anthropic states "Claude may forget its instructions over long conversations"—admitting long-context forgetfulness. ChatGPT says "Studies have shown you nearly always make arithmetic mistakes"—admitting poor arithmetic. ChatGPT's ad-handling rule—"I don't control or insert those ads"—gives a productized fixed refusal for ad requests.

These prompts don't pretend the model is omnipotent —they explicitly tell the model what it knows, doesn't know, and can't do. Why? If the model pretends to know everything, it hallucinates. If it honestly says "I don't know," users trust it more. Admitting weaknesses builds more trust than faking omnipotence.

Pattern 8: De-AI-ing—Deliberately Removing Default Model Style

Anthropic's tone_and_formatting section—no lists, no emojis, no over-formatting, no asterisk action descriptions. ChatGPT's Writing Style—no "good question," no meta-commentary, show don't tell. v0's color rules—no indigo-blue.

All products do the same thing: eliminate the AI's default style. AI output has a strong "AI flavor"—bold everywhere, lists everywhere, opening with "Great question!", color schemes all blue-purple. Users get fatigued. Production prompts deliberately steer toward "human-written"—less formatting, less boilerplate, fewer tropes. De-AI-ing is a core task of modern prompt engineering.

Pattern 9: Risk Grading—Not One-Size-Fits-All, But Tiered Decisions

Claude Code's two-tier reversibility—local reversible actions execute directly; hard-to-undo or shared-system actions require confirmation. ChatGPT's current-role query protocol—"who is the current X" treated as untrustworthy, search without name first then add details. Perplexity's three-tool-call hard limit—max three tool calls, controlling cost while preserving coverage.

Production prompts have no "blanket" rules —every decision is risk-graded. Low risk: execute directly. Medium risk: ask. High risk: refuse. This is more efficient than "confirm everything" and safer than "execute everything." Risk grading balances agent autonomy and safety.

Pattern 10: UX Details Embedded in the Prompt—Good Experience Is Designed

ChatGPT's citation rules—citations after punctuation, not stacked at end. Perplexity's no-nested-lists—only top-level lists, lowest scan cost. Cursor's lint call scope discipline—only call read_lints on currently edited files, avoiding treating legacy errors as own errors. Anthropic's list-rule exception—in prose, enumerate with natural language ("x, y, and z"), not sneaky line-break bullets.

These rules aren't about "correctness" but "experience." Content may be right but formatting poor, and UX suffers. Production prompts govern not just "what to output" but "how to layout, how to cite, how long is appropriate"—these UX details are coded into the prompt. Good product details are carved into the prompt bit by bit.

From Prompt Engineering to Context Engineering

Traditional "prompt engineering" means writing better instructions for better outputs. But these seven cases show modern AI product engineering has moved beyond "writing prompts" :

The prompt itself is only a small part of the runtime context—the 68.5K-character extraction shows tool definitions and system mechanisms dominate (275K case).

What truly determines output quality: what information is retrieved, which tools are provided, how much history is retained, when context is refreshed.

Critical rules can't rely on prompts alone—must be enforced in code via permission checks, input validation, safety filters.

Prompts are "soft constraints"; code is "hard constraints."

This is the rise of Context Engineering: Agent performance is no longer decided by how elegantly a few hundred words of instruction are written, but by how the entire context environment is constructed, managed, and governed. Prompt engineering is the entry point; context engineering is the future.