Don't Be a Meat Proxy
Niklas Gruhn's essay Don't be a meat proxy describes a familiar code-review failure: someone forwards a ticket to a coding agent, submits its output unread, then shuttles the reviewers' comments back. The reviewers end up doing the engineering through a human relay.
If you run coding agents, there's a second version of this trap. It's easier to fall into, because it feels like work.
The factory version#
Gruhn's meat proxy carries model output out to people. Run a few agents in an AI software factory and you end up relaying in every direction. You copy tickets into prompts and paste test failures back into the session. You carry one agent's code into another agent's context, re-explain the same repo quirks to every new session, and go tab by tab when someone asks how it's going.
Each small handoff feels like supervision. Really, you've become middleware. It's easy to end up here: the tools don't connect, so the person does. But it costs more than minutes. The line moves at the speed of your context switches, and attention spent carrying isn't spent judging. That's how someone busy relaying ends up merging a diff nobody really read.
Transport or judgment#
Every handoff can involve two kinds of work. Transport moves an artifact, unchanged, to where it's needed: the ticket, the stack trace, the test output, the diff. Judgment decides something that wasn't decided yet: what the ticket means, what must not change, which approach to take, whether the diff should ship.
Ask what decision you made at the handoff. Reading an unchanged diff and deciding it meets the requirements is judgment. Copying an unexamined log between tools is transport. If you supplied a missing constraint or identified a known failure, record that finding where future runs can use it.
Gruhn's advice is to check the output and contribute your own understanding before passing it on. In a factory, apply that rule to each handoff: automate the transfer when no decision is needed, and make the decision explicit when it is.
What's left for people is the part that was always the job:
- Intent: what gets built, why, and what done means.
- Constraints: what must not break, change, or leak.
- Ambiguity: what an unclear ticket really asks for, and who to ask.
- Consequential decisions: schema changes, new dependencies, anything touching auth, money, or deletion.
- Review: reading the evidence and deciding whether it ships.
One bug, before and after#
Consider this example ticket: CSV export breaks rows when a customer name contains a comma.
Before. You paste the ticket into an agent running in your main checkout, next to your half-finished branch. It runs the wrong test command, so you paste the right one. The tests fail on an unseeded database, so you seed it and paste the output back. The agent says it's fixed. You export a file by hand, find that names with quotes still break, and paste in the bad row. You copy the diff to a second agent for review, then carry its comments back. A teammate asks for status, so you go find out. CI fails on lint, and you paste the log.
That's eight relays. One of them needed you, and only because a requirement lived in your head instead of in the task.
After.
- Issue. The run starts from the ticket, text and link attached. You add the two things the ticket doesn't say: keep the column order, because downstream imports depend on it, and done means a test with commas, quotes, and newlines in names passes.
- Isolated workspace. The agent gets a fresh worktree from main, and a setup script installs dependencies and seeds a database for it.
- Implementation. The agent runs the tests itself, reads its own failures, and iterates. Nobody pastes an error.
- Checks and evidence. It runs the new test, the full suite, and lint, and keeps the output. A second model reviews the diff, and the first agent answers the review.
- Reviewable diff. You're notified when it's ready, or stuck. You read a short diff, the test output, and the review. One line looks wrong, and your comment on it goes straight to the agent that wrote it. Then you merge, or you don't.
Count your touches: two sentences at intake, one read of the evidence, one comment, and the call to merge. Each one is a decision. You didn't think less. You carried less.
Remove one handoff at a time#
You don't need a platform team for this. Start with the usual suspects:
| The relay | What carries it instead | What stays yours |
|---|---|---|
| Ticket into a prompt | Starting the run from the issue itself | Constraints and a definition of done |
| Errors back to the agent | The agent running its own checks | Calling a failure flaky or real |
| One agent's code into another | Agents reading each other's output | What the next agent should do |
| The same context, every session | Repo instructions and a setup script | Writing the rule once, fixing it when wrong |
| Status for your team | Notifications for done, blocked, and failed | What to unblock first |
Then take them one at a time:
- Keep a paste log for a day. Each time you move text between a ticket, a terminal, an agent, or a chat, note what it was.
- Remove the most frequent hop, not the most annoying. Errors are a good first candidate: they're frequent, and letting an agent run its own tests changes nothing about what ships.
- Separate transport from decisions. Automate the transfer of tickets, logs, and artifacts. Record useful constraints and verified findings in the repo's instructions file (
AGENTS.md,CLAUDE.md, or whatever your agents read), a test, or the setup script. - Watch it for a week. If the hop stays gone and quality holds, move on. If the agent needs you less but does worse, you removed judgment along with the transport. Put it back somewhere durable.
- Automate intake last. Letting issues or a schedule start runs without you is the last relay to remove. As we argued in What is an AI software factory?, doing it before review is routine gets you a pile of pull requests nobody trusts.
Automate the carrying, not the approval#
There's an overcorrection waiting here. Once errors flow back on their own and agents hand work to each other, it's tempting to automate the last hop too: tests pass, the pull request merges itself. That doesn't remove the meat proxy. It's a meat proxy with the meat taken out: output forwarded unread, now to your users. A lockfile bump with good tests might earn that. Most changes don't.
Approval prompts deserve the same suspicion. Clicking "allow" on every command without reading it is the same pattern with a nicer button. Give routine work a sandbox where it doesn't need to ask, like a container or a cloud VM, and save the prompts for things that deserve one.
Keep the gates where the consequences are: merges, deploys, migrations, new dependencies, anything with production credentials. Freeing you up for those decisions was the point.
Where Agentastic.dev fits#
We build Agentastic.dev around this split. Link a Linear or Sentry issue to a run, and its details go in with your prompt. Each task gets its own worktree by default, prepared by your setup script. Notifications flag agents that finished, failed, or are waiting on you. Agents can start other agents and read their output through the dev CLI, and a comment on a diff line goes straight to the agent in that worktree. We still think a person should be the one who merges.
Carry less, decide more#
Gruhn's advice comes down to this: if you're going to stand between a model and a person, add something. The factory version runs the same rule through the plumbing. Where a handoff needs judgment, bring real judgment and write it down. Where it doesn't, step out and let the line carry it.
The line can carry text all day. Your attention is the one thing on it that doesn't scale. Don't spend it being a pipe.
Frequently asked questions#
What is a meat proxy?#
A meat proxy is a person who relays AI output without adding anything, such as pasting a chatbot's answer to a colleague without reading it. Niklas Gruhn describes this pattern in his August 2026 essay "Don't be a meat proxy." In an AI software factory, the same pattern shows up as plumbing: a person carrying tickets, errors, context, and status between tools and agents by hand.
How do I tell relay work from useful human judgment?#
Ask what decision you contributed. Checking an unchanged diff against the requirements is judgment; copying an unexamined log between tools is transport. Put recurring constraints and verified findings in the repo so later runs can use them.
What should people still own in an AI software factory?#
Intent, constraints, ambiguity, consequential decisions, and review: what gets built and why, what must not break, what an unclear ticket actually means, calls such as schema changes or new dependencies, and whether a change ships.
Does removing the meat proxy mean auto-approving agent work?#
No. Automate the carrying, not the approval. Agents can run checks, read their own failures, and hand work to each other, but merges, deploys, migrations, and other consequential changes still need a person who reads the evidence. Auto-merging everything that passes tests just forwards unread output to your users.
Where should a team start?#
Log every paste between tools for a day, then remove the most frequent handoff. Feeding test and CI errors back to agents is a good first candidate, because the agent can run the checks and read its own failures. Confirm quality held for a week, move to the next handoff, and automate intake last.