There is a reassuring story we tell about artificial intelligence, and an unsettling one, and for the most part they are told by different people. The optimist holds that these tools will democratise expertise, handing the novice the reach of the specialist at the press of a key. The sceptic holds that they will hollow out the professions, quietly automating away the very knowledge that took a career to acquire. A recent study from Anthropic, published in June 2026, offers something more useful than either position: evidence.
The researchers examined roughly 400,000 sessions of Claude Code, the company's agentic coding tool, drawn from some 235,000 people over the seven months from October 2025 to April 2026. The work is careful and privacy-preserving, and it sets out to answer a deceptively simple set of questions: what kind of work are people actually doing with an AI agent, who is doing it, and whether it succeeds. The findings are worth sitting with, because coding is a leading case. What is visible in software today is, I suspect, a preview of what is coming for the rest of knowledge work, our own industry included.
A clear division of labour
The first finding concerns who decides what. In a typical session, the person makes around seventy per cent of the planning decisions, the questions of what to build and what counts as finished, while the agent makes roughly eighty per cent of the execution decisions, the questions of which files to change and what to write. People decide what to build; the agent decides how to build it. That division held steady across the period of study, and it maps neatly onto the way good delegation has always worked. The instinct to set direction and leave the mechanics to a capable hand is not a new skill. It is an old one, suddenly more valuable.
Expertise, not coding, is the multiplier
The second finding is the one that should give our profession pause, and then some quiet confidence. What amplifies the tool is not coding proficiency but domain expertise, and the two are not the same thing. The researchers are careful to define expertise as task-specific rather than a matter of job title. A senior engineer asking a first question in an unfamiliar language behaves as a novice; an accountant who has never written a line of code, but who knows exactly which reconciliation rules a script must enforce and catches the one edge case it mishandles, behaves as an expert. The person who understands the problem extracts far more from the agent. In the data, expert sessions set off action chains more than twice as long as novice ones and produced roughly five times the output for each instruction given.
That advantage carries through to outcomes. The more expertise a person brought to a session, the more often the session ended in success, and the more reliably they recovered when things went wrong. When a session ran into trouble, novices abandoned it at several times the rate of everyone else. Part of the value of knowing your field, it seems, is simply the ability to steer back onto course when the agent wanders.
There is a generous caveat folded into this, and it deserves emphasis rather than burial. Most of the gain comes from moving from novice to merely competent; the further step from competent to expert adds only a little more. A working grasp of the domain captures most of the benefit. One need not be the deepest specialist in the room to use these tools well. One needs to understand the work.
What this means for the built environment
It would be easy to read a study of software engineers and conclude that none of it applies to those of us who measure, cost, manage and deliver buildings. I would resist that conclusion. The mechanism on display here is not about code at all; it is about the relationship between understanding and leverage. The professional who can specify precisely what good looks like, who can recognise a wrong answer on sight, and who can correct course without losing the thread, is the professional these tools reward. That description fits a seasoned project manager or a quantity surveyor at least as well as it fits an engineer.
If the pattern holds as agents move into our work, and I think it likely will, then the moat is not the ability to operate the software. The moat is judgment: knowing what to ask for, knowing when the answer is wrong, and knowing what to do next. The implication for how we train younger professionals is significant. We should be less anxious about whether they can drive the tools, which they will learn quickly, and far more deliberate about how they build the domain understanding that makes the tools worth driving at all.
A measured conclusion
We should be careful not to over-read a single study. The authors are commendably honest about its limits: success is inferred from transcripts rather than observed in the real world, a substantial share of automated usage is excluded, and every classification rests on a model's reading of a session. These are early signals, not settled conclusions, and the picture will shift as the models, the users and the balance between them all change.
Yet the direction of travel is hard to ignore. Agentic tools appear to be absorbing the implementation-heavy work while rewarding those who understand the problems they are solving. If that is right, the response is not to retreat from the technology, nor to chase it uncritically, but to invest in the one thing it cannot supply: a firm command of our own field. The professionals who pair that command with these tools may find themselves able to do work they previously could not. Those without it will get a good deal less from the very same software. The reward, in other words, runs to the people who know their job. That has always been true. It is simply about to matter more.