One Microsoft developer sums up the promise in a single sentence: AI “lets me move from idea to a working, tested prototype far faster, so I spend my time on architecture and judgment instead of code, and I can take on org-scale problems that would have been out of reach solo.” The quote, from participant P174, opens the results of a 16 October 2026 arXiv survey of 331 Microsoft developers . It names judgment as the thing that gets the freed time. It also names the catch: the new work is the work that used to be out of reach, and that is the work you are least able to judge.
The biggest gain is the least checkable
The authors sorted what AI unlocked into three bins. Faster work took 45% of answers, Further work 36.9%, Afresh work 12.4%. Within Further, the largest share (24.2%) was work “beyond one’s own skill, knowledge, or capacity”. Another 12.7% was tasks respondents could do but had never started.
| Category | Share of answers (%) |
|---|---|
| Faster | 45 |
| Further | 36.9 |
| Afresh | 12.4 |
The first group is the striking one. Think of a back-end engineer shipping front-end features, or one person editing a deployment pipeline “which I did not have the skills to do before”, as one respondent puts it. Productivity accounting counts that as reach. Read the other way, it is a developer approving output in a domain where they cannot yet tell a working answer from one that only looks right.
The paper sees this itself. It says developers and AI “meet at the skill-judgment nexus”: AI supplies skill faster than it can reliably judge its own work. The developer either codifies judgment or becomes a “hollow orchestrator”, approving work they can no longer judge. One participant, P320, calls domain knowledge “the bulwark against fabrications or hallucinations” and worries that as it goes stale, “the chances that I miss something increase”.
Two other studies point at the same gap
The survey measured self-reported categories. It did not measure verification quality or defects in Further work, and it is one company, an 8.9% response rate, 77% men. So the hollow orchestrator is a framework, not a count.
Two independent studies suggest where to look. In Anthropic’s randomized trial , 52 mostly junior engineers learned an unfamiliar library, Trio. The AI-assisted group scored 50% on a follow-up quiz against 67% for the control group, with the widest gap on debugging. Time saved was about two minutes, not statistically significant.
A survey of 527 researchers found that over half validated AI code by running it, while automated tests and peer review were rare. Less experienced programmers trusted the AI more than themselves; experienced ones did the reverse. We have seen before that the easy run-it check misses what matters .
Here the leap is ours, not the sources’. One trial tested a chat assistant on a roughly 35-minute task. One survey asked academics how they checked. Neither studied professional teams doing Further work. Read together with the Microsoft numbers, they suggest that Further work is structurally under-verified: the people doing it have the least judgment, and the habit they reach for is the weakest check. That is a read-across from three different setups, not a measured result.
Work AI puts within reach is, by definition, work the developer has the least judgment to check.
Learning can close the gap, if it happens
The strongest objection is in the same data. Respondents also describe AI as a way to learn: “Learning outside of my domain is significantly faster due to tailored responses” (P80), and unfamiliar codebases understood “within 30 minutes” (P11). Anthropic’s trial points the same way. Participants who asked conceptual or follow-up questions, or generated code and then worked to understand it, kept quiz scores of 65% and above. Those who delegated wholesale stayed under 40%.
So Further work can build judgment instead of hollowing it out. Nothing here shows it is failing today. The hollow-orchestrator path is a framing the Microsoft paper does not measure, and we are not claiming otherwise.
But the counterpoint changes the question rather than answering it. What separates the two outcomes is behavior: asking why, or accepting the output. Reviewers watching a pull request cannot see which one happened. A diff from a stretched developer looks identical either way, and reviewers already send back a lot of agent-written code .
Further work needs a different arrangement
If Faster work is checked by the person who did it, Further work cannot be. Three arrangements fit. Borrowed review: route the change to someone who owns the domain, and say plainly that the author is out of their depth. Tests written by that person, so the check does not rely on the author’s judgment. And deliberate learning, where the author is expected to ask the conceptual questions Anthropic’s high scorers asked.
For a lead, the practical shift is to stop counting Further output as reach alone. It is reach plus borrowed judgment, and the loan has to come from somewhere. The textbook helps only if someone opens it.
