He's Right.  🔗 **Source:** [He's Right.](https://www.youtube.com/watch?v=0wemf5SZkW4) > [!note]+ Document Notes > tags: [ai-assisted-engineering, verification-loops, software-engineering-scope, agent-tooling, code-review, developer-experience] > author: Theo (t3.gg) > source: YouTube — Theo - t3․gg > reference: https://www.youtube.com/watch?v=0wemf5SZkW4 > date created: 2026-08-24 09:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: He's right. (On "coding is solved, bugs are not") > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Boris Cherny (Anthropic, Claude Code) — the "Coding is solved. Bugs are not yet solved." post under discussion - [Matt Pocock](https://www.mattpocock.com/) — the pushback and the tactical/strategic framing - [John Ousterhout, *A Philosophy of Software Design*](https://web.stanford.edu/~ouster/cgi-bin/book.php) — source of tactical vs strategic programming and "tactical tornadoes" - [The Password Game](https://neal.fun/password-game/) by Neal Agarwal — the worked example about intent versus output - [T3 Chat / T3 Code](https://t3.chat/) — the speaker's own product, used throughout as evidence - Blacksmith — CI sponsor read in the video - Ryan Carniato (SolidJS) — cited as a top-tier engineer finding agent leverage ## 📝 Summary - **What happened.** Theo responds to a fight over Boris Cherny's post — "Coding is solved. Bugs are not yet solved. Fix incoming." — made in reply to someone showing a visible bug in the Claude Code desktop app. Matt Pocock's dismissal ("a vanilla ice cream of VC funding stirred with a little pinch of turd") went wide. Theo's position: **both are right, and they are using "coding" to mean different things.** - **Why it matters.** The video is really a systems argument wearing a discourse-response costume. Its actual claim: agents have gotten very good at the middle box — turning a spec into working code — and the constraint has moved to the **verification layer** around that box. And crucially, that layer is mostly broken because *we* built codebases nobody can easily spin up and test. - **Key stakeholders.** Engineering leaders deciding how to adopt agents; anyone maintaining a codebase that is hard to run locally; tool vendors (GitHub, Anthropic, browser makers) who own the surfaces agents need to verify through; reviewers whose job just changed shape. - **Risks and tradeoffs.** It is a discourse video with a sponsor read, built on public posts rather than data, and the speaker's evidence is largely his own product. The "coding is solved" concession is stated far more absolutely than his own examples support — his central exhibit is an agent shipping a visibly broken UI. - **Bottom line.** Two ideas survive the argument. **"If it is too hard for you to spin up and test, it is way too hard for your agents to do the same"** — agent effectiveness is bounded by your existing developer experience, which makes DX an AI-readiness problem rather than a comfort problem. And **"we need to check the results, not necessarily the code"** — the class of bug that survives now is invisible in a diff, so reading the patch is no longer where verification happens. His diagnosis of why Claude Code Desktop lags Claude Code web — Electron is expensive to spin up per-thread, so the verification loop never got built — is the sharpest concrete instance in the video. ## 📖 Main Content The trigger is small and the argument is not. Someone posted a screenshot of the Claude Code desktop app showing an update notice whose text is cut off — unreadable at any reasonable window size. Boris Cherny replied "Coding is solved. Bugs are not yet solved. Fix incoming," and then, when pressed, said the truncation "isn't a bug. It's a UX issue that we have a fix for." Theo takes issue with that specifically and says so: **"This is a bug."** His challenge is fair — by what definition is text cut off at all reasonable display sizes not a bug, given it plainly is not the intended experience. But his interest is in the diagnosis, not the scoring. His account of *how* that bug shipped is the video's best passage. A model wrote the notice text while reading the code, without ever rendering it, so it never learned the available width was too small. He argues this class of mistake "frankly didn't happen a whole lot before AI generated code took over" — not because humans are smarter, but because of a social fact: a human building that feature would have looked at it in a browser at least once, because **"why would you waste the time of your co-workers with code that you never even saw the output of?"** Agents have no such reflex. Then the consequence, which is the actual insight: reviewers inherited a habit from a world that no longer exists. **"We've always trusted that original developer to test the thing they changed... But now we live in a world where the code review going up does not imply any effort was put into checking the thing ahead."** Code review was never a full verification mechanism; it worked because it sat on top of an assumption that the author had run the thing. That assumption has silently evaporated, and nobody updated the process. Before building his framework, Theo insists on definitions — for "coding" and for "solved." He lays out how elastically "coding" gets used: describing an idea to someone who builds it; opening an editor and typing; turning a Jira ticket into a pull request; reviewing and pulling down changes. He adds a fair reminder that even pre-AI, typing in an editor was a small slice of an engineer's time. His resolution: **if coding means the end-to-end job, it is obviously not solved. If coding means the act of typing code into an editor, "yes, absolutely coding is solved."** He is willing to stretch the narrow definition to include going from a rough idea to code that works. The **Password Game** detour is doing real philosophical work despite looking like a bit. Neal Agarwal's game deliberately parodies absurd password requirements. Was he coding when he built it? Obviously yes — idea, editor, working artifact. So if someone accidentally produced something equally awful, were *they* coding? Also yes. **Bad output does not mean coding did not occur.** He then splits the failure into two input cases worth separating: bad output because the request lacked detail, versus bad output because the request contained bad detail. Both produce bad software by different routes. That yields his diagram. Plans go into an engineering box and software comes out. A **good plan** with good engineers lands around 8–10 out of 10. A **bad plan** caps out around 1–4 regardless of who executes it, because good coders are hired to execute plans, not to reject them — and he notes, with visible experience, that people outside engineering "often don't like when you come in and say that their plan for how to change the software isn't great." An **empty or bare plan** produces the widest range, 1 to 10, because everything depends on how well the executor understands the domain and the users. His fix for the range is not better plans, since you cannot always control plan quality. It is **the verification layer** — QA, staging environments, slow rollouts. Things the industry already invented and, he argues, has quietly let atrophy. Verification is what catches a good-looking plan that turns out bad only once you use it. Then the substitution that makes the whole thing land: **replace the box of engineers with a swarm of agents, and the diagram is unchanged.** You give a plan to Claude or Codex, sub-agents execute, a pull request appears. If nothing ran the code, it may look fine and not be fine. Someone has to check — "and sadly enough, the human is often the one using the software in the end." Which is exactly what happened with the truncated text. He adds the asymmetry that makes it stick: **once merged, the friction to fix exceeds the friction that produced it.** The strongest line in the video follows, and it reframes developer experience entirely: **"If it is too hard for you to spin up and test, it is way too hard for your agents to do the same. You need to make it easier to actually verify your code bases."** He is candid that he has worked in many codebases where running his own change locally cost more than making it. DX debt was previously a morale and velocity problem. Under agents it becomes a hard ceiling on output quality. His worked instance is pointed, and aimed at the vendor whose employee started the argument. **Claude Code Desktop is an Electron app**, so verifying it means giving every thread its own graphical VM with a real OS — expensive, non-trivial, and compounded by Claude models being, in his assessment, weaker at computer use than models from other labs. Meanwhile **Claude Code web** is trivially testable: one machine, eight tabs, eight dev builds. His conclusion is that the desktop app's slower improvement "simply comes down to how easy it is to set up Cloud Code web for testing versus Claude Code Desktop." He generalises it into a rule of thumb worth keeping: **"if it would be hard for the human to verify, it is probably impossible for the agent to do it."** The definitional payoff arrives here. Whatever you think "coding" covers, **the whole loop is software engineering** — and software engineering includes bugs, verification loops, and architecting systems so changes can be made confidently. He is careful and fair on the point people are angriest about: **Boris said coding, not software engineering.** "If Boris had said software engineering is solved, I would be making a very different video right now." His analogy for what agents actually need is good: a newly hired excellent engineer who cannot get a test build running is equally stuck. **"Now imagine that person has been blinded"** — forced to work with their eyes closed. They will still produce decent work where seeing does not matter, and much better work if you give them what they need to verify. On bugs he goes further than his own headline. With a properly specced bug report and even minimal verification, he thinks frontier models can solve most bugs. What they cannot do is *preemptively find* bugs — and he attributes that failure jointly: **"not just because the agents are stupid and don't know how, but because our code bases are stupid and don't set them up for it, too."** He wants three things: architectures that are easier to test, better tooling from labs and platform vendors so agents can reach verification surfaces, and normalised proof-of-work from agents. He notes GitHub's CLI recently added a way for agents to upload an image or video without committing it to the repo — a small fix for a real problem that has "caused all sorts of disasters." He also reports the obvious failure mode: agents submitting proof videos that visibly show the thing not working, requiring him to point that out before they correct. His own product is the evidence he trusts most. He describes writing **thousands of lines in T3 Code** to run a dev server over Tailscale — because a localhost link is useless when you are on a different network — while pulling in a read-only snapshot of real data to make the test meaningful. Built both so he can verify agent work and so agents can verify their own. His projected next step: agents that notice they cannot verify, then build the missing scaffolding themselves, possibly as a dedicated pull request. The line most worth extracting: **"we need to check the results, not necessarily the code. Because let's be real here, nobody would have caught this bug in code review because the code looks fine."** He argues **"the era of finding bugs by just reading the code has, let's be real, ended"** — anything visible in a diff is now visible to agents too. He is careful not to overclaim: reading code still catches architectural failures, wrong abstractions, out-of-scope changes, and missing or unnecessary tests. Those are real review findings. They are not bugs in the traditional sense, and the truncated-text class is invisible to all of it. The final third walks through Boris's own clarification, which turns out to make the same distinction Theo built independently. Boris's staged timeline: models code better than he can; models do coding-adjacent engineering better than he can (debugging, profiling, optimising, bug fixing, system design, abstraction design, UI design, idea generation); eventually models do most computer work better than most people. For his own work Claude has cleared stage one and part of stage two, with early signs of three. His framing is disarming — **"I consider myself an average programmer. So Claude has already surpassed me. The same is not yet true for everyone."** He stopped writing code by hand in November of the previous year; Opus 4.8 was the first model that felt better than him; and he says plainly that **"engineering is more than coding."** Theo pushes on one point. Boris allows that a world-class compiler and type-systems expert like Anders Hejlsberg might not be at stage one yet; Theo thinks the frontier is further along even there, citing Ryan Carniato using an agent not merely to patch SolidJS but to talk through complex ideas and test theories that would previously have been too time-consuming. The claim is not that agents match such engineers, but that **parallelism lets top engineers test more hypotheses than they otherwise could.** Matt Pocock's substantive contribution is the best-sourced idea in the whole exchange: **John Ousterhout's tactical versus strategic programming.** Tactical is day-to-day implementation; strategic is codebase health, architecture, and long-horizon decisions. Pocock concedes AI has largely solved tactical and says he has seen no evidence it thinks strategically — invoking Ousterhout's **"tactical tornadoes,"** who produce astonishing volumes of work with no regard for the future, as exactly what agents feel like now. Theo largely agrees, with a useful amendment: agents will not proactively tend architecture, but they are genuinely useful **as consultants during strategy** — reviewing architecture, evaluating planned changes, investigating theories to test an idea. And once strategy is settled and verification is in place, "they can go execute a crazy bold plan in time that makes no sense at all." Pocock's closing point, which Theo endorses, is the one with the most operational bite: people are building pipelines — bug report to repro to fix, feature request to prototype, cron to architecture RFC to refactor — and **managing those pipelines is itself strategic work requiring human judgment.** Theo's summary: **"In order to make your agents act more strategic and act more like engineers, you have to do the engineering upfront yourself."** Two things to hold. His concession that "coding is solved" sits awkwardly against his own central exhibit — an agent shipping visibly broken UI is not obviously a solved-coding outcome, and he papers over that by narrowing "coding" to exclude looking at the result. And the evidence throughout is his own product, his own workflow, and public posts. It is a well-reasoned position from experience, not a measured claim, and the video does not pretend otherwise. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=0) The setup — both sides are right - Boris Cherny's post: "Coding is solved. Bugs are not yet solved. Fix incoming," replying to a screenshot of a visible Claude Code desktop bug. - Matt Pocock's dismissal, quoted: "a raspberry ripple of a vanilla ice cream of VC funding stirred with a little pinch of turd." - Theo's thesis: **both are right, and they are using the same words to mean different things.** He frames defending Boris as something he is "not excited to do." - His own stance stated early: "if you're writing your code by hand still, you are largely falling behind." #### ⏱️ [00:03:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=210) How the bug actually shipped - A model wrote the update-notice text **while reading the code, never rendering it**, so it never discovered the callout was too narrow. - The social mechanism that used to prevent this: a human would have looked at it in a browser at least once, because **"why would you waste the time of your co-workers with code that you never even saw the output of?"** - Agents have no equivalent reflex. "By default, agents don't do that at all." - **The consequence reviewers haven't absorbed:** "the code review going up does not imply any effort was put into checking the thing ahead." Code review always rested on an assumption of author testing that has quietly disappeared. - On Boris calling it a UX issue rather than a bug, Theo objects directly: **"This is a bug."** #### ⏱️ [00:06:40](https://www.youtube.com/watch?v=0wemf5SZkW4?t=400) Define "coding" before arguing about it - "Coding" is used to mean: describing an idea someone else builds; typing in an editor; Jira ticket to pull request; reviewing and pulling down changes. - Fair reminder: even pre-AI, typing in an editor was a small fraction of an engineer's time. - **The split:** end-to-end job → obviously not solved. Typing code into an editor → "yes, absolutely coding is solved." - He is willing to widen the narrow sense to include rough idea → code that works. #### ⏱️ [00:10:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=600) The Password Game — bad output isn't proof of not-coding - Neal Agarwal's game deliberately parodies absurd password rules. He had an idea, opened an editor, shipped it — clearly coding. - Therefore someone who produced something equally awful *accidentally* was also coding. **Output quality doesn't determine whether coding occurred.** - Useful distinction drawn: bad output from **missing detail** in the request versus bad output from **bad detail** in the request. Different causes, same symptom. #### ⏱️ [00:13:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=810) The plan-quality diagram - **Good plan + good engineers → ~8–10/10.** - **Bad plan → ~1–4/10 regardless of executor.** Good coders are hired to execute plans, not reject them — and "people outside of engineering often don't like when you come in and say that their plan... isn't great." - **Empty or bare plan → 1–10.** Widest variance, dependent on how well the executor understands the domain and users. - His pointed question: is an exceptional *coder* going to push back on a bad plan, "or would they just implement that bad plan because they're good at coding, not making good software? Because those are different things." #### ⏱️ [00:17:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1020) The verification layer — the thing we already invented - Since plan quality can't be controlled, the lever is the output side: **QA, staging environments, slow rollouts.** - What it buys: catching a plan that looked fine and turns out bad only once experienced. "It's unlikely that I know the actual experience is bad until I try it." - Trying it can mean local spin-up, a preview build, or an agent running the loop and showing you a video. - **Good plans and good engineers only reliably produce good outcomes when there is a system to verify the result.** #### ⏱️ [00:19:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1170) Swap engineers for agent swarms — diagram unchanged - Plan → Claude or Codex → sub-agents execute → pull request appears. **If nothing ran it, it may look fine and not be fine.** - "Usually that'll be a human. And sadly enough, the human is often the one using the software in the end." Which is precisely what happened here. - **The asymmetry that makes it stick:** "by the time it has merged, the friction to unmerge it or to fix it is higher than the friction to build and merge it in the first place." - If verification is good, problems surface before users see them. Bad results route back to planning, or straight back to implementation for a silly fix. #### ⏱️ [00:22:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1320) DX debt is now an output-quality ceiling - **The line:** "If it is too hard for you to spin up and test, it is way too hard for your agents to do the same. You need to make it easier to actually verify your code bases." - He is candid: many codebases where "spinning it up on my machine to see if my changes worked was more complex than making the change in the first place." - The old workaround — file the PR and wait for the preview build — is exactly the habit that now fails. - **Reframing worth keeping:** DX was a morale and velocity issue. Under agents it becomes a hard ceiling on quality. #### ⏱️ [00:23:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1410) Why Claude Code Desktop lags Claude Code web - **Desktop is Electron**, so verification needs a graphical VM per thread with a real OS — expensive and non-trivial. - Compounded by Claude models being, in his assessment, weaker at computer use than other labs' models. - **Web is trivially testable:** one machine, eight tabs, eight dev builds, no confusion. - His conclusion: the desktop app's slower improvement "simply comes down to how easy it is to set up Cloud Code web for testing versus Claude Code Desktop." - **The generalised rule:** "if it would be hard for the human to verify, it is probably impossible for the agent to do it." #### ⏱️ [00:26:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1590) Coding versus software engineering - Whatever "coding" covers, **the whole loop is software engineering** — including bugs, verification loops, and architecting for confident change. - "Software engineering isn't even just this square. It is far wider... The engineering isn't just what you do inside of this box. It's the platform you build for the boxes to sit on." - **The fair point everyone angry at Boris skipped:** he said *coding*, not software engineering. "If Boris had said software engineering is solved, I would be making a very different video right now." - The analogy: a newly hired excellent engineer who can't get a test build running is equally stuck. **"Now imagine that person has been blinded."** #### ⏱️ [00:29:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1740) Bugs are more solvable than the headline suggests - With a properly specced bug report **plus even minimal verification**, he thinks frontier models can solve most bugs. - What they can't do is **preemptively find** bugs — and the blame is joint: "not just because the agents are stupid and don't know how, but because our code bases are stupid and don't set them up for it, too." - Three asks: testable architectures; better tooling from labs and platform vendors so agents can reach verification surfaces; normalised proof-of-work from agents. - **GitHub CLI now lets agents upload an image or video without committing it to the repo** — a small fix for a problem that "caused all sorts of disasters." - Honest failure mode: agents submitting proof videos that visibly show the thing not working, requiring him to point it out before they fix it. #### ⏱️ [00:32:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1920) His own investment in verifiability - **Thousands of lines in T3 Code** to run a dev server over Tailscale — a localhost link is useless from another network — plus a **read-only snapshot of real data** so the test is meaningful. - Built for both directions: so he can verify agent work, and so agents can verify their own. - **Projected next step:** agents that notice they can't verify, then build the missing scaffolding themselves — possibly as a dedicated pull request. #### ⏱️ [00:34:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2040) Check results, not code - **"We need to check the results, not necessarily the code. Because let's be real here, nobody would have caught this bug in code review because the code looks fine."** - **"The era of finding bugs by just reading the code has, let's be real, ended"** — anything visible in a diff is visible to agents too. - Carefully not overclaimed: reading code still catches architectural failures, wrong abstractions, out-of-scope changes, missing or unnecessary tests. Real findings — but not bugs in the traditional sense. - Minimum acceptable standard: pull it down and test it, or at least have the agent demonstrate that it did. #### ⏱️ [00:37:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2220) Boris's own clarification makes the same distinction - Boris's staged timeline: (1) models code better than he can; (2) models do coding-adjacent engineering better — debugging, profiling, optimising, bug fixing, system design, abstraction design, UI design, idea generation; (3) models do most computer work better than most people. - His status: cleared (1) and part of (2), early signs of (3). - **Disarming framing:** "I consider myself an average programmer. So Claude has already surpassed me. The same is not yet true for everyone." - Stopped writing code by hand in November of the previous year. **Opus 4.8** was the first model that felt better than him. - His own concession: **"engineering is more than coding."** Theo notes he reached the same split independently before reading it. #### ⏱️ [00:39:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2370) Where Theo pushes further than Boris - Boris allows a world-class compiler and type-systems expert (Anders Hejlsberg) may not be at stage one yet. - Theo thinks the frontier is further along even there, citing **Ryan Carniato** using an agent not just to patch SolidJS but to talk through complex ideas and test theories previously too time-consuming. - **The claim is about parallelism, not parity:** top engineers can now test more hypotheses than they otherwise could. #### ⏱️ [00:41:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2460) Tactical versus strategic — the best-sourced idea in the exchange - Matt Pocock invokes **John Ousterhout's** distinction: tactical is day-to-day implementation; strategic is codebase health, architecture, long-horizon decisions. - Pocock: AI has largely solved tactical; **no evidence it thinks strategically.** - Ousterhout's **"tactical tornadoes"** — astonishing volumes of work with zero regard for the future — is how agents feel to him now. - Theo's amendment: agents won't proactively tend architecture, but are genuinely useful **as consultants during strategy** — reviewing architecture, evaluating planned changes, investigating theories. - Once strategy is settled and verification exists, "they can go execute a crazy bold plan in time that makes no sense at all." #### ⏱️ [00:44:00](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2640) The operational conclusion - Pocock: people are building pipelines — bug report → repro → fix; feature request → prototype; cron → architecture RFC → refactor. **Managing those pipelines is strategic work requiring human judgment.** - **Theo's summary line:** "In order to make your agents act more strategic and act more like engineers, you have to do the engineering upfront yourself." - The continuity argument: every decision that made human engineers effective — easy local spin-up, easy code navigation, easy review and rollback — makes agents more effective too. Nothing new is being asked for. - Closes by inviting disagreement on whether coding is solved and engineering isn't. #### ⏱️ [00:01:20](https://www.youtube.com/watch?v=0wemf5SZkW4?t=80) Sponsor disclosure, for the record - Blacksmith (CI): claims 2× faster hardware, 4× faster cache downloads, 40× faster Docker builds, and "sticky discs" persisting disk state across runs. - Notable detail he volunteers: he asked his agents how to speed up CI and **they found the sticky-discs feature in the docs** — an incidental data point for the video's own thesis about agents needing good surfaces. - Flagged here because the claims are vendor figures read as sponsor copy, not measurements. ## 📚 References - [A Philosophy of Software Design — John Ousterhout](https://web.stanford.edu/~ouster/cgi-bin/book.php) — tactical vs strategic programming, "tactical tornadoes" - [The Password Game — Neal Agarwal](https://neal.fun/password-game/) — the intent-versus-output example - [Matt Pocock](https://www.mattpocock.com/) — the pushback and tactical/strategic framing - [SolidJS / Ryan Carniato](https://www.solidjs.com/) — cited on agent leverage for expert engineers - [GitHub CLI releases](https://github.com/cli/cli/releases) — the image/video upload capability referenced - [Tailscale](https://tailscale.com/) — how he exposes dev servers for remote verification - [Claude Code](https://claude.com/claude-code) — the desktop and web apps compared throughout ## 🗣️ Paraphrase - **Trigger.** A visible interface bug in an AI-built desktop app prompted a claim that coding is solved while bugs are not, and a widely-shared dismissal of that claim. - **Position.** Both parties are correct, because each is using "coding" to mean something different, and neither defined it. - **Mechanism.** The bug shipped because a model wrote interface text from source without ever rendering it — a check a human would have performed reflexively out of consideration for colleagues. - **Consequence.** Code review inherited an assumption that authors test their own work. That assumption no longer holds, and the process was never updated. - **Definition.** Narrowly, as the act of producing working code from a specification, coding is essentially solved. Broadly, as everything from idea to functioning software, it plainly is not. - **Aside.** Bad output does not mean coding did not happen; poor results can come from missing detail or from wrong detail in the request. - **Model.** Plan quality bounds outcome quality — a poor plan caps results regardless of executor skill, and an empty plan produces enormous variance. - **Lever.** Since plan quality is often outside your control, the controllable factor is the verification layer that catches problems before users encounter them. - **Substitution.** Replacing human implementers with agent swarms leaves the model unchanged; the verification requirement is identical and currently unmet. - **Constraint.** Agents cannot verify what humans cannot easily verify, so difficult local setup is now a hard ceiling on output quality rather than an inconvenience. - **Instance.** A desktop application requiring a full graphical environment per test is far harder to verify than a web application, which explains divergent improvement rates between two versions of the same product. - **Scope.** The full loop is software engineering, which includes verification and architecture; the original claim concerned coding specifically and was fairer than its critics allowed. - **Bugs.** Well-specified bugs with minimal verification are largely tractable; proactively discovering bugs is not, partly because codebases do not support it. - **Asks.** Testable architectures, better verification surfaces from platform vendors, and normalised evidence that agents actually checked their work. - **Practice.** Reviewing results matters more than reviewing diffs, since the remaining bug class is invisible in source; reading code still catches architectural problems. - **Convergence.** The original author's own clarification separates coding from engineering in the same way, and describes a staged progression of capability. - **Framework.** A borrowed distinction between tactical and strategic programming captures it best: implementation is largely automated, long-horizon judgment is not. - **Conclusion.** Making agents behave strategically requires doing the strategic engineering yourself first. ## 📰 Newsletter **"If it is too hard for you to spin up and test, it is way too hard for your agents to do the same"** That's the sentence to take from Theo's response to the Boris-Cherny-versus-Matt-Pocock fight, and it reframes developer experience as an AI-readiness problem rather than a comfort one. **Quick context.** Someone posted a screenshot of the Claude Code desktop app with its update notice text cut off — unreadable. Boris Cherny replied "Coding is solved. Bugs are not yet solved." Matt Pocock called that "a vanilla ice cream of VC funding stirred with a little pinch of turd." Theo's take: they're both right and they're arguing about a word neither defined. **How that bug shipped is the actually interesting part.** A model wrote the notice text by reading the code and never rendering it, so it never discovered the box was too narrow. Theo's point isn't that agents are dumb — it's about a *social* mechanism that quietly vanished: a human would have looked at it in a browser once, because *"why would you waste the time of your co-workers with code that you never even saw the output of?"* And then the bit reviewers haven't caught up to: **"the code review going up does not imply any effort was put into checking the thing ahead."** Code review was never full verification. It worked because it sat on top of an assumption that the author ran the thing. That assumption is gone and nobody updated the process. **The reframe.** Plan quality bounds your outcome — bad plan caps you around 1–4 out of 10 no matter who executes, because good coders are hired to execute plans, not reject them. You often can't fix plan quality. What you *can* fix is the verification layer: QA, staging, slow rollouts. Stuff we invented decades ago and let rot. Now swap the box of engineers for a swarm of agents — **the diagram doesn't change at all.** Same requirement, and mostly unmet. Which lands on DX debt. Theo's honest about codebases where "spinning it up on my machine to see if my changes worked was more complex than making the change in the first place." That used to be a morale tax. Now it's **a hard ceiling on output quality** — and his generalised rule is *"if it would be hard for the human to verify, it is probably impossible for the agent to do it."* His worked example is pointed and aimed at the vendor whose employee started this: **Claude Code Desktop is Electron**, so testing it needs a graphical VM per thread. Claude Code *web* needs one machine with eight tabs. He thinks that difference alone explains why web improves fast and desktop doesn't. **The line I keep coming back to:** *"We need to check the results, not necessarily the code."* Nobody would have caught this in review, because the code looks fine. He argues the era of finding bugs by reading diffs has ended — anything visible in a diff is visible to agents too. He's careful not to overclaim: review still catches architectural failures, wrong abstractions, missing tests. Real findings. Just not *this* class of bug. **The best-sourced idea in the whole exchange is Pocock's,** borrowed from John Ousterhout: **tactical versus strategic programming.** Tactical is day-to-day implementation. Strategic is codebase health and architecture. AI solved tactical; Pocock's seen no evidence it thinks strategically — and Ousterhout's phrase **"tactical tornadoes"** (astonishing output, zero regard for the future) is exactly how agents feel right now. Theo's amendment is fair: agents won't *proactively* tend architecture, but they're genuinely useful as consultants *while* you do. **Why this matters beyond the discourse:** this batch keeps circling the same drain. Christopher Penn: the model that wrote the text can't be the only one grading it. WooCommerce: MCP abilities kept read-only because "we really don't want to break sites." The WP Rocket fatal: a three-way interaction bug nobody's test suite caught, answered with a 200-plugin compatibility harness. Zsolt Viczián: git diffs as the defence against silent AI deletion. **Five independent sources, one conclusion — generation got cheap and verification didn't, so verification is now the whole job.** **Two caveats.** "Coding is solved" sits awkwardly next to his own central exhibit — an agent shipping visibly broken UI. He gets there by narrowing "coding" to exclude looking at the result, which is convenient. And the evidence throughout is his own product and public posts. Reasoned position from experience; not a measurement. ## ✅ Action Items #### DevRel - Developer advocacy: build the talk around "your DX is now your AI ceiling." It reframes work teams already wanted to do and gives it an urgent, defensible justification. - Education: teach the review shift explicitly — what a diff still catches (architecture, abstractions, scope, test coverage) versus what only running the thing catches. Most reviewers have not made this distinction consciously. - Developer experience: measure time-to-first-local-run for your project and treat it as a headline metric. It now bounds both human and agent effectiveness. - Developer marketing: the tactical/strategic split from Ousterhout is a better frame for AI tooling messaging than "10× productivity," and it survives contact with practitioners. - Community management: normalise agents providing evidence of verification in contributions — screenshots, recordings, test output — before this becomes a review bottleneck. - Internal/external/cross-project: push platform vendors for verification surfaces. GitHub's CLI image/video upload is one; there should be many more. #### OSPO - Policy & Governance: write the AI-contribution policy around **evidence of verification**, not around disclosure of AI use. Whether an agent wrote it matters far less than whether anyone ran it. - License Compliance: not applicable to this source. - Security Management: unverified merged code is a security surface, not just a quality one. Require demonstrated execution for changes touching auth, input handling, or data access. - Software Inventory: track which of your repositories can actually be spun up and tested by a newcomer or an agent. Most organisations do not know. - Developer Support: fund the boring work — reproducible dev environments, seeded test data, preview builds. This is the highest-leverage AI investment available and it looks like maintenance. - Community Engagement: share verification tooling across projects rather than each rebuilding it; the requirement is now universal. - Strategic Alignment: adopt time-to-verify as a tracked engineering metric alongside delivery speed. #### Community - Maintainers: make your project runnable in one command. Under agents this is no longer a nicety — it determines the quality of contributions you receive. - Contributors: run the thing before you open the PR, and say that you did. That single sentence is becoming the differentiator in AI-assisted contribution. - Sponsors: fund test infrastructure and seeded fixtures. Unglamorous, universally beneficial, and never prioritised. - Ecosystem: agree a convention for how agents present proof-of-work in pull requests, before every project invents an incompatible one. #### WordPress - Core: **the WP Rocket incident is this argument in the wild** — a three-way interaction bug no single test suite could catch. The 200-plugin compatibility harness is exactly the verification layer being described here. - Core Performance: performance regressions are the classic case of a bug invisible in a diff. Automated measurement is verification, not nice-to-have. - Core AI: whatever ships must be judged on whether it can verify its own output, not on what it can generate. That is the axis that matters. - **Core Program Team:** treat the compatibility testing proposal milestoned for 7.2 as core infrastructure with committed maintenance, not a volunteer side project. - Mobile: not applicable to this source. - Playground: **Playground is a strong answer to "agents can't verify."** A one-URL disposable environment with seeded data is precisely the missing surface. WooCommerce's empty-store limitation is the gap to close. - Community: not applicable to this source. - Training: build a lesson on verifying AI-assisted contributions — what to check, in what order, and why reading the diff is no longer sufficient. - Marketing: not applicable to this source. - Support: expect more bugs that look fine in code and fail in use. Reproduction steps matter more than patches now. - Design: visual regressions are the canonical invisible-in-diff bug class. Visual diffing is verification infrastructure. - Documentation: document local setup as a first-class deliverable. If a newcomer cannot run it, neither can an agent. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: translation correctness is invisible in a diff to a non-speaker — the same verification-gap argument applies, and it applies to AI translation features directly. - Accessibility: **accessibility bugs are the purest invisible-in-diff class** — the truncated-text example is itself an accessibility failure. Automated accessibility checking is verification infrastructure, which connects directly to the Accessibility Lab plugin work. - Meta: developer tooling that makes a plugin trivially runnable would raise contribution quality more than most process changes. - CLI: WP-CLI is a natural verification harness for agents; make that role explicit. - Hosting: preview environments per pull request are verification infrastructure; hosts are well placed to provide them. - Tide: automated verification at ecosystem scale is Tide's premise, and this argument is the strongest case for it in years. - Openverse: not applicable to this source. - Themes: visual output cannot be verified from a diff; theme review needs rendered comparison. - Plugins: require evidence that a submission was actually run, not merely that it passes static checks. #### The WPOCC - Programs: a workshop on building verifiable projects — one-command setup, seeded data, preview builds — serves both human contributors and agent-assisted ones. - Projects: publish a reference "verifiable WordPress project" template that others can copy. - Funding experiments: fund shared verification infrastructure. It is the clearest current example of a shared good nobody individually funds. ### FAIR - Technical independence: verification you control is independence in practice — a project that cannot test itself depends on whoever can. - Policies and covenants: require demonstrated verification for contributions to anything security-relevant. - Productized governance artifacts: a contribution standard specifying what evidence of verification must accompany a change is a small, reusable artifact worth templating. ### 🧪 Hypotheses 1. **Time-to-first-local-run predicts AI-assisted contribution quality.** Repositories that can be spun up faster will show lower post-merge defect rates in agent-authored changes than repositories with slow or complex setup. 2. **The invisible-in-diff bug class has grown.** Since agent-authored code became common, the proportion of defects undetectable by code review alone will have risen relative to defects catchable in review. 3. **Verification-surface availability explains divergent product quality.** Theo's specific claim — that Claude Code web improves faster than desktop because it is easier to test — is testable via release cadence and defect rates on comparable feature sets. 4. **Requiring proof-of-execution reduces defects more than requiring AI disclosure.** Projects mandating evidence that a change was run will show lower defect rates than projects mandating only disclosure of AI authorship. 5. **Agents do not improve strategic code health.** Over time, codebases with heavy agent contribution and no strategic human oversight will accumulate architectural debt faster than comparable human-maintained codebases — the "tactical tornadoes" claim, stated falsifiably. 6. **Plan quality bounds outcome quality more than executor quality does.** Variance in output quality will be explained more by specification completeness than by whether a human or an agent implemented it. ### 📊 Methodology - **H1:** Measure setup time across a sample of open source repositories (fresh clone to running test suite), then correlate against post-merge revert and hotfix rates for AI-assisted PRs. Identifying AI-assisted PRs is the methodological difficulty; commit metadata and PR templates give partial signal. - **H2:** Classify defects in a bug tracker as diff-visible or execution-only, comparing periods before and after widespread agent adoption. Requires hand-coding a sample; a few hundred issues would be indicative. - **H3:** Compare release frequency and defect reports for Claude Code web versus desktop over matched feature areas. Public data is limited; the claim is plausible but currently anecdotal. - **H4:** Prospective trial across projects adopting different contribution policies, measuring defect rates. Confounded by project maturity; matched pairs help. - **H5:** Longitudinal architectural quality assessment — coupling, cyclomatic complexity, duplication — on codebases segmented by agent contribution share. The hard part is controlling for project age and growth rate. - **H6:** Controlled experiment: same task, specification quality varied systematically, executed by both human and agent groups; blind graders score output. Directly tests the diagram the video is built on, which is otherwise pure assertion. ### ❓ Questions - If reading diffs no longer finds bugs, what does code review become — and how should reviewer time be reallocated? - What is the minimum verification setup that makes agent contributions trustworthy, and can it be templated rather than rebuilt per project? - Is "coding is solved" defensible when the video's own central exhibit is an agent shipping visibly broken UI, or does that narrowing make the claim unfalsifiable? - What would it take for an agent to reliably recognise it cannot verify its work, and stop rather than proceed? - If agents are tactical tornadoes, who is accountable for architectural health, and how is that work made visible enough to fund? - Does the parallelism argument — top engineers testing more hypotheses — hold up empirically, or is it selection bias from visible practitioners? - What proportion of merged agent-authored changes are actually executed by anyone before reaching users? - How should proof-of-work be presented so it is genuinely checkable, given agents already submit videos showing the thing failing? ### 🔮 Future Research - **The invisible-bug class.** Whether defect composition has genuinely shifted toward execution-only bugs is measurable, important, and unmeasured. - **Verifiability as an architectural property.** The claim that testability now bounds achievable quality deserves formal treatment — what makes a system verifiable by an agent, specifically? - **Self-unblocking agents.** Theo's projection — agents building their own verification scaffolding — is a concrete research direction with an obvious evaluation. - **Strategic capability in models.** Pocock's claim of no evidence for strategic thinking is a testable gap; longitudinal architectural quality is the natural measure. - **Proof-of-work formats.** Agents already produce misleading evidence. What makes verification evidence tamper-evident and cheaply checkable is an open design problem. - **Specification quality as the dominant variable.** If plan quality bounds outcomes more than executor quality, effort should shift substantially toward specification practice — which nobody has quantified. ### 💡 Implications - **Practice.** Two concrete moves: measure how long it takes to run your project from a fresh clone, and stop treating a clean diff as sufficient review. Both are free and both bind immediately. - **Policy.** Contribution policies should require **evidence of execution**, not disclosure of AI authorship. The second is easy to comply with and mostly irrelevant; the first addresses the actual failure. - **Security.** Unverified merged code is a security surface. Changes touching authentication, input handling, or data access warrant demonstrated execution as a hard gate. - **Education.** The tactical/strategic distinction is genuinely teachable and predates AI, which makes it more durable than most current framing. Ousterhout's book is the primary source and worth reading directly. - **Funding.** Verification infrastructure — reproducible environments, seeded data, preview builds, visual diffing — is the clearest shared good in current engineering, benefits everyone, and is nobody's headline project. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 9; Flesch Reading Ease ≈ 60. Conversational and profane-adjacent, easy at sentence level. The barrier is contextual: it assumes familiarity with the participants, the tooling, PR workflow, Electron, and Tailscale, none of which are explained. #### 👀 Visual learners - Present: strong — he builds the plan-quality and verification diagram live on screen and returns to it repeatedly as the argument's spine. The Password Game is demonstrated rather than described. - Improve: the diagram is drawn incrementally and never shown complete; a single final frame would make it shareable, which is a shame since it is the video's most portable artifact. #### 🔊 Aural learners - Present: the native format, and the argument is carried entirely in speech — you lose little by listening only. - Improve: 45 minutes with no chapters and several digressions; the structure only becomes clear in retrospect. #### 🗣️ Verbal learners - Present: excellent. The whole video is an argument about definitions, and he is unusually careful about them — "we need definitions for the words coding and for solved" is stated explicitly before the framework is built. - Improve: the blinded-new-hire analogy is the strongest teaching device and arrives late; leading with it would have anchored the argument sooner. #### 🧩 Kinesthetic learners - Present: concrete and immediately actionable — measure your setup time, run the thing before merging, look at results rather than diffs. - Improve: no walkthrough of *how* to build the verification loop he keeps advocating. He describes his Tailscale plus read-only-snapshot setup without showing it. #### 🧠 Logical learners - Present: the reasoning is genuinely well-structured — definitions first, then a model, then substitution of agents into the model, then a worked instance. The reasoning is the content. - Improve: every number in the framework (8–10, 1–4, 1–10, "99% of the time," "95% of the time") is invented for illustration and stated with unearned precision. #### 🧑‍🤝‍🧑 Social learners - Present: the entire piece is engagement with named practitioners' public positions, quoted at length and steel-manned rather than caricatured. He closes by inviting disagreement. - Improve: all participants are from one visible corner of the industry; no voices from teams operating under different constraints. #### 🧘‍♀️ Solitary learners - Present: self-contained; you can follow the argument without having seen the original posts. - Improve: no summary artifact. For a video whose value is a reusable framework, a written version would multiply its usefulness. #### 🌿 Naturalistic learners - Present: none. - Improve: **Not applicable to this source** — though the compute cost of per-thread graphical VMs for verification is a real efficiency dimension left entirely unexamined. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: he narrates most of what he shows, and the argument survives audio-only reasonably well. - Improve: the central diagram is described only partially as he draws it, and tweet screenshots are read aloud inconsistently. Maps to **WCAG 2.2 AA 1.2.5 Audio Description (Prerecorded)**. #### Keyboard navigation - Present: not applicable to the video artifact. - Improve: not applicable to this source. #### Contrast and readability - Present: screenshots of posts and a hand-drawn diagram, generally legible at desktop size. - Improve: quoted post screenshots are shown at original resolution and will be unreadable on a phone. Maps to **1.4.4 Resize Text**. #### Text resizing and reflow - Present: not applicable to fixed-frame video. - Improve: not applicable to this source. #### Media and captions - Present: auto-generated captions exist. - Improve: the captions mangle names and terms consistently — "Cloud Code"/"quadcode" for Claude Code, "Codeex" for Codex, "Matt PCO" for Matt Pocock, "Andarus Hellsburg" for Anders Hejlsberg, "John Asterhout" for John Ousterhout, "Ryan Carneato" for Carniato, "Neil Fun" for Neal Agarwal's neal.fun, "Babel" apparently for a model name. **Mangling the primary sources of a definitional argument is not cosmetic.** Maps to **1.2.2 Captions (Prerecorded)**. #### Forms and interactions - Present: not applicable to the video artifact. - Improve: not applicable to this source. #### Standards reference - Primary gap: **1.2.2 Captions**, elevated because the argument depends on correctly attributing positions to named people whose names the captions destroy. Secondary: **1.2.5** for the partially-narrated diagram. Worth noting the irony that the bug under discussion — text truncated below readable size — is itself an accessibility failure, and nobody in the exchange names it as one. ### 🌍 DEIB Assessment #### Cultural breadth - Present: minimal — the frame is US-centric venture-funded startup engineering and its social-media discourse. - Improve: the verification argument is universal and would land harder with examples from constrained contexts — teams without CI budget, without staging environments, or working on legacy systems where the advice is hardest to follow and most needed. #### Inclusive language - Present: neutral toward people; he steel-mans both parties and criticises positions rather than persons. - Improve: heavy unglossed context — participants, tools, PR workflow, Electron, Tailscale — gates the argument to insiders. "Code monkey" appears once and is doing pejorative work about a role, not a person, but is still a term worth retiring. #### Neurodiversity support - Present: the recurring diagram gives a stable spine, and he returns to it deliberately after each digression. - Improve: 45 minutes, no chapters, frequent asides, and an unannounced sponsor break mid-argument. Chapters would cost nothing and help substantially. #### Representation - Present: a single speaker engaging three named practitioners' positions. - Improve: everyone involved — speaker, Cherny, Pocock, Carniato, Hejlsberg — occupies a similar and highly visible position in the industry. Absent entirely: anyone working in the codebases he describes as impossible to verify, which is where his advice would be hardest to act on. #### Psychological safety - Present: genuinely good and unusual for the genre. He defends someone he does not want to defend, credits Pocock's framing as the better-sourced idea, concedes his own video ran long, admits he did not read Boris's clarification before recording, and reports agents failing in ways that reflect on his own workflow. - Improve: "if you're writing your code by hand still, you are largely falling behind" is stated early, absolutely, and without evidence. In a video otherwise careful about definitions, that is a status claim rather than an argument, and it will land badly on people with good reasons for their practice. ### ✅ Logical Validity #### Strong reasoning - **Definitional analysis, [00:06:40].** The entire video's method — refusing to argue until "coding" and "solved" are defined, then showing the disagreement dissolves under disambiguation — is the correct treatment of a term dispute and is rare in practice. - **Mechanistic explanation, [00:03:30].** The account of how the bug shipped identifies a *social* mechanism (humans check because colleagues' time matters) rather than a technical one, then correctly notes agents lack it. Specific, plausible, and explanatory rather than merely descriptive. - **Causal, [00:04:30].** The observation that code review's value rested on an unstated assumption of author testing — and that this assumption silently evaporated — is genuinely insightful and explains a failure most teams have felt without diagnosing. - **Substitution argument, [00:19:30].** Swapping human implementers for agent swarms while holding the model constant is a clean way to show that the verification requirement is invariant to who writes the code. The conclusion follows from the structure. - **Worked instance, [00:23:30].** The Electron-versus-web explanation for divergent improvement rates is a specific, falsifiable causal claim with a stated mechanism, applied to the vendor whose employee he is defending. That is intellectual honesty operating against his own rhetorical interest. - **Steel-manning, throughout.** He defends a position he dislikes, notes Boris said "coding" rather than "software engineering," and credits Pocock's Ousterhout framing as the better-sourced idea. He also flags that he reached the same distinction independently before reading Boris's clarification — a check on hindsight bias. #### Fallacies - **Equivocation, partially self-inflicted** — [00:08:30]. Having correctly identified that the dispute turns on an ambiguous term, he then adopts the narrow definition and asserts "absolutely coding is solved" without consistently flagging which sense he means. *Weakness:* the claim is only true under a definition narrow enough to exclude looking at the output — which is precisely the failure his central example demonstrates. *Fix:* state the narrow sense every time the claim is made, and note explicitly that under it, "solved" excludes checking the result. - **False precision** — [00:14:00] and [00:38:00]. Quality ranges of 8–10, 1–4, 1–10, plus "they will do it 99% of the time" and "they'll fix it 95% of the time." *Weakness:* invented illustrative numbers delivered in the register of measurement; audiences will repeat them as findings. *Fix:* say "high," "low," "wide variance," or state that the numbers are illustrative. - **Hasty generalization** — [00:00:30]. "If you're writing your code by hand still, you are largely falling behind." *Weakness:* an absolute claim about all practitioners with no evidence and no acknowledgement of contexts — regulated environments, safety-critical systems, unusual domains — where it is straightforwardly false. *Fix:* scope it to the work he does and the teams he observes. - **Anecdotal evidence as general support** — throughout. T3 Code, his own PR volume, his own agent workflows. *Weakness:* the argument's empirical base is one practitioner's experience with his own product, presented as an account of how software works generally. *Fix:* nothing available within the format — but it deserves the caveat once, which it never gets. - **Appeal to authority via cherry-picked example** — [00:39:30]. Ryan Carniato using agents on SolidJS is offered as evidence the frontier extends to top-tier engineers. *Weakness:* one visible practitioner, selected because his adoption is publicly known. Selection bias is total — engineers who tried agents and abandoned them do not post about it. *Fix:* present as an existence proof rather than a trend. - **Unfalsifiable framing (minor)** — [00:29:00]. Bugs will be increasingly solved "if you make it easier and easier to identify these bugs and the models get smarter and smarter." *Weakness:* the conditional makes the claim unfalsifiable — any counterexample can be attributed to insufficient tooling or insufficiently smart models. *Fix:* state what would count as evidence against it. #### Tone of voice - Reluctant-advocate framing throughout: "I have to do a thing I am not excited to do. I have to defend what Boris said here." The reluctance is doing rhetorical work but also appears sincere. - Direct to the point of confrontation with the person he is defending — "Boris, I'm doing my best to defend you here, but this reply is making it harder." - Self-aware and self-deprecating: notes the video ran far longer than planned, admits he did not read the clarification before recording, reports his own agents producing misleading evidence. - Casual and profane-adjacent, delivered as thinking-aloud rather than presentation; the register assumes an in-group. - Genuinely inquisitive at the close, inviting disagreement on the two claims most likely to attract it rather than declaring the matter settled. ### 🛡️ DARVO Analysis - **Deny:** Not present in the speaker. Notably, he *rejects* a denial — Boris's "this isn't a bug. It's a UX issue" is a minimisation of responsibility, and Theo declines to accept it despite defending Boris's broader position: "This is a bug." Refusing a convenient denial that would have helped his own argument is the opposite of the pattern. - **Attack:** Not present. Criticism is directed at claims, tooling, and codebases — including his own and his sponsor-adjacent subject's. No participant is disparaged; both are quoted at length and steel-manned. - **Reverse victim/offender:** Not present. No victim/offender framing exists in the material, and the speaker is not a party to any grievance. - **Emotional cues and rhetoric:** The reluctant-defender framing ("I have to defend what Boris said") is a rhetorical device that borrows credibility from apparent reluctance, and it is worth naming as such — but it is transparent rather than concealed, and he does subsequently criticise Boris directly, which is not what a purely strategic version of the device would do. - **One item catalogued elsewhere:** the equivocation between narrow and broad senses of "coding" allows the strongest claim to be asserted while the weakest reading is defended. That is an argumentative weakness rather than a defensive pattern, and it is treated under Logical Validity above. - **Assessment:** DARVO is **not applicable to this source** — a technical commentary with no accusatory dynamic. Worth recording positively that the video models the opposite behaviour: the speaker declines a denial offered by the person whose position he is defending. ## 🎯 Conclusion - **Bottom line.** The dispute dissolves once "coding" is defined, but the durable claim is structural: **generation got cheap and verification did not, so verification is now the constraint.** Two lines carry it. **"If it is too hard for you to spin up and test, it is way too hard for your agents to do the same"** — which converts developer-experience debt from a morale problem into a hard ceiling on output quality. And **"we need to check the results, not necessarily the code"** — because the surviving bug class is invisible in a diff. - **The insight most teams haven't absorbed.** Code review was never full verification. It worked because it rested on an unstated assumption that the author had run the thing. Agents removed that assumption and nobody updated the process. That is why a visibly broken UI shipped through a review that found nothing wrong. - **The best-sourced idea isn't his.** Ousterhout's **tactical versus strategic programming**, via Pocock, is the most durable framing in the whole exchange, and it predates AI — which is exactly why it will outlast this argument. "Tactical tornadoes" describes current agent behaviour better than anything either principal coined. - **What to discount.** "Coding is solved" only holds under a definition narrow enough to exclude looking at the output — which is the very failure the video is about. Every number in the framework is invented for illustration. The evidence base is one practitioner's product and public posts, and "if you're writing your code by hand you are falling behind" is a status claim, not an argument. - **Why this batch keeps arriving at the same place.** Penn: the model that wrote the text cannot be its only judge. WooCommerce: MCP abilities kept read-only because "we really don't want to break sites." The WP Rocket fatal: an interaction bug no single test suite could catch, answered with a 200-plugin harness. Viczián: git diffs as defence against silent AI deletion. **Five independent sources, one conclusion.** The interesting work has moved from producing output to proving it. - **Next steps for readers.** Time a fresh clone to a running test suite on your main project — that number now bounds both human and agent contribution quality. Stop treating a clean diff as sufficient review, and be explicit with your team about what a diff still catches (architecture, abstractions, scope, tests) versus what only running it catches. If you set contribution policy, require **evidence of execution** rather than disclosure of AI authorship; the second is easy to satisfy and mostly beside the point. ## 🔄 Refactor Appendix — He's right. (On "coding is solved, bugs are not") > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Agents cannot verify what humans cannot verify > [!quote] > If it is too hard for you to spin up and test, it is way too hard for your agents to do the same. **Context & use**: - [00:22:40](https://www.youtube.com/watch?v=0wemf5SZkW4?t=1360) - Converts DX debt from a morale problem into a hard ceiling on output quality. Worked instance: Claude Code Desktop is Electron, needing a graphical VM per thread, so its verification loop never got built — while Claude Code web improves fast because eight tabs on one machine is trivial. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] Code review assumed the author ran the code > [!quote] > now we live in a world where the code review going up does not imply any effort was put into checking the thing ahead **Context & use**: - [00:04:40](https://www.youtube.com/watch?v=0wemf5SZkW4?t=280) - The unexamined premise underneath every review process. Review was never full verification — it worked because it sat on top of author testing. Agents removed that assumption silently, and no team updated the process to compensate. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H3] Check results, not diffs > [!quote] > nobody would have caught this bug in code review because the code looks fine **Context & use**: - [00:34:20](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2060) - Anything visible in a diff is now visible to agents too, so the surviving bug class is execution-only. Carefully bounded: reading code still catches architectural failures, wrong abstractions, out-of-scope changes, and test coverage gaps — real findings, but not bugs of this kind. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] Agents are tactical tornadoes > [!quote] > tactical tornadoes, able to churn out astonishing amounts of work with zero high for the future **Context & use**: - [00:42:30](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2550) — Matt Pocock citing John Ousterhout, transcribed imperfectly ("zero regard for the future"). The best-sourced idea in the exchange and it predates AI, which is why it will outlast the argument. Tactical implementation is largely automated; strategic judgment about codebase health is not. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H5] Strategic agent behaviour requires human engineering first > [!quote] > In order to make your agents act more strategic and act more like engineers, you have to do the engineering upfront yourself. **Context & use**: - [00:44:40](https://www.youtube.com/watch?v=0wemf5SZkW4?t=2680) - The operational conclusion. Every decision that made human engineers effective — easy local spin-up, navigable code, easy review and rollback — makes agents more effective too. Nothing genuinely new is being asked for, which is the encouraging part. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Verifiability bounds achievable quality **Claim** (one sentence, Courtney's voice): A system's output quality is capped by how easily its results can be checked, so investment in verification raises the ceiling in a way that investment in generation cannot. **Evidence pointer**: [[#H1]] and [[#H3]] **Scope & conditions**: Holds where output is complex enough that correctness is not obvious on inspection. Strengthens as generation gets cheaper, because the bottleneck moves entirely to checking. Fails where verification is inherently as expensive as production — some research and design work — in which case the ceiling is set elsewhere. Distinct from testing: the claim is about the *cost* of checking, not the presence of tests. **Links** (≥1 with annotation): - [[The-producer-of-an-artifact-must-not-be-its-only-evaluator]] — because extends - [[Ecosystem-scale-compatibility-testing]] — because applies-in WordPress - [[Maker-checker-split]] — because contrasts on who does the checking **Optional**: `proof_state: working` <!-- atomicity: 1 idea ✓ --> #### [P2] Automation removes the social checks a process silently depended on **Claim** (one sentence, Courtney's voice): When a task is automated, the informal human behaviours that quietly held the surrounding process together disappear with it, and the process fails in ways nobody predicted because nobody had written those behaviours down. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds wherever a process rests on unstated norms rather than enforced gates — code review depending on author testing is the instance here. The fix is to make the implicit check explicit and mandatory, not to reject the automation. Generalises well beyond engineering: any handoff where "of course they'd have checked" was doing load-bearing work. **Links** (≥1 with annotation): - [[Verifiability-bounds-achievable-quality]] — because extends - [[Procedural-burden-falls-hardest-on-those-with-least-standing]] — because contrasts on which assumptions get examined - [[Implicit-contracts-in-systems]] — because applies-in process design <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Five sources across two days converge: Penn (model can't grade itself), Woo (read-only MCP because "we don't want to break sites"), WP Rocket (interaction bug → 200-plugin harness), Viczián (git diffs vs silent deletion), and this. **Generation got cheap, verification didn't.** That's the synthesis piece for this batch. — https://www.youtube.com/watch?v=0wemf5SZkW4 #fleeting #articleseed - [F2] Ousterhout's *A Philosophy of Software Design* — tactical vs strategic, tactical tornadoes. Cited secondhand through Pocock; read the primary source. — #fleeting #inbox - [F3] "Time from fresh clone to running test suite" as a headline engineering metric. Cheap to measure, nobody tracks it, and under agents it bounds contribution quality. Possible post. — #fleeting #articleseed - [F4] The truncated-text bug at the centre of this argument is itself an accessibility failure, and not one participant names it as one. Worth noting against the Accessibility Lab piece from the same batch. — #fleeting #xref - [F5] Contribution policy should require **evidence of execution**, not **disclosure of AI authorship**. The second is trivially satisfiable and mostly irrelevant to the actual failure mode. Raise where I have influence over CoC/contributing docs. — #fleeting #share ### → Things 3 (max 2 actions) - [ ] Measure fresh-clone-to-running-tests time on my active repos and fix the worst one — engineering #things - [ ] Draft the "generation got cheap, verification didn't" synthesis piece across this batch's five sources — writing #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/He's Right..md|He's Right. by YouTube]] ## Highlights - look through the code quick and everything seems fine. We've always trusted that original developer to test the thing they changed and make sure there are no bugs before we put it up for code review. But now we live in a world where the code review going up does not imply any effort was put into checking the thing ahead. And you end up with stuff like this. This is why Peter's post quoting the coding is solved thing is actually hilarious and rightfully so. Because while agents can write the code, they're missing so many of the things that we would expect ([View Highlight](https://read.readwise.io/read/01m0sz8xe5wmbg7r078ejdm5dq)) - Note: [H2] Code review assumed the author ran the code. The unexamined premise underneath every review process. Review was never full verification — it worked because it sat on top of author testing. Agents removed that assumption silently, and no team updated the process to compensate. - Tags: atom/literature/h2, articleseed - And it ends up being easier to just file the pull request and wait for the preview build to come up than it is to try and test it on my machine. If it is too hard for you to spin up and test, it is way too hard for your agents to do the same. You need to make it easier to actually verify your code bases. And I find the companies struggling the most with this are the ones who are building in a way that is hard to verify. Funny enough, Anthropic is one of the most guilty of this. Since Claude Code Desktop is a full desktopbacked Electron app, in order to run QA and verify it, ([View Highlight](https://read.readwise.io/read/01m0sz8fqd2edgk4pebjj138v2)) - Note: [H1] Agents cannot verify what humans cannot verify. Converts DX debt from a morale problem into a hard ceiling on output quality. Worked instance follows: Claude Code Desktop is Electron, needing a graphical VM per thread, so its verification loop never got built — while the web version improves fast because eight tabs on one machine is trivial. - Tags: aphorisms, atom/literature/h1 - when the bugs happen. And most importantly, we need to check the results, not necessarily the code. Because let's be real here, nobody would have caught this bug in code review because the code looks fine. If it didn't, the agents would have solved it. The era of finding bugs by just reading the code has, let's be real, ended. Any bug you notice from just reading code can almost certainly be noticed by the agents, too, and ideally noticed within their own development loops. But you still can notice a lot from reading the code, like architectural failures, not ([View Highlight](https://read.readwise.io/read/01m0sz9bqvyyt5ech6enxmgz93)) - Note: [H3] Check results, not diffs. Anything visible in a diff is now visible to agents too, so the surviving bug class is execution-only. Carefully bounded: reading code still catches architectural failures, wrong abstractions, out-of-scope changes, and test coverage gaps — real findings, but not bugs of this kind. - Tags: share, atom/literature/h3 - T3 Code myself. I won't have the agents propose fixes based on what people are tweeting yet. Matt calls out that he agrees partially on the strategic coding being automated thing, saying that people are building pipelines like bug report to repro to fix feature request to prototype or cron to codebase architecture RFC to refactor. Managing these pipelines is very much a strategic concern, one that a human needs to apply their judgment to. Absolutely agree. In order to make your agents act more strategic and act more like engineers, you have to do the engineering upfront ([View Highlight](https://read.readwise.io/read/01m0sz9sv3rfresde9atj9rpr8)) - Note: [H5] Strategic agent behaviour requires human engineering first. The operational conclusion. Every decision that made human engineers effective — easy local spin-up, navigable code, easy review and rollback — makes agents more effective too. Nothing genuinely new is being asked for, which is the encouraging part. - Tags: atom/literature/h5