Meat Proxy: The Mistake of Copying and Pasting Claude’s Answers Without Reading Them

⏱️ Lectura: 10 min

On August 3, developer Gruhn published a short piece with a single request: stop pasting Claude’s full answer into the team chat, a pull request, or the WhatsApp group. He named the habit meat proxy: the person who carries text generated by an AI without adding anything of their own.

📑 En este artículo

1. TL;DR
2. What happened: the post that named the habit
3. Context: how we got to AI copy-paste in every channel
4. The full pattern: from ticket to merge without anyone reading anything
5. How to avoid being a meat proxy
6. Impact and analysis: why this isn’t purist nitpicking
7. What’s next
8. Frequently Asked Questions
   1. What exactly does meat proxy mean?
   2. Is the argument against using AI at work?
   3. How does this apply to code review?
   4. Is writing in your own words just a formality?
   5. Are there cases where copying and pasting is fine?
   6. Who is Gruhn?
9. References

The post, published on gruhn.me, doesn’t attack the use of AI itself. It attacks forwarding the output without reading it, without understanding it, and without validating it before sharing it with someone else.

TL;DR

• Developer Gruhn published “Don’t be a meat proxy” on August 3, 2026 on gruhn.me.
• The term describes someone who pastes an AI’s full answer into Slack, pull requests, or group chats without filtering it.
• His real example: the phrase “NATS control-plane events: stream leader election / R3 quorum re-form during pod churn,” which he had to look up word by word.
• The argument isn’t against using AI, it’s against forwarding output without reading, understanding, and validating it first.
• In code review he describes the extreme case: pasting the ticket into Claude Code, never looking at the code, and forwarding reviewers’ feedback straight back to the AI.
• The final result works and gets merged, but no one in the chain actually did the implementation.
• His proposal: use AI to research, but write the final answer in your own words.

What happened: the post that named the habit

Gruhn describes a situation that repeats across different channels: he asks something on Slack, leaves feedback under a pull request, or discusses something with friends in a WhatsApp group, and gets back a block of text that starts with “Claude said:” followed by the full answer, with not a single word edited.

His central complaint is simple: reading unfiltered AI output takes extra effort. The text is usually long, mixes plausible claims with errors, and increasingly uses technical jargon without explaining it. Gruhn cites a real example he received: “NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.” He had to look up nearly every word to understand the full sentence.

His conclusion: if someone can talk to the AI directly, he’d rather do it himself. It’s faster and he controls the context of the conversation. He doesn’t need a human intermediary who just forwards someone else’s text without filtering it.

Context: how we got to AI copy-paste in every channel

The pattern didn’t start in 2026. Since AI assistants became integrated into Slack, code editors, and messaging clients, copying and pasting became the path of least resistance. Writing your own answer takes time; pasting a model’s output takes a second.

This same outlet already documented a related trend: developer forums and communities flooded with unedited generated answers, a phenomenon some call ai slop. The meat proxy is a specific variant of that problem, applied to direct interpersonal communication: a colleague replying to another colleague, not a stranger in a public forum.

The difference matters. In a forum, a bad comment gets lost among thousands. In a team channel or a pull request, every message has a specific recipient who assumes the person behind it thought it through before sending.

There’s another factor that makes the problem worse: the technical jargon in AI answers keeps getting denser. The more specific the domain (infrastructure, distributed databases, networking), the more model-specific terms show up unglossed. Forwarding that text without translating it into the team’s own language multiplies the reading effort for the recipient.

The full pattern: from ticket to merge without anyone reading anything

Gruhn points to the most extreme case within a software organization: code review. He describes the flow like this: you copy and paste the ticket description into Claude Code. You don’t look at the code it generates. If there are reviewer comments, you copy and paste them back into Claude Code. You repeat until the pull request is approved.

The result works: the code passes the tests, the pull request gets merged, the feature ships to production. But no one in the chain did the implementation. The reviewers did it, using Claude Code to understand what they were approving, and the person who only acted as a meat proxy between the AI and the repository.

flowchart TD
    A["Question or ticket"] --> B["Claude generates answer"]
    B --> C{"Did you read and understand it?"}
    C -- "No" --> D["Pasted as-is (meat proxy)"]
    C -- "Yes" --> E["Summarized in your own words"]
    D --> F["Recipient doesn't know whether to trust it"]
    E --> G["Recipient gains real context"]

Pattern	What the human does	Main risk	When it’s acceptable
Pure meat proxy	Copies and pastes the full answer without reading it	No one understands or validates the content	Never, if the text includes analysis or decisions
Partial meat proxy	Skims it, pastes it anyway without summarizing	False sense of having reviewed it	Specific, verifiable data (dates, versions)
Verified relay	Reads, validates, and rewrites in their own words	Takes more time per message	Whenever the recipient expects human judgment

How to avoid being a meat proxy

Gruhn’s proposal isn’t to stop using AI. It’s to add a step between generating the answer and sharing it: read it, understand it, validate it, and then write it in your own words. That last step works as proof that you did the first three.

In code review, this can be enforced with simple repository-level rules. A minimal example: a git hook that blocks commit messages that are a literal paste of an AI block with no summary of your own.

#!/usr/bin/env bash
# .git/hooks/prepare-commit-msg
# Blocks commits whose message is a literal paste of an AI block

MSG_FILE="$1"
BODY=$(cat "$MSG_FILE")

if echo "$BODY" | grep -qiE "claude (said)|as an ai language model"; then
  echo "The commit message looks like a literal paste from an AI."
  echo "Write in your own words what changes and why, before committing."
  exit 1
fi

The hook doesn’t understand semantics, but it stops the most obvious case: pasting the raw output exactly as it came out of the model. It’s a cheap filter, not a complete solution.

A second trick works at the prompt level: ask the AI for raw data instead of finished prose, so you’re the one writing the connection between those data points.

Give me the data as raw bullets, no connecting prose:
- what changes technically
- what breaks if something goes wrong
- what alternative you considered and why you ruled it out

Don't write explanatory paragraphs. I'll connect the dots
and write the final answer for the team.

With this structure, the AI still does the heavy research, but the final writing (and the responsibility for what it says) stays on the human side.

💡 Tip: If you can’t summarize the AI’s answer in two sentences of your own, you haven’t understood it well enough to forward it yet.

Impact and analysis: why this isn’t purist nitpicking

The cost of this habit isn’t just the discomfort of reading long text. It’s the erosion of trust within a team. When a reviewer approves a pull request, they assume someone understood the change. If that person was a meat proxy, that assumption is false.

There’s a slower but more expensive organizational effect: knowledge becomes orphaned. If no one on the team actually understood why the code ended up that way, the next person who has to touch it (sometimes months later) has no one to ask about the original reasoning, because that reasoning never existed on the human side.

There’s an honest limit to Gruhn’s argument: not every exchange needs the full filter. Asking for a date, an exact syntax, or a specific fact and pasting it as-is doesn’t hurt anyone. The problem shows up when the output mixes opinion, analysis, or a design decision, and that mix gets forwarded as if it were the sender’s own judgment.

It’s also not a problem exclusive to code review. It applies to product feedback, architecture discussions, and casual conversations between friends: any exchange where the recipient expects human judgment and gets unfiltered text instead.

⚠️ Heads up: Approving a pull request generated end to end without anyone actually reading it leaves the real responsibility for the implementation in no one’s hands in particular.

What’s next

Gruhn doesn’t propose a tool or a formal policy, just a change of habit: use AI to research and write the final answer with your own judgment. It’s a stance that’s hard to fully automate because it depends on individual discipline, not a configuration flag.

Engineering teams will likely start including this criterion explicitly in their code review guidelines, alongside already-standard rules like requiring tests or a minimal description of the change. The discussion the post opened, though, goes beyond code: it touches on how anyone decides which communication deserves their own judgment and which doesn’t.

📖 Summary on Telegram: View summary

Try it yourself: next time you copy an answer from Claude for a colleague, summarize it in two sentences of your own before sending it, and notice how much the tone of the conversation changes.

Frequently Asked Questions

What exactly does meat proxy mean?

It’s the term developer Gruhn coined to describe a person who forwards an AI’s full answer to someone else without reading, understanding, or validating it first.

Is the argument against using AI at work?

No. Gruhn makes clear that using AI to research or generate drafts is fine. The problem is forwarding the output without adding your own judgment before sharing it with someone else.

How does this apply to code review?

In the extreme case Gruhn describes, someone pastes the ticket description into Claude Code, never looks at the generated code, and only forwards reviewers’ feedback back to the AI until the pull request gets approved.

Is writing in your own words just a formality?

Not according to Gruhn: it works as evidence that you read, understood, and validated the answer before sharing it. If you can’t rephrase it, you probably haven’t understood it yet.

Are there cases where copying and pasting is fine?

Yes, for specific, verifiable data, like a date or an exact syntax, a literal paste doesn’t cause the same problem. The risk shows up when the text includes analysis or a design decision that the recipient assumes is the sender’s own judgment.

Who is Gruhn?

He’s the author of the personal blog gruhn.me, where he published the original post on August 3, 2026 after repeatedly receiving unedited, forwarded AI answers across different communication channels.

References

• Don’t be a meat proxy: Gruhn’s original post, published on August 3, 2026.
• Code review (Wikipedia): definition and standard practices of the process the post questions.
• Anthropic: developer of Claude and Claude Code, the tools mentioned in the original post.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion

Imagen destacada: Foto de Annie Spratt en Unsplash