The most accurate single statement one can make about the writing of software in the spring of 2026 is that the programmer has, for the most part, stopped writing it. This is not a figure of speech and it is not a forecast. It is a description of the working day. The act that defined the profession for sixty years — a person sitting at a keyboard and composing, line by line, the instructions a machine will execute — is now the exception rather than the rule in a great many engineering organisations, and the person sitting at the keyboard is doing something else with most of the hours. What that something else is, how well it is going, and what it has cost, is the subject of this account. I want to set down the state of the craft as it actually stands now, in the present tense, before the present moment is overwritten by the next one — which, on current evidence, will not be long in coming.
The numbers, taken on their own, do not tell the story, but they establish the floor under it. By the most recent surveys, somewhere around eighty-four per cent of professional developers use AI tools of some kind in their work — a figure that includes the chatbot consulted in a browser tab — and a little over half use them every working day. The narrower and more telling category is the dedicated coding tool, the agent or the AI-native editor wired into the repository itself; here the numbers are much smaller and rising fast. Something like a third of developers now work with an agent, and the AI-native editors, taken one by one, command smaller shares still. That is where the momentum plainly is, even if it is not yet where the majority has arrived. A meaningful and rising fraction of the code merged into production — by some measures a fifth or more — was produced in the first instance by a model rather than a person. These figures would have seemed extravagant eighteen months ago. They are now unremarkable, and the developer who uses none of these tools at all has become a sufficiently rare creature that one notices, and quietly wonders, when one meets him.
What the Day Looks Like Now
Consider the shape of an ordinary task. A bug is filed; a feature is specified; some corner of the system needs to be extended. In 2022 the engineer assigned to this would have opened the relevant files, read them, formed a model of the code in her head, and begun to type — and the typing would have been most of the work, interrupted by the reading and the thinking but fundamentally continuous with them. The typing was how the thinking got externalised. One did not entirely know what one thought about a piece of code until one had tried to write it.
In 2026 the same engineer opens a coding agent — Claude Code, or Cursor’s agent mode, or one of their several competitors — describes the task in a paragraph or two of English, and waits. The agent reads the files. It forms, or appears to form, a model of the code. It proposes a change, often a large one, sometimes spanning a dozen files; it writes the tests; it runs the tests; where the tests fail it revises and runs them again. Minutes pass, sometimes a great many minutes, and at the end of them the engineer is presented not with a blank editor but with a finished diff and an account of what was done and why.
The engineer’s work, then, begins where it used to end. She reads the diff. She decides whether the model has understood the task — not merely whether the code runs, but whether it has done the right thing, in the right place, in a manner consistent with the rest of the system and with the things the specification did not think to say. This is the work now: specification at one end and judgement at the other, with the middle — the composition — increasingly delegated. The agents have stopped being autocomplete. The defining shift of the past year is that they run not for seconds but for minutes and hours, unattended, and the engineer has become something between an editor and a foreman, dispatching work and inspecting it on its return.
It is worth being precise about how far this goes, because the breathless accounts and the dismissive ones both tend to round it off. It does not go all the way. The agent that runs for an hour is supervised at both ends and frequently in the middle; the experienced engineer learns to recognise the shape of a task that will go well unattended and the shape of one that will not, and the recognition is itself a skill, newly minted and not yet named. The honest summary is that the model now does reliably what a competent but uninformed colleague could do — the boilerplate, the test scaffolding, the routine refactor, the second language one half-knows, the documentation nobody wanted to write — and does not reliably do what requires holding the whole system, and the business it serves, in mind at once. The boundary is real. It is also blurry, it moves, and a great deal of the working programmer’s new skill consists in knowing where it is this month.
What Is Genuinely Better
It would be a failure of honesty to survey this moment and arrive only at lament, because a good deal of what has happened is straightforwardly good, and the people enjoying it are not fools or dupes.
The first gain is speed, and it is not imaginary. The drudgery has genuinely been removed — not reduced, removed — from a wide band of ordinary work. The migration that would have consumed a careful week is done in an afternoon. The test suite that no one would ever have found time to write gets written, because writing it now costs a sentence rather than a day. The unfamiliar codebase yields up its structure to a few questions instead of to a fortnight of silent reading. A working developer in 2026, asked what she no longer has to do, will produce a list of small miseries — the configuration boilerplate, the error-handling that is the same every time, the third re-typing of a data structure into a third file — and every item on that list is a genuine subtraction from the sum of tedium in the world. One should not be too proud to admit that this is a real and welcome thing.
The second gain is the lowered floor, and here the picture is more complicated, but the gain is still a gain. A person who could not previously have built a working program can now build one. The hobbyist, the scientist with a data problem, the founder who is not an engineer, the engineer reaching outside her specialty — all of them can now get further, faster, than the old gradient of difficulty would have allowed. A great deal of software that simply would not have existed, because the cost of the first ninety per cent of it was prohibitive, now exists. That this same lowered floor also produces a great deal of software that should not exist is true, and I will come to it; but the floor itself, considered on its own, has let a large number of people make things, and making things is good.
The third gain is the one the productivity statistics capture least well and the one I am most confident is real: the removal of friction at the moment of not knowing. The old experience of programming was punctuated, constantly, by small walls — an unfamiliar API, a cryptic error, a syntax half-remembered — and each wall imposed a context-switch, a search, a scattering of attention. The model has flattened most of those walls. One stays inside the problem. The work has become, for those who have adapted to it, markedly more continuous than it was, and continuity of attention is not a small thing; it is most of what made the good days good.
What Has Quietly Been Lost
Against this, and not cancelling it but standing beside it, is a column of losses, and the losses are quieter than the gains because no one ships a press release about them.
The first and most discussed is the review burden, and it has become severe. The asymmetry is simple and unforgiving: generating code is now extremely cheap, and reviewing it is exactly as expensive as it ever was. The natural consequence has arrived on schedule. Pull requests have grown — by some measures substantially, with one large study of heavily AI-using teams putting them more than half again as large as two years ago, and other estimates considerably more modest — and they arrive faster, and the reviewers have not multiplied to match. A team that finds itself with thirty pull requests a day and six people to read them is not a hypothetical; it is a case study, and there are many like it. The researchers studying this have reached for the language of the commons, and the phrase fits: each individual’s productivity gain externalises a cost onto whoever must read the result, and the reading does not scale, and the reviewer increasingly describes the sensation of being the first human being ever to have looked closely at the code he is approving. That sensation is new, and it should trouble anyone who hears it described.
The second loss is subtler and concerns the shape of debugging. To debug a system one wrote oneself is to consult one’s own memory; the bug is somewhere in a structure one built, and the building of it laid down the very knowledge the debugging now draws on. To debug a system one did not write — that an agent wrote, an hour ago, while one was reading email — is a different and worse activity. There is no memory to consult. One must reverse-engineer the intent from the artefact, reconstruct after the fact the model the machine had and did not keep, and do this under the additional handicap that the code is plausible. The model’s code is not wrong in the way a beginner’s code is wrong, with the wrongness showing on its face. It is wrong in the way a confident and slightly careless colleague’s code is wrong: it reads well, it very nearly works, and the defect is precisely where the plausibility is thickest. Several engineers have told me, in almost the same words, that the review of an AI’s work now takes longer than its creation — which is an odd sentence to be able to write about a productivity tool, and a true one.
The third loss is the one that will matter most in ten years and is hardest to point at now, because it is a non-event: the erosion of the deep understanding that used to be a by-product of the work. Knowledge of a system used to be acquired the way one acquires knowledge of a city by walking it — slowly, incidentally, through the accumulated friction of having been everywhere at least once. The friction is now mostly gone, and so is the incidental knowledge. The engineer who has an agent write the authentication layer does not, afterward, understand the authentication layer the way the engineer who wrote it would have. She understands the diff. She has read it carefully; she has approved it responsibly; and she has, all the same, not been to those streets. Multiply this across a career and across a team and one arrives at a profession that ships more code and understands it less — not through any individual’s negligence, but because the mechanism by which understanding used to accumulate has been quietly disconnected. No one decided this. It is simply what removing the friction also removed.
And then there is the slop. The lowered floor that lets the hobbyist build a real thing also lets a great deal of low-quality, half-understood, structurally careless code into repositories that must then live with it. The open-source maintainers feel this most acutely — the AI-generated bug report that wastes an afternoon, the pull request that no human can quite vouch for — but it is not confined to them. Slop is the characteristic pollution of this moment, and like most pollution it is produced by people acting locally reasonably and consumed by people who did not produce it.
The Divide
One cannot survey this moment honestly without naming the divide that now runs through the profession, because it is the single most consequential fact about the working population of engineers, and it is not the divide one might have predicted.
It is not, principally, a divide between those who use the tools and those who refuse them; the refusers are now too few to constitute a side. It is a divide between two ways of using them. On one side stands the engineer — and she is very often a senior engineer, though not always — who treats the model as a fast, capable, and fundamentally untrustworthy subordinate: who delegates aggressively but reviews ruthlessly, who has retained the judgement to know when the agent has produced something plausible and wrong, and who is, in consequence, genuinely and substantially more productive than she was. The tool has multiplied her, because she brought to it a discipline it does not supply.
On the other side stands the engineer who has allowed the model to become not a subordinate but a substitute — who ships what it produces because it runs and the tests are green, who has stopped reading the diffs with full attention because there are too many of them and they are usually fine, and who is, slowly and without noticing, losing the capacity to tell the plausible-and-wrong from the plausible-and-right. This engineer is also more productive, by the crude measure of code merged. He is also, by a measure that does not yet appear on any dashboard, becoming less of an engineer every quarter.
The unsettling thing about this divide is that it does not announce itself. Both engineers look the same in the metrics; both close their tickets; both have green tests. The difference is in a quantity — retained judgement, the understanding that lets one catch the confident error — that the current tooling neither measures nor rewards, and which erodes silently in the second engineer while it compounds in the first. The profession has not yet built the instruments to see this divide clearly. It will need to, because the divide is real, and it is widening, and on present evidence it tracks not seniority or talent but something more like temperament — the disposition to remain suspicious of a machine that is usually right.
The Tools, Plainly
A word on the state of the tools themselves, since their condition is part of the snapshot.
The landscape has, over the past year, both consolidated and proliferated — consolidated in form and proliferated in number. The dominant shape is now agreed upon: an agent that can read a whole repository, run commands, execute tests, and work unattended for a stretch. Within that shape there is vigorous competition. The incumbent assistant that defined the first era of this technology is still the most widely installed, and is still adding users in absolute terms, but its share of the field has slipped — from something like two-thirds of professional developers to roughly half — as faster-growing rivals have taken the energy of the moment, and the tools that have taken it are the agentic ones — Claude Code foremost among them, having gone from nothing to the front of the field in well under a year, with Cursor’s agent and a clutch of others close behind. The experienced engineer no longer uses one tool; the surveys find she runs two or three at once, and has opinions about which is suited to which kind of work, the way a tradesman has opinions about which saw.
What has not happened — and the absence is worth marking — is any closing of the trust gap. Adoption has risen steeply and trust has, if anything, fallen: a much-cited survey finds that the fraction of developers who actually trust the accuracy of what these tools produce has declined even as the fraction using them daily has climbed. This is not the contradiction it first appears. It is the signature of a mature working relationship with a powerful and unreliable instrument. One does not have to trust a tool to use it constantly; one has only to know its failure modes. The developers have learned the failure modes. That learning is itself one of the real skills of 2026, and it is held, unevenly, across the divide described above.
What Has Not Changed
It would be easy, surveying all this motion, to conclude that everything is in flux. It is not, and the things that have held still are as much a part of the present state as the things that have moved.
The hard part of software was never the typing, and it still is not. The hard part was deciding what to build, understanding the problem beneath the request, holding a large system in mind well enough to know where a change belongs and what it will disturb, and bearing the responsibility for the result. None of this has been automated, and there is no present sign of its being automated. The model will write the function; it will not tell you that the function should not exist, that the feature is a mistake, that the real problem is two layers down and political rather than technical. Judgement, taste, the modelling of systems, the modelling of the people the systems are for — these remain exactly where they were, in the human, and the engineers who have prospered in this transition are precisely the ones who already had them and found a machine to take the typing off their hands.
Debugging, too, in its deepest form, has not changed. The intermittent failure, the race condition, the bug that emerges only from the interaction of three subsystems none of which is individually wrong — these still demand a human who can hold the whole thing in mind and reason about it, and the holding-in-mind is still learned only by having done it. The agent assists; it does not relieve one of the need to be the kind of person who could have done it alone.
And the fundamental texture of the work — that it is the precise instruction of a literal machine, that the machine will do exactly what it is told and not what was meant, that the gap between intent and instruction is where all the trouble lives — that has not moved at all. The model has merely inserted itself into the gap. It has not closed it. It has, if one is honest, added a second gap: between what one meant and what one told the model, and between what one told the model and what the model told the machine. There is more translation in the pipeline now, not less, and translation is where meaning is lost.
The Direction of Travel
I said at the outset that this is a snapshot and not a forecast, and I mean to hold to that. But a snapshot of a moving thing must at least record the direction of the motion, and the direction is not in serious doubt. The agents are being trusted with longer and more autonomous stretches of work; the human’s position is migrating steadily toward the specifying and reviewing ends and away from the composing middle; the divide between the two ways of using the tools is widening rather than closing. Whether all of this arrives somewhere good is a question for a different essay, and I will not pretend to settle it in this one.
What I will say, as the thing worth leaving on the page, is this. The profession is in the middle of a genuine and irreversible change in what the daily work consists of, and the change is neither the triumph the boosters describe nor the catastrophe the declinists describe. It is something harder to hold in one hand: a real and substantial gain in speed and reach, bought with a real and substantial loss of understanding and craft, distributed unevenly across a workforce that has split, quietly, into those who have kept their judgement and those who are spending it. The good news and the bad news are not two stories. They are one story, and its name is delegation, and the whole of the question is what one keeps for oneself while delegating the rest.
The typing is gone, or going. The thinking, for now, is not. The state of coding in May 2026 is the state of a craft discovering, task by task and engineer by engineer, which of the two it was made of all along.