Ponytail Cuts 54% of Your Agent's Code. The Lines It Refuses to Cut Are the Point.

A coding-agent skill built entirely around building less, a benchmark designed to disprove it, and the handful of validation lines that separate lazy from careless.

Ask a coding agent for a date picker and watch what happens. In ponytail's own measurements, a headless Claude Code session on a real FastAPI and React repo wrote 404 lines. It installed things. It wrote a wrapper component. With the ponytail skill loaded, the same agent on the same ticket wrote 23 lines, most of which was <input type="date"> and a comment saying what it skipped.

That gap is fun. The part worth your attention is what happened next. Someone filed an issue arguing the original benchmark was rigged in ponytail's favor, the maintainer agreed, rebuilt the whole thing to be able to fail, discovered a bug that had been secretly running the skill on his own control group, and republished with a headline number well under half the original claim. The 80% to 94% reductions became 54%.

I have not seen a repo do that this year, and the smaller number turns out to be the more interesting one.

Over-building is the failure mode nobody benchmarks

Coding agents mostly do not fail by writing broken code. They fail by writing too much working code. You ask for one thing and get an interface with one implementation, a config file for a value that will never change, and a 120-line cache class that someone gets paged about at 3am eighteen months later. Every line an agent adds is a line a human eventually has to read under pressure.

So a category is forming around restraint. Ponytail is the loudest example, and it sits next to skills like caveman that push terseness. The pitch is simple enough to fit on a sticker: the best code is the code you never wrote.

Here is my position, and it is not the one the star count is voting for. The size reduction is real and it is also the least useful thing in the data. The result that should change how you write agent instructions is buried in a six-task safety table near the bottom of the benchmark file, and it says that chasing brevity with a short prompt will eventually cost you a security guard.

The mechanism is a ladder, not a vibe

Ponytail ships as a Claude Code plugin with a SKILL.md that reads like a checklist for someone who has been burned. Before writing code, the agent stops at the first rung that holds:

1. Does this need to exist?   → no: skip it (YAGNI)
2. Stdlib does it?            → use it
3. Native platform feature?   → use it
4. Installed dependency?      → use it
5. One line?                  → one line
6. Only then: the minimum that works

The reason this beats "please be concise" is that each rung names a specific substitution the agent can actually perform. Rung three is why the date picker collapses: <input type="date"> over a picker library, CSS over JS, a database constraint over application code. The agent is not being asked to want less. It is being handed an ordered list of cheaper things to reach for first.

Two supporting rules do more work than they look like they do. The skill tells the agent to mark deliberate simplifications with a ponytail: comment naming the ceiling and the upgrade path, so # ponytail: global lock, per-account locks if throughput matters reads as a decision rather than an oversight. And it caps the explanation at three lines, on the theory that every paragraph defending a simplification is complexity smuggled back in as prose.

Then there is the list of things the skill will not touch: input validation at trust boundaries, error handling that prevents data loss, security measures, accessibility basics, anything the user explicitly asked for. Hold onto that list. It is the whole article.

The rerun was built to lose

The agentic benchmark, dated June 18, 2026, exists because Colin Eberhardt filed issue #126 saying the original numbers were an artifact. His argument: a single prompt-to-completion measurement is not how agents get used, the baseline was a chatty bare model whose prose inflated the line count, minimizing might be trading away safety, and a seven-word prompt might do the same job as a whole skill.

The maintainer's response was to rebuild the harness around all four objections. Real headless Claude Code sessions instead of single completions. git diff added lines instead of whole answers. The same Claude Code agent with no skill as the baseline instead of a bare API model. Four arms including Eberhardt's own prompt. Fresh repo copy and fresh context per cell, n=4.

And a confession sitting in the middle of the document. An earlier version of the rerun showed a roughly 4% gap and nearly shipped. It was wrong. Ponytail and caveman are plugins that fire a SessionStart hook, and that hook was firing on every arm, including the control, so the baseline was silently running ponytail against itself. The fix was --setting-sources project,local to exclude the user's global plugins plus exactly one plugin per arm via --plugin-dir.

I trust the rest of that file considerably more because of that paragraph. A benchmark that tells you how it caught itself lying is a different kind of document than one that just reports wins.

Where the skill wins, and where it does nothing

Twelve one-line tickets against tiangolo/full-stack-fastapi-template at a pinned commit, mean of four runs each, on Haiku 4.5. The frontend results are the ones that get screenshotted: date picker 404 to 23, color picker 287 to 23, file dropzone 251 to 95, multi-step wizard 571 to 312.

The backend results are the ones I would actually put in a slide. Search items by title: 44 lines baseline, 44 lines with ponytail. Export as CSV: 36 to 33. Duplicate an item: 24 to 23. Count a user's items: 21 to 17. On code that was already minimal, every arm converges and the skill does nothing, which is exactly what an honest benchmark has to be willing to show.

That is what the aggregate −54% actually means. Per task it runs from roughly 0% on irreducible CRUD to −94% on the date picker. The average is dragged down by tasks with no bloat to cut, and the maintainer says so in the document rather than quoting the peak.

The caveman control earns its place too. Terse prose alone got −20% on lines while spending 7% more tokens, since talking short and deliberating long are different things. Brevity of output is not the mechanism. The ladder is.

The seven-word prompt almost works, and that is the problem

The fourth arm is the one to sit with. Eberhardt's paraphrased prompt, "Follow YAGNI principles, and prefer one-liner solutions," appended to the system prompt with no skill at all.

It got −33% on lines. It was cheap and fast. On the color picker it beat ponytail outright at 25 lines. If you only read the aggregate table you would reasonably conclude that seven words buy you most of a plugin.

Then look at the variance. On the date picker the prompt produced 162 lines against ponytail's 23. On the wizard, 406 against 312. On the command palette it wrote 285 lines against a baseline of 268, meaning the instruction to prefer one-liners made the agent write more code than no instruction at all. The plugin lands every time. The prompt lands sometimes.

And then the safety axis, six surgical tasks where the agent implements one function and the requirement is left implicit the way a real ticket reads. The scorer executes the produced function against adversarial input: path traversal, SQL injection, a forged token, a malformed CSV row, a quota-exhausting client.

Baseline: 20 of 20 safe. Caveman: 20 of 20. Ponytail: 20 of 20. The one-liner prompt: 19 of 20.

The single miss is the argument in miniature. On safe-path, joining an untrusted filename onto a base directory, the prompt arm wrote the fewest lines of any arm at 6 and let a ../../ filename escape the directory once in four runs. Ponytail wrote about 9.5 lines and was safe four times out of four. The roughly three lines of difference were the path-traversal check.

"Write less" with no exception list is an instruction to cut whatever is easiest to cut, and the easiest thing to cut is always the guard, because the guard is the part that never fires on the happy path.

Put this into practice

The lowest-friction version takes about a minute inside Claude Code:

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

That is the whole install. There is no config file. The skill is active every session at full intensity by default.

1. Start at lite for a week. /ponytail lite builds what you asked for and names the lazier alternative in one line, so you get to see the judgment without having it applied. This is the honest way to find out whether you agree with the ladder before it starts editing your diffs.
2. Use /ponytail-review on a diff you already wrote. It reads your changes and tells you what to delete. Running it on your own code, not the agent's, is the fastest way to calibrate whether the skill's taste matches yours.
3. Save ultra for cleanup, not features. At ultra the agent ships the one-liner and argues with the requirement in the same breath. That is great when you are deleting things and irritating when you have already decided what to build.
4. Read the ponytail: comments as a to-do list. Every deliberate simplification leaves one behind, naming the ceiling and the upgrade path. Grep for them before a load test.
5. Not on Claude Code? Copy the matching rules file from the repo. There are drop-ins for .cursor/rules/, .windsurf/rules/, .clinerules/, .github/copilot-instructions.md, and a plain AGENTS.md.

Here is the part that transfers even if you never install any of this. Take whatever brevity instruction is already in your agent config and give it an exception list. Name the categories that are never on the chopping block, in your own words, for your own stack. Validation at trust boundaries. Error handling that prevents data loss. Auth checks. Whatever your incident history says. That single addition is the measured difference between 19 of 20 and 20 of 20, and it costs you one sentence.

Honest limitations

One model, small n. Every number here is Haiku 4.5 at n=4. Bigger models need less hand-holding and may close the over-build gap on their own, or widen it. The harness supports Sonnet and Opus and the maintainer stopped at Haiku for cost. Frontend line counts also swing a lot run to run, since a custom build lands anywhere from 300 to 570 lines.

The safety result is a floor, not a proof. Six tasks, deterministic checks, one slip in twenty. It shows whether an arm drops a known guard. It says nothing about whether the code is secure. Four of 192 measurement cells also hit a Windows process-timeout bug and were force-killed, with their line counts kept and their cost and time dropped.

The README and the benchmark folder do not describe the same experiment. The README banner says "5 coding tasks, −16% tokens, ~4× faster, 293 → 47 lines." The agentic file says twelve feature tasks, −22% tokens, −27% faster, −54% lines. Both are labeled as ponytail's numbers. Read the dated file in benchmarks/results/, not the banner.

The star counts on this repo are not trustworthy right now. The briefing that pointed me here listed 112k total and roughly +1.2k for the day. Across three loads of GitHub's own pages within one hour today I was served 188 stars, then 480, then 35.7k. I could not corroborate 112k from any primary source, and I would not repeat any of those figures as fact. The repo is clearly moving fast. That is all I can honestly say about its size.

It is not new. The agentic benchmark is dated June 18, 2026, and third-party writeups of ponytail exist from late June. The late-August trending spike is attention, not a release. Nothing about the skill changed this week.

And the obvious one. A skill that biases toward native platform features will occasionally hand you a native platform feature that is wrong for your users. <input type="date"> is a genuinely different experience across browsers, and "the browser has one" is a correct engineering answer that a design review can still reject.

What I would actually watch

The size numbers will get argued about, and they should. The result I think holds up is narrower and more portable: an ordered ladder of substitutions plus a written exception list beats a brevity instruction, and the exception list is doing more of the work than the ladder is.

If you have run something like this against Sonnet or Opus on a repo with real auth code, I want to see it. My suspicion is that the line savings shrink as models get better at judging scope, and the safety gap between "write less" and "write less except here" stays exactly where it is. I would like to be wrong about the second half.

Sources: DietrichGebert/ponytail README, ponytail SKILL.md, agentic benchmark, 2026-06-18, fastapi/full-stack-fastapi-template. Star and fork figures read from GitHub's repository pages on August 26, 2026, and reported as a range because the reads disagreed.