What he said

Niklas Gruhn, in a short post on his blog, describes a pattern he keeps running into: someone asks a question in Slack, leaves feedback on a pull request (a proposed code change waiting for a teammate to review it), or argues in a group chat, and gets back an unedited wall of AI text instead of a real answer. He calls the person relaying that text a “meat proxy.”

“Too often I ask a question in Slack or leave feedback under a merge/pull request or argue with friends in a WhatsApp group and get back: Claude said: [giant response verbatim]. Please don’t do this,” Gruhn writes. “This is not adding value. I can talk to Claude myself. It’s going to be faster and I get to control the context. I don’t need a meat proxy in between.”

His fix is simple: “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 (a decent certificate that you’ve done the prior steps). Making that effort is value you can add.”

Who he is

Gruhn is a software engineer at DeepL, the machine translation company, according to his GitHub profile and his listing in DeepL’s GitHub organization. His public repositories are working developer tools, including a QR code scanning library for the Vue.js framework and a Sudoku solver that uses TypeScript’s type checker to catch mistakes. He is not a public AI commentator with a large following. The post reads as a practitioner venting about something he sees daily at work, which is exactly why it lands: this is a workplace habit he is describing from the inside, not a trend piece written from the outside.

What he gets right, and where it’s incomplete

Gruhn’s sharpest example is code review. “Shipping some code can be done with close to zero effort now: Copy/paste the ticket description into Claude Code,” he writes, referring to the written task description in a team’s issue tracker and to Anthropic’s terminal-based coding assistant. “Don’t look at the code or read what Claude has written. If there’s any feedback from reviewers, copy/paste that into Claude Code as well. If necessary, iterate. That works. But who has done the implementation? The reviewers did, using Claude Code, and you as a meat proxy.”

That is a real and specific failure mode, not a hypothetical: a developer can keep their name on a pull request while contributing almost no judgment to it, because both the writing and the fixing happen inside the AI tool and the human is just copying text between two boxes.

Where the post stays thin is on how to catch this happening. Gruhn describes the problem clearly but does not offer a process fix, like a rule that a pull request must include the author’s own explanation of why a change works, not just what it does. His stated solution, “read it, understand it, validate it, write it in your own words,” is aimed at individual discipline. It relies on the person choosing to slow down, with no check for a team that doesn’t.

Why it’s notable

Most AI workplace advice is about prompting better or picking the right tool. Gruhn is naming a different problem: what happens to the human in the loop when the AI’s answer is good enough to relay unread. His example of unreadable AI output, a sentence full of dense technical shorthand that even he had to look up piece by piece, makes a sharper point than a general warning about “AI slop” (a common shorthand for low-effort, mass-produced AI content) would: the more capable and articulate the AI’s answer looks, the easier it is to skip the step of actually understanding it before passing it along.

What it means for builders

If you are the one relaying answers, the cheap test Gruhn implies is real: could you explain this in your own words to the person who asked, without rereading the AI’s output? If not, you have not actually done the work yet.

If you are on the receiving end, especially reviewing a pull request, watch for the same signal in reverse: a contributor who can’t explain why their own change works, or who answers every follow-up question by pasting a new AI response instead of reasoning from the first one, is telling you they may not have engaged with the code at all. That is worth raising directly, before the change ships, not after.


End of article