Is Coding Solved? Theo Separates Code Generation from Engineering

Boris Cherny’s claim that coding is solved but bugs are not has irritated plenty of developers. I want to defend one reading of it while also taking Matt Pocock’s criticism seriously. Much of the disagreement comes from using the word “coding” to mean different scopes of work.

The immediate example is a Claude Code desktop update notice whose text is visibly truncated. I think this is a bug, even though Boris later described it as a UX issue and said a fix was coming. The screenshot demonstrates the result, but it does not establish who wrote the code or what testing occurred.

My concern is that generated code can look plausible in a diff while nobody has actually inspected the running interface. In a human workflow, the author would often see the screen while building it. With an agent, a pull request alone does not prove that either a person or the agent checked the experience.

The distinction between a UX problem and a bug is not convincing to me when users cannot read the text. But before arguing over “coding is solved,” we need to define coding. It might mean typing code, turning a ticket into a PR, or the entire process from an idea to a working product.

If coding means all the work an engineer performs, I do not think it is solved. If it means the narrow act of producing source code, I think current agents can do a great deal of it. That is my assessment, not a claim that they succeed on every task.

I use Neal.fun’s Password Game as a deliberately terrible password experience. Its creator clearly wrote code to make it behave that way. A developer could also accidentally build a bad experience: the fact that software is poor does not mean no coding took place.

A bad result can come from an underspecified request or from detailed instructions that encode a bad idea. Those are different input problems. A capable implementer may still produce an undesirable experience if the plan itself points in the wrong direction.

I draw a simple diagram: a good, bad or bare plan enters an engineering process, which produces software. Strong engineers can question the plan, but executing a bad plan faithfully can still yield bad software. With a vague plan, the outcome depends heavily on context and judgment.

The diagram’s scores are illustrations, not measured probabilities. A good plan and capable engineers improve the odds, but they do not guarantee the result. An incomplete plan can lead to anything from a useful product to a bad one depending on the complexity and the team’s understanding.

The missing layer is verification: QA, staging, preview builds and gradual rollouts. Trying the actual experience can reveal that a plan which sounded reasonable does not work well for users. Verification checks both the implementation and, sometimes, the plan.

Replace the engineers in the diagram with agents. A PR can look reasonable without the code ever being run. If the only person who discovers the issue is the customer, the feedback loop is too late. I suspect the truncated notice illustrates that kind of gap, though I do not know its full development history.

When verification finds a problem, the result should feed back into implementation or planning. A small defect may go straight back for a fix; a poor product decision may require revising the plan. The aim is to catch problems before they reach users, not to promise perfect software.

Testing can be hard because of the environment, not just the model. I have worked in repositories where getting a local build running took longer than making the change. If verification is difficult for a human, an agent will also need help and usable tools.

I suspect that desktop applications are particularly difficult to test in parallel: separate builds may need graphical environments, independent state and a way for an agent to interact with them. I compare that with testing multiple web builds in separate browser tabs. My explanation of Anthropic’s internal process is a hypothesis.

Humans face these setup problems too. Instead of blaming a model for never checking something it cannot easily run, build a workflow that makes the check possible. That is engineering work around the code-writing step.

This returns us to the definition. Some people reserve coding for translating a plan into source code; others include planning and verification. I can understand either usage, but the entire loop and the platform supporting it are software engineering, which I do not consider solved.

Boris did not say that software engineering was solved. Bugs, test environments, system architecture and making changes confidently all belong to the wider process. Agents need support here, just as a new engineer needs a working development environment.

My interpretation is that Boris sees agents as very capable at implementing a specified change, while discovering and preventing bugs autonomously remains harder. My informal percentages for how often agents succeed are personal estimates, not benchmark results.

Improvement requires both better project architecture and better tools from model and platform providers. Agents need a repeatable way to run the product, inspect it and show what they checked. Even a video is not automatically proof: I have seen agent-produced recordings that visibly showed the feature failing.

A clear bug report plus a way to verify a fix can make many bugs tractable for current agents, in my experience. That is different from reliably anticipating every edge case before release. I do not expect software to become completely bug-free.

For T3 Code, I invested in making development servers available over Tailscale and using a read-only snapshot of real data. That helps me inspect work remotely and helps agents exercise more representative scenarios. Building that infrastructure was substantial engineering work.

Until agents can create and use all of those verification loops reliably, people need to build the systems and examine the results. Looking at behavior matters because a change can appear plausible in source form yet produce an obviously broken interface.

I think agents are increasingly capable of spotting many issues visible in code, but code review can still reveal architectural mismatches, inappropriate dependencies, risky changes and missing or unnecessary tests. My claim about the limits of reading code is an opinion, not evidence that review has no value.

Matt’s objection is reasonable if “coding” means the whole software lifecycle. Boris’s original short post did not define the term. People can disagree intensely while actually describing different parts of the work.

In his follow-up, Boris describes stages: models exceed his own coding ability, then improve on adjacent engineering tasks, and eventually outperform people on more computer-based work. He says Claude has reached the first stage for his own work and parts of the second; that is his assessment and forecast.

Boris also notes that the result is not the same for every expert. He says he stopped writing code by hand in November 2025 but continues coding with agents, and explicitly distinguishes engineering from code generation. He acknowledges that model-produced code still has bugs and inefficiencies.

Matt uses John Ousterhout’s distinction between tactical programming and strategic programming. Tactical work is day-to-day implementation; strategic work concerns long-term architecture and codebase health. Matt accepts substantial automation of the former but questions whether agents think strategically.

I largely agree that agents do not reliably and proactively maintain long-term architecture on their own. They can still act as useful consultants: ask them to investigate a proposed design, compare approaches or test a theory before committing to a strategy.

Once people have established a plan and provided ways to verify the result, agents can execute work quickly. The same infrastructure that helps humans—easy setup, review, deployment and rollback—also helps agents. Speed does not remove the need to assess what was built.

Boris says some strategic work is beginning to be automated, including maintenance pipelines. Matt points out that designing and managing pipelines from a bug report to reproduction and fix, or from an architecture proposal to refactoring, itself requires strategic judgment.

I agree that people must do the engineering to set these systems up, even if agents assist. My position is that producing code has become much more automatable, while planning, verification and long-term judgment remain unresolved. Where to draw the boundary is open to debate.