▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=0wemf5SZkW4
• Original title :: He's right.

Theo referees the fight between Boris Cherny's "coding is solved, bugs are not yet solved" and Matt Pocock's mockery of it, and concludes both are right because they use "coding" to mean different things. The narrow act of turning a spec into working source code is genuinely automated; the surrounding engineering — planning, verification, architecture, strategic judgment — is not, and the visible AI-slop bugs everyone points at come from missing verification loops rather than from models being unable to write code.

The bug that started it

The Claude Code desktop app shipped an update callout whose text is truncated at every reasonable window size. A model wrote the string by reading code without ever rendering it. Boris called this "a UX issue, not a bug"; Theo pushes back — text cut off in all display sizes cannot be the intended experience, so it is a bug. The deeper point is why nobody caught it: a human writing this feature would have opened the browser at least once out of basic courtesy to reviewers. Agents don't do that by default, and reviewers have adapted to merging agent PRs that nobody ever ran.

Two definitions of "coding"

Coding can mean anything from "typing keys in an editor" to "everything an engineer does between arriving at the office and leaving". Under the narrow reading — spec in, working code out — Theo agrees it is solved: give an agent a well-specified change and it lands it 99% of the time, and fixes its mistake 95% of the time when told. Under the wide reading it obviously isn't. Boris and Matt are arguing the same word with different scopes, which is why the thread went nowhere.

Plans, engineers, and the verification layer

Theo's model: a plan goes into an execution box (a team, or today a swarm of agents) and software comes out. A good plan with good engineers lands 8–10/10. A bad plan reliably lands 1–4/10 regardless of engineer quality, because great coders execute plans rather than pushing back on them. An empty or vague plan has the widest variance — anywhere from 1 to 10.

The fix is the verification layer that the industry has had for decades: QA, staging, preview builds, slow rollouts. Verification is what catches both bad plans and good plans that turn out badly once experienced. Without it you cannot tell whether the output matches the intent — and the human who eventually discovers the mismatch is usually the end user, as happened here.

If it's hard for a human to verify, it's impossible for an agent

Theo's sharpest practical claim. Codebases where spinning up and testing a change locally is harder than making the change train everyone — humans and agents — to skip verification. Anthropic is a prime offender: Claude Code Desktop is an Electron app, so QA needs a full graphical VM per thread, and Claude models are comparatively weak at computer use. He argues this alone explains why Claude Code web improves constantly while the desktop app stalls — the web app is trivially testable with eight browser tabs, the desktop app isn't.

The corollary is a hiring analogy: a brilliant new engineer who can't get a test build running is just as stuck as the agent, and an agent working without a rendering loop is that engineer working blindfolded.

What needs to be built

• Codebases that agents can actually spin up, test, and observe — Theo rewrote thousands of lines in T3 Code just to run dev servers over Tailscale with a read-only data snapshot, so both he and the agents can verify work remotely.
• Tooling from providers (Anthropic, OpenAI, GitHub, Chrome) that lets agents drive and inspect real systems, plus a norm of agents proving their work. The new GitHub CLI support for uploading images and videos on a PR without committing them to the repo is a real step.
• Skepticism about that proof — Theo has repeatedly had to tell an agent "the video you shared shows this not working."

He also claims that a properly specified bug report plus even a minimal verification system is enough for frontier models to fix most bugs today. Bug-free software is not coming, but as verification gets cheaper and models get smarter, bugs get progressively more solved.

Reading code no longer finds bugs

Any bug visible by reading the diff is a bug the agent could have caught itself. Code review still catches architectural failures — wrong abstraction, touching things it shouldn't, missing or pointless tests — but those aren't bugs in the traditional sense. Catching real bugs now means running the result, or making the agent demonstrate it ran the result.

Boris's and Matt's actual positions

Boris's timeline: (1) models code better than he does — reached, since he stopped writing code by hand in November; (2) models do coding-adjacent engineering better — debugging, profiling, system and UI design — partly reached; (3) models do most computer work better than most people — only early signs. He frames model capability as covering a distribution of human ability, calls himself an average programmer, and notes Anders Hejlsberg-tier specialists aren't surpassed yet. Theo counters that even top engineers like Ryan Carniato are now using Fable to explore ideas in Solid.js that were previously too time-consuming.

Matt invokes John Ousterhout's tactical vs strategic programming: AI has largely solved tactical work, but he's seen no evidence of strategic thinking, and agents behave like "tactical tornadoes" — enormous output, zero regard for the future. Theo largely agrees: agents won't proactively maintain codebase health, but they are excellent consultants during strategy work, and pipelines like bug-report → repro → fix or cron → architecture RFC → refactor are themselves strategic artifacts a human must own.

Takeaway

To make agents act like engineers, do the engineering up front yourself. Every investment that historically made human engineers effective — easy local runs, discoverable code, fast review and rollback — makes agent swarms effective too, and now pays off hundreds of times a day instead of a few.