Last month I was walking my team lead through a change in one of our backend services. The change worked. The tests passed. Then he asked me a question I could not answer: "Why did we add the second cache eviction pass?"
I froze. The code had come out of one of my own AI agents two weeks earlier. I had reviewed the diff, skimmed the logic, approved it, shipped it. But I never owned it. I could not explain why that eviction pass existed, because I had never actually thought about it. I had just read it fast enough to believe it.
That memory is exactly why two essays that tore through Hacker News this week hit me so hard. The first, "Don't be a meat proxy" by developer Niklas Gruhn, hit 858 points and 364 comments. The second, "Prevent cognitive debt by manually retyping LLM-generated code" by Ankur Sethi, pulled 124 points and 101 comments. They were written a month apart by people who have never met, and they diagnose the same disease from two different angles. If you write code with AI, both are worth your time. Here is what each one says, where they disagree, and the workflow I stitched together from them.
Essay one: stop being the LLM's posting mechanism
Gruhn's essay, published August 3 on his blog, names a habit you have almost certainly seen in your Slack this month. Someone asks a question. The person they ask does not answer it. They feed it to Claude, then paste the raw output back, verbatim, without reading it, rewriting it, or owning a single word of it. Gruhn calls that person a "meat proxy."
His complaint is not that people use AI. He explicitly says "by all means, prompt AI." His complaint is what the raw output does to the person receiving it. AI output is verbose, it is jargon dense, and it contains what he calls "all too plausible nonsense." His example is a sentence Claude produced about his infrastructure: "NATS control-plane events: stream leader election / R3 quorum re-form during pod churn." He had to look up almost every word to make sense of it. The receiver of a pasted answer has to do that work every single time, and the sender did none of it.
The rule he lands on is simple and worth writing down: read it, understand it, validate it, then write the response in your own words. Your own phrasing is proof you did the first three steps.
The HN discussion pushed the essay somewhere darker and more useful. Several commenters traced the worst meat-proxy behavior to management incentives. Managers are being measured on AI adoption, so they reward the appearance of AI-native work: more AI-generated docs, more transcripts, more agent-authored PR comments, none of it read by anyone. When adoption volume is the metric, pasting raw output is the rational move. If you lead a team, that is the part to fix. Stop measuring AI usage by the volume of artifacts it produces.
Essay two: type every line yourself
Sethi's essay, published August 2, attacks the same problem from the opposite end. He is not talking about Slack messages. He is talking about the code in his own personal projects.
His observation: letting a coding agent one-shot entire features leaves him fast but disoriented. He knows the feature works. He does not know how it works. Reviewing hundreds of lines of "overly defensive, badly-commented, subtly incorrect" AI code in a PR is miserable, so he came up with a fix he describes as grossly inefficient and slightly comical. His agent lives in chat only. It proposes every edit as text in the conversation. He types every line into his editor himself. Same for commands: the agent shows them, he runs them.
The instructions he keeps in his agents files say it plainly: "I want to understand every line of code that goes into this project. Never create, edit, move, rename, or delete project files unless I explicitly ask you to do so."
The cost is speed. He estimates the workflow makes him roughly 2x faster than no AI at all, instead of the 10x he would get handing the keyboard to the machine. What he gets back:
- A mental model of every line, because he typed it.
- A hallucination filter, because typing slowly surfaces bad design choices that skimming a diff hides.
- A "spatial map" of the codebase. He knows where every bit of functionality lives, which makes the next change and the next prompt easier.
He closes with the fear behind the whole essay: the industry is accumulating cognitive debt it will pay back "when we no longer understand how large parts of our digital infrastructure are put together."
Where they disagree, and why it does not matter
On the surface, the two essays give contradictory advice. Gruhn is fine with the machine drafting; his bar is that a human rewrites the output before it reaches another human. Sethi goes further and demands that the human physically retype every line of code. Paste versus type. Summarize versus transcribe.
But the disagreement is about mechanism, not principle. Both essays are pointing at the same failure: shipping words you cannot defend. Gruhn's reviewer cannot defend a pasted Slack answer. Sethi cannot defend agent-authored code he never typed or truly read. The mechanism differs because the artifact differs. A Slack message needs one accurate rewrite. A codebase needs a mental model that survives a production incident at 2 AM. Retyping is just Sethi's enforcement mechanism for building it, and HN commenters who tried the same trick in the 90s, retyping book examples and whole codebases to learn them, recognized the muscle immediately. One commenter described taking over an unfamiliar codebase by opening it in one window and typing it into another, and becoming "a near expert overnight."
The principle underneath both essays fits in one sentence: if you cannot explain a line in your own words, you have not shipped it, your model has.
The workflow I run now
I run my own AI agent infrastructure, the kind that writes and publishes content while I sleep, and I use agents heavily in my day job on production backend services. I am not going to retype every line an agent generates for a production service. That is a personal-project luxury, and pretending otherwise would be dishonest advice from someone whose employer expects 10x, not 2x. Full disclosure: I have only been running this filter for about a week, on small changes, so treat it as a direction, not a proven system.
What I took from both essays is a three-question gate that every AI-generated diff has to pass before it ships. I keep it next to my review checklist:
- The "why" question. Why this approach and not the obvious alternative? If I cannot name the alternative the code rejected, I have not reviewed it. This is the exact question I failed on that cache eviction call.
- The removal question. What breaks if I delete this block? If the answer is "I would have to test and see," the block is a stranger living in my codebase.
- The words question. Could I rewrite the commit message and the PR description in my own words, from memory? This is Gruhn's "your own words are a certificate" test, applied to code.
If a diff fails any of the three, I do not retype it the way Sethi does. I rewrite it. I delete the block and write it again myself with the agent's version sitting there as a reference, the same way I retyped book examples when I was learning. Rewriting is faster than transcribing and it forces the same ownership. On small changes, this costs me minutes. On anything touching payments, auth, or data migration, I do go full Sethi and type it line by line, because those are the lines where a model's plausible nonsense costs the most.
For my agent setup itself, I borrowed one more thing directly from Sethi: write-file access is a privilege now, not the default. Drafting agents propose; nothing lands without passing the gate. The speed difference in my week so far is small. The difference in how the codebase feels is not. I know what is in it again.
The checklist, if you save one thing
- Read before you relay. No AI output goes to a teammate, a PR, or a status update without you rewriting it in your own words.
- Gate every diff on three questions. Why this approach, what breaks if removed, could I rewrite the commit message from memory.
- Escalate ownership with blast radius. Rewrite for ordinary code. Type it yourself for payments, auth, migrations, and anything you will be paged for.
- Fix the incentive, not just the habit. If you manage people, stop rewarding the volume of AI artifacts. Reward decisions your team can explain.
- Watch the debt line. The real bill arrives the day nobody on the team can explain the system without asking a model. Every ungated paste moves that day closer.
I write about AI agents, backend engineering, and the messy reality of building with these tools every week. Subscribe, it is free.
Have you caught yourself being a meat proxy, or shipping AI code you could not explain? What is your gate before agent code lands? Tell me in the comments.
Top comments (1)
The economic trap with agent-generated diffs is that they break the historical coupling between code generation cost and verification cost. Writing code manually was always an implicit proof-of-work mechanism: the hours spent typing and structuring logic forced you to build an internal state machine of failure modes. When token generation drops that production cost to zero while production incident triage remains strictly linear in human engineering time, the resulting delta is pure unpriced tail risk.
Treating the review process as an ownership solvency check gets the incentive structure right. Accepting a diff you cannot explain from first principles is functionally identical to selling unhedged options on production stability: you bank a small, immediate throughput gain today in exchange for absorbing all the downside variance when an edge case breaks at runtime. Forcing a rewrite on failing the why or removal test restores the capital requirement for merging code into the shared repository.