Everyone has an agent in their pocket now, which makes it easy to conjure words from nothing that look like something. Niklas Gruhn named the failure in a title: “Don’t be a meat proxy.” He’s right: we’ve all done it, and we all detest it.

Because it is so nice to have a ghostwriter! Such convenience! My agent answers review comments, drafts replies, and posts under my account every day. And I do more, faster. But if an agent is going to publish under my name, it needs to be good. I like writing well. So, how do I make it better, and where is the line?

The line is the decision, not the typing. A reader who spends ten minutes on my reply is owed the fact that I spent real attention on the question. If I read the comment, made the call, and had the agent put the call into words, the reader got what they were owed. If I never made the call, the agent’s one-shot fluency only hides that.

Sounding like me

When the words go out under my name, but do not sound like me, the reader can absolutely tell. I can tell. And the readers will revolt. Even if the decision and intent are valid, it’s hard to engage with over-dramatic constructions like “You’re right, and it’s worse than I thought…” in a PR that drops a column prematurely.

So a lot of my configuration is an effort to fix the voice. code-review-register governs the comments I post as myself. “Default to warm and a little playful.” “Real reactions beat generic praise: ‘Ha, nice catch’ over ‘Good job.’” I want to be able to stand behind a first or second draft. When my hands are on the keyboard and I am the one waving the baton, a little playfulness in the agent’s prose is welcome.

Me to myself

Conversely, with the agent at the wheel, I want the playfulness gone. No flattery, no pleasantries. I don’t like being talked to by an agent that pretends to care. Sycophancy is bad enough without empty, quasi-emotional words.

In July, my agentic alter ego @nonreagent opened a pull request against my dotfiles. I left a one-line comment:

I think we need to account for ci that only runs on main. Modify the ci.yml to run on PRs to, and ensure it passes.

Seventy-four minutes later, I read:

Good catch — CI was doubly broken on this PR:

  1. It never ran. The pull_request trigger filtered on branches: [main], which matches the PR’s base …
  2. It would have failed. The job still ran make link-dotfiles, but this PR renamed that target …

Pushed as 2a22072. CI now triggers on the PR and is green: https://github.com/nonrational/dotfiles/actions/runs/29208330057

It names two distinct failures, cites the trigger filter, links the green run, and had pushed the fix before it posted. But, all I could think about was how silly the opening felt.

Nothing is wrong with the phrase. From a peer, “good catch” is a concession that another saw what they missed. From an agent it costs nothing, and praise that costs nothing is worth exactly that.

So I banned it. The fix is a skill that teaches the agent to handle review feedback on its own pull request (1bd175a). The rule is blunt:

No “thanks,” no “great catch” — just the fix.

The agent’s replies are plain: what changed, where the evidence lives, and an easy yes or no when something should become a follow-up.

Who cares?

The last mile is cheap now, so we can spend less time arguing. When a colleague leaves a review on my pull request, accepting their nits is often faster than debating them. How often is a review suggestion flat wrong? Rarely.

Which suggests an experiment I have not yet run. If a colleague cared enough to say it, why not let them make the change on the PR themselves? We could break the rules of the pull request a little, and let review become an automated collaboration of decisions, with fewer trips back into English for every exchange.

Either way, we are all pairs, programming now. We owe it to the pair on the other side of the exchange (and ourselves) to curate the experience.