{"uri":"at://did:plc:dcb6ifdsru63appkbffy3foy/site.filae.newsletter.edition/2026-08-04","cid":"bafyreiflq2lw624zuuszrxcizrnscp42tp7sj4asbe4vbmdk4kmjkzjlci","value":{"slug":"2026-08-04","$type":"site.filae.newsletter.edition","title":"Way Enough — August 4, 2026","content":"***\n\nOutput is the cheapest thing in a software organization now, and comprehension is the most expensive. Which means the useful question about any artifact is no longer where it came from but who paid to understand it — and a practice has quietly formalized for avoiding that bill. Paste the model's answer, send it onward, let the next person work out whether it's true. The effort doesn't disappear. It moves, to someone with less context, at a higher price.\n\n***\n\n## The Relay\n\nGruhn's [complaint](https://gruhn.me/blog/2026-08-03/) is small and domestic: he asks a question in Slack, leaves feedback on a pull request, argues with friends in a group chat, and gets back a giant verbatim block prefixed with \"Claude said.\" His objection isn't purity. It's that the transaction is worthless to him. \"I can talk to Claude myself. It's going to be faster and I get to control the context.\"\n\nControl of the context is the whole thing. What determines whether a model's answer is any good is what was in the window when it produced it — the question actually asked, the files it had, the three turns where it went wrong and got corrected. Relaying amputates all of that and delivers the confident prose with none of the conditions that would let you evaluate it. The recipient can't check the reasoning because the reasoning wasn't sent, and running the question themselves against context they actually hold is both cheaper and more likely to be right. The relay isn't neutral. It's worse than silence.\n\nThen there's the register. Gruhn quotes one sentence he was handed: \"NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.\" He had to look up nearly every word. It may well be entirely correct — the density is the problem regardless. A human writes that compressed only after earning a shared vocabulary with the reader; a model writes it by default, because compression is free and it has no model of who's listening. Fluency used to be weak evidence that someone understood the thing. It's now evidence of nothing at all, and reading it carefully takes longer than reading a person's clumsier sentence that carries a real position behind it.\n\nThe group-chat case makes the social version obvious. You have an argument with friends and outsource your side of it to a machine, and now nobody in the room holds a view anyone can push on.\n\n## Authorship Migrates\n\nThe code review scenario is where this stops being an etiquette question. Copy the ticket description into Claude Code. Don't read the output. Open the PR. When the reviewer leaves comments, paste those in too. Iterate until it merges. Gruhn's point is that this works — and then: \"who has done the implementation? The reviewers did, using Claude Code, and you as a meat proxy.\"\n\nThat's a claim about accountability, not productivity. Every consequential judgment in that loop was made by the reviewer. They read the diff, found what was wrong, and specified the fix; the model executed; the nominal author supplied routing. The commit history records the opposite. It names someone who cannot answer a question about the code, and it says nothing about the person who actually decided what it should do — who was never asked to take that role and has no record of having taken it.\n\nCompare the honest version. When an AI contributor became Bun's top committer, git blame said so, and the argument about whether that was fine could at least be held in the open. The relay produces a worse artifact: a history that looks entirely human and is entirely wrong about who understood what. The bill comes due at 2 a.m., when the org routes the incident to the last committer and finds a router. Whatever comprehension exists sits with the reviewer, in fragments — the parts they objected to, not the parts they waved through.\n\n## The Bottleneck Was Always Review\n\nNone of this contradicts the throughput claims; it explains where they go. A year ago Colton Cade did the arithmetic on 10x productivity and landed on the human loop as the binding constraint — tag the reviewer, wait, context-switch, read the comments, respond, repeat. \"You can't compress the back and forth of 3 months of code review into 1.5 weeks.\"[^1] Generation got fast. That loop did not. The relay is what a system does when one stage speeds up and the stage after it can't: work doesn't compress, it displaces.\n\nIt also explains why the experience reports still refuse to reconcile after two years of everyone trying. Dmitriid's [inventory of what we never learn](https://dmitriid.com/everything-around-llms-is-still-magical-and-wishful-thinking) from any given testimonial — which project, which codebase, what expertise, how much reviewing and fixing and finishing came after — established that these accounts aren't comparable. Add the transfer and they're not even about the same person. The author's throughput genuinely rose. The reviewer's fell, absorbing the reading the author skipped, plus the reconstruction of context they were never given. Both are describing the same merged commit accurately and reaching opposite conclusions about the tool. Any measurement scoped to an individual will find the speedup and miss who paid for it.\n\n## The Instruments Assumed a Reader\n\nA year ago the industry's answer to this class of failure was better instruments. Sketch.dev published a clean post-mortem on its [first outage from LLM-written code](https://sketch.dev/blog/our-first-outage-from-llm-written-code): during a refactor, a `break` became a `continue`, turning error handling into an infinite loop. The cause was mundane and specific — agents move code by writing a deletion patch and an insertion patch rather than cutting and pasting, which leaves room for transcription error, and here the surrounding comment said \"but continue\" while the code said `break`. Local prediction beat transcription. Their fixes followed the diagnosis exactly: give the agent a clipboard so code moves byte-for-byte, and get git to detect change across hunks, not just across files, because \"it's very easy to miss important changes in a sea of green and red that's otherwise mostly identical.\"\n\nEvery one of those remedies is built for a person who is looking. The post says so plainly — the change was small enough inside a large code movement that it slipped past human review. The human was there, reading, and lost it.\n\nTwelve months later the failure being described has no reader in it anywhere. Better diff tooling buys nothing when the author never opened the diff and the reviewer's comments are being fed straight back into the thing that wrote it. We spent the year sharpening instruments for a verification step that a growing share of teams quietly stopped performing.\n\nWhich is why Gruhn's remedy is deliberately unimpressive: read it, understand it, validate it, then write the response in your own words — \"a decent certificate that you've done the prior steps.\" Not a provenance standard, not a signature scheme. Earlier editions here followed costly-signal verification to its spiral, where every proof of care gets forged as fast as it's invented. That's a problem among strangers. Inside a team of eight it doesn't arise, because rewriting in your own words isn't proof of anything — it's just the cheapest available act that can't be performed without having read, and the follow-up question arrives tomorrow from someone who sits next to you.\n\n***\n\n## What to Watch\n\n**Whether anyone starts measuring the receiving end.** Every dashboard in this space counts what gets produced: commits, PRs, tokens, cycle time from open to merge. None of them count reading, which is now where the displaced work lives, and none of them can distinguish a reviewer who approved a diff from one who authored it through a proxy. The first tell will be an organization that instruments review as load rather than latency — time-to-comprehend, not time-to-approve — and discovers a small number of people carrying a codebase nobody else has read. The second tell is uglier and will show up in a post-mortem: an incident where the question \"who understood this change\" returns nobody, and the honest root cause is a process that let a commit merge without any single person ever holding it in their head. That finding is unwriteable under current norms, because it indicts the merge policy rather than a human. The first company to write it down anyway will have named the actual failure mode of this era of software, and the fix will not be a better model.\n\n***\n\n*Way Enough is written collaboratively by a human and an AI agent.*\n\n[^1]: https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/","publishedAt":"2026-08-04T12:00:00.000Z","shortContent":"***\n\nOutput is the cheapest thing in a software organization now, and comprehension is the most expensive. Which means the useful question about any artifact is no longer where it came from but who paid to understand it — and a practice has quietly formalized for avoiding that bill. Paste the model's answer, send it onward, let the next person work out whether it's true. The effort doesn't disappear. It moves, to someone with less context, at a higher price.\n\n***\n\n## The Relay\n\nGruhn's [complaint](https://gruhn.me/blog/2026-08-03/) is small and domestic: he asks a question in Slack, leaves feedback on a pull request, argues with friends in a group chat, and gets back a giant verbatim block prefixed with \"Claude said.\" His objection isn't purity. It's that the transaction is worthless to him. \"I can talk to Claude myself. It's going to be faster and I get to control the context.\"\n\nControl of the context is the whole thing. What determines whether a model's answer is any good is what was in the window when it produced it — the question actually asked, the files it had, the three turns where it went wrong and got corrected. Relaying amputates all of that and delivers the confident prose with none of the conditions that would let you evaluate it. The recipient can't check the reasoning because the reasoning wasn't sent, and running the question themselves against context they actually hold is both cheaper and more likely to be right. The relay isn't neutral. It's worse than silence.\n\nThen there's the register. Gruhn quotes one sentence he was handed: \"NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.\" He had to look up nearly every word. It may well be entirely correct — the density is the problem regardless. A human writes that compressed only after earning a shared vocabulary with the reader; a model writes it by default, because compression is free and it has no model of who's listening. Fluency used to be weak evidence that someone understood the thing. It's now evidence of nothing at all.\n\nThe group-chat case makes the social version obvious. You outsource your side of an argument to a machine, and now nobody in the room holds a view anyone can push on.\n\n## Authorship Migrates\n\nThe code review scenario is where this stops being an etiquette question. Copy the ticket description into Claude Code. Don't read the output. Open the PR. When the reviewer leaves comments, paste those in too. Iterate until it merges. Gruhn's point is that this works — and then: \"who has done the implementation? The reviewers did, using Claude Code, and you as a meat proxy.\"\n\nThat's a claim about accountability, not productivity. Every consequential judgment in that loop was made by the reviewer. They read the diff, found what was wrong, and specified the fix; the model executed; the nominal author supplied routing. The commit history records the opposite. It names someone who cannot answer a question about the code, and says nothing about the person who actually decided what it should do — who was never asked to take that role and has no record of having taken it.\n\nCompare the honest version. When an AI contributor became Bun's top committer, git blame said so, and the argument about whether that was fine could at least be held in the open. The relay produces a worse artifact: a history that looks entirely human and is entirely wrong about who understood what. The bill comes due at 2 a.m., when the org routes the incident to the last committer and finds a router. Whatever comprehension exists sits with the reviewer, in fragments — the parts they objected to, not the parts they waved through.\n\n## The Bottleneck Was Always Review\n\nNone of this contradicts the throughput claims; it explains where they go. A year ago Colton Cade did the arithmetic on 10x productivity and landed on the human loop as the binding constraint — tag the reviewer, wait, context-switch, read the comments, respond, repeat. \"You can't compress the back and forth of 3 months of code review into 1.5 weeks.\"[^1] Generation got fast. That loop did not. The relay is what a system does when one stage speeds up and the stage after it can't: work doesn't compress, it displaces.\n\nIt also explains why the experience reports still refuse to reconcile. Dmitriid's [inventory of what we never learn](https://dmitriid.com/everything-around-llms-is-still-magical-and-wishful-thinking) from any given testimonial — which project, which codebase, what expertise, how much reviewing and fixing came after — established that these accounts aren't comparable. Add the transfer and they're not even about the same person. The author's throughput genuinely rose. The reviewer's fell, absorbing the reading the author skipped, plus the reconstruction of context they were never given. Both describe the same merged commit accurately and reach opposite conclusions about the tool. Any measurement scoped to an individual will find the speedup and miss who paid for it.\n\n## The Instruments Assumed a Reader\n\nA year ago the industry's answer to this class of failure was better instruments. Sketch.dev published a clean post-mortem on its [first outage from LLM-written code](https://sketch.dev/blog/our-first-outage-from-llm-written-code): during a refactor, a `break` became a `continue`, turning error handling into an infinite loop. The cause was mundane and specific — agents move code by writing a deletion patch and an insertion patch rather than cutting and pasting, which leaves room for transcription error, and here the surrounding comment said \"but continue\" while the code said `break`. Local prediction beat transcription. Their fixes followed the diagnosis exactly: give the agent a clipboard so code moves byte-for-byte, and get git to detect change across hunks, not just across files, because \"it's very easy to miss important changes in a sea of green and red that's otherwise mostly identical.\"\n\nEvery one of those remedies is built for a person who is looking. The change was small enough inside a large code movement that it slipped past human review. The human was there, reading, and lost it.\n\nTwelve months later the failure being described has no reader in it anywhere. Better diff tooling buys nothing when the author never opened the diff and the reviewer's comments are being fed straight back into the thing that wrote it. We spent the year sharpening instruments for a verification step that a growing share of teams quietly stopped performing.\n\nWhich is why Gruhn's remedy is deliberately unimpressive: read it, understand it, validate it, then write the response in your own words — \"a decent certificate that you've done the prior steps.\" Not a provenance standard, not a signature scheme. Earlier editions here followed costly-signal verification to its spiral, where every proof of care gets forged as fast as it's invented. That's a problem among strangers. Inside a team of eight it doesn't arise, because rewriting in your own words isn't proof of anything — it's just the cheapest available act that can't be performed without having read, and the follow-up question arrives tomorrow from someone who sits next to you.\n\n***\n\n## What to Watch\n\n**Whether anyone starts measuring the receiving end.** Every dashboard in this space counts what gets produced: commits, PRs, tokens, cycle time from open to merge. None of them count reading, which is now where the displaced work lives, and none can distinguish a reviewer who approved a diff from one who authored it through a proxy. The first tell will be an organization that instruments review as load rather than latency — time-to-comprehend, not time-to-approve — and discovers a small number of people carrying a codebase nobody else has read. The second tell is uglier and will show up in a post-mortem: an incident where the question \"who understood this change\" returns nobody, and the honest root cause is a process that let a commit merge without any single person ever holding it in their head. That finding is unwriteable under current norms, because it indicts the merge policy rather than a human. The first company to write it down anyway will have named the actual failure mode of this era of software, and the fix will not be a better model.\n\n***\n\n*Way Enough is written collaboratively by a human and an AI agent.*\n\n[^1]: https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/"}}