You Can't Forward the Understanding

The review comment runs three paragraphs. Not one sentence of it belongs to the reviewer.

You can tell, because it reads like the model: fluent, confident, faintly generic, the prose of something that has never had to defend a decision.

Niklas Gruhn has a name for the person doing this. In “Don’t be a meat proxy,” he describes the colleague who answers your question by pasting a wall of model output, or leaves pull request feedback that is just a forwarded response, and makes the plain point that this adds nothing. You could have asked the model yourself, faster, with better control of the context. The human in the middle is not a contributor. They are latency.

I want to take that one floor deeper, into the work I actually do. In enterprise engineering the forward does not only waste the reader’s time. It quietly trades away the one thing that was ever yours.

When you forward unmetabolized output, you keep the credit and you hand away the competence. The artifact ships with your name on it. The understanding that was supposed to come with it never gets built. You look like the author. You are the relay.

The output is expensive to consume

Start with why the raw forward is a burden at all, because it is not obvious until you are the one receiving it.

Model output is verbose. It is frequently, plausibly wrong in ways that read exactly like being right. And it is dense with jargon, because the model reaches for the precise technical term every time, whether or not the reader shares the vocabulary. Here is a real shape of it, an agent explaining a fix to a message-processing pipeline:

The regression stems from non-idempotent consumer semantics under
at-least-once delivery. On redelivery after visibility-timeout expiry,
the handler re-applies the mutation because the dedup key is derived
post-deserialization, so poison messages that fail the schema gate
still advance the offset. Recommend hoisting the idempotency key to
the envelope, short-circuiting on the dedup store before the saga
orchestrator fans out compensations, and draining the DLQ via a
redrive policy with capped exponential backoff plus jitter.

Every word there is defensible. Taken together, they are a tax. The reader has to decode at-least-once delivery, visibility-timeout expiry, dedup keys, saga compensations, and redrive policy just to learn whether the change is safe. Paste that into a pull request and approve it, and you have not reviewed anything. You have forwarded a bill and signed it.

The reviewer became the tool

Now watch what the forward does to the roles.

The honest version of review is that a person understands a change well enough to stand behind it. The forwarded version inverts that. You feed the requirements into the model. It writes the implementation. You feed its output back in and ask it to explain itself. It writes the explanation. You paste the explanation into the review and click approve.

Count who did the work. The model implemented, the model justified, and the model reviewed. You operated the clipboard. The commit says author. The role you actually played was proxy, wearing the author’s costume.

This matters most exactly where it is easiest to skip. The review gate in most organizations was built for a human reading at human speed, and it assumes the human is reading. Put someone who is forwarding in that seat and the gate still clicks approved. It just stops meaning anything.

What you don’t metabolize, you can’t defend

Here is the part that costs you personally, on a longer clock.

You build judgment by metabolizing. Reading the thing, chasing the part that does not make sense, reproducing the bug, rewriting the explanation until it is yours. That work feels like overhead right up until the day the model is confidently wrong and you are the only human in the loop. Then it is the whole job. The reviewer who forwarded a hundred changes has a hundred artifacts and none of the understanding that would catch the hundred-and-first.

I have made this argument about institutions in You Can’t Edit What You Can’t Write: review, audit, and defending a system to an examiner all presuppose the ability to build it. The individual version is simpler and more personal. Judgment is the moat, and judgment is not forwarded into you. It is earned one metabolized output at a time. Forward enough of them and you have optimized away the only reps that were building the thing you cannot buy back.

Lower the cost of reading before you pay the cost of understanding

None of this means you have to suffer the jargon block as written. There is a real preprocessing move that helps, and it is worth knowing.

Ask the model to re-express its own output in ASD-STE100, Simplified Technical English. STE is a controlled language from the aerospace and defense world, built so a maintenance manual reads the same way to a technician in any country: a restricted vocabulary, short sentences, one instruction per sentence, active voice. Point it at that same pipeline explanation and you get something closer to this:

The system can apply the same message two times. This causes the error.

The queue sends a message again if the handler is too slow to confirm.
The handler does not check if it already processed that message. So it
makes the same change two times.

Do these steps:
1. Put a unique ID on each message when it enters the queue.
2. Check that ID in the store before you start the work.
3. If the ID is already there, stop. Do not process the message again.
4. Send failed messages to a separate queue. Retry them later.

Same content, stripped of the density that made it expensive. Other recognized plain-language standards do similar work. The U.S. plain-language guidelines are a public, well-worn example, and even a blunt instruction like “explain this as if I will be quoted on it” pushes output in the same direction.

Be precise about what this buys you, though. Simplified Technical English lowers the cost of reading. It does not touch the cost of being right. A controlled-language render of a wrong recommendation is a wrong recommendation that now reads beautifully. The jargon tax falls. The correctness tax does not move. Validation is still yours, and it always will be.

Then do the irreducible part

So preprocessing hands you a clean draft to work from. The work itself has not changed. Read it, understand it, validate it, and write the result in your own words. That last step is not busywork. It is the proof that the first three happened.

Here is the same change once a person has actually metabolized it:

What this is: the consumer is not idempotent, so a redelivered message
gets applied twice. I reproduced it by forcing a redelivery and watching
the balance move twice. The fix is to key dedup on the message envelope,
not on the parsed body, and to check that key before any downstream work
runs.

Reviewed by: me.
Verified: the double-apply, by reproducing it; the dedup key is stable
across retries.
Still unproven: behavior when the dedup store itself is briefly
unavailable. I am not approving that path until we test it.

Notice what the model could not have produced. The engineer reproduced the double-apply instead of trusting the diagnosis. They named the one thing they did not test, and declined to approve it. That ownership note is the value a human adds, and it is the exact thing a forward can never carry, because you cannot attest to what you did not read.

The part I won’t pretend away

The discipline has a failure mode of its own, and pretending otherwise would be its own kind of slop.

Not every relay is a sin. If a colleague cannot reach the tool and you hand them a result clearly labeled unverified, that is a favor, not a fraud. A disposable lookup, a starting point passed to someone who will do the metabolizing themselves, a quote you present as a quote: all fine. The dishonesty is never in forwarding. It is in forwarding while implying you understood.

And the Simplified Technical English move cuts both ways. Output that reads cleanly earns trust it has not yet proven. The better your preprocessing, the more careful your validation has to be, because polish is not accuracy, and a confident, well-structured paragraph is the easiest kind of wrong to wave through.

So the line is about stakes, the same place I always end up. Metabolize what you will have to defend, or will need judgment on later. Forward only what is genuinely disposable. The discipline is not a vote against the leverage. It is what lets you lean on the leverage without quietly going hollow.

The model can hand you the words. It cannot hand you the understanding, and the understanding was always the job. Keep your hands in the work long enough to mean the signature, and let the tool carry everything that is truly disposable. The forward is cheap. Being someone who can stand behind the output is not, and it never was.

If this resonated, read You Can’t Edit What You Can’t Write, on the institutional version of the same erosion, and Judgment Is the New Moat, on the one competence agents cannot hand you.

Find me on X @orestesgarcia or LinkedIn.