Skip to content

Ponytail: Teaching AI Agents to Write Less Code (and Why It Works)

9 min read
AI Agents Developer Tools Claude Code Code Quality

I asked Claude Code for a countdown timer in React. It gave me 267 lines: four component variants, a custom hook, styled-components with CSS animations, a progress bar, and pause/resume logic I never asked for.

The correct answer was 9 lines.

This is the default mode of every AI coding agent I’ve used. You ask for X, you get X plus a helper function, a config object, error handling for scenarios that can’t happen, an advanced version, and a comparison table explaining why the advanced version is better. The model isn’t broken. It’s trained to be helpful. And “helpful” in the RLHF sense means comprehensive, thorough, covering all the bases. I wrote about this same pattern in how Claude Code actually works: the model is a maximalist generator by default, and all constraint has to come from the environment.

The result? Teams using AI agents report code review fatigue from bloated PRs, unnecessary dependencies sneaking in, and a growing surface area of code that nobody asked for but everyone now has to maintain. The UC San Diego study on professional developers found that experienced engineers spend most of their AI interaction time constraining output, not generating it. They plan, verify, and prune. Ponytail automates the pruning.

Ponytail fixes this at the prompt layer. It’s an MIT-licensed ruleset that you plug into Claude Code, Codex, Cursor, Copilot, Gemini/ Antigravity CLI, or any other agent, and it makes the agent behave like a lazy senior developer. Not careless. Lazy in the way that a principal engineer is lazy: they know the platform already solved this problem, and they refuse to re-solve it.

“He says nothing. He writes one line. It works.”

The Ponytail philosophy, distilled.

The Six-Level Laziness Ladder

Ponytail’s core mechanism is a decision ladder the agent must climb before writing any custom code:

LevelQuestionAction
1. YAGNIDoes this need to be built at all?Skip it
2. StdlibDoes the standard library do this?Use it
3. Native platformCan a browser/OS built-in cover it?Use it
4. Installed dependencyIs there an already-installed library?Use it
5. One lineCan this be done in a single expression?Make it one line
6. Minimum codeOnly then write the smallest working solutionWrite it

The agent is forced to stop at the lowest level that solves the problem. If structuredClone() exists, you don’t install lodash. If <input type="date"> works, you don’t reach for a date-picker library. If csv.DictReader handles it in one line, you don’t import pandas.

The ladder runs after the agent understands the problem, not instead of understanding it. It reads the code, traces the flow, then picks the lowest level that holds. Lazy about the solution, never about comprehension.

Here’s the decision flow:

  Need to exist?  ──no──▶  STOP (YAGNI)
       │ yes
  Stdlib does it? ──yes──▶  USE STDLIB
       │ no
  Native platform? ─yes──▶  USE BUILT-IN
       │ no
  Installed dep?  ──yes──▶  USE EXISTING DEP
       │ no
  One line?       ──yes──▶  WRITE ONE LINE
       │ no
       ▼
  MINIMUM CODE THAT WORKS

Why this works: LLMs are biased toward generation. They want to produce tokens. The ladder gives them a structured reason to stop early. It’s the same principle behind chain-of-thought prompting, but pointed at code minimalism instead of reasoning quality.

Before and After: The Date Picker That Started It All

The signature example captures the whole philosophy:

Without PonytailWith Ponytail
npm install flatpickr<input type="date">
Wrapper componentDone.
Stylesheet import
Timezone discussion
404 lines23 lines

That’s step 3: native platform feature. The browser literally ships a date picker. No dependency, no wrapper, no stylesheet. The agent reached for a native <input> instead of building a component.

More before/after survivors in their examples directory.

Single-Shot Benchmarks

These are verbatim output from the same model (Claude Haiku 4.5) on the same prompts, with and without Ponytail active:

TaskWithout (LOC)With (LOC)Reduction
Email validation75396%
Debounce1161091%
CSV sum20385%
Countdown timer267997%
Rate limiting1281092%

Here’s what the CSV task looks like in practice:

Without Ponytail (the model gives you pandas, error handling, a comparison of approaches):

import pandas as pd

df = pd.read_csv('sales.csv')
total_amount = df['amount'].sum()
print(f"Total amount: ${total_amount:,.2f}")

Plus two alternative implementations and a recommendation table. 20 lines total.

With Ponytail (stdlib first, one expression):

import csv

total = sum(float(row['amount']) for row in csv.DictReader(open('sales.csv')))
print(total)

3 lines. No pandas dependency. The ponytail: comment would note: “Skipped pandas, error handling, file closing. Add when the CSV is large, malformed, or you need more analysis.”

The Debt Tracking Pattern

This is where Ponytail gets interesting from an engineering perspective. Every intentional shortcut is annotated with a ponytail: comment that names:

  1. What was simplified
  2. The known ceiling of the simplification
  3. The upgrade path when you outgrow it
// ponytail: structuredClone does this. Ceiling: can't clone functions or DOM nodes.
// Upgrade: custom clone when you need those types.
const copy = structuredClone(original);

Then /ponytail-debt harvests all these comments into a structured ledger. You run it during backlog grooming and decide which shortcuts to pay down. This turns “we took a shortcut” from hidden fragility into explicit, tracked technical debt with a named upgrade path.

The key insight: deliberate under-engineering with a documented ceiling is safer than accidental over-engineering that nobody fully understands. The 9-line countdown timer is trivial to extend when you actually need pause/resume. The 267-line version is a maintenance burden from day one.

Architecture: One Ruleset, Every Agent

Ponytail is structured as a single authoritative ruleset in AGENTS.md that gets copied into host-specific formats:

AGENTS.md (source of truth)
├── .claude/settings.json (Claude Code plugin)
├── .cursor/rules/ (Cursor)
├── .windsurf/rules/ (Windsurf)
├── .github/copilot-instructions.md (Copilot)
├── gemini-extension.json (Gemini CLI / Antigravity)
├── hooks/ (Claude Code / Codex lifecycle hooks)
└── pi-ponytail/ (Pi agent package)

A sync script (check-rule-copies.js) ensures all copies stay identical to the source. This is the same pattern I’ve been advocating in harness engineering: encode your engineering standards once, enforce them everywhere the agent runs.

For Claude Code, installation is two prompts:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

The lifecycle hooks automatically inject Ponytail’s instructions at session start, so you don’t need to remember to invoke it. The skills (/ponytail-review, /ponytail-audit, /ponytail-debt) work as slash commands in hosts that support them and as chat-triggered operations elsewhere.

Do the Benchmarks Hold Up?

I respect that Ponytail is honest about its own numbers. The original single-shot benchmarks (80-94% less code) were partially a conversational-baseline artifact: the bare model pads its answer with prose, options, and comparison tables that inflate the “without” count. The team acknowledged this in issue #126 and ran a more rigorous agentic benchmark.

The corrected numbers come from headless Claude Code sessions editing a real FastAPI + React repo (12 feature tickets, n=4, Haiku 4.5), scored on the git diff left behind:

vs no-skill baselineLOCTokensCostTimeSafe
Ponytail-54%-22%-20%-27%100%
Caveman (terse-prose control)-20%+7%+3%+2%100%
“YAGNI + one-liners” prompt-33%-14%-21%-30%95%

The key column is “Safe.” They ran adversarial checks for dropped validation, missing error handling, and security gaps. Ponytail stays at 100%. The naive “YAGNI + one-liners” prompt hits 95% because it drops a safety guard that Ponytail’s explicit guardrails protect.

The single-shot numbers (80-94%) still hold for isolated generation tasks where the baseline is genuinely bloated. But 54% on real agentic work is the defensible figure. Reproduce it yourself: npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml.

Where the real cost savings compound: it’s not the generation turn. The savings come from every subsequent turn in the session. In an agentic loop, generated code lands in context and stays there for every follow-up tool call:

Without Ponytail (40-turn session):
  Turn 1:  generate 267 lines → 15,000 tokens in context
  Turn 2:  carry 15,000 tokens (input cost)
  Turn 3:  carry 15,000 tokens (input cost)
  ...
  Turn 40: carry 15,000 tokens (input cost)
  Total context tax: ~585,000 tokens

With Ponytail (40-turn session):
  Turn 1:  generate 9 lines → 2,000 tokens in context
  Turn 2:  carry 2,000 tokens (input cost)
  ...
  Turn 40: carry 2,000 tokens (input cost)
  Total context tax: ~78,000 tokens

That’s a 7.5x difference in recurring context cost from a single task. Multiply across every file the agent touches in a session, and the compounding gets serious.

What I’d want to see extended: benchmarks on more complex tasks where YAGNI competes with legitimate architecture, and results across different model families. On GPT-5.5, the project notes that a “terse reasoning model that spends thinking tokens deliberating the levels can go the other way.” The ladder works best on models that are already good at following structured instructions (Claude, in particular).

What It Refuses to Simplify

Ponytail explicitly protects five areas from laziness. The contrast makes the philosophy concrete:

Lazy about (simplify freely)Never lazy about (always keep)
Helper functionsInput validation at trust boundaries
Wrapper componentsError handling that prevents data loss
Config objectsAuth, encryption, access control
”Advanced” versionsARIA attributes, semantic HTML
Comparison tablesPlatform-specific hardware workarounds

This is the difference between “lazy” and “negligent.” The ladder governs complexity. The guardrails protect correctness. You can delete the helper function. You cannot delete the authentication check.

Where It Breaks

Ponytail is a prompt-level ruleset, not a static analyser. Its failure modes come from the model, not the rules:

Failure ModeWhat HappensWorkaround
Model complianceLlama/Mistral variants partially ignore the ladderStick to Claude or GPT models
Prose taxponytail: comments add tokens backNet savings still positive, just not as dramatic as LOC suggests
YAGNI resistancePushes back against legitimate abstractionsExplicitly tell the agent “yes, build this”
No auto-refactorWon’t simplify existing code unpromptedRun /ponytail-audit manually

The YAGNI resistance is the most common friction point. If you need a factory pattern because three callers each need different configurations, you’ll have to explicitly tell the agent “yes, build the abstraction.” This adds interaction overhead for senior developers who already reason this way.

The Bigger Pattern: Agent Governance via Skills

Here’s why Ponytail matters beyond its immediate utility. It’s a proof of concept for prompt-level governance of AI agents.

The idea: encode engineering heuristics as machine-readable rules, distribute them across every agent your team uses, and get consistent behaviour without relying on individual prompt discipline. Ponytail does this for code minimalism. The same pattern works for:

  • Cost governance: a “cloud budget ladder” that prefers spot instances, then reserved, then on-demand
  • Observability standards: requiring structured logging and trace context on every new service
  • Security baselines: mandating parameterized queries, never string interpolation for SQL
  • Compliance flows: enforcing audit trails and data residency checks in regulated codebases

The architecture is transferable: one authoritative ruleset, host-specific adapters, lifecycle hooks for automatic injection, and slash commands for on-demand auditing. This is harness engineering applied to a specific domain (code complexity), and it demonstrates that the pattern scales. If you’ve read what the Claude Code source leak revealed about composable agent patterns, Ponytail is a concrete example of pattern #7: the skill/plugin as a reusable constraint layer that shapes agent behaviour without modifying the model.

The interesting next step: combining this with static analysis. Ponytail governs at generation time. Tools like Ultracite (Biome-based), Ruff, ESLint, and Clippy enforce at commit time. Together they form a two-layer constraint system:

Generation layer:  Ponytail ladder → agent writes minimal code
Commit layer:      Ultracite/Ruff/ESLint → pre-commit hooks reject violations

The agent gets constrained before it writes, and the linter catches what slips through. In practice, this means Ponytail reduces the volume of generated code, and the static analyser ensures the remaining code meets formatting, import, and complexity standards. Neither layer alone is sufficient. Ponytail can’t enforce import ordering. Ruff can’t tell the agent to use csv.DictReader instead of pandas. Stack them and you get an agent that generates less code, and the code it does generate passes CI on the first try.

The Bottom Line

AI coding agents have a bloat problem. Not because the models are bad, but because “helpful” and “minimal” are different objectives, and RLHF optimizes for helpful.

Ponytail solves this with a 6-level decision ladder, explicit debt tracking via ponytail: comments, and guardrails that protect the things laziness should never touch. The benchmarks show 80-94% less code on standard tasks and 54% less on real-world features.

But the real contribution isn’t the specific ruleset. It’s the pattern: encode your engineering standards as agent-readable policies, distribute them across every host, and get consistent behaviour without relying on human discipline in every prompt. That’s the future of AI developer tooling. Not bigger models. Smarter constraints.

Using AI coding agents in production? I’d love to hear how you’re keeping generated code under control. Reach out on LinkedIn.

Back to top