The arrival of tools that can write code has provoked a reaction familiar to anyone who has watched a profession encounter automation before. The first response was dismissal — the code it writes is not very good. The second was anxiety — the code it writes is getting better. The third, arriving now, is the more interesting and less resolved one: what does the work of programming actually become when a meaningful share of it can be done by a machine that never tires? The answer, as the profession is discovering, is neither the obsolescence the anxious predicted nor the irrelevance the dismissive assumed. It is a rearrangement of which parts of the job a person does, and which parts they merely supervise.

The tools work, in the narrow sense, by predicting the code a programmer is about to write, and writing it for them if the prediction is good enough. The prediction is good enough, increasingly, for the routine parts: the boilerplate, the familiar patterns, the tests that follow from the function they describe. The parts that resist prediction are the ones that were always the actual work: deciding what to build, understanding why the existing system behaves the way it does, and judging whether the code the tool produced is correct in the ways that matter. The tool did not eliminate the work. It concentrated it, and concentrated work, for the people who can do it, is more valuable rather than less.

The productivity that is hard to measure

The claim most often made for the tools is that they make programmers faster, and the claim is both true and surprisingly hard to verify. Programmers who use the tools report feeling faster, and they produce more code in less time on the tasks the tools assist well. But the relationship between code produced and value delivered has always been loose, and the things that slow software projects — unclear requirements, coordination across teams, the cost of maintaining what was built — are precisely the things the tools do not touch. The honest measurement of productivity in software has eluded the industry for half a century. The tools did not solve that problem; they made it more urgent.

What is measurable is the change in the texture of the work. The programmer who once spent a morning writing a routine now spends the morning reviewing what the tool wrote, correcting its assumptions, and integrating it into a system whose constraints the tool does not fully grasp. The skill being exercised shifts from composition to evaluation, and evaluation is a subtler and harder skill than composition, not an easier one. The junior programmer who once learned by writing a great deal of mediocre code now writes less and reviews more, and whether that produces better senior programmers, or merely different ones, is a question the industry has not yet had time to answer.

The risk the enthusiasm hides

The danger that the early adopters are beginning to name is not that the tools write bad code. They write good code, increasingly, and the code they write badly they write quickly enough to correct. The danger is that the tools lower the cost of producing code that nobody fully understands, and code that nobody fully understands has a long history of failing in the ways that are hardest to debug. The system assembled from a thousand generated fragments, each plausible in isolation, may behave in ways none of its authors anticipated, and the people who will have to fix it may not be the people who wrote it. The tools democratize the ability to make software. They do not democratize the responsibility for maintaining it, and the gap between those two is where the trouble will live.

The profession that emerges from this transition will be smaller in some roles and larger in others, and the skills it values will be different from the ones it valued a decade ago. That is not a catastrophe. It is what happens to professions, and the programmers who thrive will be the ones who treat the tools as colleagues rather than competitors — learning what they are good at, refusing to trust them where they are weak, and keeping the judgment that the tools, for all their fluency, still do not possess.

The work that remains

Software engineering was never really about writing code, though it looked like it was for a long time. It was about understanding what to build, building it in a way that can change, and keeping it working as the world around it changes. The tools that write code accelerate the middle of that process and leave the ends untouched, and the ends are where the value was all along. The programmer who survives the arrival of the tools is the one who rediscovers, after a decade of distraction by the mechanics of writing, that the work was always the understanding. The tools did not take the job. They returned it to what it was supposed to be.