“I think by the end of the year, everyone is going to be a product manager, and everyone codes. The title software engineer is going to start to go away,” Boris Cherny said on Lenny Rachitsky’s podcast. “It’s just going to be replaced by ‘builder,’ and it’s going to be painful for a lot of people.”
Jobs titles in Silicon Valley had never kept up with tooling. However, the statement made by Cherny falls flat since it is made by the individual who created one of the tools that have enhanced the speed of the change: Claude Code, an agentic system capable of performing multiple steps of programming with minimal human intervention. It is not the provocative bit that AI is capable of writing code, but that the workflow is beginning to see code-writing as the least significant part of a broader assembly process of planning, delegation, review, and maintenance.
That is a workflow that Cherny has overdone. “I have not edited a single line by hand since November,” he said, adding that he still checks what the system produces. “I don’t think we’re at the point where you can be totally hands-off, especially when there’s a lot of people running the program. You have to make sure that it’s correct. You have to make sure it’s safe.” The differentiation between hands-off typing and hands-on responsibility has turned out to be the point of contention in the way engineering teams are restructuring around coding agents.
The change also redefines the meaning of “productivity.” The output of many organizations is measured in lines of code shipped, but developers actually take up only a small proportion of their day writing code in any form; the rest is taken up in investigation, coordination and the slowness of matching software to actual user requirements. Consequently, the faster the code generator, the more counterintuitive is the possible bottleneck: the more to read, the more to incorporate, and the more to maintain through time.
That is the coherence issue which is presented in anecdotes and in research. As reported in MIT Technology Review of how developers solve puzzling expectations-reality mismatches, the kind of work that is done by tools is well-known: boilerplate, tests, debugging, and commentary on unknown code is straightforward but when the work is on a large scale code base, then the task becomes difficult. The fundamental constraint does not just lie in correctness in isolation but the capability to adhere to conventions of a repository, to maintain this architecture, and to not to generate the complexity that is difficult to maintain and become the technical debt of future humans.
Moving to agency first development still does not always yield the same results in terms of task. In an empirical study of 7,156 pull requests in five coding agents (2026) the authors determined that the rate of acceptance has been significantly dependent on the nature of the task requested by the agent. The acceptance of documentation changes was 82.1%, which is almost twice as high as the acceptance of new features at 66.1, which is also much higher than the difference between tools. In the same work Claude Code was the most successful on documentation (reported at 92.3) and features (72.6%), whereas other agents excelled on fixes or tests data that indicates that “AI coding” is not a fixed set of capabilities or failure modes but a transitory set of capabilities and failures.
That imbalance is part of the reason why at least one engineer identifies a new form of exhaustion: it is no longer necessary to write line-by-line functions, but rather necessary to interrogate the outputs, refine requirements and run through repeated revision cycles until the changes in the system come to fit the larger design. Stated differently, work drifts vertically between the key strokes and the desire.
The framing by Cherny is based on historical analogy on its part. He has equated the coding agents with the printing press: the point at which copying became inexpensive the center of gravity shifted to a higher level. His closer example is internal: he claims that all his team codes, even the positions that were not historically involved in implementation. In that model, the term builder is not a redistribution of who is allowed to transform ideas into working software, but rather a rebrand.
The lasting lesson is that software does not vanish, but that the work delimitation surrounding the job title of “software engineer” is increasingly difficult as code can be created more rapidly, more cheaply, and more generally available- and yet the work in terms of comprehending systems, defining behavior, and ensuring software security is left oddly human.
