{"slug": "two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone", "title": "Two Viral Essays, One Warning: Your AI Code Is Fine, Your Understanding Is Gone", "summary": "Two viral developer essays diagnose a common problem with AI-assisted coding: developers losing understanding of code they generate. Niklas Gruhn's 'Don't be a meat proxy' criticizes pasting raw AI output without comprehension, while Ankur Sethi's 'Prevent cognitive debt by manually retyping LLM-generated code' advocates manually typing AI-proposed code to maintain ownership. Both essays, which trended on Hacker News, highlight the risk of 'cognitive debt' and the importance of understanding AI-generated code.", "body_md": "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?\"\n\nI 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.\n\nThat 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.\n\nGruhn'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.\"\n\nHis 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.\n\nThe 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.\n\nThe 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.\n\nSethi'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.\n\nHis 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.\n\nThe 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.\"\n\nThe 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:\n\nHe 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.\"\n\nOn 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.\n\nBut 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.\"\n\nThe 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.\n\nI 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.\n\nWhat 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:\n\nIf 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.\n\nFor 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.\n\nI write about AI agents, backend engineering, and the messy reality of building with these tools every week. Subscribe, it is free.\n\nHave 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.", "url": "https://wpnews.pro/news/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone", "canonical_source": "https://dev.to/jamilxt/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone-4kde", "published_at": "2026-09-09 12:11:54+00:00", "updated_at": "2026-09-09 12:41:49.581431+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-ethics"], "entities": ["Niklas Gruhn", "Ankur Sethi", "Hacker News", "Claude"], "alternates": {"html": "https://wpnews.pro/news/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone", "markdown": "https://wpnews.pro/news/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone.md", "text": "https://wpnews.pro/news/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone.txt", "jsonld": "https://wpnews.pro/news/two-viral-essays-one-warning-your-ai-code-is-fine-your-understanding-is-gone.jsonld"}}