Claude Code over-engineers by default — the six-question ladder that stops it, with or without a plugin

Ask a coding agent for email validation and you don’t get a line — you get an EmailValidator class with a wrapper, config options nobody requested, and a regex that’s somehow still wrong. That failure mode is so universally recognized that a fix for it became the top post on r/ClaudeCode today: a “lazy senior dev” skill the author benchmarked at roughly 6× less code on his launch tasks. The thread sits at 1,200+ upvotes and the repo crossed 750 stars within days.

The skill is worth knowing about. The mechanism inside it is worth understanding even if you never install anything — it’s a dozen lines of CLAUDE.md away. This page covers both, plus the two sharp critiques from the same thread that the victory laps skipped.

The 30-second version

1. Agents over-deliver because they treat every prompt as a feature request. Nothing in their reward signal prices in the cost of a line of code.
2. The fix that works is a forced pause: a fixed sequence of “can I avoid writing code?” checks the agent must walk before generating anything.
3. You can get it as a plugin — Ponytail, MIT, auto-activates in Claude Code, ships rules files for Cursor/Windsurf/Cline/Copilot/Aider/Kiro.
4. Or paste the no-install version below into your CLAUDE.md. The checklist does the work; the persona is decoration.
5. Watch the failure mode in the other direction: “minimum code” is not “fewest lines”, it’s no more than necessary — and necessary includes the right abstraction.

Why agents write 190-line dashboards for 13-line tasks

The launch post’s best anecdote: asked for a countdown timer, the unmodified agent produced a 190-line “dashboard” with animations nobody asked for. The skill-equipped run shipped 13 lines.

This isn’t a Claude quirk; it’s the default disposition of every current coding agent. Three forces stack:

• Thoroughness is rewarded, brevity isn’t. Models are tuned to be helpful and complete. An agent that handles edge cases you didn’t mention feels more competent — so that behavior won.
• Every prompt reads as a feature request. As one commenter put it, most over-generation happens because the model treats each instruction as a green light to build, not a question to scope.
• Nobody prices the output. A human senior dev hesitates before adding a class because they’ll maintain it. The agent won’t — but you will, and on metered plans you’re also paying for every token of it. The same week this thread ran, a separate 588-upvote post made the cost angle explicit: experienced users have Claude build deterministic scripts precisely so repeated work costs zero tokens. Output volume is quota, money, and review burden.

The mechanism: five chances to not write code

Strip the ponytail-and-glasses character away and the skill is a decision ladder the agent must walk, in order, before generating code:

1. Does this need to exist at all? If not — and “not” includes deleting code instead — stop there.
2. Does the standard library already do it? Use it.
3. Does a native platform feature do it? Use it.
4. Does an already-installed dependency do it? Use it.
5. Can it be one line? Then it’s one line.
6. Only after all five: write new code — the minimum that works.

The author’s expanded benchmark (six adversarial tasks, in the repo) self-reports 47% fewer tokens, ~3× faster runs, and 490 total lines versus 3,629 for the unmodified control, with both variants passing the same security and concurrency probes; on a follow-up feature-extension task the gap was 96 changed lines versus 1,115. Treat the numbers as a founder demo, not an independent eval — the launch post’s earlier five-task run claimed a different set (16% fewer tokens, ~4× faster, 293 lines → 47), so the measurements are clearly evolving. The direction is consistent and matches what the mechanism predicts: most generated code fails the “did this need to exist?” test.

Install as a plugin (/plugin marketplace add DietrichGebert/ponytail in Claude Code), or grab the per-tool rules files from the repo if you’re on Cursor, Windsurf, Cline, Copilot, Aider, or Kiro. The plugin form auto-activates every session — which matters, because a commenter nailed the real reason packaging wins: consistency beats a perfect prompt you forget to use.

The no-install version

Most of the effect is available as plain rules. Ours, distilled from the ladder plus the thread’s corrections — paste into your project’s CLAUDE.md (see our CLAUDE.md guide for where these live):

## Code volume rules

Before writing any code, answer in order — first "yes" wins:
1. Solvable by deleting code or doing nothing? Do that.
2. Standard library already does it? Use it.
3. Platform or an installed dependency already does it? Use it.
4. A small edit to existing code suffices? Make that edit.
5. Only then write new code — the minimum that satisfies the stated requirement.

- No wrapper classes, managers, or abstraction layers for a single call site.
- No handling for error conditions that cannot occur in this codebase.
- No features, options, or configuration beyond what was asked.
- After tests pass, do one simplification pass: remove anything the tests don't require.
- If the request is ambiguous between a small fix and a subsystem, ask before building the subsystem.
- Exception: when the task is structural (shared logic, public interfaces), prefer the proper
  abstraction over the shortest diff — say which rule you're overriding and why.

Note what’s not in there: a character. The next section is why.

What the skeptics in the thread got right

Two pushbacks stood out, and both survive contact with how these models actually work.

The persona is overhead, not mechanism. The sharpest critical comment argued that personas pollute context: every thinking block now spends tokens decoding what “a lazy senior dev who’s seen it all” implies for the code at hand, instead of just following constraints. The checklist — a concrete, ordered sequence of checks — is what changes output. The costume rides along in every context window, costing tokens and adding interpretive noise. If you write your own rules, write imperatives, not characters. (The plugin’s results don’t refute this; its rules contain the ladder and the persona, and the ladder plausibly does all the lifting.)

Minimum ≠ fewest lines. The top engineering comment drew the line precisely: senior devs don’t one-line because shorter is better — they write no more than necessary, and necessary includes feature-completeness and the right abstraction for the code’s future (separation of concerns, DRY where it’s load-bearing, bounded contexts). A hard “one line if possible” preference produces band-aids: locally minimal patches that retire nothing and accrue interest. His countermeasure is a prompt worth stealing — when the agent proposes an approach, ask whether it’s the proper fix that retires the debt or a patch over it; in his experience the model frequently admits it’s a patch and produces the structural fix when asked. That check is the Exception line in our rules block.

Levers that need no rules at all

• Plan first, then constrain the plan. Over-engineering is cheapest to kill at the plan stage — “your plan has 4 components; which 2 can be deleted?” costs one message. Cutting generated code after the fact costs review time.
• Ask for the simplification pass explicitly. After green tests: “remove everything the tests don’t require.” Agents are good at this when asked and almost never do it unasked — the same bias that over-builds also under-deletes.
• Lower the effort setting for mechanical work. On models that expose effort control, lower effort produces terser output and fewer, more consolidated tool calls — we keep it low for rote edits and raise it for design work. It’s a volume knob that costs nothing to turn.

What would change this page

An independent replication of the benchmark (the repo’s numbers are self-reported and have already shifted once between the launch post and the README); a Claude Code release that prices output volume natively — say, a built-in diff-budget mode; or evidence that the rules degrade correctness on structural tasks, which is the failure direction the thread’s best critics predicted.

Companion reading

• The CLAUDE.md Guide — where project rules live, what belongs in them, and what doesn’t
• Five habits in your CLAUDE.md that are quietly burning tokens — the input-side twin of this problem: context bloat instead of output bloat
• Managing Claude Code’s context window — less code generated is less context consumed; the runtime side of the same token math
• Claude Code usage limits, explained — why output tokens are the meter that matters on capped plans

Sources

1. r/ClaudeCode — “I gave Claude Code a ‘lazy senior dev’ mode and it writes like 6x less code” (June 12, 2026)
2. Ponytail — the skill, rules files, and benchmark data (DietrichGebert, MIT)
3. r/ClaudeAI — “build tools with Claude Code that cost zero tokens to run” (June 11, 2026)
4. Anthropic engineering — Claude Code best practices (CLAUDE.md conventions)

FAQ

How do I stop Claude Code from writing too much code? Put explicit code-volume rules in CLAUDE.md: a fixed pre-code checklist (does this need to exist → stdlib → platform → existing dependency → small edit) and only then minimum new code. The plugin version auto-activates; the rules version above gets most of the effect with zero install.

Does the Ponytail skill work with Cursor, Windsurf, or Copilot? Yes — it’s a Claude Code plugin first, but the repo ships plain rules files for Cursor, Windsurf, Cline, Copilot, Aider, and Kiro, plus an AGENTS.md for everything else. MIT licensed.

Do persona prompts like “you are a lazy senior dev” actually help? The checklist does the work; the costume is overhead. Persona text rides along in every context window and makes the model spend tokens interpreting the character. Plain imperative constraints produce the same restraint more cheaply.

Can forcing minimal code backfire? Two ways: band-aid fixes where structural work was needed (locally minimal, globally expensive), and over-absolute rules fighting legitimate multi-part implementations. Keep an explicit exception for structural tasks and ask the agent whether its proposal is the proper fix or a patch — it will usually tell you.