Ponytail: the lazy senior dev agent skill

What Ponytail is

Ponytail is a rule set that makes an AI coding agent write less code. The project describes itself in one line: "Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote." It is MIT licensed. It has no runtime of its own, and nothing in it executes. It is text that goes into the agent's instructions, packaged as a skill for hosts that load skills and as plain rule files for hosts that do not.

The repository is DietrichGebert/ponytail. It was created on 12 June 2026 and passed 90,000 stars by 1 August 2026. The latest tagged release on 1 August 2026 is v4.8.4, published 29 June 2026, and the releases page lists ten tags between 14 and 29 June alone. A project moving at that rate will have changed by the time you read this, so pin a tag before you build anything on top of it.

The idea before the tool: stop at the first rung that holds

The core of Ponytail is a decision ladder. The agent climbs it before writing anything and stops at the first rung that holds.

1. Does this need to exist at all? This is YAGNI (you are not going to need it). If the answer is no, skip it.
2. Does it already exist in this codebase? Reuse the helper or the pattern that is already there.
3. Does the standard library do it? Use it.
4. Does a native platform feature cover it? Use it.
5. Does an already installed dependency solve it? Use it.
6. Can it be one line? Make it one line.
7. Only then, write the minimum code that works.

The order does the work, not any single rung. An agent asked for a date picker will write a date picker, because writing one is what it was told to do. The ladder makes it check rung 4 first, and rung 4 says the browser already has <input type="date">. The project's own benchmark notes exactly this case: a date picker that came out at 404 lines without the rule came out at 23 lines with it, because the agent reached for the native input instead of building a component. A colour picker went from 287 lines to 23 for the same reason.

Lazy here does not mean careless, and the ruleset says so directly. Its "never lazy about" list covers understanding the problem before deciding, input validation at trust boundaries, error handling that prevents data loss, security, accessibility, and anything you asked for by name. It also asks for one small runnable check per piece of non-trivial logic. The rule cuts invention. It does not cut correctness.

What the repository actually ships

• AGENTS.md, the always-on ruleset, which is the whole idea in one file you can read in five minutes.
• skills/ponytail/SKILL.md, the skill definition, with an argument hint of lite, full or ultra.
• Rule files under editor-specific directories such as .cursor/rules/ and .windsurf/rules/, for hosts that read rules but do not load skills.
• hooks/, benchmarks/, examples/ and scripts/.

The intensity argument changes how hard the rule pushes. lite builds what you asked for and names a lazier option in one line. full is the default and enforces the ladder. ultra is the YAGNI extremist setting: it prefers deletion to addition and it will argue with the requirement itself.

Skill-capable hosts also get slash commands. /ponytail sets the level, /ponytail-review checks a diff for over-engineering, /ponytail-audit checks a whole repository, /ponytail-debt collects the shortcuts you deferred, and /ponytail-gain prints the benchmark scorecard. Hosts that only read rule files get the ruleset with no commands.

To read the source before you trust it, clone the tag rather than the branch:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

On Claude Code the project documents a plugin install instead, and these two lines are as documented on 1 August 2026:

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

The plugin path follows the default branch rather than a tag, so the instructions steering your agent can change under you between sessions. That is the trade you accept for the convenience of an update command.

Why a lazy agent is cheaper on a VPS

The diff an agent writes does not leave the conversation. On the next turn it is context the model reads again, along with every file it opened to produce it. A 500 line change therefore taxes every later turn in the session, not only the turn that produced it. This is why a runaway refactor makes an agent feel slower and dumber as the session goes on: the window fills with the agent's own output, so the room left for your actual code shrinks. Keeping that under control is the whole subject of managing a coding agent's context window.

Tokens are billed going in and going out, so a diff that is half the size is cheaper twice over, once when it is written and again on every turn that re-reads it. If you are watching the bill on a self-hosted setup, the instruction file is a lever that costs nothing to pull. Controlling what an AI agent costs you starts with output volume, and how a coding agent spends its tokens explains why the re-reading matters more than people expect.

A human still reads the diff. A 400 line change that should have been 20 lines costs the reviewer's attention, and attention is the resource that runs out first. Nobody reviews the fourth long diff of the day with the care they gave the first one, so over-building does not only waste time. It quietly lowers the quality of the review that is supposed to catch the mistakes.

On a server the stakes change, because the agent often runs with nobody watching. An agent working in a tmux session or on a timer has hours to build on a bad decision before you see it. That is the practical risk in running a coding agent on a VPS, and it is why people doing loop engineering spend so much care on the standing instructions rather than on individual prompts. A rule in the always-on file applies to turn 200. A rule you typed in chat applies to turn 3.

New dependencies are the other quiet cost. Rung 5 says use what is installed. Every package an agent adds on its own initiative is something you patch later and something that ends up in every container image you build from that repository.

What Ponytail's own benchmark numbers say

The project publishes two sets of results, and they disagree with each other by a wide margin. Both are the project's own published figures. Neither is an independent test.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

The single shot column comes from a bare model answering a small set of prompts with and without the rule, taken as medians over repeated runs dated 13 and 17 June 2026. The agentic column comes from a headless Claude Code session editing tiangolo's full-stack-fastapi-template, a real FastAPI and React repository, over twelve feature tickets with four runs each on Haiku 4.5, scored on the git diff left behind.

Read the second column. The agentic result is 54 percent fewer lines of code, 20 percent lower cost and 27 percent less wall clock time, against 93 percent and 74 percent for the same measures in the single shot setup. The README is honest about why: the single shot baseline is a bare model that "answers with several options plus commentary", which is an easy thing to beat. Measure against a real agent doing real work and the win shrinks. It also stays real, which is the more useful fact.

One caveat is the project's own, and it is the one that decides whether this helps you. The saving is largest where there is a genuine over-build trap and near zero on code that was already minimal. Twelve tickets in one Python and TypeScript repository do not predict your repository. If the number matters to you, run the comparison on your own tickets, with and without the rule, and count the lines yourself.

The pattern you can copy today without installing anything

The ladder is text, so you do not need the plugin to use the idea. Paste a block like this into the instruction file your agent already reads, whether that is AGENTS.md, CLAUDE.md or your editor's rules file.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

That last rule is worth taking on its own. Ponytail's convention is a comment tagged with the tool's name:

# ponytail: global lock, per-account locks if throughput matters

The comment is two lines of work and it settles a question that would otherwise cost a review cycle. It tells the next reader that the simple version was a decision, and it names the condition under which that decision stops holding. Without it, a reviewer cannot tell a considered shortcut from something the agent forgot, so they have to ask.

Where you put the block matters as much as what it says. A file the agent loads on every run steers every run, including the ones you are not watching. That difference is the subject of writing an AGENTS.md your agent actually follows, and it is the reason this pattern belongs in a committed file rather than in your shell history.

Where the rule stops being right

The ladder is tuned for feature work in a codebase that already exists, where reuse is usually available and usually correct. It fits a greenfield project badly, because rung 2 has nothing to reuse and rung 5 has nothing installed, so the agent falls through to rung 7 every time. It also fits badly at the moment you genuinely want the abstraction. If you are about to add the fourth caller of the same copied block, "shortest diff" hands you a fifth copy.

The ultra level will challenge your requirements. That is what the level is for, and it is a real cost when you have already made the decision and want the work done. Use full for ordinary work and reach for ultra when you suspect a feature request is the problem.

No instruction block saves you from a wrong reading of the problem. The ruleset's own first item is understanding the code before deciding, which is the expensive part and the part the text cannot do for you. A minimal diff in the wrong function is still the wrong fix, and it is now a small wrong fix that is easy to approve.

The honest summary is that Ponytail is a carefully written prompt, distributed well, with numbers attached. Nothing in it requires the plugin. What the project gives you is that someone wrote the list properly, tested it against a real repository, and published the method next to the result.

FAQ

Does Ponytail work with agents other than Claude Code?

Yes. It ships as a skill for hosts that load skills, a list that includes Claude Code, Codex, OpenCode, Gemini and several others named in the README. Editors that read rule files but do not load skills, such as Cursor, Windsurf, Cline and Copilot, take the always-on ruleset from the matching rules directory and get no slash commands. The text is the same either way, so the real difference is whether your host keeps that text in context on every turn or only when a skill is triggered.

Will a lazy agent skip tests, validation or security?

No, and the ruleset states this directly. Its "never lazy about" list names input validation at trust boundaries, error handling that prevents data loss, security and accessibility, and it asks for one small runnable check for each piece of non-trivial logic. What the rule removes is invented structure: abstractions nobody requested and dependencies nobody needed. If your agent starts dropping tests after you install it, the cause is another instruction in your own config outranking this one, so read the file the agent loads last.

Are the published speed and cost numbers trustworthy?

They are the project's own measurements, published with their method, and they should be read as that. The single shot figures compare against a bare model that replies with options and commentary, which the README itself flags as a weak baseline. The agentic figures come from a headless Claude Code session on one FastAPI and React repository, twelve tickets, four runs each, on Haiku 4.5. Those are honest numbers for that setup. They are not a forecast for your codebase, because the project also says the saving falls to near zero on code that was already minimal.

Do I need to install anything to get the benefit?

No. The ladder is text, and an equivalent block pasted into the instruction file your agent already reads gives you most of the effect. The plugin gives you the maintained wording, the intensity levels, the review commands and an update path. Trying the copied block first is the rung 1 answer to the question of whether the install needs to exist at all.

How do I stop an unattended agent from over-building overnight?

Put the rule in the always-on instruction file rather than in a chat message, so it applies on turn 200 of a long run and not only on turn 3. Then bound the damage separately: give the agent a checkout it is allowed to ruin instead of your only copy, and require a human diff review before anything merges. A minimal diff rule reduces how much you have to read. It does not decide what lands, and it should not.