Don’t Be a Meat Proxy – Why Relaying LLM Output Without Adding Value Harms Teams

TL;DR

People who copy‑paste AI output (e.g., “Claude said: …”) into Slack, PR comments, or chats without reading, validating, or re‑phrasing it are providing no real contribution; this practice, dubbed meat proxying, wastes time, spreads jargon, and shifts responsibility away from the human.

The Core Argument

The author observes a growing habit: developers and managers ask an LLM, then forward the verbatim answer to a colleague with a pre‑fixed prefix like “Claude said:”. The author argues that this is unproductive because:

  1. Extra cognitive load – Recipients must parse verbose, jargon‑heavy text that often contains plausible but incorrect statements.
  2. Loss of ownership – The human who forwards the answer does not demonstrate they understood the content, making it hard to trust the information.
  3. Reduced learning – Skipping the step of reading and validating the AI output prevents the proxy from deepening their own knowledge.

The recommended workflow is to read, understand, validate, and then rewrite the answer in one’s own words before sharing it.

Real‑World Examples from the Discussion

  • Slack fatigue – A commenter (eddythompson80) describes senior managers asking “Can you read this 300‑line AI response for me?” and notes the frustration when junior engineers are forced to act as intermediaries.
  • Corporate AI code of conduct – mft_ mentions that companies are already drafting policies because the “meat proxy” behavior appears as soon as a corporate LLM account is enabled.
  • Social media dilution – rishsriv points out that AI‑polished posts on platforms like Twitter often lose their original insight, making the content less valuable to readers unfamiliar with LLM jargon.
  • Misplaced authority – A journalist mistakenly used Claude to “detect” AI‑generated lyrics, assuming the model could provide authoritative forensic analysis (comment by -0_0-).
  • Code review shortcut – The author’s example shows a reviewer copying the ticket description into Claude Code, letting the model generate a PR, and then merging without ever looking at the code themselves.
  • Technical jargon overload – Several commenters (denis‑stable, supermatt) note that the dense terminology (e.g., “NATS control‑plane events…”) can be legitimate for specialists but is often incomprehensible to the broader team.
  • Accountability concerns – sethammons and OJFord argue that quoting an LLM is a way to abdicate responsibility; the proxy should instead stand behind the final answer.
  • Learning vs. laziness – Some users (dwarhl, gjulianm) intentionally keep the proxy step to force teammates to research on their own, treating it as a modern “RTFM”.
  • Potential for automation – RicDan suggests that if everyone only copies LLM output, the role could be replaced entirely by the model, highlighting a risk to certain job functions.

Why the Problem Persists

  1. Convenience over quality – Prompting an LLM is faster than digging into documentation, especially for non‑technical stakeholders.
  2. Perceived authority – Attaching “Claude said” gives the impression of an expert opinion, even when the model hallucinates.
  3. Organizational norms – In some teams, forwarding AI output has become an accepted shortcut, reinforced by managers who value speed over depth.
  4. Token economics – Engineers with limited token budgets may offload work to senior staff who have unlimited access, creating an uneven distribution of effort.

Community‑Suggested Mitigations

  • Explicit rewrite requirement – Encourage a policy that any AI‑generated text must be paraphrased and signed off by the human before sharing.
  • Prompt engineering for brevity – Use prompts like “Explain briefly” or “Break down each term in plain English” to reduce verbosity at the source.
  • Verification step – Require a quick sanity‑check (e.g., search the web, run a test) before accepting AI answers.
  • Education on AI limits – Share examples where LLMs fail (e.g., mis‑identifying song authorship) to temper over‑reliance.
  • Dedicated “AI‑proxy” channels – Some commenters suggest a separate Slack channel or domain (e.g., nohello.com) where raw AI output can be posted without polluting productive conversations.
  • Skill‑based routing – Direct queries to the most appropriate human expert rather than a blanket AI proxy, as suggested by torment‑nexus.

When Forwarding AI Output Might Be Acceptable

A minority of comments acknowledge that in certain contexts forwarding raw LLM output can be useful:

  • Rapid intel gathering – xyzelement notes that a 10‑page Claude synthesis gave a sales rep actionable information faster than pre‑AI research.
  • Highly specialized domains – If the recipient is an expert familiar with the jargon, the dense output may be directly usable (supermatt).
  • Transparent collaboration – When both parties agree that the AI is a shared research assistant, the “Claude said” prefix can serve as a provenance marker (theletterf).

In these cases, the key is mutual consent and clear responsibility for any downstream decisions.

Practical Checklist for Avoiding Meat Proxying

  1. Read the AI response fully.
  2. Validate facts (search, run code, consult documentation).
  3. Summarize in your own words – aim for a concise paragraph or bullet list.
  4. Add personal insight (why the answer matters, any caveats).
  5. Attribute the source only if it adds value (e.g., “I consulted Claude for a quick definition, then verified X”).

Conclusion

The “meat proxy” pattern erodes the quality of technical communication, inflates cognitive load, and shifts accountability away from humans. By insisting on personal comprehension, validation, and re‑articulation of AI output, teams can retain the productivity gains of LLMs while preserving trust, learning, and clear responsibility.

Sources