ptrnsai

God Prompt

Basic🚫 Anti-Pattern💥 Anti-Patterns: WorkflowAnthropic
🚫Anti-Pattern— This describes a common mistake to avoid, not a pattern to follow.

The Anti-Pattern

Cramming an entire complex task into a single monolithic prompt, expecting the LLM to handle everything at once.

Why It Happens

Developers try to avoid latency and architectural complexity by writing one mega-prompt: ‘Analyze the codebase, find the bug, fix it, write tests, update docs, and create a PR summary.’ The model’s attention spreads thin across all these subtasks, individual pieces get dropped or degraded, and the output is unreliable. The God Prompt feels efficient but produces worse results than doing each step properly.

How to Fix It

Decompose into focused steps using prompt chaining. Each step does one thing well and passes its output to the next. Total quality improves dramatically even though you make more API calls — because each call is simpler and more reliable. The test is simple: if your prompt has more than 3 distinct instructions, it’s probably a God Prompt. Split it.

Diagram

  God Prompt (unreliable):                Prompt Chain (reliable):
  ┌───────────────────────────┐           ┌─────────┐   ┌─────────┐   ┌─────────┐
  │ Analyze code              │           │ Analyze │──▶│  Fix    │──▶│  Test   │
  │ Find bugs                 │  ──▶ ?    │  code   │ ✓ │  bug    │ ✓ │  & doc  │
  │ Fix them                  │           └─────────┘   └─────────┘   └─────────┘
  │ Write tests               │              Step 1       Step 2        Step 3
  │ Update docs               │           Each step: focused, verifiable, reliable
  │ Create PR summary         │
  └───────────────────────────┘

Symptoms

  • Prompts contain 4+ distinct instructions or subtasks
  • LLM consistently drops or poorly executes some subtasks
  • Output quality varies wildly between runs of the same prompt
  • Users keep adding ‘Don’t forget to...’ reminders to the prompt

False Positives

  • Simple tasks that genuinely can be done well in a single call
  • Tasks where the overhead of decomposition exceeds the quality benefit
  • Quick one-off queries where reliability isn’t critical

Warning Signs & Consequences

Warning Signs

  • Prompt length exceeding 500+ words of instructions
  • Frequent re-runs hoping for a better output this time
  • ‘Don’t forget to...’ patches accumulating in the prompt
  • Inconsistent results — sometimes great, sometimes missing entire sections

Consequences

  • Unreliable execution where subtasks are dropped or degraded
  • Wasted tokens on retries when the output misses something
  • User frustration from unpredictable quality
  • False sense of efficiency — one call that needs 3 retries costs more than 3 focused calls

Remediation Steps

  1. 1Identify the natural task boundaries in your mega-prompt
  2. 2Create a separate focused prompt for each subtask
  3. 3Define clear input/output formats so steps can pass data
  4. 4Add validation gates between steps to catch errors early
  5. 5Test each step independently before testing the full chain

Real-World Example

Code Review Attention Spread

A code review prompt asks the LLM to check for bugs, security issues, performance problems, style violations, and documentation gaps all at once. It consistently catches style issues (easy, pattern-matching) but misses a critical SQL injection vulnerability (hard, requires reasoning). Splitting into separate security, performance, and style review prompts catches all issues because each prompt gets the model’s full attention.

References