Ponytail rewired how I review agent code

My problem was never that the agent wrote bad code. It wrote too much good code. Ask for a feature flag and you'd get the flag, a config schema, a factory, and a README section: 400 competent lines where 30 would do, each one something I now owned. I covered what Ponytail is when I first found it: a skill that forces the laziest working solution, stdlib before dependencies, one line before fifty. This post is about what it did to my code reviews, because that's where it actually changed my week.

The diff went quiet

First noticeable effect: my June diffs were about 38% smaller than April's for comparable tickets. I checked, because it felt too good. I pulled the merged-PR line counts for both months and normalized by ticket type. Not scientific, but not nothing.

Second effect, the one I care about more: the diffs got legible. A Ponytail diff is mostly the change itself, with little scaffolding around it. Reviewing it feels like reading a sentence instead of a form. The skill ships an output contract (code first, then at most three lines on what was skipped and when to add it), and those three lines turned out to be the most valuable part.

The ceiling comments

When Ponytail takes a deliberate shortcut, it marks it: a comment naming the ceiling and the upgrade path. A global lock with a note saying per-account locks come when throughput demands it. An O(n²) scan with the threshold where it stops being fine.

These became anchors in review. Instead of me discovering a simplification and wondering whether the agent was being smart or sloppy, the diff declares it, and review becomes a conversation about whether the ceiling is acceptable. That's the conversation senior engineers were always supposed to have. We just never had a syntax for it.

The comments mark decisions made, and decisions are reviewable.

Two arguments it lost, one it won

Won: I asked for a response cache on an internal API. Ponytail refused: no cache until a profiler says so, and when it does, use the stdlib memoizer. I grumbled, profiled, and the endpoint was 4% of request time. The cache would have been a bug farm with a hit rate, exactly as advertised.

Lost, round one: it one-lined a retry loop without jitter. Fine at our scale until the day it synchronized fifty workers into a thundering herd against a rate-limited API. The ceiling comment had actually named this: retry without jitter, add backoff when concurrent callers appear. I'd waved it through anyway. The tool put the decision in front of me and I made the wrong call, which stung precisely because I couldn't blame the tool. More on that reviewing discipline in the AI code review post.

Lost, round two: it YAGNI'd a second implementation of an interface I knew was coming within the sprint. The skill can't see the roadmap. I overrode it, and the skill took the override without re-arguing. That's in its contract too, and it matters. A lazy tool that fights you stops being lazy.

What I'd tell you

Run it at full, not ultra, for the first two weeks: ultra questions whether your feature should exist, and that's a lot of philosophy before coffee. Read every ceiling comment like it's a line item in a contract, because it is; the one incident I ate came from skimming one. And pair it with Caveman: terse prose plus lazy code is where agent output stops feeling like something you manage and starts feeling like something you read.

The deeper shift: I used to review agent code for what it did. Now I review it for what it deliberately didn't do, and that's a better use of a principal engineer's hour.