Subtract, Align, Prove: Three Skills That Keep AI Agents From Spaghettifying Your Repo

We hand coding agents real tickets every day, and they almost always ship something that works. That was never the worry. The worry is how they work: a new helper next to three that already do the job, a fresh abstraction for a single caller, a fix that patches the one path the ticket named and leaves four siblings broken, a finding that is “probably a bug” with no proof either way. Every change is locally reasonable. In aggregate they are entropy.

TL;DR: Across five Tier-3 pull requests on our agent-orchestration core, three composable skills — ponytail (subtract), grain (align), and review-proof (prove) — removed 821 lines while shipping five features, caught a silent contract break that plausibility alone would have merged, and kept every change going with the grain of the existing architecture. Here is what each one does, with the real diffs to back it.

Take the guardrails away and a coding agent is a very fast generator of plausible-looking liabilities. So we lean on three small skills that push the other way — one instinct each: subtract, align, prove.

• ponytail — write the laziest thing that actually works. Delete before you add. (We didn’t write this one — it’s an open-source skill by Dietrich Gebert that we adapted for our stack.)
• grain / grain-review — put it where the codebase already decided it goes. Don’t invent a second way.
• review-proof — don’t believe a finding until it reproduces as a failing test.

grain and review-proof we built in the same spirit as ponytail, tuned to our architecture. Every one of the five PRs below touches our agent-orchestration core — the single most expensive place in the repo to get sloppy — and every one is classified Tier 3: extra test coverage and human review on top of the automated reviewer, no exceptions.

The three skills at a glance: ponytail subtracts, grain aligns, review-proof proves.

Part 1 · WHAT — entropy is the default

Here’s the thing nobody warns you about when you hand a repo to AI agents: each agent optimizes locally and remembers nothing. It sees the ticket, not the months of conventions your team converged on. It has no reason to prefer your existing email service over a fresh one, no memory that the redirect-status set is already defined three files over, no instinct that “the fix goes in the shared function, not this one caller.” Left to run, N agents produce N slightly-different ways to do the same thing. That’s not a code-quality problem you can lint away — it’s a structural drift that compounds.

The three skills each target one axis of that drift.

ponytail — the laziest thing that works

Ponytail is a senior developer who has been paged at 3am for someone else’s clever abstraction and refuses to write the next one. It runs a ladder and stops at the first rung that holds: does this need to exist at all (YAGNI) → is it already in this codebase → does the standard library do it → native platform feature → already-installed dependency → can it be one line → only then, the minimum code that works.

The rung that matters most for agents is “is it already in this codebase?” Re-implementing what’s a few files over is the single most common form of agent slop. And ponytail’s bug-fix rule keeps diffs honest: fix the root cause, not the symptom. Grep every caller of the function you’re about to touch; one guard in the shared function is a smaller diff than a guard in every caller — and it doesn’t leave the siblings broken.

grain / grain-review — go with the grain

If ponytail governs how little you write, grain governs where it goes and what shape it takes. Its one rule: find the nearest existing example, copy its shape, name what you copied. New code should read as though the person who wrote the file next to it wrote this one too.

Grain is also where architecture is enforced. Our backend is a fairly standard vertical-slice + hexagonal layout — presentation calls application calls domain, infrastructure depends inward, and the domain never reaches back out. A finding like “this route skips its controller and pulls the service directly” isn’t pedantry — it’s the difference between a codebase an agent can navigate next month and one it can’t. grain-review hunts exactly these: duplicated helpers, crossed layer boundaries, reaching into another feature’s internals, a second convention for something already done one way.

review-proof — earn the finding

Standard AI code review produces plausible findings. Some are real; some are confident nonsense; from the outside they look identical. review-proof refuses to trust itself: it reviews, then forces every correctness finding to reproduce as a real failing test or runnable repro, and drops anything that won’t. It closes with a grain-review pass for structural fit. What ships is a review where each item comes with executable evidence — not a vibe.

What we should see if this works

• H1 — Deletion shows up in feature PRs. If ponytail + grain are working, adding a feature should frequently remove net structure, not only add it.
• H2 — Fixes land once, in the shared place. Root-cause fixes should collapse many call sites onto one guard, not sprinkle guards per caller.
• H3 — The review catches contract breaks a human skims past. Proof-backed review should surface bugs that “looks fine” review misses — especially the silent kind.

Part 2 · SO WHAT — five PRs, one instinct each

Five real changes to our agent core. We’re keeping the internals vague on purpose — the repo is private — but the numbers are computed from the actual diffs and the lessons are the transferable part.

Subtract: one guard for a dozen fetch sites

One family of flow steps fetched user-supplied URLs without a DNS-resolving safety check, so a hostname that resolved to an internal address could reach cloud metadata from the backend. The tempting fix adds a check at each of the dozen-plus fetch sites. Ponytail’s answer was the opposite: one shared, guarded fetch helper, used everywhere — and we deleted a hand-rolled private-network table that a wildcard-DNS trick walked straight past, plus three duplicated redirect loops and a network check copy-pasted into several files.

The diff added the shared helper and removed ~90 lines of duplication across 22 files. That deletion is the story: this is H2 in the flesh — the root-cause fix routed every caller through one guard instead of patching the one path the ticket named.

The root-cause fix: a dozen ad-hoc fetch sites collapse onto one shared, guarded helper. The lazy fix and the safe fix are the same fix.

Subtract + prove: one shape guard, proven on the real runtime

Our worker runtime persists a run’s result as a serialized string, sometimes wrapped in a single-element list. Consumers that expected a plain object crashed on it. The wrong fix scatters defensive type-checks at each consumer. Instead: one small shape-normalizing helper, and every consumer re-pointed at it — a near-pure addition of one guard that replaces the N ad-hoc ones a less disciplined agent would have written (+558 / −24, 7 files).

The part that makes this a review-proof story is the test. Instead of asserting against an assumed serialization shape, we ran a real workflow through the actual runtime and storage — no mocks — and proved the shape the runtime actually persists. The open question in the ticket was literally what does the runtime serialize here? — and the only honest answer is one you can run.

Prove: the review caught a silent contract break

Feature: a per-node fallback model, so a flow pinned to one provider degrades gracefully during an outage. The obvious first cut wrapped the model in the framework’s built-in fallback combinator.

It worked in the happy path. It also silently switched off two provider features that gate on the concrete model type via isinstance — a wrapped object is no longer that type, so native structured output and prompt caching both quietly turned off. No error. No failing happy-path test. Exactly the kind of thing a human review skims past and a “looks fine” agent approves.

review-proof didn’t approve it — it reproduced both breaks as failing tests, which forced the redesign: apply the fallback lower down, at execution time, so every model stays its concrete type and the type-gated features keep working. H3, confirmed decisively: proof caught a bug that plausibility would have shipped.

Align: one picker, not two copies

Adding a second notification channel meant the channel-picker UI now had two homes — a create wizard and a settings modal. The default agent move adds the new branch to both, growing two copies of the same state machine. grain said: there is already one way this should be shaped — make it shared. We extracted a single picker hook and drove both screens through it, slotted the new channel into the existing config union, and reused the existing email service instead of adding new send machinery.

+1,735 / −340 across 24 files. A feature this size removing 340 lines is H1 made visible: the dedup of two picker copies into one paid for a good chunk of the new channel.

Align + prove: reuse the endpoint, mirror the path

Letting users attach files at issue creation could have meant a new upload endpoint, a new dispatch mechanism, a new prompt path. grain routed nearly all of it onto existing rails: the existing upload endpoint, a frontend accept-list that mirrors the backend whitelist exactly, and a deferred-dispatch fix that reused the eligibility mechanism scheduled work already used. It shipped with proof-backed fixes, including a real transaction-isolation bug that would have lost data under parallel uploads. +1,776 / −218 across 27 files — a big feature that still found 218 lines to remove by joining existing slices instead of inventing new ones.

The scoreboard

Five Tier-3 PRs: what each added, what it removed, and the instinct behind it.

Five feature and fix PRs on the agent core removed 821 lines — not by doing less, but by refusing to duplicate what already existed and to keep symptom-patches a root-cause fix made redundant.

Full disclosure

• These are skills, not a study. This isn’t a controlled experiment with a baseline arm; it’s five real PRs where the discipline was applied. The counterfactual — what the same agent would have shipped without the skills — is an informed estimate, not a measurement. The silent-contract-break story is the cleanest evidence, because we watched the review reproduce the bug before the redesign.
• Line counts are proxies. The −821 is a real number from the diffs, but “lines removed” stands in for “duplication and dead flexibility avoided.” A skill that talks an agent out of writing 200 speculative lines leaves no trace in a diff at all — the biggest wins are invisible here.
• Token savings are directional. Smaller diffs, fewer files touched, and reused structures mean fewer tokens spent generating, reviewing, and re-reviewing — but we’re not quoting a hard per-PR token delta.
• ponytail is not ours. It’s an open-source skill by Dietrich Gebert ; we adapted it. grain and review-proof are ours, built in the same spirit. All three run as local project skills on Claude Code — prompt-and-procedure, not a binary you install.

Ready to grow your business?

Start your free trial today and see results within days.

Request demo Log in

Part 3 · NOW WHAT

What shipped. Three composable skills. ponytail and grain run while writing; ponytail-review, grain-review, and review-proof run on a diff. review-proof chains grain-review as its final phase, so a single proven review also gets a structural pass for free.

What you can do on Monday — you don’t need our exact skills:

1. Make “reuse” rung two, not rung ten. Before an agent writes a helper, make it grep for one that exists. “Is it already in this codebase?” belongs above “can I write it cleanly?”
2. Fix at the root, prove it with the caller list. Require every bug fix to name every caller of the touched function. One guard in the shared function beats a guard per caller — and it’s a smaller diff.
3. Give new code a nearest-sibling to copy. “Find the closest existing example and mirror its shape” turns architecture from a doc nobody reads into a default the agent follows.
4. Enforce layer boundaries in CI, not vibes. A ratchet that fails only on new cross-layer imports lets you hold the line without boiling the ocean of existing debt.
5. Don’t ship a finding you can’t reproduce. Make the agent write the failing test first. If it can’t make the bug reproduce, it’s not a bug — it’s an opinion. Drop it.
6. Let the review delete. Point a review pass at over-engineering specifically — “what can we cut” — separate from correctness. The best outcome of a diff is that it gets shorter.

Try it, especially if it fails for you. If you run coding agents on a real codebase, the entropy is already happening — you just haven’t measured it. Turn one of these into a review pass on your next ten agent PRs and count the deletions. If subtract-align-prove doesn’t shrink your diffs or catch a silent break, we’d genuinely like to hear it. Corrections and counterexamples especially welcome.

An agent adds. The job is to make the agent earn every line.