On Monday, a blog post titled “Don’t Be a Meat Proxy” shot to the top of Hacker News, racking up 1,118 points and 468 comments by midday. The author, writing on his personal site at gruhn.me, described a pattern he keeps seeing: a colleague uses Claude Code to generate an implementation, submits it for review without reading it, and when reviewers leave feedback, pastes that feedback right back into the AI. The colleague never engages with the code. The reviewers do. “Who has done the implementation?” the post asks. “The reviewers did, using Claude Code, and you as a meat proxy.”

The post struck a nerve. It is, on its face, a story about individual responsibility — about the moral hazard of outsourcing your thinking to a language model and calling it work. The comments are full of people nodding along. Yes, this is what’s wrong with AI. Yes, people are getting lazy. Yes, craft is dying.

But the post is also describing something that should feel familiar to anyone who has worked in a software organization larger than about thirty people. The “meat proxy” didn’t arrive with Claude Code. It arrived with the division of labor.

The Junior Developer Was the Original Meat Proxy

For decades, the standard career path in software engineering has worked like this: you join a team as a junior, you’re assigned tickets, you write code, you submit it for review, and a senior engineer tells you what to change. You make the changes. You may or may not fully understand why. Over time, you absorb the patterns and graduate to doing the reviewing yourself.

In this arrangement, the junior developer was often functioning as a kind of meat proxy for the senior engineer’s design intent. The senior knew what the code should look like; the junior typed it. The review process was where the real engineering judgment lived. The junior’s job was to be a fast, inexpensive feedback loop between the senior’s brain and the codebase.

None of this was a scandal. We called it mentorship. We called it learning on the job. And for many people, it worked — eventually. But the structure was always there: a person whose role was to translate someone else’s understanding into text, with variable amounts of their own comprehension along the way.

What Claude Code did was make that person cheaper and faster. The AI doesn’t get tired, doesn’t push back, doesn’t need a visa, and doesn’t eventually demand a senior title. It just produces the diff. The review process — the part where the senior engineer applies judgment — remains exactly the same. The only thing that changed is who, or what, is on the other end of the pull request.

When Review Becomes the Work

Here is the uncomfortable implication the blog post gestures toward but doesn’t quite name: if the reviewer is doing all the intellectual work, and the “meat proxy” is just relaying instructions to an AI, then the review process has become the implementation process. The typing was never the valuable part. The valuable part was always the judgment — the decisions about architecture, error handling, edge cases, and tradeoffs. The person submitting the PR was just the hands.

This is not a new problem. It is the logical endpoint of a culture that spent two decades optimizing for “velocity” — a metric that measures how many tickets move across a board, not whether anyone understands the system they’re building. Velocity culture taught engineers that the thing that gets measured is the PR, not the comprehension. AI didn’t create that incentive. It just made the gap between shipping and understanding impossible to ignore.

One principal engineer at a logistics software company, reviewing a PR at 11 p.m. from a colleague he’d never met in person, described the dynamic this way: “I used to spend 40% of my review time on logic errors and 60% on style. Now it’s flipped. The AI writes clean code with subtle, catastrophic mistakes buried three layers deep. I’m not reviewing anymore. I’m debugging someone else’s prompt.”

That shift — from reviewer to debugger — is where the real story lives. The “meat proxy” is a symptom. The disease is an engineering culture that decided, years before LLMs arrived, that understanding was optional as long as the tests passed.

The Uncomfortable Question Nobody’s Asking

The blog post frames the meat proxy as a moral failing of the individual. Be better, it says. Read the code. Understand it. Validate it. This is good advice. It is also advice that runs directly counter to the incentive structures most engineers actually work under.

If your performance review depends on how many story points you close, and your manager has never once asked whether you understood the code you shipped, and the AI produces a diff that passes CI in thirty seconds — what exactly is supposed to motivate you to spend an extra hour reading it? Professional pride? That’s a lovely idea. It is also not how large organizations function.

The uncomfortable question the “meat proxy” post raises, probably unintentionally, is this: if a process can be reduced to copy-pasting between a ticket, an AI, and a reviewer, was the process ever really engineering? And if the answer is no — if large swaths of what we’ve been calling software engineering turn out to be clerical work with better branding — then the problem isn’t the person copy-pasting. The problem is the system that spent years pretending otherwise.

The AI didn’t break anything. It just held up a mirror. What we do next depends on whether we’re willing to look at it.

Sources