AI Has Solved Coding, But Not Software Engineering

Two words ignited the latest skirmish in the ongoing AI-and-software debate: "Coding solved."

That was Boris — the engineer who built Claude Code, Anthropic's AI coding tool — posting in response to a screenshot of a visible bug in the very product he built. The irony was not lost on anyone. Theo, the developer and YouTuber behind the t3.gg channel, spent a recent video untangling why both Boris and his loudest critic are essentially correct, just talking past each other. The argument is worth following carefully, because it maps something real about where AI development tools actually stand.

The Definition Problem

Theo's core observation is disarmingly simple: Boris and his critics are using the same word to mean different things, and the whole fight falls apart once you notice that.

"If we think of coding as the end-to-end aspect of what an engineer does, obviously coding is not solved," Theo says. "But if we think of coding as the thing that happens when I open up my text editor and I'm pressing keys on my keyboard — yes, absolutely coding is solved."

That distinction is not a rhetorical dodge. It's the actual load-bearing question. Before AI entered the picture, a working software engineer spent a minority of their day literally typing code. The rest went to reading requirements, reviewing colleagues' work — submitting changes for team review is the modern version of that — debugging, arguing about architecture, and staring at logs trying to figure out why something that should work doesn't. If "coding" means all of that, nothing is solved. If it means the act of translating a clear specification into working syntax, AI has genuinely crossed that threshold.

Boris, in his follow-up, confirmed this is exactly what he meant. He described a three-stage framework: first, models code better than he does; second, models handle coding-adjacent engineering work — debugging, profiling, optimizing, system design — better than he does; third, models do most things a computer can do better than most people. By his account, according to a profile documented at Stackademic, Boris stopped writing code by hand entirely, though he continues to direct and work with AI agents daily. For him, stage one is settled. Stage two is mostly settled. Stage three is beginning.

The Bug in the Screenshot

The specific bug that kicked this off is instructive. Claude Code's desktop application — an Electron app, meaning it runs as a standalone program rather than inside a web browser — shipped an update where the text describing the update was too long to fit the display window. It was truncated. Nobody could read it.

Theo is willing to defend Boris's broader claim while calling this particular dismissal out directly: "Boris, I'm doing my best to defend you here, but this reply is making it harder. By what logic would you say the text being cut off in all reasonable display sizes isn't a bug?"

The bug itself isn't the interesting part. The interesting part is why it got through. An engineer building this feature by hand would have looked at it in the application before submitting it for review. That's not heroic quality assurance — it's the minimum. You check that the thing you made looks like you intended. AI agents, by default, don't do that. They write the code and submit it for review without ever running the application to see what it actually looks like. In a world where teams have learned to trust agent-generated code and wave it through review quickly, that default behavior produces exactly this kind of bug: invisible to anyone reading the code, immediately obvious to anyone who runs the software.

This is the gap Boris is pointing at when he says bugs aren't yet solved. And Theo's explanation of why the gap exists is the sharpest part of the video.

The Testability Problem

The era of finding bugs by reading code is over. That's not rhetorical — it's a functional description of where things stand. Any bug detectable in the source text can, at this point, be detected by the AI that wrote it. If the problem were visible in the code itself, the agent would have caught it. The bugs that slip through are the ones you can only find by running the software and looking at it.

Which means the critical infrastructure for AI-assisted development isn't better models. It's better verification systems — the pipelines that catch problems before users do. Quality assurance testing, staging environments where changes can be reviewed before going live, slow rollouts that limit the blast radius when something goes wrong. None of this is new. Software teams have built verification layers for decades. What's new is that those layers now determine whether AI development works at all, rather than just working better.

Theo makes a structural point here that deserves more attention than it usually gets: the testability of a codebase determines the ceiling for what AI agents can accomplish within it. The Claude Code web application is improving steadily. The Claude Code desktop application, despite being made by the same company, is not improving at the same rate. His explanation is architectural. A web application runs in a browser — the same environment on every machine, easy to spin up multiple instances, straightforward for an agent to interact with. An Electron desktop application requires its own full operating system environment for every test run, with a real graphical display that the agent needs to control. Running multiple simultaneous test versions of a desktop app is a substantially harder problem than opening additional browser tabs. The capability gap between these two products isn't a gap in model quality. It's a gap in how easy each product is to actually test.

The implication is uncomfortable for anyone who has spent years building software that's painful to set up and run locally. Those codebases were already friction for human engineers. For AI agents, they're closer to walls.

The Strategic Question

Theo's critic, Matt, brings in a framework from computer science professor John Ousterhout that separates tactical programming — the day-to-day execution of specific tasks — from strategic programming — the long-term architectural decisions that determine whether a codebase remains healthy over years. Matt's position, as Theo describes it, is that AI has largely solved tactical programming but shows no evidence of strategic capability. Agents churn out work at impressive speed with no regard for what that accumulation of work does to the system over time.

Theo's own position here is worth stating plainly, because he commits to it: agents are not going to spontaneously develop strategic judgment. They are not going to wake up and decide your authentication architecture needs rethinking. But they can be genuinely useful consultants during the strategic process — given a question, they can investigate, model possibilities, and help stress-test ideas that a human engineer is forming. The strategy remains human work. The agent's role is to execute that strategy faster and at greater scale than any human team could.

This is not a compromise position. It's a specific claim about where the human role actually lives in this new arrangement, and it's different from the "humans will just move up the value chain" hand-wave that usually substitutes for analysis in these conversations. The value chain doesn't move up uniformly. It moves specifically toward the decisions that require understanding what users actually need, what the business actually requires, and what the codebase will look like in three years if you keep making the choices you're making today. Those aren't tasks. They're judgments, and they require context that an agent operating on a single code submission simply doesn't have.

Boris's distribution argument — that model capabilities are sweeping across the range of human programming ability, from the median outward toward the extremes — is the most genuinely interesting part of his framework. He positions himself as an average programmer who has already been surpassed. He acknowledges that world-class specialists in narrow domains may not have been surpassed yet, while betting they will be. That's a falsifiable prediction, and the honest answer is that we don't know the answer yet. What I'd observe, having watched similar predictions cycle through the minicomputer era, the PC era, and the internet era, is that the timeline is almost always wrong — usually longer than optimists project, shorter than skeptics hope. The capability is real. The schedule is guesswork.

What's not guesswork is the verification problem. Until AI agents reliably run the software they've written and confirm it behaves as intended, the human review process is doing work that the agents should be doing themselves. Submitting code for team review without having tested it is something human engineers learned not to do because their colleagues would make their lives unpleasant. Agents haven't learned that yet. Building the infrastructure to teach them — or to catch what they miss — is the actual engineering problem sitting in front of the industry right now.

Boris is right that coding is solved, in the narrow and accurate sense of that word. The question is whether the industry is ready to do the engineering.

---

Bob Reynolds is a Senior Technology Correspondent at BuzzRAG.