A common mistake in AI-assisted work is assuming that speed alone equals productivity.
If a chatbot drafts something and you paste it into Slack, email, a spec, or a code review without reading it carefully, you are not saving time in any meaningful way. You are just moving the thinking step from your own brain to the recipient’s inbox. That is the behavior developer Niklas Gruhn called being a “meat proxy,” and the term lands because it describes a real failure mode: a human acting as a thin wrapper around machine output.
The problem is not AI itself. The problem is unedited AI output being treated as finished work.
For developers, this shows up everywhere:
- replying to a teammate with a raw chatbot answer instead of a considered response
- copying generated explanations into docs without checking accuracy
- pasting AI-written code or configs without understanding the assumptions
- delegating too much context to the model and too little to yourself
That pattern is closely related to what researchers call cognitive offloading or cognitive surrender. In practice, it means your judgment, not the model’s text, is the scarce resource you are failing to apply.
Why this matters in developer workflows
Most software work is contextual. A suggestion can be syntactically correct and still be the wrong answer for your codebase, your team norms, your performance constraints, or your threat model.
AI tools are very good at producing plausible text. They are much less reliable at knowing:
- your internal architecture
- which edge cases are important in your product
- whether a dependency is acceptable
- what your team considers readable or maintainable
- which tradeoffs matter more right now
That is why blindly forwarding model output often creates more work downstream. The recipient has to re-evaluate the response from scratch, and now they also have to guess whether you understood it.
From a collaboration perspective, that is the real issue. Not only is it low value, it can reduce trust. If people know they still need to verify everything you send, you have not accelerated the workflow. You have added another review layer.
A better pattern: use AI as a draft generator, not a context replacement
Gruhn’s practical advice is simple and still the best starting point: read it, understand it, validate it, then rewrite it in your own words.
That sequence is worth turning into a repeatable workflow.
1. Ask AI for a draft, not the final artifact
Use the model to generate options, summaries, or a first pass. This is especially helpful for:
- outlining a response
- surfacing missing considerations
- translating between formats
- brainstorming edge cases
- generating a rough explanation for a nontechnical audience
The key is to treat the output as raw material.
2. Validate every claim that matters
Before you send anything, check the parts that could affect correctness:
- facts
- API behavior
- security implications
- compatibility assumptions
- performance claims
- version-specific details
If the output contains code, do not rely on confidence in the prose. Read the code line by line. Ask whether it handles error paths, types, boundaries, and dependency constraints. A polished explanation does not make an untested snippet safe.
3. Re-express the answer in your own voice
This is the step people skip most often, and it is also the step that adds the most value.
Rewriting is not cosmetic. It forces you to decide:
- what actually matters
- what can be omitted
- what should be emphasized
- what tone is appropriate for the audience
That is where your judgment becomes visible. A teammate does not need a transcript of a chatbot conversation. They need your interpretation of the issue.
4. Add context the model cannot infer
If you want to be useful, include the thing the model cannot know on its own:
- “We cannot introduce a new dependency here.”
- “This needs to fit our existing event pipeline.”
- “Keep the explanation short because this is for the support team.”
- “We already tried approach A and it failed because of X.”
That small amount of context often makes the difference between generic slop and genuinely useful work.
A simple standard you can apply today
If you want a rule that is easy to remember, use this:
Never send model output you would not be willing to defend in a meeting.
That standard is strict enough to catch most meat-proxy behavior.
Before sending anything AI-assisted, ask yourself:
- Could I explain this without looking at the tool output?
- Do I understand why this answer is correct?
- Did I check the parts most likely to be wrong?
- Did I tailor this to the actual recipient?
- Would this still be useful if the model were unavailable?
If the answer to any of those is no, you probably need another pass.
Tradeoffs: where AI helps and where it hurts
There is a real upside to AI in engineering workflows. It can speed up first drafts, reduce blank-page friction, and help you explore alternatives faster than manual searching alone.
But the tradeoff is obvious: the easier it becomes to produce text, the easier it becomes to stop thinking.
That risk is especially visible in developer culture because so much of our work is already mediated by tools. We rely on autocomplete, linters, formatters, search, and codegen. None of those are inherently bad. The difference is whether the tool amplifies your understanding or replaces it.
Autocomplete assists the human. A meat proxy workflow inverts that relationship.
The practical takeaway
The useful habit is not “never use AI.” It is “do not let AI stand between you and your own judgment.”
Use it to draft, compress, and explore. Do not use it to avoid reading, thinking, or contextualizing. If you are sending something to another person, make sure the final message reflects your understanding, not just the model’s phrasing.
That is the difference between using AI as a tool and becoming the tool.
Top comments (0)