My best coding upgrade this month was telling my agents to be lazy.
Claude and Codex write extra code for free, and I pay for it in review time. Every helper they invent is one more thing I have to read, trust and keep working when the app changes.
On October 7, I added a skill called Ponytail to my project instructions. It makes the agent climb a seven-rung ladder before it writes anything, and the first rung asks whether the code needs to exist at all. I run it in Claude and in Codex.
Twelve days later, I asked Claude for an MCP server for my SaaS. Claude delivered one commit with 44 tools and a single new dependency, and I had it live and tested the next day.
Below is how the skill works, what it changed in that build, the one place where less code would have been wrong, and the shortcuts it wrote into my codebase on purpose.
In This Edition
Climb before you code. Ponytail makes Claude and Codex check seven options, from skipping the code to reusing what exists, before they write anything new.
Reuse beats a second API. My 44-tool MCP server sends every tool through pages the app already has and adds a single dependency.
Some code earns its place. Two wait tools add lines and stop an agent from calling a half-written brief done.
Read the notes it leaves. Every
ponytail:comment marks a shortcut you still own, so review them before they turn into bugs.
Subscribe for agent builds with the code, checks and failures left in.
The Seven-Rung Ladder
Most coding instructions stop at “keep it simple”, while Ponytail gives the agent an order to work through.
Before writing anything, the agent reads the task and traces the code it touches. For a bug, that means finding every caller of the broken function and fixing it once, in the shared place. Then it climbs the ladder and stops at the first rung that holds:
Does this code need to exist at all?
Can it reuse something already in the codebase?
Does the standard library cover it?
Does the platform do it natively?
Does an installed dependency already handle it?
Can it be one line?
Write the minimum code that works.
The first rung applies the cut I argued for with features in What Gordon Ramsay Taught Me About Vibe Coding, one level down at the code.
It comes in three levels. Lite builds what you asked and names a lazier option in one line. Full runs the whole ladder. Ultra deletes before it adds and questions the requirement itself.
I run full mode, and my project’s AGENTS.md spells out what that means: trace the existing flow, reuse local helpers and components, prefer native platform features and installed dependencies, and add only what the current screen needs.
Ponytail also protects the parts that keep an app safe, like validation at trust boundaries, error handling that prevents data loss, and anything you asked for by name. It asks for one small runnable check on any non-trivial logic.
My favorite rule covers shortcuts: when the agent picks a simpler version with a known ceiling, it leaves a ponytail: comment naming the limit and the upgrade path, and you’ll see why that matters in the catch.
The skill is short, and you can read the whole thing on GitHub.
44 Tools, No Second API
The SaaS is Yahini, my content strategy app, and its MCP lets Claude, ChatGPT or Cursor work in it as you. They can create projects, run keyword research, fill the workbook, and generate briefs and drafts.
The website already knew who can open a project, which actions spend credits and what happens when a request fails. A fresh API layer for the agent would look clean in a diff and give me two copies of every rule. The day I changed one, the website and the agent would start giving the same user different answers.
Ponytail stopped Claude at rung two, so each of the 44 tools runs the page’s own loader or action with the user’s session. The app keeps handling permissions, credit checks and validation, exactly like it does on the website.
A test locks that in by failing whenever a tool points at a page the app’s routes don’t list, so no agent can slip in a tool with its own private logic.
The other rungs show up too:
Rung 5, an installed dependency: sign-in runs through Cloudflare’s
workers-oauth-provider, the only package the build added.Rung 7, the minimum: the server answers JSON-RPC over plain POST with no streaming, from a 187-line request handler.
Claude kept the careful parts too, giving each connection its own Supabase session so connecting an agent never rotates the session in your browser. Disconnecting an app from your account deletes its tokens and that session with them.
Reuse still costs something, because the MCP now depends on those page operations and renaming a form field on the website breaks the mapping. Another test checks that arguments become exactly the fields each page reads, which catches a small refactor before it breaks every connected agent.
Where Less Code Is Wrong
Briefs and drafts in the app generate in the background. When an agent asks for one, the first response only confirms that the app accepted the job, long before the document is ready.
A minimal build would return that response and let your agent tell you the brief is done while the app is still writing it. Notifications and webhooks can’t reach a chat agent, so nothing would correct it.
That’s why the MCP has two extra tools, wait_for_generation and wait_for_document, which re-read the page every 5 seconds for up to 45 seconds and then answer with finished. While it’s false, the agent calls again, so it follows the run within its own turn and you never have to ask twice.
Those 45 seconds earn their code, and Ponytail agrees: its protected list keeps error handling that prevents data loss and asks for a check on non-trivial logic. Two of the 11 tests in mcp.test.ts cover the wait tools, including the case where the limit runs out before the work does.
Refusals get the same care, with a test that turns the app’s own answers into tool results so a 403 reaches the agent as an error. Without it, your agent could report a change as saved when the app said no.
Know someone whose coding agent turns every small fix into a new module? Send them this before their next pull request.
The Catch
Ponytail ships shortcuts, and it tells you so. My codebase now has 14 ponytail: comments, and each one marks a limit the agent chose and wrote down.
Two of them are real bugs waiting for the right timing:
ponytail: two submits racing in flight can still both create;
the backend needs an idempotency key to close that.
ponytail: read-modify-write, so two people editing the same
list at once can drop one change
Neither is hidden, and both are still mine to fix. If you never read those comments, Ponytail’s honesty turns into debt you forgot you took on.
The MCP has its own limits, starting with a connected apps page that lists only the first 100 connections, since one app per user rarely gets near that. I left billing out on purpose, so checkout and plan changes still send you back to the app.
The bigger risk is the agent grading its own work, because one session writes the code, writes the test and explains why both are right. If the test copies the code’s assumption, everything agrees and the feature is still wrong. I gave my Hermes agent approval gates for the same reason.
Keep one check the agent didn’t write, the way I connected this server to a real client and used it before calling it live.
I haven’t run a controlled test, so I can’t give you a percentage of bugs Ponytail prevents, and I’d be suspicious of anyone who did. What I can show you is the code, the tests and the notes it left.
Start With One Task
Pick a change small enough to review in one sitting, with a result you can check. If it needs a plan first, my five-minute architecture pass gets you one before the agent sees the task. Save the starting code, load Ponytail in a fresh session and give the agent this:
Implement this change using the existing project conventions.
Before editing, find the code that already owns this behavior.
Keep the change limited to the requested outcome.
Check the failure case most likely to mislead a user.
Report what changed, what you verified, and what you skipped.
Then pick the level by the problem you keep hitting:
Your agent adds files and abstractions you didn’t ask for: run full.
It builds roughly the right thing, only bigger: start with lite and read the lazier option it suggests.
You suspect the whole feature is overbuilt: try ultra on a branch you’re happy to throw away.
Your setup already ships focused changes with real checks: keep it, because a skill should earn the instructions it adds.
Write the level into your project’s AGENTS.md so every session starts with it. Then search the repo for ponytail: once a week and decide which limits you’re still happy with.
If long explanations bother you more than the code, Ponytail pairs with Caveman , a separate skill for terse answers. If your agent keeps solving the wrong problem, the community’s Karpathy-inspired guidelines start by making it state its assumptions. I haven’t used either one, so start from their published rules.
My Substack API build with Hermes and Codex came down to the same standard: follow the request into the code, then find the proof that “done” means done.
One dependency, 44 tools and a note on every shortcut add up to AI code I can live with.
Tell me the last thing your coding agent overbuilt, and I’ll tell you which rung it should have stopped on.
Subscribe for more agent builds with the files, decisions and failure checks behind them.
Top comments (0)