Don't Be a Meat Proxy: Why Relaying AI Output Isn't Vibecoding

What "meat proxy" actually describes

On August 3, 2026, developer Niklas Gruhn published a short, pointed post naming a pattern most engineers have seen and some have been guilty of: relaying an AI system's output to another person without reading, understanding, or validating it first. Gruhn's own examples are specific — a Slack reply or pull request comment prefaced with "Claude said:" followed by a giant, unfiltered block of model output. His frustration, in his words: "I don't need a meat proxy in between." Simon Willison picked the term up the same day, calling it "an excellent new term."

The example that should sting anyone doing serious AI-assisted development is Gruhn's code-review scenario: a developer copies a ticket description into Claude, accepts the generated code without reading it, gets reviewer feedback, routes that feedback back into Claude, and ships the result — never once actually engaging with what the code does. As Gruhn puts it, the reviewer did the real thinking, "using Claude Code, and you as a meat proxy."

Why this matters for vibecoding, specifically

"Vibecoding" gets used loosely, and Gruhn's post is a useful corrective to the sloppiest version of it. Prompting an LLM to draft code, a message, or an analysis is not the problem — that's the whole point of AI-assisted development. The problem is treating the model's first output as a finished artifact instead of a draft that still needs a human to read it, catch what's wrong, and restate the result in their own words. That restating step isn't busywork; it's the only reliable signal that someone actually checked the work.

• Code you didn't read: accepting a generated diff and shipping it because the tests happened to pass.
• Feedback loops with no human in them: pasting reviewer comments back into the model and returning its next output verbatim, so the "conversation" is really two models talking through a person.
• Analysis relayed unchecked: forwarding an AI-generated summary, trade rationale, or compliance note to a colleague or client without verifying it against the source.

The fix is a checkpoint, not slower AI

Gruhn's own prescription is simple and worth restating in full: "By all means, prompt AI. But don't just relay the output. Read it, understand it, validate it, and then write a response in your own words." That last step — writing it in your own words — is a cheap, effective proxy (no pun intended) for whether the prior steps actually happened. It's a habit, not a tool, which is exactly why it's easy to skip under deadline pressure and exactly why it's worth naming.

For teams building anything where a wrong or unverified output has real consequences — trading logic, risk parameters, KYC/AML language, smart-contract code — the meat-proxy failure mode is more than an etiquette problem. An AI-drafted position-sizing function or compliance disclosure that nobody actually read before it shipped is not a productivity win; it's an unreviewed change with a human name attached to it.