I have started to notice a new kind of bad handoff. Someone asks a question in Slack, opens a pull request, or replies to a customer, then pastes the answer they got from an AI assistant. The answer can be long, polished, and completely beside the point. Now the person on the other end has to read it, find the useful part, and decide whether any of it is true.
Niklas Gruhn gave this pattern a memorable name: a meat proxy. The phrase is deliberately rude, but the underlying complaint is fair. If an assistant can answer the question directly, putting a human copy-and-paste step in the middle does not add much. It adds another inbox for the output.
The problem is not using AI. The problem is sending the transcript instead of the conclusion.
The hidden cost of a raw answer
A useful message does at least three jobs. It tells the reader what happened, explains why you believe that, and makes the next action clear. A raw AI response usually does none of those things reliably. It gives you possibilities, caveats, guesses, and a confident-looking explanation. The reader has to reconstruct the question you meant to ask and the decision you need them to make.
That reconstruction is work. It is also work that the sender was in the best position to do, because the sender knows why the question matters and what has already been tried. Forwarding the whole response throws away that context and makes the recipient pay for it with attention.
There is a second cost: the recipient cannot tell which parts you agree with. Did you check the explanation? Is the proposed fix already running? Are you asking for a review, permission, or simply sharing an interesting possibility? A long answer hides those questions instead of answering them.
AI should be your workbench, not your mouth
An assistant is good at producing candidate explanations, listing edge cases, turning a vague idea into a few options, and giving you a place to start. Those are private thinking aids. The useful output is the part that survives your judgment.
Think of the assistant as a workbench. You can spread parts across it, compare them, throw some away, and ask for a different shape. The person you are talking to should receive the assembled result, not a photograph of the workbench.
This is also why a short answer is not automatically better. Sometimes the important answer needs detail. The test is not word count. The test is whether every paragraph helps the reader understand the situation, trust the claim, or act on it.
The five-minute translation pass
Before you send AI-assisted work to another person, make one translation pass. It does not need to take long. It needs to put you back in charge of the message.
1. State the question you are answering
Write the question in your own words. “Why is the deploy failing after the dependency update?” is a real question. “Here is what Claude said” is not. Naming the question also exposes when the assistant answered a nearby question instead.
2. Separate facts from suggestions
Mark what you observed directly, what you looked up, and what the assistant suggested. A log line, a failing test, and a model-generated theory do not have the same status. Put them in different sentences so the reader does not have to guess.
3. Check the parts that matter
You do not need to verify every sentence with a research paper. You do need to check the claim that changes the decision. Open the relevant documentation, inspect the diff, run the smallest useful test, or compare the answer with the actual system. If you cannot check it, label it as a possibility.
4. Remove the assistant voice
Delete the greeting, the repeated summary, the generic caveats, and the confident filler. Keep the explanation that helps the reader. Replace “the AI recommends” with what you actually recommend and why.
5. End with a clear next step
Ask for one thing. “Can you review this approach?” is better than dropping 900 words into a channel and waiting. If you need approval, say so. If you are only sharing a finding, say that instead.
I checked the failing request against the current API docs. The issue is the client sending the old field name, not the server timeout. I have a small fix ready and need a review of the migration path.
That message may have started as an AI conversation. The reader does not need to know that unless it changes how they should evaluate the result.
Code review makes the failure obvious
Code review is where raw relay causes the most damage. An agent can generate a patch, explain its changes, write a test, and produce a list of reasons the patch is safe. If the author forwards all of that to the reviewer, the reviewer still has to answer the only questions that count: does this change solve the intended problem, and what did it break?
GitHub’s own guidance for reviewing AI-generated code starts with functional checks, context and intent, code quality, dependencies, and AI-specific failure modes. It also says AI review should supplement human review. That is a useful description of the division of labor: let the tool widen the search, then let a person decide what deserves trust.Read GitHub’s review guidance
A good pull request description is not an assistant transcript. It is a compact map for the reviewer:
The bug was caused by the cache key ignoring the account ID. The patch includes the account ID and adds a test with two accounts. I checked the existing invalidation path, but I am less certain about the old mobile client, so please focus your review there.
That gives the reviewer a target. It also makes the author’s uncertainty visible. A vague request produces a vague review. A checked summary gives another person a chance to apply their expertise where it matters.
Polished does not mean true
AI output is especially dangerous in a handoff because it often sounds finished before the thinking is finished. It can put a tidy explanation around an incorrect assumption. The prose becomes a kind of camouflage: the more fluent it sounds, the easier it is to mistake fluency for evidence.
Model output can also change. OpenAI’s API documentation notes that outputs are variable across model snapshots and recommends pinned versions and evals when consistent behavior matters. That is advice for building systems, but the same principle applies to everyday communication: an answer that sounds certain is still an answer that needs a reason to be trusted.See OpenAI’s notes on model output stability
The practical habit is simple: do not pass confidence from the assistant to the reader. Pass evidence, your interpretation, and the remaining uncertainty.
When forwarding the raw output is useful
There are legitimate exceptions. Send the original output when the other person explicitly asked to inspect the transcript, when the exact wording is part of a bug report, or when you are preserving an incident record. A support engineer may need the complete request and response. A researcher may want the unedited material for comparison.
Even then, add a short wrapper. Say what you want the reader to look for, what you already checked, and whether the output is verified. Raw material is useful when it is evidence. It is wasteful when it is being used as a substitute for a position.
A better pattern for everyday messages
Use this small structure whenever an assistant helped you investigate something:
Question: what I was trying to find out.
Conclusion: what I think is happening.
Evidence: the facts, tests, or docs that support it.
Uncertainty: the part I could not confirm.
Next step: the one thing I need from you.
You can make that two sentences for a quick Slack reply or several paragraphs for a design decision. The structure scales because it follows the reader’s actual needs. It also gives the assistant a useful job: help you fill the blanks, challenge the conclusion, and find missing evidence.
If someone sends you a giant AI answer
You do not have to silently become the editor of someone else’s prompt. Ask a small question back: “What is your conclusion?” or “Which part do you want me to review?” That moves the conversation from pasted material to an actual request.
If the answer is important, ask the sender to separate the facts from the theory. If they cannot summarize the output, that is useful information. It means the next step may be learning the system or narrowing the question, not asking a second person to validate a wall of generated prose.
The human part is the useful part
AI makes it cheap to produce more text, more alternatives, and more plausible explanations. That makes selection more valuable, not less. Someone still has to decide which problem is real, which constraint matters, which source is authoritative, and what another person should do next.
That is the part of the work people experience as judgment. It is also the part that builds trust. When you send a message in your own words, you are telling the reader that you looked at the answer, understood enough to summarize it, and are willing to be corrected.
Use AI privately as much as it helps. Ask it to brainstorm, challenge, explain, test, and rewrite. Then put the tool away for the last pass. Read the result, keep what you can defend, and send the answer you actually mean.
Do not be a relay between a model and another human. Add the part only you can add: context, judgment, and ownership.