Ponytail 5: Making AI Agents Read Code Before Writing It — 53% Less Code, All Tests Passing
> Project studied: DietrichGebert/ponytail
> Snapshot date: 2026-10-20 | Stars: 1,396
> License: MIT | Language: JavaScript
A Person You Definitely Know
Every company has that one person. Long ponytail, oval glasses, been at the company longer than version control. Show them fifty lines of code and they say nothing — they just replace it with one line.
Ponytail puts that person inside an AI agent.
But this rewrite, Ponytail 5, differs fundamentally from previous versions: it no longer just "cuts code" — it reads code first, then decides what to cut.
The Numbers Speak
Benchmark results (2026-10-07, agentic mode, multiple runs):
| Metric | No skill | Ponytail 4.13 | Ponytail 5 | |--------|---------|---------------|------------| | Lines of code | 100% | 52% | 47% | | Output tokens | 100% | 57% | 55% | | Cost | 100% | 84% | 74% | | Time | 100% | 62% | 59% |
Two even more critical numbers:
- 98% of risky logic ships with tests (68% without the skill)
- Agent-written tests caught 66% of injected bugs (46% without)
- How much the current task has cost
- Tokens used and agent time
- Reuse rate: how much code is reused vs. newly written
- Whether tests pass after the last change
- Reads the code your change touches, not just the diff
- Checks bugs, security, real workloads, missing tests, slow paths, and cuttable code
- Every finding states four things: what the code does, what's wrong, how to fix it, and what happens if you don't
Code cut in half, test coverage went *up*. This isn't "writing less code" — it's "writing only necessary code."
On six security tasks (SQL injection, path traversal, forged tokens, rate limiting, malformed CSV rows, caching), Ponytail 5 passed all 30 runs. Less code, not less safe.
The Seven-Level Ladder: A Priority Order for Laziness
Ponytail's core mechanism is a seven-level ladder. Before writing code, the agent starts at level one and stops at the first level that holds:
1. Does this need to exist? — Maybe it doesn't need to be written at all.
2. Does the repo already have it? — Search first.
3. Can the standard library do it? — Built into Python/JS.
4. Native platform feature? — The browser's own <input type="date">.
5. Can an installed dependency do it? — Already in package.json.
6. Can it be one line? — Genuinely one line.
7. Only if none of the above: write the minimal working code — plus a small test (if there's logic).
The key isn't "write less" — it's "confirm necessity first, then write." Most AI agents' problem isn't bad code; it's writing code without ever asking "does this need to exist?"
The README has a before/after example: ask the agent to add a date picker. Without the skill, the agent installs a date-picker library or hand-writes a full calendar — 335 lines. Ponytail 5 first checks what's in the repo: there's an Input component, and the browser natively supports date picking. Put the two together — 10 lines.
The 381-line gap wasn't "optimized" away; it vanished by "asking the right question."
"Lazy, but Never Careless"
One precise line from the README:
> Lazy about the solution, never about reading.
Be lazy about the solution; never lazy about reading code. The ladder runs only after the agent has read the code and understood the problem — it doesn't replace understanding.
There's also an iron rule:
> Trust-boundary validation, data-loss handling, security, and accessibility are never on the chopping block.
Trust-boundary validation, data-loss handling, security, accessibility — these four are never cut. Ponytail cuts "unnecessary code," not "important code." That's why code dropped 53% while all security tests passed.
Branches, loops, parsers, and anything touching money or security get a small test. Every response ends with "what was skipped, what wasn't checked, what risks remain." Laziness doesn't mean irresponsibility.
New Features: Band and Board
Ponytail 5.3 adds the "band" — a status bar shown above the prompt in Claude Code:
This reuse rate is Ponytail's most distinctive metric. Most agent dashboards show "how much code was written"; Ponytail shows "how much code was reused." A 71% reuse rate means 71% of the code came from existing parts of the repo, only 29% was new.
The "board" is a local page showing cost, time, tokens, and test status across all projects. All data stays local by default (~/.config/ponytail/band/) — nothing is uploaded anywhere.
/ponytail-review: From "What to Cut" to "What to Fix"
The old /ponytail-review only looked for code to cut. The 5.0 rewrite gives it the perspective of "the senior developer called in at 3 a.m. to fix a bug":
"Reading code outside the diff" is the key. Most code review tools only look at the diff, but many bugs are chain reactions from a change — rename one field, and an untouched file breaks. Ponytail review reads that file.
/ponytail-audit: The Whole Repo, Ranked by Priority
/ponytail-audit applies the same checks to an entire repository. It first maps the terrain: entry points, data flows, expected workloads. Then it ranks findings by priority:
> 1 must fix: office batches with 1,200 fail completely > 2 must fix: the import silently skips bad rows > 3 must fix: a mistyped SKU in an office batch is silently ignored > 4 should fix: the risky code paths have no tests > 5 nice to have: the API crashes on a body that isn't an object
"What to fix first" is more useful than "how many problems exist." Most audit reports list 50 issues without ranking, and developers close the tab. Ponytail audit says directly: "fix #1 first, because 1,200-row batches fail completely."
/ponytail-debt: Turning "Later" Into a Ledger
Developers write // TODO: refactor later or // shortcut: hardcoded for now, fix later. These shortcuts accumulate into technical debt, but few teams track them.
/ponytail-debt scans code for shortcut: comments and collects them into a ledger. Each shortcut records its location, reason, and blast radius. "Later" no longer becomes "never."
It's a very Ponytail feature: acknowledge that you'll take shortcuts, but make them visible.
One Prompt, Not a Framework
Ponytail's core is a single prompt: skills/ponytail/SKILL.md. No RAG, no fine-tuning, no vector database, no agent framework. Just a carefully written prompt loaded into different agents.
This proves one thing: many agent behavior problems don't need infrastructure to solve — they need better instructions. You don't need to install a "code review microservice" for your agent; you need to tell it "before writing code, ask yourself these seven questions."
Ponytail's success backs an unpopular opinion: prompt engineering hasn't hit its ceiling. While everyone talks about RAG, fine-tuning, and agent frameworks, one well-written prompt cut code by 53%, raised test coverage, and reduced cost by 26%.
"Less" Is the Goal; "Necessary" Is the Checklist
A closing line from the README:
> The rule was never "fewest tokens." It is: write only what the task needs, and never cut validation, error handling, security, or accessibility. The code ends up small because it is necessary, not golfed. Lower cost and latency are a side effect.
The goal isn't "fewest tokens" — it's "write only what's necessary." The code ends up small because it's necessary, not because it was compressed. Lower cost and latency are side effects.
This distinction matters: "less" is the goal; "necessary" is the checklist. A goal alone doesn't tell the agent what not to cut — it will cut validation and error handling too. The checklist explicitly says validation, security, and accessibility are off the table. That 98% test coverage of risky logic exists precisely because the checklist says so.
---
GitHub: https://github.com/DietrichGebert/ponytail License: MIT Benchmarks: benchmarks/results/2026-10-07-agentic.md