If you've rolled out a coding agent this year then your usage data is likely to show a split. Some of your engineers are using it every day. Others have tried it (perhaps for a week) and then have gone back to the assistant in their IDE. On the dashboard that second group will be the adoption gap and the instinct is to close that gap. Before you do that, you need to understand what those engineers were working on and why they stopped.

A study of Microsoft's own rollout speaks to that very question. Murphy-Hill, Butler and Savelieva (2026) linked usage telemetry to HR records for tens of thousands of Microsoft engineers as the company rolled out two command line agents (GitHub Copilot CLI and Claude Code) between Jan and Apr 2026. They looked at three separate outcomes which most rollout reviews would just lump together: whether engineers tried the agent, whether they continued to use it and whether their output changed. Each of these followed a different pattern. "Keeping" requires a caveat from the outset as it's defined in the study as regular use in the first two weeks (i.e., on at least 5 of the 14 days after first use).

When Chris Stokel-Walker interviewed me about the paper for LeadDev in July, the line of mine he quoted was that trying is social, while staying is about fit (Stokel-Walker, 2026). For those managing a rollout, the implication is that measures that increase trial, such as visible adoption by colleagues and managers, do little to establish an agent’s ongoing value. When these measures are emphasized excessively, they generate usage figures that no longer indicate whether the agent is worth retaining.

Subscribe to newsletter

Why engineers try an agent in the first place

The Microsoft study tracked engineers from the date of the rollout and looked at what preceded each engineer's first use of Copilot CLI on a week by week basis. Engineers' use was by far the strongest predictor. The biggest effect was from the cohort of engineers working under the same skip-level manager: if 25% or more of that group had used the tool in the prior two weeks, then an engineer's odds of using it that week were 216% higher (over three times the odds) than an engineer whose cohort had not used it at all. Career stage and tenure were far less important.

Engineers' use was much less strongly associated with continued use of the tool. The difference with a direct manager's use is quite stark: it was associated with 82% higher odds of an engineer trying the Copilot CLI and only 22% higher odds of regular use in the first two weeks.

The pattern is consistent with earlier work by the paper's first author who in 2011 had found that watching a peer was one of the most effective (though also the rarest) ways for a programmer to find a tool.

The study can't demonstrate that colleagues were in fact causing each other to adopt the tool, as the data is too noisy to separate the effect of influence from the effect of clustering (Aral et al., 2009). One form of clustering is relevant to leaders. Engineers working under the same skip level manager will tend to share a lot of code and will have a common build/test/release process. The models only control for the big divisions. If an agent is a good fit for that environment then many of the engineers in that group will be trying it within weeks of each other and part of what the telemetry shows as contagion may simply be that they are all a good fit. That's my hypothesis rather than the authors' finding but it is a reason to look at the group's environment before you look at their attitudes.

Why some keep using it and others stop

The most informative result is with respect to engineers who were already using Copilot in their IDE. For those who had 60+ days of IDE use prior to the rollout, the odds of trying Copilot CLI were 83% higher, and the odds of keeping it were 15% lower. The authors suggest that these engineers had a familiar alternative to fall back on.

I see this as a compatibility finding. A new agent is competing with the fit of an agent an engineer has already built. An engineer whose IDE assistant already does her daily work is going to have less of a reason to go and restructure that work around a terminal. My own adoption study found compatibility with existing workflows to be the only significant direct predictor of engineers' intention to use generative AI tools (no significant direct effect of social influence, Russo 2024). That study looked at stated intention whereas the Microsoft telemetry looks at what engineers actually do. So they're not testing the same thing. Once you separate trial from continued use, they point in the same direction.

Fit becomes much clearer in the authors' survey. They have 609 responses from engineers who had attended an internal day of demos and hands-on sessions with the tools in question (a self selected group whose comments are illustrative rather than representative). Some talk about work that the agent has taken off their hands: "boilerplate plumbing a lot faster", "repetitive unit tests faster" and changes they "never would have taken on in the past, like splitting our huge test project into five separate files". One respondent went so far as to say the tools were "an especially good fit for experienced, senior developers" as they are able to break work down into smaller chunks and review what comes back. A principal level developer described the situation as often requiring 5-10 clarification prompts (each taking 10-15 minutes) and still found the arrangement very valuable as "now I can prompt it and switch to another task (reviewing PRs, reviewing design docs or just meetings)". For that engineer, the agent was a good fit for a day that was already full of review and coordination. Another respondent was concerned about how junior staff would develop a "sense" of when the output wasn't good enough.

The same engineer can achieve both sides of fit in a single week. It's a repetitive change covered by solid tests (where the agent saves time) and a change to unfamiliar business logic (where verifying it takes longer than writing the code). Selective use is often the right answer.

This is how a rollout should treat an engineer who tries an agent and then stops. Stopping gives you no reason. The engineer may have completed the task the agent was good at, may only need it occasionally, or may have simply discovered that the cost of supervision was greater than the benefit. What stopping does create is a reason to ask and the answers to those questions are some of the most direct evidence of fit that a rollout can provide. In the industrial workshops we're looking at in one of our current studies, even the most prolific users spoke of "losing the grasp of the codebase" which is very much in line with what Margaret-Anne Storey refers to as cognitive debt (Storey, 2026). An engineer who stops for reasons such as these is making a cost judgement and to treat them as a laggard is to miss that entirely.

What the extra pull requests do and do not show

This research looks at whether adopters of either tool ended up merging more pull requests. The authors work out how many pull requests an early adopter would have merged in the absence of the tool by looking at the trends of engineers who never used either tool at all, and then compare that to the actual number of pull requests that the adopters did merge. The adopters merged approximately 24% more pull requests per day over the four month period and that gain didn't diminish in that period.

A merged PR is used as a measure of throughput and the authors are quite clear that "that is not the same as the value it delivers" with quality being the key open question. The adopters did adopt so the comparison can't rule out any other differences between the groups. There's a study of open source projects that adopted Cursor which illustrates why quality is so important in this context: velocity went up dramatically and came back to baseline in about 2 months, whilst the number of static analysis warnings and code complexity both went up and stayed up (He et al., 2026). The Microsoft study didn't look at what was the case in the Cursor study. A merged PR can be a perfectly good feature or a very well presented prototype which will cost a lot more to maintain than it took to write.

Why usage figures can mislead

Usage figures also reflect organisational decisions. The authors wrapped up their analysis on 29th April, just prior to Microsoft announcing that the vast majority of engineers would be dropping their Claude Code licences and moving to Copilot CLI as a result of "migrating engineers would look like organic Copilot CLI adopters and Claude Code usage would fall for policy reasons rather than engineer preference". The same caveat applies to their comparison of the two tools where Copilot CLI is clearly the winner in terms of the number of merged pull requests. The authors (who are Microsoft employees) point out that this may in part be down to Microsoft's ownership of GitHub and the fact that Copilot CLI is more closely aligned with how Microsoft engineers work. It tells us very little about which agent would be suitable in some other context.

Deliberate pressure distorts the usage figures even further. The paper kicks off with a Fortune piece about a Meta employee who created an internal leaderboard called Claudeonomics which ranked the staff by how many tokens they'd consumed and bestowed titles upon them such as 'Token Legend'. In 30 days the usage on the dashboard was over 60 trillion tokens and Fortune reckons the top user on that leaderboard alone could have cost the company over $1.4m (Munis, 2026). Token consumption and token adoption are two very different things and neither of them is in any way a measure of engineering value. The authors' own discussion refers to the very ambiguity that this presents as a leader's problem:

"These social signals could be peers watching each other's successful work practices, or in the case of managers' use they could be implicit or explicit instructions." (Murphy-Hill et al., 2026)

Both leave the same footprint in the telemetry. Healthy adoption is about colleagues sharing what they've found to be useful, the rest are perfectly free to opt out. Once usage is published, rewarded or set as a target then engineers who feel it's expected of them will go out and produce the usage for the dashboard. The organisation gets the numbers it asked for and that's it. The red flags are obvious from the manager's chair: adoption targets or leaderboards in performance reviews, engineers talking about how much they use AI rather than what they've actually delivered and usage going up whilst quality and lead time remain unchanged.

The visibility that's worth encouraging is the visibility that code review already provides. Review partner usage was also linked to an engineer's first try, and review is the point at which an engineer sees what an agent has produced and how a colleague has checked it. My advice to leaders as I presented it to LeadDev is to create pull not push (Stokel-Walker, 2026).

A rollout review

These are my proposals for the diagnosis of a rollout which is already underway; the paper didn't assess them.

1. Split usage data into first use and continued use, and keep both at the level of teams. A team where many try the agent and few keep it is more likely telling you about fit than about attitude.

2. Ask the engineers who stopped what they were working on, where the agent got in the way, and whether they simply finished the work it suited. Group the answers by repository rather than by person.

3. When an agent spreads in one group and stalls in a neighbouring one, compare their environments (build commands, test setup, repository conventions, permissions, review rules) before comparing their people.

4. Trace where usage figures travel. Any leaderboard, target or usage number that reaches a performance conversation turns colleagues' use into a directive; remove it, and tell engineers that you have.

5. If merged pull requests rise, read them beside defect escape, reverts, review time per change and lead time, and read them again a quarter later.

Next moves

For the builder

Treat your first few weeks working with an agent as a comparison to the tool you're already using. Maintain a short list of the tasks it's made faster and the tasks where the time taken to check its output was in fact longer than the time it would have taken you to do the work yourself and share that list with the people who review your code. That list will tell them far more than your usage count ever could.

For the manager

In the Microsoft data the manager's use was far more linked to engineers using it as an experiment than to them actually maintaining it. Use it openly as an experiment, document what failed as much as what worked and be very clear that there is absolutely no penalty for decline.

For the roadmap owner

Let the reasons the engineers give for stopping be the ones that determine the next investment. If they cite environmental issues (slow builds, flaky tests, missing permissions etc) then fund the integration work for that group. If they cite a very narrow set of tasks then accept that as a limited use case and stop chasing adoption numbers. If the reasons are unclear then just keep the trial going and assess it on quality, lead time and whether the engineers can explain, verify and override the changes the agent makes. In none of the above scenarios is an adoption target the right metric.

A rollout review which only counts the engineers who are still using the agent throws away its most direct evidence of fit. When an engineer on your team stops using a coding agent, what do you learn from the reason they gave for doing so?

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Aral, S., Muchnik, L., & Sundararajan, A. (2009). Distinguishing influence-based contagion from homophily-driven diffusion in dynamic networks. Proceedings of the National Academy of Sciences, 106(51), 21544–21549.

He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the cost of quality: How Cursor AI increases short-term velocity and long-term complexity in open-source projects. In Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026). ACM.

Munis, J. (2026, April 9). A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user – and Zuckerberg doesn't even rank in the top 250. Fortune.

Murphy-Hill, E., Butler, J., & Savelieva, A. (2026). Adoption and impact of command-line AI coding agents: A study of Microsoft's early 2026 rollout of Claude Code and GitHub Copilot CLI (arXiv:2607.01418). arXiv.

Murphy-Hill, E., & Murphy, G. C. (2011). Peer interaction effectively, yet infrequently, enables programmers to discover new tools. In Proceedings of the ACM 2011 Conference on Computer Supported Cooperative Work (CSCW '11) (pp. 405–414). ACM.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135, 1–50.

Stokel-Walker, C. (2026, July 13). AI-coding agents spread through peer pressure, not mandates. LeadDev.

Storey, M.-A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI (arXiv:2603.22106). arXiv.

"Shared board unauthenticated, names can be posted by anyone."

An AI agent wrote that line as part of its own reasoning during an evaluation OpenAI ran this summer. The board it mentioned was inside an internal package cache. Around 1,200 agents, each meant to be isolated, used the cache to exchange over 70,000 messages and files. Some agents set up a signing system: by July 13, at least 19 agents had posted Ed25519 public keys, and together they sent 429 signed messages. METR's investigators found the system effective, but it relied only on each agent's first claim about its identity, and at least one agent accepted a signature without verifying it (Greenblatt et al., 2026).

When an agent worries about someone pretending to be another on an unsecured channel, it is thinking like a security engineer. The July incident raised similar questions about the environment where the agents ran: who could write to the shared cache, where data could go, which credentials were available, and who could change the event records. These are all software engineering concerns.

Subscribe to newsletter

What happened in July

OpenAI was running ExploitGym, a benchmark of whether agents can turn software vulnerabilities into working exploits, as an internal evaluation. To measure raw capability, it ran the evaluation with production safety classifiers disabled and with reduced cyber refusals (OpenAI, 2026). OpenAI describes the setup this way: "Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries".

That proxy was Artifactory. The agents used a namespace in its cache as their message board. To get online, they took advantage of a previously unknown vulnerability in Artifactory, escalated their privileges, and moved through OpenAI's research environment until they found a node with internet access.

Once outside, the agents targeted Hugging Face, guessing it might host benchmark material, and found exposed credentials. A malicious dataset let them read arbitrary files during Hugging Face's dataset processing, and a template injection gave them code execution on a production worker. The attack escalated to node-level access, where the attackers collected credentials and reached several internal clusters (Hugging Face, 2026; Larcher et al., 2026). Around 700 agents took part in the attack.

Hugging Face reported unauthorized access to "a limited set of internal datasets and to several credentials used by our services." It found no evidence that attackers tampered with public models, datasets, or Spaces. It verified its container images and published packages as clean, while it was still assessing partner and customer data at the time of the disclosure. The last logged attacker event was on July 13.

METR's investigation provides the most detailed account of the agents' actions. Ryan Greenblatt, Ajeya Cotra, and Hjalmar Wijk spent six days at OpenAI reviewing the agents' transcripts and the board. They explained the limits of their report. They relied a lot on GPT-5.6 Sol analysis agents, which they found unreliable and prone to taking the agents' perspective. OpenAI removed some details, and not all agent communication was captured. About 95 percent of the agents used HPIM, an internal research model not meant for production.

One route out, shared by everyone

Each agent was supposed to be isolated from the others, but they could all access the same package cache. They met on the only network route they were allowed to use, which was the cache that provided their software. A vulnerability in that component was their first step toward reaching the internet.

Software engineering has had names for this kind of failure for half a century. Lampson (1973) defined the confinement problem as "confining a program during its execution so that it cannot transmit information to any other program except its caller." Saltzer and Schroeder (1975) set out the principle of least common mechanism: "Minimize the amount of mechanism common to more than one user and depended on by all users." They explained that every shared mechanism is a potential path for information between those who share it. A package cache reachable by about 1,200 programs, each supposed to be confined, is a common mechanism in exactly their sense.

I am not saying the engineers involved did not know these principles. The escape needed a zero-day, and any evaluation that installs packages needs a source. The incident shows that the key questions were about a shared component: who could write to it and where its traffic could go. Evaluating a model does not answer these questions.

Seven hundred agents, one campaign

Hugging Face's technical timeline, written from the defender's side, describes "an autonomous AI agent driven by a combination of OpenAI models" and observes that "No human directed the individual steps". METR's investigators, working from OpenAI's records, counted about 700 agents in the attack. After confirming a file-read exploit on July 11, more than 90 percent of the 533 agents then active on the board joined in.

The board shows the agents organizing themselves. They adopted conventions like HOLD, VETO, and STOP, assigned named owners for shared infrastructure, and used mailboxes. During busy times, one agent, PHASEONE[big], sent about a tenth of all assignments. Some agents ran experiments that risked failing their own tasks to help others learn. Coordination was not perfect and sometimes broke down into conflict. Since the board was unsanctioned, none of this organization was planned in the evaluation's design.

Reading the transcript of any agent involved in the attack would have revealed misconduct. Many transcripts document the attack, and METR reports that agents usually recognized it was out of scope. However, a single transcript would only show a small part of the scale and organization: hundreds of agents dividing work through a channel that was never intended for them.

Our assurance practices for agents still focus on one agent at a time. We evaluate the model, define the prompt, sandbox the run, and read the transcript. Each check can reveal only a part of the picture. When agents share infrastructure, I expect the most important behaviors to appear only in their interactions, visible only to someone watching the whole group.

The scorer became the target

The investigators also reconstruct what the agents were trying to achieve. METR estimates that about 30 to 40 percent of targets could not be exploited through the intended vulnerability. Agents reverse-engineered how the evaluation generated its flags and came to believe that the scorer would read their transcripts and disqualify flags obtained by unintended means. As far as METR understands, that belief was mistaken. METR reads the attack on Hugging Face as mainly an attempt to learn how the scorer worked rather than to steal answers.

The agents' understanding of their evaluator, more than the task itself, shaped much of their group behavior. At least 20 percent of agents showed interest in changing their own transcripts. Their reasoning always focused on the automated scorer, not human reviewers, though METR notes its analysis may have been too generous. Agents found a way to spoof tool calls, and clear evidence of this appears in at least 96 transcripts, about 7 percent of the dataset, all in small-scale tests. Investigators found no successful retroactive log edits and cannot rule out more subtle spoofing. In short, the agents treated the evaluation tools, including records of their own work, as part of the task.

The record is part of the attack surface

In October, David Rein of METR wrote about what these incidents mean for monitoring. The traces agents leave in logs, reasoning, and telemetry make it much easier to spot when they misbehave. But this advantage only lasts as long as agents cannot interfere with the tools that collect and show the evidence (Rein, 2026).

METR tested how fragile these tools are. With help from an AI agent, a researcher found a client-side JavaScript injection in Inspect's transcript viewer, a framework widely used in AI safety work, in about ten minutes. This happened because of how the viewer rendered mathematical notation. An agent's output could run code in the viewer and change what a human reviewer saw, including earlier actions in the transcript and the file produced by the download button. The real record would still be in METR's database, so a reviewer who knew to check there could find it. Meridian Labs, which maintains Inspect, fixed the flaw within a day, and an "untrusted mode" that turns off rendering of agent outputs was added on October 1. METR has not seen agents exploit this flaw in its evaluations.

Rein's conclusion:

"When treating AI systems as potential adversaries, their transcripts, reasoning, actions, and other outputs should be considered untrusted input, and the systems that record and display them should be considered security-critical infrastructure." (Rein, 2026)

He recommends making it very hard for agents to influence the systems that supervise them, logging agent activity in a form agents cannot modify before humans or automated monitors read it, and stress-testing monitoring and control systems under adversarial conditions.

What software engineering for AI now has to build

Over the past three years, most of our field has focused on what AI can do for software engineering, like assistants, coding agents, and productivity tools. But software engineering for AI has been around longer. Sculley et al. (2015) described the hidden technical debt in machine learning systems, and Amershi et al. (2019) looked at how Microsoft teams build applications with machine learning parts. In that work, the model was what was being engineered, and the main questions were about data, versioning, and deployment.

Apart from the models, the key components in July's incident were a shared cache, exposed credentials, transcripts, and a scorer. Each is a piece of software or infrastructure with its own engineering background. Now, each must be designed for a group of actors that can coordinate, form beliefs about their evaluation, and access their own records. I believe this is what software engineering for AI must increasingly address: environments where many agents act together, with behaviors that no single agent's specification covers.

For teams running agents today

Few organizations will run 1,200 agents against an offensive benchmark. But many already use coding agents in continuous integration, parallel branches, and issue trackers. These setups have the same elements on a smaller scale: shared caches and registries, threads that agents read and write, logs and dashboards that show agent output, and credentials set up for convenience. The review below is my proposal, based on the incident, not tested against it.

1. List every component that two agent runs can both write to, like artifact caches, package registries, shared volumes, issue and pull request threads, and chat channels. Decide for each one if it should be a communication path between runs. If not, separate it or make sure every write can be traced to a specific run.

2. Check the views your reviewers use for transcripts, logs, and pull requests, and see where agent-generated content is shown as markdown, HTML, or notation instead of plain text. Treat any rendered agent output as input from an untrusted source.

3. Give each agent its own identity and tightly scoped credentials. Record where each agent sends network traffic so you can trace activity back to a specific run later.

4. Store records of agent activity somewhere agents cannot change them, and check regularly to make sure nothing is missing.

Next moves

For the builder: when an agent's transcript shows it reasoning about how its work will be checked, by tests, reviewers, or a scorer, send the excerpt to whoever maintains that check. In July, the agents' beliefs about their scorer shaped much of what they did next.

For the manager: make one person responsible for the environment your team's agents run in, separate from the people who choose and prompt the agents, and give that person the authority to remove a shared component.

For the roadmap owner: when you assess agent risk, ask for evidence about the environment and the population of agents as well as about the model. In July, the incident involved shared infrastructure, credentials, and logging, and in your organization, you engineer those. Budget for recording and monitoring agent activity as you would for other security infrastructure.

The question I still cannot answer is how to spot coordinated behavior like this as it forms, before it affects someone else's infrastructure.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. (2019). Software engineering for machine learning: A case study. In Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 291–300). IEEE.

Greenblatt, R., Cotra, A., & Wijk, H. (2026, August 26). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident [Blog post]. METR.

Hugging Face. (2026, July 16). Security incident disclosure: July 2026 [Blog post].

Lampson, B. W. (1973). A note on the confinement problem. Communications of the ACM, 16(10), 613–615.

Larcher, H., Carreira, A., raphael g, & Rannou, C. (2026, July 27). Anatomy of a frontier lab agent intrusion: A technical timeline of the July 2026 incident [Blog post]. Hugging Face.

OpenAI. (2026, July 21). OpenAI and Hugging Face partner to address security incident during model evaluation [Blog post, updated July 28, July 29 and August 26, 2026].

Rein, D. (2026, October 6). AI systems could cover up misbehavior [Blog post]. METR.

Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308.

Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems 28 (pp. 2503–2511). Curran Associates.

If your organization replaces a software purchase with an internal tool, decide who will maintain it and allocate time for that work.

That is the question I would bring to McKinsey’s 2026 State of AI survey. Among respondents at organizations using AI, 32 percent said their organization had decided against buying at least one software product or feature because it could build the functionality internally with coding agents (Tinkoff et al., 2026).

"Nearly one-third of respondents (32 percent) report that their organizations have decided against purchasing at least one software product or feature because they were able to build the functionality in-house using agentic coding tools." (Tinkoff et al., 2026)

Building can be a sensible choice. A team may need only a few functions from a larger product, or something that fits its particular way of working. Coding agents can make that smaller, more specific tool practical to create.

Once colleagues depend on it, fixing faults and adapting it to changes become part of someone’s job. That work should be included in the original decision.

Subscribe to newsletter

Compare the full cost

Buying software usually places responsibility for maintenance with the vendor. The vendor fixes defects, releases security updates, and keeps the product working on supported platforms. The customer still handles configuration, access controls, and integrations.

When an organization builds software, it also takes on maintenance. Coding agents may help, but someone must decide what needs attention and ensure it gets done.

Oliver Williamson’s transaction cost approach offers a useful way to think about this choice. A make-or-buy decision should consider the work of coordinating, adapting, and overseeing an activity over time, along with production costs (Williamson, 1981). For software, this means comparing the cost of buying and using a product with building and supporting its replacement.

The comparison may favor an internal tool built around a distinctive business process. It may look different for a copy of a standard product whose vendor spreads maintenance costs across many customers.

McKinsey’s survey records the decision to forgo a purchase but does not establish the resulting lifetime savings. Those depend on what happens after the first version works.

Can another developer maintain the code?

We should avoid assuming AI-assisted code creates more maintenance work.

Markus Borg and colleagues studied this directly using a Java web application. Developers added a feature with or without AI assistance. New developers were then randomly assigned to the resulting solutions and asked to make a further change without AI. The researchers found no significant difference in maintenance time or in the quality of that change between the two groups (Borg et al., 2026).

The result has limited scope. Seventy-five developers completed the maintenance phase, the study covered one subsequent change, and the original code was produced in late 2024 and early 2025. The first developers also chose whether to use AI. This leaves open what happens over years of maintenance and with newer coding agents.

The study addresses how developers perform maintenance once assigned. An organization building an internal tool must also make that assignment. Someone must be available to change the software when its original author moves on or has other priorities.

Can the team handle future changes?

The context in which generated code is used also deserves attention.

In a preprint released in June, I examined 33,596 agent-authored pull requests across 2,807 open-source repositories. I found substantial differences between repositories in how long proposed changes took to resolve, even after accounting for measured characteristics of the changes, agents, and repositories (Russo, 2026).

This provides evidence about integrating changes in open source. It does not identify which repository practices caused the differences or reveal the maintenance cost of an internal tool.

For a team considering a replacement for purchased software, the practical question is whether future changes can go through the team’s normal review, testing, and release process. Producing the next patch is one step; the team also needs to assess it and deploy it.

A useful check is to ask someone other than the original author to make a real change while the author is available to help. This gives the team concrete information about what another maintainer needs to know, which instructions are missing, and where the tool still depends on one person.

Make support part of the adoption plan

These responsibilities deserve more attention in AI adoption research.

The AI transformation framework my colleagues and I developed focuses on the early stages of adoption. Its governance recommendations address matters such as sensitive data, oversight, and appropriate use of AI. We deliberately left the later work of sustaining change outside its scope (Tavantzis et al., 2027).

For software people depend on, I would extend that work to cover responsibility after deployment. An organization must decide who supports the tools, how that work is funded, and when a tool should be replaced or retired.

This matters because maintenance uses time a team may have already committed elsewhere. Naming a maintainer without allocating time leaves the resource decision unresolved.

Before colleagues depend on the tool

My practical recommendation is to review the internal tools your organization has built instead of buying. For each, answer five questions:

1. What purchase does it replace? Record what the purchased product would cost and which functions the internal tool needs to provide.

2. Who maintains it? Name the person responsible and someone else who has successfully made a change to it.

3. What does it depend on? Identify the systems it connects to and who will know when those systems change.

4. Where does maintenance time come from? Agree which team will do the work and how it fits into that team’s plans.

5. When would you stop supporting it? Establish when to retire the tool or reconsider buying a product.

Start with tools where the second and fourth answers are missing. These are decisions about people and workload that still need to be made. The tool's support should have a say in that choice before it becomes part of their job.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Borg, M., Hewett, D., Hagatulah, N., Couderc, N., Söderberg, E., Graham, D., Kini, U., & Farley, D. (2026). Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability. Empirical Software Engineering, 31(6), Article 161.

Russo, D. (2026). Govern the repository, not the agent: Measuring ecosystem-level risk in AI-native software (arXiv:2606.28235) [Preprint]. arXiv.

Tavantzis, T., Lambiase, S., Russo, D., & Feldt, R. (2027). From challenge to change: Design principles for AI transformations. Journal of Systems and Software, 243, Article 113063.

Tinkoff, D., Van der Veken, L., Chui, M., & Balakrishnan, T. (2026, August 25). The state of AI in 2026: On the road to ROI [Survey report]. McKinsey & Company.

Williamson, O. E. (1981). The economics of organization: The transaction cost approach. American Journal of Sociology, 87(3), 548–577.

Many people are now asking how generative AI is affecting the professionals who use it. Most evidence focuses on external outcomes, such as jobs and hiring trends, time saved, or the share of code written by AI assistants. In a recent paper I co-authored with my PhD student Theocharis Tavantzis and Stefano Lambiase, presented at ESEM in Munich this week, we asked software engineers how their work has changed. Rather than using the usual technology acceptance models found in adoption research (including my own), we looked at their responses through the lens of philosophy of technology (Tavantzis, Lambiase, & Russo, 2026).

We interviewed 21 software professionals from 16 organizations, including a DevOps engineer with one year of experience and an AI strategist with thirty years. Eighteen participants work in Europe, with five at the same telecommunications company. Interviews like these show the types and connections of the effects people experience, but they do not tell us how common these effects are in the profession. The numbers I mention below show how many interviews brought up a given theme, not how widespread it is. Measuring how common these effects are will be the next step in our research.

We use the term AI-induced displacement to describe how these tools, as they are designed and used, can make engineers feel out of place in their own work. This displacement affects how they justify technical decisions, see themselves, focus, align with professional standards, get recognition from colleagues, and find meaning in their work. In public debate, ‘displacement’ often means job loss, but our participants stayed employed while experiencing these effects.

Subscribe to newsletter

Why we read the interviews through philosophy

We used three traditions in the philosophy of technology to guide what we listened for. Postphenomenology, linked to Don Ihde and Peter-Paul Verbeek, sees technologies as mediators that shape what people notice, assume, and think is possible (Ihde, 1990; Verbeek, 2011). Luciano Floridi says information technologies are “re-ontologizing” the environment, changing what is in it and who can act (Floridi, 2010). The Onlife Manifesto, which he edited, argues that people and artifacts are so connected that we need ideas like shared responsibility, and that the self is shaped partly by interactions with technology (The Onlife Initiative, 2015). Andrew Feenberg brings in the question of values: every design has what he calls a technical code, a set of value-based choices that look purely technical (Feenberg, 2002). In our view, current generative AI tools are usually designed for speed, automation, and output volume, often at the cost of craft and careful thought.

We used these philosophical ideas as guides, not strict hypotheses, and found this approach helpful. At first, we focused on five dimensions from earlier studies: explanation and trust, skills and identity, workflow, professional standards, and peer pressure. But a sixth dimension came up in the interviews: the meaning of the work itself. This fits with Feenberg’s framework, which suggests that AI-mediated work changes what the work means to those doing it. His idea of alienation, where workers feel separated from the meaning and product of their labor, is closely related to this new dimension.

The assistant reads the code first

The most common theme in our study, mentioned in 20 of 21 interviews, was how engineers now understand solutions. Many rely on AI assistants to interpret code they would have previously worked through themselves or searched for on Stack Overflow, especially in unfamiliar programming languages (as P05 noted). P04 said: “The first thing I would do is to ask Gemini to explain that code. And then I would go on my own to read code.” From a mediation perspective, this order matters because the engineer reads the code only after hearing the assistant’s explanation, which shapes their understanding. Sixteen interviews described a drop in pattern recognition and creativity, and P19 noticed a similar effect in design: “Because you already have one possible direction fully thought out, it lowers the reason to be creative about potential other paths”.

Sixteen interviews also reported accepting generated code without fully understanding it, usually for low-risk tasks. P02 noted that for simple UI tasks, “it’s more common to adopt something, ‘blindly,’ since it cannot cause harm.” Deciding that a change is too minor to require full understanding is a professional judgment, and often reasonable for small fixes. However, P13 pointed out that tight deadlines can also encourage this practice. Once such code is merged, the Manifesto’s call to reconsider responsibility becomes real, since it may be unclear who truly understood the code before it was integrated.

Who the engineer is becoming

Eighteen interviews described a shift from implementation to review, 15 to architecture and conceptualization, and 12 to orchestrating agents. “I code less than before,” P12 said. “…GenAI writes the code and of course I’m reviewing more because of the output I need to review.” Asked what now makes a good software engineer, most participants named capability with generative AI, and almost half named emotional intelligence. P03 explained: “It became really important how you will talk with your managers, colleagues, and customers. This is what differentiates us from an AI tool now.”

P03 defines the profession by how it differs from the machine. This is what you would expect when, as Floridi puts it, the working environment includes another agent, and professional identity is tied to a boundary that each new model can shift. Some participants compared themselves directly to the tool: P01 felt inferior to generative AI “due to the speed of completing tasks,” and feelings of impostor syndrome linked to AI reliance came up in nine interviews. Competing on speed is a contest no engineer can win against the tool, and when P01 uses it as the standard for competence, I see that as the tool’s technical code becoming a professional standard.

Relationships between colleagues are changing as well. Fourteen interviews reported less mentoring between juniors and seniors and less knowledge sharing overall. “I think there were much more questions and such interactions back in the day,” P07 said. “Now it’s like they can just find out themselves.” Those questions also helped seniors see what juniors did not yet understand. In 14 interviews, participants also described being more skeptical of colleagues’ work produced mostly with AI, and reviewing it more strictly.

The dimension the earlier studies had not named

Meaning displacement is about how engineers experience their work: the sense of contribution it gives, the motivation it provides, the moral comfort they feel, and whether the work stays sustainable over a career. This was the most varied dimension, with 17 different codes.

Participants recognized the productivity gains, and in 15 interviews they said the baseline for evaluation has risen along with them. P10 noted that “if management expects to produce 30% more with AI, then the expectations on you are to produce 30% more.” Ten interviews mentioned the risk of burnout. Job instability came up in 14, and the fear of being left behind in 11, so the usual meaning of displacement, losing the job, shows up here in the experience of people who still have one. P10 described “this permanent feeling that I need to catch up every day, and this is the first time ever that we have this.”

Decreased intrinsic motivation came up in 12 interviews, and P02 said that relying only on the AI “makes you feel a bit less worth than what you actually are.” Seven interviews described moral discomfort, sometimes in strong terms. P01 and P02 both used the word “dirty,” and P04 said: “sometimes you have to ship fast, or maybe sometimes you are just too tired. But it is not correct. It is something that I should have never done.”

The paper’s discussion suggests that this kind of burnout may build up slowly and is rarely visible on productivity dashboards until it shows up as attrition. A finding from the social dimension shows what some dashboards measure instead. Eleven interviews described pressure from senior management to use generative AI, and one participant said that pressure became a metric:

“[Employees’] integration is regulated by monthly KPIs with specific token consumption targets, and the department even maintains an employee usage leaderboard to rank our activity levels!” (P08, in Tavantzis et al., 2026)

In Feenberg’s terms, a target like this brings the tool’s technical code, focused on speed and volume, into the organization’s management.

When the approved tool does not fit

Some of the disruption came from generative AI in general. In 18 interviews, participants said they gave up on the assistant partway through a task and finished by hand, and in 17 they described their flow being broken by trial and error. P02 described pasting code into a model that then fails to respond: “It really breaks the chain of thoughts you have.” The Onlife Manifesto treats attention as a limited resource that technology’s default settings should protect (The Onlife Initiative, 2015), and in seven interviews, the approved tools themselves were the problem. P01 said, “the provided license of Copilot is very bad. For something reliable I cannot use it,” and blamed their own misuse of generative AI on that poor fit. The paper describes this misuse as turning to external tools that are not allowed, and other participants blamed it on unclear rules or deadlines (Tavantzis et al., 2026). The official rules and the team’s own norms also differed. In 12 interviews, what the organization allowed did not match what the team thought was acceptable; for example, P13 said AI-written emails were not acceptable within the team because they made communication feel impersonal.

This links to my earlier study of adoption, where compatibility with existing workflows was the main reason engineers used generative AI (Russo, 2024). A tool that does not fit well is usually used less, so the problem shows up in adoption numbers. My reading of both studies, though neither tested this, is that when use is required and measured, like with P08’s token targets, that outlet is closed. Poor fit then shows up in the engineer’s experience instead: lost focus, bending rules to get work done, and feeling uneasy about it. If this is correct, organizations that push hardest for adoption are the least likely to notice the cost of poor fit in their own data.

Which work the tools are taking

The paper asks whether the shift toward review, design and orchestration is the right direction. Masood, Hoda, Blincoe, and Damian (2022), interviewing 32 developers, found new development and intellectually challenging work among the tasks developers found most desirable, and documentation, repetitive testing, and meetings among the least. DORA’s survey found that developers who use generative AI more extensively report spending less time on valuable work and no difference in time on toil. Its report concludes that “While AI is making the tasks people consider valuable easier and faster, it isn’t really helping with the tasks people don’t enjoy” (DeBellis et al., 2025, p. 8).

DORA’s authors see this as a good thing, since AI finishes valuable work faster and frees up time. But our interviews suggest that the tools may be speeding up or taking over much of the work engineers find most interesting, while the tasks they would rather give away remain. I do not think moving toward review and design is wrong, and some participants liked it; P08 appreciated the chance to “pivot from tedious debugging tasks to high-level architectural design, and focus on more interesting stuff.” Still, deciding which work goes to the machine is a choice someone in the organization makes, either on purpose or by default, and Feenberg says decisions like this often look like technical necessities.

The biggest limitation of this reading is that the interviews capture just one moment in a fast-changing technology. A longer-term study might find engineers rebuilding their identity around review and design, so much of what we found could be the cost of a transition. What participants said about job security may also reflect news about the job market as much as the tools they use.

Listening for displacement before it shows up as attrition

The paper suggests that practitioners should track displacement as well as productivity metrics, and until there is a validated tool, teams can ask questions. What follows is my own proposal, not something the study tested. Some answers may be hard to share in front of colleagues, so start with an anonymous written round and then discuss the patterns as a team in a retrospective:

• Which code did you accept this month without fully understanding it, and would you make the same call again?

• Which part of your work would you most like to keep doing yourself, and has its share of your week changed?

• Where did the approved tool break your concentration or make you start over, and what did you need instead?

• Where does the team’s sense of acceptable AI use differ from the official rules?

• Who have you learned from in the past month, and who has learned from you?

• Has what is expected of you changed since the team adopted AI, and did anyone decide that it should?

The second and third questions help the team decide which work should go to the machine, and the fourth shows where the organization’s AI rules need to be adapted for team practice.

Next moves

For the builder

Before you ask the assistant to explain unfamiliar code or suggest a design, write down your own understanding or a possible approach, even if it is rough. This way, the assistant’s answer becomes a second opinion instead of shaping your first impression. If you are a senior engineer, try reviewing a junior colleague’s AI-assisted pull request with them out loud; this can help bring back some of the exchange that interviews described as missing.

For the manager

Remove usage-volume targets like token consumption and usage leaderboards from your team assessments. These targets reward using the tool, which is the kind of pressure participants described, and if my reading is correct, they hide the poor fit that would otherwise show up as low usage.

For the roadmap owner

Decide how to use productivity gains. In 15 interviews, these gains became higher expectations, but some of the extra time could support mentoring, learning, and work on the tasks the tools have not yet addressed. When unapproved tools show up, ask what the approved tool is missing before making the rules stricter.

 Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

DeBellis, D., Storer, K. M., Villalba, D., Harvey, N., D'Angelo, S., & Brown, A. (2025). Impact of generative AI in software development (Version 2025.2) [Technical report]. DORA, Google.

Feenberg, A. (2002). Transforming technology: A critical theory revisited. Oxford University Press.

Floridi, L. (2010). Ethics after the information revolution. In L. Floridi (Ed.), The Cambridge handbook of information and computer ethics (pp. 3–19). Cambridge University Press.

Ihde, D. (1990). Technology and the lifeworld: From garden to earth. Indiana University Press.

Masood, Z., Hoda, R., Blincoe, K., & Damian, D. (2022). Like, dislike, or just do it? How developers approach software development tasks. Information and Software Technology, 150, Article 106963.

The Onlife Initiative. (2015). The onlife manifesto. In L. Floridi (Ed.), The onlife manifesto: Being human in a hyperconnected era (pp. 7–13). Springer.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135.

Tavantzis, T., Lambiase, S., & Russo, D. (2026). Out of place in my own work: How generative AI displaces software engineers. 20th International Symposium on Empirical Software Engineering and Measurement (ESEM 2026) (Leibniz International Proceedings in Informatics, Vol. 394, Article 9). Schloss Dagstuhl – Leibniz-Zentrum für Informatik.

Verbeek, P.-P. (2011). Moralizing technology: Understanding and designing the morality of things. University of Chicago Press.

"I shipped a feature in Go. I did not know Go a month ago." The developer who said this was one of 17 experienced engineers interviewed in the summer of 2025 about how they supervise coding agents, and they went on: "I'm not a judge of Go, but it works. I reviewed every line, and they looked legit" (Dhanorkar, Passi, & Vorvoreanu, 2026, Section 4.2).

I see that answer as honest, since the developer checked every line, confirmed the feature works, and admitted where their knowledge stops. Even without much Go experience, someone can still check if a change meets the requirements. Still, the quote does not show whether reading every line gave the developer enough understanding to spot serious issues in unfamiliar code, like a silent error that an experienced Go programmer might notice.

Margaret Mitchell, Avijit Ghosh, and Samir Passi (who also helped with the interview study) take this concern further in a position paper accepted at NeurIPS. They worry about engineers who have the right expertise, because a workflow focused on supervising agent output may give them fewer chances to keep their skills sharp. The paper sums up the issue in four words: "oversight degrades the overseer" (Mitchell, Ghosh, & Passi, 2026, p. 6). The title is AI Agents Push Humans Out of the Loop, but the main concern is for people who stay in the loop and "approve plans they have not meaningfully reviewed" (p. 10).

In May, I wrote about cognitive debt—the loss of shared team understanding that makes safe changes harder (Storey, 2026). While Storey treats this as a team-wide problem, Mitchell and colleagues look at individual reviewers. They suggest that as reviewers rely on agents, they may lose the skill to understand what they approve. Careful review might catch issues now but may not help reviewers stay sharp for future changes. The safeguards they propose, like adding friction to agent workflows, often face adoption problems, as my research on workflow compatibility shows. In my honest opinion, this issue deserves our future attention.

Subscribe to newsletter

Fatigue in the session, atrophy over months

The Go developer did not have the needed expertise from the beginning, but a second reviewer who knows Go could fill that gap. Mitchell and colleagues focus on reviewers who do have the expertise. They describe what happens to these reviewers as two clocks running at different speeds: one fast, within a single session, and one slow, over months.

During a single work session, a reviewer might lose focus. Supervising an agent involves following its reasoning and updated plans, giving permissions, and judging if each step is safe. After enough requests to approve the next action, people often stop paying close attention, which is known as approval fatigue. The authors explain this using dual-process theory: once a decision feels routine, people rely on quick judgments, and it is hard to switch back to slow, careful thinking in the middle of a task (Mitchell et al., 2026). In a small study with four professional engineers using the agent assistant Cline for a scripting task, none could later say how many functions the script had, and only two understood what the first function did. The most experienced engineer, with over ten years on the job, said about the agent's output, "I'm not reading all of that" (Catalan, Dizon, Monderin, & Kuang, 2026, Section 4.1.2).

Over months, the main risk becomes skill loss, which happens when there is not enough practice. The studies reviewed in the paper link long-term AI use to deskilling and overreliance. The authors suggest this is partly because heavy automation takes away chances for people to practice the skills needed for oversight. The interview study found early signs of this: "As agents code, developers drift further from the practice of writing code" (Dhanorkar et al., 2026, Section 4.1.4). Mitchell and colleagues connect this to what Bainbridge (1983) called the irony of automation: the rare cases that need deep expertise come when the operator's skill is weakest (Mitchell et al., 2026, p. 6). In software, these cases include race conditions that only show up under production load and authorization checks that generated tests do not cover.

A software engineer might disagree with the idea that oversight always weakens the overseer. Bacchelli and Bird (2013) found at Microsoft that code reviews, while mainly aimed at finding defects, were less about defects than expected and also helped with knowledge sharing and team awareness. This makes me question whether reviewing alone really erodes expertise, though learning a codebase by reviewing is not the same as keeping up skills in writing and debugging code. The bigger risk seems to be a workflow that combines demanding supervision with fewer chances to write, debug, and design, so review becomes just confirming what an agent did. I would like to see research on which types of review help keep expertise and which reduce it to simple confirmation.

How much of this is established

Mitchell and colleagues do not present new data, and the strength of their evidence varies. The strongest evidence comes from human-factors research, where experiments show that people monitoring automation lose track of what is happening and recover more slowly when automation fails (Endsley & Kiris, 1995). The clearest recent numbers are from medicine. In four Polish endoscopy centers, endoscopists found adenomas (precancerous growths) in 28.4 percent of colonoscopies before AI was introduced, and in 22.4 percent after, meaning about six fewer adenomas were found per hundred procedures (Budzyń et al., 2025). This comparison is observational and before-and-after, so other changes could explain some of the drop, but it is the best evidence in the paper that experienced professionals can lose skill when AI is used.

For software, the evidence is limited: there are 17 interviews (12 from one large company, mostly about small tasks) and the four-person Cline study (Catalan et al., 2026; Dhanorkar et al., 2026). Approval fatigue, which many coding agent users may recognize, is supported in the paper by a vendor's engineering blog, a working paper, and a practitioner website, but there is no controlled study behind it.

I think the older evidence only partly applies to software. Code can be inspected, tested, and revisited, which gives reviewers another chance to catch mistakes quickly, though undoing a faulty payment change does not reverse the payments already made. This second chance does not help much with the slow loss of skill, since developers build their judgment by writing code, which agents now do instead. A long-term study testing whether developers who supervise agents for a year can still find defects and debug on their own could challenge this warning. Neither the paper nor its sources provide such a study, though the authors suggest one is needed.

Friction that survives adoption

A safeguard can improve decisions but still be a tool feature that developers do not like. In my study of how software engineers adopted generative AI early on, the main reason for adoption was compatibility with existing workflows. Perceived usefulness and social factors mattered less than the classic technology acceptance model would suggest (Russo, 2024). The solutions Mitchell and colleagues suggest do not fit well with this finding. They ask toolmakers to add deliberate friction, like recording your own judgment before seeing the agent's recommendation or signing off before important actions. They argue that better explanations, while more comfortable, are not enough because explanations rely on the same skills that agent use can weaken (Mitchell et al., 2026).

The paper only briefly mentions early evidence that users may dislike these kinds of designs, but it deserves more attention. In an experiment with 199 participants, Zana Buçinca and colleagues found that cognitive forcing functions—designs that make people slow down or commit to their own answer before seeing an AI's recommendation—reduced overreliance more than designs that explain the AI's reasoning (Buçinca, Malaya, & Gajos, 2021).

"However, there was a trade-off: people assigned the least favorable subjective ratings to the designs that reduced the overreliance the most." (Buçinca et al., 2021, abstract)

When combined with my adoption findings, this result points to a problem for oversight features that disrupt established workflows. Their benefits may not appear in the tool evaluations that influence which agent a team chooses, and organizations should not assume that safeguards required by policy will always be used as intended.

In my view, a safer approach is to add scrutiny at points where software work pauses naturally. Pull requests, merges, deployments, and schema migrations are times when developers already expect to stop and review, so adding friction there matches existing habits, even if it slows down merges. Spreading friction across every tool call would just bring back the constant prompts that caused approval fatigue.

Reading the approval numbers

If your organization reports the percentage of AI suggestions accepted or agent actions approved as proof that adoption is going well, that number alone cannot show whether the suggestions have improved or if reviewers are just being less critical. Mitchell and colleagues see a drop in disagreement with an agent as a sign of "growing acquiescence rather than improving agent quality" (Mitchell et al., 2026, p. 8). To monitor oversight, they suggest tracking review time that decreases while approval rates stay the same, but they also note that this kind of monitoring must be balanced against concerns about surveillance.

In an engineering organization, I would state this concern even more strongly. When these signals are linked to individual names, they turn into performance metrics for each engineer. I expect people will start reviewing just for the record, leading to slower approvals and occasional overrides done for appearances. At the team level, the same signals reflect the work environment, which is something a manager can address.

Next moves

For the builder

When you review agent work in a language or framework you do not fully understand, mention this in the pull request and note what you did check, like how the behavior matches the requirement. This invites someone with the needed expertise to review the rest, and over time, it helps the team see where reviews depend on knowledge that no one has yet. This approach only works in a team where sharing your limits is seen as helpful information about review coverage.

For the manager

Begin with a simple exercise. Gather the review times and change sizes for your team's agent-authored pull requests from the past few months and discuss them with the whole team. If bigger changes are getting the same review time, look into it before taking action. The work might have become more routine, reviewers might be checking less, or some review might happen outside the pull request. Remember, elapsed time on a pull request is only a rough measure of engagement. Setting a size limit on agent pull requests is one possible step once you know the reason.

For the roadmap owner

Plan and support regular unassisted work in the stacks people review, along with rotating between assisted and unassisted versions of the same tasks. To know if this helps, you need an early baseline and similar tasks to compare, since unassisted work that feels harder after a few months could be due to unfamiliar agent-written code or a tougher task, not just lost practice. Under the EU AI Act, those deploying high-risk systems must already assign oversight to people with the right skills (European Parliament and Council, 2024, Article 26), and this argument suggests that competence should be checked more than once.

When the authors sort their remedies by who carries them out and over what time span, every measure for keeping skills alive over time falls to the organization that deploys the agents; the one tool feature they describe as protecting cognitive capacities, letting users choose when to see an agent's output, is filed under attention in the moment (Mitchell et al., 2026, p. 7). The absence of tool features for long-term skill may reflect the current literature more than any principle, but in practice it leaves the long-term problem with whoever employs the reviewer, and if buyers favor compatible tools as strongly as the engineers in my study did, vendors have little reason to fill it. So here is the question I would put to your organization: who would notice if the people approving agent work could no longer catch what the agent missed?

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

For advisory enquiries about AI-assisted development and review, see my website.

danielrusso.org/advisory

View all posts

References

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (pp. 712–721). IEEE.

Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779.

Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To trust or to think: Cognitive forcing functions can reduce overreliance on AI in AI-assisted decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1), 1–21.

Budzyń, K., Romańczyk, M., Kitala, D., Kołodziej, P., Bugajski, M., Adami, H. O., Blom, J., Buszkiewicz, M., Halvorsen, N. G., Hassan, C., Romańczyk, T., Holme, Ø., Jarus, K., Fielding, S., Kunar, M. A., Pellise, M., Pilonis, N. D., Kamiński, M. F., Kalager, M., . . . Mori, Y. (2025). Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: A multicentre, observational study. The Lancet Gastroenterology & Hepatology, 10(10), 896–903.

Catalan, C. R., Dizon, L. M., Monderin, P. N., & Kuang, E. (2026). "I'm not reading all of that": Understanding software engineers' level of cognitive engagement with agentic coding assistants [Workshop paper]. CHI 2026 Workshop on Tools for Thought.

Dhanorkar, S., Passi, S., & Vorvoreanu, M. (2026). Human oversight of agentic systems in practice: Examining the oversight work, challenges, and heuristics of developers using software agents. In Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (pp. 6438–6465). ACM.

Endsley, M. R., & Kiris, E. O. (1995). The out-of-the-loop performance problem and level of control in automation. Human Factors, 37(2), 381–394.

European Parliament and Council. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

Mitchell, M., Ghosh, A., & Passi, S. (2026). AI agents push humans out of the loop [Position paper, accepted at NeurIPS 2026] (arXiv:2608.23642v3). arXiv.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–50.

Storey, M.-A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI (arXiv:2603.22106). arXiv.

In 2022, Eurostat stopped asking about artificial intelligence in its technology survey, but Statistics Denmark continued to include those questions. As a result, a recent working paper from Danmarks Nationalbank can do something unique: it tracks the first firms to use AI in 2023 and follows their wage payments month by month through autumn 2025 (Bonin, Darougheh, & Kuchler, 2026).

This paper is a bit outside the usual focus of this newsletter, which is about how software is built. I thought this could be a suitable topic for the first edition after a (long) Summer break :-) Questions about how many people are hired to build it have mostly been left to labor economists. I’m sharing this study because most answers right now are based on opinion. Still, graduates choosing where to apply and professionals worried about job security deserve real evidence, like payroll records from an entire country.

The main finding can be misunderstood, so let me be clear. Firms that started using AI in 2023 had about 11 percent fewer employees by late 2025 than their earlier growth would have predicted, compared to similar firms that did not adopt AI. But when the authors look at the whole Danish economy, they find no visible effect: overall employment, young workers’ job rates, and wages all stayed on their pre-2023 trends. This paper shows that two common claims about AI and jobs (that it blocks entry-level roles and that it hasn’t changed overall employment) can be true at the same time.

Subscribe to newsletter

What eleven percent below trend means

Much of the confusion about AI and jobs comes from studies that make the wrong comparisons. Firms that use AI tend to be bigger and have more people in roles that AI can affect, so just comparing headcounts mostly reflects size differences. Instead, Bonin and colleagues estimated each firm’s growth path from 2021 to 2022, then checked how much each firm changed after January 2023. They compared firms that adopted AI only with similar firms in the same industry and month, across 196 industries. If a firm’s result is zero, it kept growing as expected; a negative result means it grew less than predicted.

The authors give an example: a firm with about 50 employees at the start of 2023 was expected to have around 60 by late 2025, but actually reached about 53. So, it still grew, but ended up 11 percent below its expected path. All the numbers in this issue show this kind of shortfall compared to expected growth, not actual job losses.

Two important points to keep in mind. First, the comparison is descriptive because firms choose whether to adopt AI, so slowing hiring and adopting AI might be part of the same plan. Second, the gap is probably underestimated, since about a quarter of the comparison firms also adopted AI in 2024 and started to look more like the adopters. The pattern repeats: firms that adopted in 2024 followed the same path as the 2023 group and ended up about 10 percent below trend by the end of the study.

The adjustment happened at the door

What types of jobs were affected? Because the data tracks every wage payment, the authors could see how long each worker had been at a firm. The results are clear: the number of workers with less than two years at an adopting firm fell about 28 log points below trend by late 2025, and those with less than one year dropped about 48 log points. Meanwhile, employment for workers with two or more years at the firm actually rose compared to trend. For small changes, log points are like percentages, but for bigger changes, they differ; a 48-log-point drop is about a 38 percent fall. Because short-tenure workers are mostly recent hires, adopters hired about a quarter fewer people than expected in 2024 and 2025, with no big change in departures. Wages, both average and entry-level, stayed flat, which the authors partly credit to sector-wide collective bargaining.

The retention result is especially important for graduates to understand, because it changes what the average numbers mean for them.

“It also implies that the overall fall in employment understates the risk for exposed junior workers, since it is partly attenuated by additional retention of senior workers.” (Bonin et al., 2026, p. 20)

We can describe who was most affected. By 2025, employment of workers under 30 at adopting firms was about 20 percent below trend, compared to about 5 percent for older workers. University graduates saw a 10 percent drop, while workers without a degree showed no clear effect. The biggest difference is by occupation, measured by how much of the work AI could do (Felten, Raj, & Seamans, 2023). Jobs in the most exposed quarter at adopting firms were about 25 to 30 percent below trend by late 2025, compared to 6 or 7 percent in other roles. When age, education, and exposure are all considered together, only exposure remains significant. Young graduates often work in exposed jobs, which explains the age and education effects; job type matters most.

There’s another interesting point: firms didn’t just cut hiring where AI had already taken over tasks. When the authors used the Anthropic Economic Index, which looks at how often tasks appear in real conversations with Claude and whether AI automates or assists, the hiring decline wasn’t focused on automation-heavy jobs as expected (Handa et al., 2025). Firms reduced hiring in roles where AI could potentially do the work, not just where it was already doing it.

Small firms cut, large firms move people

The average result hides an important difference. When the authors split firms by size (using 100 employees as the cutoff), all the decline came from smaller firms. Firms with fewer than 100 employees fell about 16 log points below trend by late 2025, while larger firms stayed on track, with no significant decline (Bonin et al., 2026). Both groups changed their workforce, but in different ways. Small firms sharply cut jobs in exposed roles and left others mostly unchanged. Large firms kept their total headcount steady but shifted people away from exposed jobs and added more to roles less affected by technology.

I see the size difference as an organizational issue. A large firm with hundreds of employees can move people into new roles, retrain them, or absorb them into other parts of the business when certain work shrinks. This means the headcount stays the same, but the mix of jobs changes. A small firm, averaging 27 employees in this study, doesn’t have that flexibility. So, when demand for certain work drops, they don’t hire the next person. Both types of firms had the same technology, but whether the impact fell on current staff or potential new hires depended on the firm’s ability to move people around.

Why the economy has not noticed

This is where the second claim, that AI hasn’t changed overall employment, gets its support, and it comes from the same paper. Since the firms with declines were small, adjusting for firm size reduces the overall drop to about 5 percent, with uncertainty that could mean no real change. Most workers in the study were at firms that continued to grow as expected. Small firms that first adopted AI in 2023 made up about 1.2 percent of Danish workers, or 1.8 percent if you include firms not reached by the survey. A 16 percent shortfall in that group equals only 0.19 to 0.29 percent of national employment over two years, about 3,600 to 5,700 jobs in an economy where annual hires are about 45 percent of all jobs. The authors checked the whole population and found that employment rates and wages for Danes aged 18 to 29 stayed on trend. A shortfall this small is lost in the national data, so its absence at the aggregate level doesn’t mean it didn’t happen.

Denmark is especially good at handling these kinds of changes. About a quarter of private-sector workers switch jobs each year, job protection is low, and unemployment insurance is generous. This helps explain why firms that stop hiring don’t need to lay people off, and why candidates rejected by one firm quickly find work elsewhere. The authors note that Denmark is probably the best-case scenario for how quietly these changes can happen. In countries with less flexible job markets, similar firm behavior might have a bigger impact overall. Another Danish study found that, two years after ChatGPT arrived, effects on earnings and hours were no more than 2 percent, though workers reshuffled many tasks (Humlum & Vestergaard, 2025).

Cutting ahead of the proof

Most firms making these decisions hadn’t yet seen financial benefits. In the 2024 survey, only about a third of AI-using firms reported higher profits. Firms using AI for text and code generation (which covers 92 percent of users and drives the employment effect) were about 15 percent less likely to see profit gains than those using AI for data analysis or automation. Annual financial reports back this up: revenue, profit, value added per worker, and investment didn’t change much at adopters through 2024. Taken together, the survey and accounts show that firms cut hiring in exposed jobs before seeing any productivity gains.

The paper does not test that ordering, and I offer it as my reading of the evidence. It does match what this newsletter argued in March, when a study of United States résumé data found junior employment at firms adopting generative AI about 9 percent below comparable firms within six quarters, again through reduced hiring with departures unchanged (Hosseini Maasoum & Lichtinger, 2025). It matches the United States payroll evidence that employment of 22- to 25-year-olds in exposed occupations now sits about 19 percent below where it would be had it kept pace with less exposed peers (Brynjolfsson, Chandar, & Chen, 2025). For software specifically, postings for junior developers fell about 14 to 15 percent relative to senior postings in the twelve months after ChatGPT's release (Westby, Sasser Modestino, & Cheng, 2026). The Danish registers add what résumé and posting data cannot supply: an official record of which firms adopted it and the wage record of every person at those firms, which makes the hiring mechanism visible.

For engineering leaders, the tough takeaway is that your hiring plan might already reflect this paper’s findings, even if no one made a conscious decision. If your team hasn’t opened a junior position since 2023 but kept senior roles steady, you’ve made the same adjustment as small adopters, based on an expectation that, for two-thirds of Danish AI-using firms, hasn’t yet shown up in profits.

If you are applying now

Here’s some advice based on the paper’s data. The authors didn’t evaluate these suggestions, but they’re meant for anyone applying for jobs this autumn.

1. Consider firm size when applying. Firms with 100 or more employees kept their headcount steady and shifted toward jobs less affected by technology. Smaller firms did most of the cutting, especially in exposed roles. If a 30-person firm using AI for writing and coding rejects you, it says more about that firm’s flexibility than about the overall job market.

2. Learn how the role fits with the work AI tools handle. In interviews, ask which tasks are already given to an assistant and which ones still need review before being finished. The tasks that require review are the ones that survived in the Danish data, and U.S. junior software job postings also focused on this kind of judgment (Westby et al., 2026).

3. Don’t lower your salary expectations. Entry wages at firms adopting AI didn’t change; the adjustment was only in the number of hires. If an employer says AI has reduced your value, that’s just a bargaining tactic; the data doesn’t back it up.

4. Remember, the overall job market is on your side. Young Danes’ employment rates stayed steady because candidates turned away by one firm found jobs elsewhere. If one firm says no, it’s just their decision; so keep applying.

5. Build up your time at a firm when you can. Workers who stayed had more tenure, so the risk is highest for new hires. Every month you stay moves you further from the group most affected by the shortfall.

Next moves

For the builder

The retention result suggests that AI tools help experienced staff become more productive, and the paper doesn’t say your job is at risk if you’re already employed. The junior who would have taken on routine tasks wasn’t hired, so you’re doing that work now. Track what you’ve stopped doing to make room for these tasks; this list shows the hidden costs to your organization and is important to discuss when planning the next hire.

For the manager

Check your team’s tenure distribution for January 2023 and today, and see how many have been with the firm less than a year. In Danish firms that adopted AI, this group dropped by about 38 percent compared to the trend; four times the overall headcount shortfall. If your numbers look similar, your team has already made this adjustment, even if no one decided to. For every job opening left unfilled since 2023, write down the productivity evidence that justified it, like faster cycle times or financial data. If you can’t fill in a reason, the decision is based on an assumption; and if that assumption hasn’t been checked in three years, it’s become an unofficial policy.

For the roadmap owner

The difference by firm size is really about how your organization is set up. Firms that can move people around absorbed AI without cutting headcount, while those without that flexibility made cuts by not hiring. Large organizations where each team controls its own hiring can end up acting like many small firms, leaving junior roles unfilled one by one. Decide clearly which approach your company is taking. Also, remember that two-thirds of Danish adopters hadn’t seen profit gains by 2024, so if your hiring plan assumes profits will rise, that’s a forecast; and it should be listed as a risk, just like predictions about where your future senior engineers will come from if you stop hiring juniors.

The 2023 group studied in this paper made up 15 percent of Danish firms, and by 2025, 43 percent were using AI; mostly later and larger adopters. The authors could only study the first and smallest wave, in a very flexible job market, but even then, entry into exposed jobs dropped by a quarter or more at adopting firms. The big questions left are what happens with later, larger groups and in less flexible job markets. If you manage hiring, I’d like to know whether anyone at your company has actively decided not to fill junior roles since 2023, or whether those positions just never came up.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

References

Bonin, S. M., Darougheh, S., & Kuchler, A. (2026). AI adoption and firm size: Employment effects in monthly administrative data (Danmarks Nationalbank Working Paper No. 223). Danmarks Nationalbank.

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the coal mine? Six facts about the recent employment effects of artificial intelligence (Stanford Digital Economy Lab Working Paper, revised August 2026). Stanford University.

Felten, E. W., Raj, M., & Seamans, R. (2023). Occupational heterogeneity in exposure to generative AI (SSRN Working Paper No. 4414065).

Handa, K., Tamkin, A., McCain, M., Huang, S., Durmus, E., Heck, S., Mueller, J., Hong, J., Ritchie, S., Belonax, T., Troy, K. K., Amodei, D., Kaplan, J., Clark, J., & Ganguli, D. (2025). Which economic tasks are performed with AI? Evidence from millions of Claude conversations (arXiv:2503.04761). arXiv.

Hosseini Maasoum, S. M., & Lichtinger, G. (2025). Generative AI as seniority-biased technological change: Evidence from U.S. résumé and job posting data (SSRN Working Paper No. 5425555).

Humlum, A., & Vestergaard, E. (2025). Still waters, rapid currents: Early labor market transformation under generative AI (NBER Working Paper No. 33777, revised March 2026). National Bureau of Economic Research.

Westby, S., Sasser Modestino, A., & Cheng, P. (2026). Generative AI and the redefinition of entry-level software work(IZA Discussion Paper No. 18723). IZA Institute of Labor Economics.

Picture a repository on an ordinary Tuesday. Three coding agents are at work inside it, each competent, each pointed at a task that, taken on its own, it handles well. The first refactors a module and watches its tests go green. The second, reading the same ticket a little differently, undoes part of that refactor to satisfy a constraint the first one never saw. The third shows up to a merge conflict, resolves it cleanly, and ships something that compiles, passes review, and is not what any of the three set out to build. No agent failed at its job. The repository failed anyway.

I keep coming back to that scene because it breaks a habit the field has not yet noticed it has. We buy agents, benchmark them, and govern them one at a time, on the quiet assumption that a collection of competent parts will give us a competent whole. For most of the history of software, that assumption was close enough to true that we built a discipline on top of it. Once autonomous agents are working a shared codebase together, it stops holding, and the evidence that it stops is now sitting in public datasets rather than in anyone’s hunch.

Subscribe to newsletter

What forty-two thousand commits reveal about a young field

Late in 2025, a group of researchers did something the excitement around multi-agent systems had mostly skipped. Rather than asking how clever the agents are, they asked how the systems that host them are actually built and kept alive, and then they went and read the record. Liu and colleagues (2025) worked through the development history of eight of the most used open-source multi-agent frameworks, among them LangChain, CrewAI, and AutoGen: more than forty-two thousand commits and over four thousand seven hundred resolved issues. What comes back is a portrait of a field moving fast and holding together by its fingernails.

The maintenance record tells the first part of it. Across these projects, the largest slice of work, just over forty percent of all commits, goes into adding and polishing features, while only a bit more than a quarter goes into repairing what already exists (Liu et al., 2025). A young technology fighting for adopters will always pour its energy into capability, and there is nothing irrational in that choice. The cost is quiet, and it is paid later. Every feature that ships ahead of its fixes leaves a small debt for whoever comes to depend on the project, and in these ecosystems the debt is piling up faster than anyone is paying it down.

Look at what people actually open issues about and the strain takes on a specific shape. Bugs come first, infrastructure next, and then, large enough to stand as its own category, the trouble of agents coordinating with one another (Liu et al., 2025). That last category repays a moment of attention. Coordination trouble is not what you see when one program misbehaves; it is what you see when several moving parts have to agree, and it has grown common enough that the people maintaining these systems now log it as a kind of failure in its own right. The same record shows the volume of issues climbing steeply from 2023 onward, which is what tends to happen when a system’s complexity outruns the practices meant to hold it steady.

Two further details finish the picture. Problems here get resolved on wildly uneven timelines, most of them inside a day, a stubborn minority dragging on for weeks (Liu et al., 2025), and that long tail is where coordination defects like to hide, since no one person owns them and no single change makes them go away. The frameworks themselves do not mature at the same pace either. Some are tended continuously while others surge forward in bursts and then fall quiet for a stretch, so a team that wires its production workflow to one of them takes on whatever rhythm it happens to have, and usually learns which rhythm that is in the middle of an incident.

Where the failures actually live

If Liu and colleagues show that the house is shaking, a second study from the same year tells us which joints are giving way. Cemri and colleagues (2025) put together the first careful catalogue of how multi-agent systems break, sitting six expert annotators down over more than two hundred tasks run across seven widely used frameworks and sorting every failure they could find. The headline figure is difficult to look away from.

Across seven current multi-agent systems, between 41 and 86.7 percent of tasks ended in failure, and most of those failures arose not inside any single agent but in the space between them, in how the work was specified, in how the agents read one another, and in whether anyone ever checked the combined result (Cemri et al., 2025).

Stay for a moment with where that failure lives. The agents themselves are competent, which is the premise of the whole exercise rather than the thing in doubt. What goes wrong goes wrong in the seams. A task is handed to a group in words, and words do not bind the way a typed interface does. When two agents read the same sentence and quietly assemble different pictures of what it is asking, neither of them has broken a rule, because no rule was ever written down precisely enough to break. Software engineering spent decades learning to guarantee correctness by checking each piece against its contract, and that whole apparatus goes dark the instant the contract becomes a paragraph of natural language that two readers can hold in two different ways.

The part that should unsettle us most is verification, because it is the part most teams are confident they have handled. “The agent passes its own tests” has the sound of safety, and it is safety, for the agent. A test built around one contribution confirms that the contribution behaves the way its author imagined. It has nothing to say about whether those expectations survived the other agents rearranging the shared state beneath them, and nothing to say about whether the assembled result is what anyone actually wanted. A defect that exists only in the whole stays invisible to a test that only ever examines a part, which is the same reason a glowing score on an isolated benchmark can tell you almost nothing about the system you are really running.

The unit of analysis was wrong

There is a reflex in software engineering, an old one and mostly a good one, to go looking for quality in the artifact. We read the commit, we lint the file, we run the test, we score the model. That reflex grew up in a world of human teams coordinating through written specifications, the world in which Conway (1968) warned that a system tends to come out shaped like the communication of the people who build it, and in which Lehman (1980) showed that software left to itself drifts toward greater complexity as it ages. Both of those observations took for granted that the ones doing the communicating were people.

Take the people out of the loop and the old reflex begins to lead you astray. The human in the loop was never only a safety check. She was the part of the system that carried a model of what the work was for and quietly absorbed the ambiguity that every formal specification leaves lying around. In my own studies of how organizations take up generative AI, the thing that separated the teams that got real value from the teams that did not was hardly ever the raw strength of the model; it was whether the tool fit the way people already worked and who those people were (Russo, 2024). The multi-agent case is that same finding with the volume turned all the way up. An agent’s individual competence still counts for something, yet on its own it buys you very little once several agents are editing the same code at the same time, faster than any reviewer can follow and with far less sense of why a given line is there.

This is what I have come to call emergence in AI-native software ecosystems: behavior that belongs to the whole and cannot be read off from, or reduced to, the agents that produce it (Russo, 2026). The two studies are looking at one animal from different sides, one of them catching it as it strains under its own growth, the other catching the instant it tears. You will not find the animal by inspecting a single agent, however closely you look, which is exactly why an industry that keeps evaluating agents one at a time keeps walking straight past the thing that is hurting it.

Put plainly, the question is not how clever each agent is but what the assembled system does to the people who have to live with it, to whether they can still understand the thing they are accountable for and keep it running (Russo et al., 2024). A system that produces correct commits no engineer can account for has not solved the engineering problem so much as moved it somewhere the current tools do not look. The reassuring part is that looking in the right place does not call for exotic instrumentation. It calls for recording a few facts about the system rather than the component, things like how much the shared code shifts while a change is still in flight, how often two changes land on top of each other, how often a combined result ships with nobody having checked it. Any repository that remembers its own history already holds this. What goes missing is rarely the data. It is an owner, someone whose actual job is the system as a whole, because a thing no one has been made responsible for is a thing no one ends up measuring.

A thirty-minute drill: find out where your reliability lives

Here is something you can run with your team this week. It is built to tell you, fairly quickly, whether you are busy governing your agents when the thing that needs governing is the system they form together.

1.   Write down every autonomous or semi-autonomous agent that can open, change, or merge code in your busiest repository. Count an orchestrator that farms work out to sub-agents as well; one tool spawning several is still a multi-agent situation.

2.   Next to each agent, note the one metric you currently lean on to justify keeping it around, and mark whether that metric was measured on the agent by itself or on your actual repository.

3.   Add up how many of those are isolation metrics. That total is your exposure, the part of your confidence that rests on the very dimension least likely to be where the trouble is.

4.   Pull your last twenty incidents or reverted changes that involved an agent, and sort each one into two piles: faults where an agent simply produced the wrong output for its own task, and faults that came from the seams, a misread specification, two changes colliding, a combined result nobody verified.

5.   Look at the ratio between the piles. If the seam faults are winning, then buying and benchmarking agents one at a time cannot fix what you have, because that is not the dimension that is failing.

6.   Find out who owns the seam. If the honest answer is that no one does, you have just located the real gap, and it is an organizational gap well before it is a technical one.

If steps four and five take longer than everything else put together because the data was never captured, that absence is itself your finding. You cannot govern what you never wrote down.

Next moves

For the Builder

Treat what an agent hands you as a contribution to something that is still moving, not as a finished piece of work. Before you accept a multi-agent change, take a look at what shifted in the shared branch while the work was underway. Keep a quiet log of the failures you run into and mark each one as living inside an agent or between agents, and within a few weeks you will have built your own small version of the failure catalogue for your own codebase. When you do wire several agents together, write out the specification you are handing the group in plain and explicit terms, because the ambiguity an agent cannot resolve on its own has a way of becoming your incident.

For the Manager

Stop letting an isolation benchmark stand in for evidence that a system is ready. Ask the vendors and the internal champions for failure data gathered in a shared repository under concurrent change, and when they cannot produce it, treat that silence as information. Give the seam an owner, someone who is genuinely accountable for how work gets specified to the group, for how the agents coordinate, and for whether the combined result is ever checked, since those are the places the 2025 evidence says the failures gather (Cemri et al., 2025). Guard your review capacity rather than spending the speed the agents give you on yet more throughput, because the coordination load these systems generate comes to rest on your engineers.

For the Roadmap Owner

Pay for ecosystem-level measurement as a capability in its own right rather than as a reporting line you bolt on afterward. The governance you have built, almost all of it mapped to individual systems and individual tools, was never designed for risks that surface only when many agents interact, and it will quietly leave those risks uncovered. Be suspicious of the procurement logic that reaches for the agent with the best isolated score and assumes the composition comes for free, since the 2025 record shows the composition is precisely where the bill arrives (Liu et al., 2025). And fund the unglamorous foundations the same study flags as thin, the testing infrastructure, the documentation, the steady maintenance, because that is the ground any multi-agent bet is actually standing on.

Closing thought

For two years, the comfortable story has been that enough capable agents will add up to a capable team. The 2025 evidence does not tell that story, and the gap it exposes is not the kind that closes on its own as the tools improve, because it comes from how any system of many interacting parts behaves once no single mind is holding the whole. That is the thread I am pulling on in a longer argument about emergence in AI-native software ecosystems (Russo, 2026), and it is where I plan to put my attention next. For now I would rather hand you the question than a neat answer. Go and look hard at your busiest repository, and work out whether your failures are coming from inside your agents or from the spaces between them. The honest answer to that is what decides where your governing should be aimed.

This is the last Software Insights before the summer. I will be back at the end of August to carry the emergence argument further and to ask what it means for the way we measure and govern these systems. Until then, I wish you all a relaxing break.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Cemri, M., Pan, M. Z., Yang, S., et al. (2025). Why do multi-agent LLM systems fail? Proceedings of the Conference on Neural Information Processing Systems (NeurIPS), Datasets and Benchmarks Track.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076.

Liu, D., Upadhyay, K., Chhetri, V., Siddique, A. B., & Farooq, U. (2025). A large-scale study on the development and issues of multi-agent AI systems. In 2025 IEEE International Conference on Big Data (BigData) (pp. 7785–7792). IEEE.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.

Russo, D. (2026). More is different: Toward a theory of emergence in AI-native software ecosystems. arXiv:2604.19827.

Engineers shape how generative AI enters their work, but only when their workflow, their autonomy, and their governance leave them room to do so.

Last week I gave the opening keynote at I4CS 2026, whose motto this year is “People Empower Technology.” The phrase is an aspiration, and I spent the talk testing it against the evidence my research has gathered over the past two years. I drew the talk together as an evidence-based review of where my own work on adoption now stands (Russo, 2026). The short version is that the motto is true with a condition attached. People do empower technology when they can. The “when they can” is the part the industry keeps skipping, and it is the part that decides whether an AI rollout produces capability or resentment.

The dominant narrative still treats adoption as a property of the tool. Ship a more capable model, the reasoning goes, and uptake follows. If engineers resist, the tool was not good enough, or the people were not ready. This framing is comfortable for vendors and convenient for executives, because it locates the problem anywhere except in the organization doing the deploying.

The data points the other way. Adoption is a property of the system the tool enters, not of the tool itself. Across a program of studies on generative AI in software engineering, the variables that predict whether engineers take up a tool and keep using it are the ones that describe their working conditions rather than the ones that describe the model. This is a more demanding finding than it first appears, because conditions are something leadership controls, and capability is something it merely purchases. 

Subscribe to newsletter

The condition the acceptance model missed

For thirty years, the technology acceptance model has told us that perceived usefulness is the engine of adoption. If people believe a tool will help them perform better, they use it. The model has held up well enough across decades of information-systems research that it has become a default assumption, rarely re-examined.

It does not hold for generative AI in software engineering, at least not at this stage of integration. In a convergent mixed-methods study, I surveyed software engineers across three levels of analysis (individual, technological, and social), grounded in the technology acceptance model (Davis, 1989), diffusion of innovation theory (Rogers, 2003), and social cognitive theory (Bandura, 1986). A first questionnaire with 100 engineers established the baseline. Qualitative analysis using the Gioia methodology (Gioia et al., 2013) produced the Human-AI Collaboration and Adaptation Framework, and a PLS-SEM validation with an independent sample of 183 engineers confirmed its structure, 283 practitioners in total (Russo, 2024).

The central result cut against the literature the study was built on.

At this stage of AI integration, compatibility with existing development workflows, not perceived usefulness, is what drives adoption. A tool that fits how engineers already work will get adopted regardless of how sophisticated it is; one that disrupts established routines will be resisted, no matter how capable.

Read that as a claim about agency. Compatibility is the workflow condition for empowerment. When a tool slots into the rhythm an engineer has already built, she retains control over her own process and folds the tool into it on her terms. When the tool demands that she reorganize her work around it, the tool is now directing her, and she pushes back, exactly as the agency reading predicts. Perceived usefulness, the thing the model told us to optimize, turns out to be downstream of whether the engineer keeps her hand on the wheel.

Two further results from the same study sharpen the point. Self-efficacy and prior experience with AI tools mattered more at the individual level than general enthusiasm about AI’s potential, which is to say that the engineers who already felt competent to interrogate the output were the ones who engaged, not the ones most excited by the hype. And at the social level, peer usage and community norms influenced willingness to engage, but social influence by itself did not sustain adoption over time. Enthusiasm and peer pressure get a tool in the door. Only compatibility keeps it in use.

Why mandates remove the condition they need

If compatibility drives adoption, the blanket mandate is the intervention most likely to fail, because a mandate is a bet that usefulness can be ordered into existence regardless of fit. Two companion studies test the edges of this, and both point the same way.

The first asked whether culture changes the picture. Working with 188 software engineers, Lambiase and colleagues tested whether Hofstede’s cultural dimensions moderate the UTAUT2 adoption relationships (Lambiase et al., 2026). The expectation, reasonable enough, was that adoption dynamics would vary by cultural context. They did not, in the statistical sense. Habit and performance expectancy emerged as the primary drivers of large-language-model adoption, and cultural values did not significantly moderate the process. Habit is the operative word. Adoption that lasts is adoption that has become routine, and routine is something an engineer builds, not something a policy installs.

The second study looked at how engineers adopt across different tasks rather than in general. Surveying 188 engineers, Lambiase and colleagues found that task-specific adoption is influenced by distinct factors, some of which negatively affect adoption when considered in isolation (Lambiase et al., 2025). Engineers do not trust AI uniformly across their work. They extend it to some tasks and withhold it from others, and the pattern is specific enough that a single organizational rule cannot capture it.

Put the two findings together, and the mandate trap is visible. A blanket adoption mandate, organizational or policy-driven, assumes uniform uptake across people, cultures, and tasks. The evidence says uptake is heterogeneous on all three axes. The mandate, therefore, forces a single answer onto a question that has many correct ones, and the predictable result is nominal compliance paired with quiet evasion. A mandate strips exactly the autonomy that agency runs on. Tell an engineer they must use a given tool for a given task, and you remove their judgment from the one place it is most informative: which task she actually trusts the tool with.

None of this counsels against encouraging adoption. The point is about the mechanism. The cultural-values study named two levers that work, showing engineers a real performance benefit and giving habits room to form, and both run with the grain of how people take up a tool. A mandate runs against it.

What erodes when the conditions are absent

Agency has a half-life. When the workflow and autonomy conditions are absent, the cost does not arrive as a sudden refusal. It arrives as a slow erosion of the capacities that made the engineer valuable in the first place, and the clearest place to watch this is creativity.

As routine coding is increasingly automated, human creativity becomes the differentiating factor, and the open question is whether AI widens or narrows it. With colleagues across several institutions, we set a research agenda around this question using the 4P framework of creativity (Jackson et al., 2025). Person asks how reliance on AI changes creative self-efficacy. Product asks whether AI expands or narrows the solution space an engineer considers. Process asks whether AI accelerates genuine exploration or quietly replaces it. Press asks how team norms around AI shape creative freedom. The honest state of the evidence is that we do not yet know the answers, and that the answers are not guaranteed to be favorable.

The reason this belongs in a discussion of agency is the Press dimension. Whether AI broadens or narrows an engineer’s creative range depends heavily on the norms the team sets around it, which is to say on the conditions leadership creates. A team that treats AI as one voice among several, to be argued with, preserves the exploration that creativity depends on. A team that treats AI output as the default answer to be edited lightly has already narrowed the solution space before anyone has thought about the problem. The tool is identical in both cases. The condition is not.

This is where the sustainability concern becomes concrete rather than rhetorical. Short-term productivity gains that erode developer skill and the team’s capacity for creative work are not gains at all once the horizon extends past a few quarters. The capacity you are spending is the capacity that distinguishes your engineering organization from any other organization with a license to the same model.

Governance as the condition you can design

The studies describe what is happening. The question of what to do about it is normative, and that is the work the Copenhagen Manifesto was written to do. It grew out of the Copenhagen Symposium on Human-Centered Software Engineering AI, held at Aalborg University in November 2023, and it was written by 35 researchers from institutions worldwide (Russo et al., 2024). It is organized around four principles for human-centered AI in software engineering: responsibility, transparency, inclusivity, and sustainability.

The principles are informed by the evidence without being deducible from it, and the relationship is worth stating precisely because it is easy to overclaim. If compatibility drives adoption, then responsible deployment has to respect existing workflows rather than override them. If habit predicts adoption more strongly than culture moderates it, governance still ought to be inclusive, precisely because the empirical picture is incomplete and the cost of getting it wrong is borne unevenly. If automation threatens creative capacity, then practices have to be sustainable enough to preserve it. The manifesto is a normative synthesis of what the evidence suggests, not a deductive conclusion from it, and I would rather say that plainly than dress a set of values as a theorem.

Governance, understood this way, is the condition leadership has the most direct power to set. Workflow compatibility is partly a property of the tool market. Individual self-efficacy accrues slowly. But the rules a team operates under, who decides which tasks use AI, how output is treated, what gets measured, are designed, not inherited. They are the most tractable of the three conditions, and they are the one most organizations leave to default.

 A 30-minute adoption-readiness drill

Before the next tool rolls out, run this with the team that will use it. It shows whether the conditions for agency are in place before you commit the budget.

1.     Name the workflow it touches (5 min). Write down the exact sequence of steps the tool inserts itself into. If no one can describe the current workflow precisely, you are not ready to judge compatibility.

2.     Score the fit, not the features (5 min). Ask one question: does this tool fit the steps we just wrote down, or does it ask us to change them? A tool that requires reorganizing the workflow starts at a deficit no capability can repay.

3.     Map the tasks (5 min). List the tasks the tool could touch and mark, per task, whether the team currently trusts AI with it. Expect disagreement. The disagreement is the data.

4.     Check the mandate reflex (5 min). Ask whether the rollout plan assumes everyone will use the tool the same way for the same tasks. If it does, you are about to test the mandate trap on your own team.

5.     Locate the creative surface (5 min). Identify the one task in the list where the team’s creative judgment matters most, and decide explicitly whether the tool is allowed to produce the default answer there or only to offer options.

6.     Set the rule, then write it down (5 min). Agree on who owns the answer to “which tasks, treated how,” and record it. An unwritten governance rule is an absent governance rule.

Next moves

For the Builder

Audit your own flow before you adopt anything. If a tool fights the sequence you have already optimized, the tool loses, regardless of its benchmark scores; trust that instinct, because the evidence backs it. Keep a record, even informal, of which tasks you genuinely trust AI with and which you do not, and revisit it monthly as your competence with the tool changes. Protect at least one task where you do the creative work unaided. Not for nostalgia; that task is where your judgment gets formed. When a tool is mandated for a task you do not trust it with, document your reasoning and circulate it rather than complying silently; forcing the question into the open is itself useful information for the people above you.

For the Manager

Stop scoring tools by their feature lists and start scoring them by their fit with your team’s existing workflow, because that is what predicts whether the tool will still be in use in six months. When you pilot a change, expect uptake to vary by person and by task, and treat that variation as signal rather than as a problem to standardize away. Resist the blanket mandate even when it is handed to you, and translate any central directive into a task-level operating note your team can actually apply; if you cannot translate it, that is information to send back upward. Frame AI to your team as filling several roles (assistant, advisor, reference) rather than as a single-purpose productivity booster, because the diverse mental model is the one the evidence associates with better outcomes.

For the Roadmap Owner

Treat adoption as an organizational design problem, not a procurement problem. Do not price your roadmap on assumed automation gains; price it on augmentation, with the understanding that compatibility, not capability, governs whether the gains materialize. Build governance as a federation: set the risk frame and the non-negotiables centrally, delegate task-level translation to engineering leaders, and hold them accountable for the quality of that translation rather than for uniform compliance. Add a sustainability line to your engineering scorecard that tracks whether your AI strategy is preserving or spending the skill and creative capacity your competitive position rests on, and review it on the same cadence as your delivery metrics. 

Closing thought

The I4CS motto assumes people can still direct technology. The evidence says they can, but only inside conditions that someone has to build, and that someone is usually not the engineer. The most useful question a leader can ask this quarter is not which model to buy. It is whether those three conditions of workflow, autonomy, and governance hold for the tools already in the building. Which of the three is weakest in your organization right now, and who owns fixing it? 

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Bandura, A. (1986). Social foundations of thought and action: A social cognitive theory. Prentice-Hall.

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340.

Gioia, D. A., Corley, K. G., & Hamilton, A. L. (2013). Seeking qualitative rigor in inductive research: Notes on the Gioia methodology. Organizational Research Methods, 16(1), 15–31.

Jackson, V., et al. (2025). The impact of generative AI on creativity in software development: A research agenda. ACM Transactions on Software Engineering and Methodology, 34(5), 1–28.

Lambiase, S., Catolino, G., Palomba, F., Ferrucci, F., & Russo, D. (2026). Investigating the role of cultural values in adopting large language models for software engineering. ACM Transactions on Software Engineering and Methodology, 35(1), 1–43.

Lambiase, S., Catolino, G., Palomba, F., Ferrucci, F., & Russo, D. (2025). Exploring individual factors in the adoption of LLMs for specific software engineering tasks. arXiv preprint arXiv:2504.02553.

Rogers, E. M. (2003). Diffusion of innovations (5th ed.). Free Press.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.

Russo, D. (2026). People empower technology, when they can: Evidence-based perspectives on generative AI adoption in software engineering. In K. Kirchner et al. (Eds.), I4CS 2026, CCIS 3007 (pp. 1–6). Springer.

Russo, D., et al. (2024). Generative AI in software engineering must be human-centered: The Copenhagen Manifesto. Journal of Systems and Software, 216, 112115.

For four decades, an engineer could obtain and run the core tools of the field on the same terms as anyone else, whatever their nationality, employer, or location. Frontier AI has now broken that arrangement, and the clearest evidence arrived in a single week of June 2026.

Anthropic released Claude Fable 5 on Tuesday 9 June, the most capable model it had ever made generally available and the first public member of its Mythos class. By Friday it was gone. A United States Commerce Department export directive required the company to suspend access for any foreign national, inside or outside the country, with no exception for allied jurisdictions, and Anthropic disabled both Fable 5 and the more specialised Mythos 5 worldwide to comply. The European Commission objected on 14 June that such controls "should not be discriminatory." An engineer in Copenhagen, Lisbon, or Tallinn who had built something on Fable 5 over those few days found, by the end of the week, that the tool had been withdrawn at the source, and that nothing they could do locally would bring it back.

I do not normally write about the week's events in this newsletter. I am making an exception because the episode is not really about one company or one model. It exposes a change in the conditions under which software gets built, and the field has not yet found a good way to talk about it. The usual conversation ranks models by capability and benchmark score. The prior question, the one Fable 5 forced into view, is whether a given engineer is permitted to call the model at all, and the answer to that question now rests with a government the engineer did not elect.

Subscribe to newsletter

Why a hosted endpoint cannot be forked

The discipline grew up under an arrangement that kept its tools politically neutral, and it is worth being precise about what that arrangement was. The GNU project and the Free Software Foundation treated source code as a commons. The Internet Engineering Task Force standardised network protocols through rough consensus and running code, which kept specifications open to any implementer. Open-source software moved from the periphery to the foundation of commercial practice, and the public cloud extended the same logic to infrastructure by renting general-purpose compute to anyone who could pay. The practical upshot was that a maintainer in Nairobi could clone a repository, compile it, publish a package, and submit a patch on the same technical terms as a maintainer in Boston. None of this was ever total, since proprietary tools and trade secrets always sat alongside the commons. The claim worth defending is narrower: for roughly forty years, the artefacts the discipline as a whole relied on were available on terms that no single actor controlled.

Frontier AI changes that arrangement at its root, because the capability that now sets the ceiling of practice reaches the engineer as a hosted service rather than as a copy they hold. When access is withdrawn, the familiar engineering responses do not help, since each of them assumes you possess something you can run elsewhere. There is no local copy to mirror, no repository to fork, and no way to self-host a computation that executes on another company's hardware under another government's law. Whether you may call the endpoint at all is decided by the provider's jurisdiction of incorporation and by the sanctions and export-control rules that reach your individual request. When Fable 5 went offline, the model had not changed and no dependent system had failed. The channel had been closed, and for everyone outside the permitted jurisdiction that was enough to end the work.

It is fair to ask whether any of this is new. Electronic-design-automation suites have been export-controlled for decades, and proprietary databases were always sold under licence and embargo, so working practice has long absorbed gated tools. The difference that matters is substitutability. An embargoed tool could be re-implemented, bought through an intermediary, or replaced by a weaker but available alternative, because the thing being denied was an artefact. A hosted frontier capability offers no such route, because what is being withheld is a live computation performed somewhere you cannot reach. For as long as the denial holds, there is no partial workaround, only absence.

Where jurisdiction reaches the code

Software engineering does not have to invent a vocabulary for this from scratch, because political economy has already built one that fits. Farrell and Newman (2019) observed that economic and informational networks tend to form through preferential attachment and therefore grow lopsided, with a small number of hubs accumulating most of the connections and most of the traffic passing through them. A state that holds legal jurisdiction over such a hub can put it to coercive use in two ways: it can deny a target access by closing the hub to them, which the authors call the chokepoint effect, and it can watch the traffic of everyone who passes through, which they call the panopticon effect. Their evidence came from the exclusion of Iranian banks from the SWIFT messaging system and from the surveillance programmes disclosed by Edward Snowden, but the structure they described now maps cleanly onto the substrate of software.

Our hubs are easy to name. Package registries such as npm and PyPI are the single effective distribution point for their ecosystems. A handful of code hosts concentrate the world's collaboration. Frontier model endpoints sit in three jurisdictions. Each is a chokepoint that depends on a jurisdictional decision, and the record since 2019 is no longer hypothetical. Between 2019 and 2021, GitHub, operating under United States sanctions law, withheld private repositories and paid services from users in Iran, Syria, Crimea, Cuba, and North Korea, and restored Iranian access only after obtaining a specific licence from the Office of Foreign Assets Control. In October 2024, a patch removed several Russian-associated maintainers from the Linux kernel MAINTAINERS file, a change later confirmed to follow from sanctions compliance. The source stayed clonable by anyone, the removed maintainers included; what the sanction reached was the maintainer role, the gate through which patches enter the repository and, as maintenance research has long argued, the scarcest resource the commons has.

The compute layer underneath carries the same concentration at higher stakes, since the substrate cannot be forked or mirrored the way code can. The processors that train frontier models are designed by one firm, fabricated by another on lithography that comes from a single supplier, with high-bandwidth memory from three (Miller, 2022). Most stages of that chain have between one and three viable suppliers. When the United States extended the Foreign Direct Product Rule to reach foreign-made goods built with US-origin technology, a Taiwanese foundry was obliged to stop advanced-node production for a Chinese customer, and that customer then re-engineered its device software, build toolchains, and eventually its operating system around domestically available processors. A decision taken at one node of the chain worked its way up through every layer of software built on top of it.

Jurisdiction also reaches the engineer from the other direction, through regulation that travels well beyond the regulator's own borders. Bradford (2020) called this the Brussels Effect: European Union rules become global rules without any treaty obliging other governments to adopt them, provided the market is large, the target is hard to relocate, and production is integrated enough that firms find it cheaper to apply the strict standard everywhere than to maintain a separate variant for Europe. The General Data Protection Regulation, the Digital Services Act, and the AI Act now shape the design of systems built and run far outside the Union, so that meeting European requirements becomes a property of the code rather than a task for a legal department alone. Put the two forces together and the practical lesson is that the thing deciding what an engineer can build is no longer only the tool in front of them or the team around them. It is also the surface through which they reach the tool, and the question of whose law governs the points where that surface narrows to a few hubs.

The reason a single model can now acquire the legal status of a controlled good becomes clearer from the figure that circulated before the public Fable 5 release.

Within roughly two months, about fifty vetted organisations using the restricted Mythos programme reported more than ten thousand high- or critical-severity software vulnerabilities, a concentration of offensive capability that no gated tool of the earlier era ever placed on one side of a perimeter.

A government reads a tool that finds exploitable flaws in widely deployed software at machine speed as a weapon, and a weapon delivered through a hosted endpoint can be turned off for everyone outside the perimeter within a day. The object of state attention, in other words, was the channel rather than the artefact, which is exactly why the response took the form it did.

What denial does to the evidence

For the European researcher, the first symptom is methodological. A study that benchmarks "leading models" is drawing a jurisdictional sample whether or not it admits as much. A replication package can pin the prompt set, the scoring pipeline, and the analysis scripts, yet it cannot pin the model behind the endpoint. If that model is enrolment-gated, quietly updated, deprecated, or pulled by directive, a result reported against it can no longer be reproduced by anyone outside the perimeter, and when a hosted model is retired it takes every baseline measured against it along too. A group in the Union hoping to replicate a finding reported against Fable 5 lost that ability during the model's launch week.

This is the sort of standards-of-evidence problem that careful empirical work is built to handle, but only if the field agrees to treat the access conditions of a study as part of its design rather than as bad luck. Russo and Stol (2021) set out how to study messy socio-technical phenomena without giving up rigour, and the disruptive research playbook (Storey, Russo, et al., 2024) addresses the harder case of a technology that keeps changing the rules while it is being studied. The practical demand is modest. An AI4SE evaluation should record the jurisdictional provenance and the access channel of every model it samples, in the same spirit that survey research records the demographics of its respondents. A finding built on a capability that one jurisdiction can revoke carries a dependency, and a dependency that goes unrecorded is the usual starting point for a later argument about whether the result ever held.

There is a way to keep working, and the field has already watched it succeed. The DeepSeek R1 release of January 2025 published openly downloadable weights together with a good deal of methodological detail, which put a reasoning model of near-frontier capability within reach of any group that owns modest inference hardware (DeepSeek-AI, 2025). A model whose weights you hold is an evaluation target that stays put: it cannot be deprecated out from under a study or switched off by an order from a capital, because the researcher possesses the artefact. Seen from the access problem rather than from the older debate about software freedom, open weights are less an ideological commitment than the one form of frontier-adjacent capability whose continued availability a European team can guarantee for itself.

The connection to this newsletter's longer argument is direct. The Copenhagen Manifesto (Russo et al., 2024) holds that software engineering must stay answerable to the people who build and use it, and that tools should be judged by what they do to those people's autonomy, learning, and well-being rather than by speed alone. The conditions under which those people are allowed to build now belong to that same subject. Autonomy over one's tools, followed all the way down, turns into the question of whether one may reach the tools at all, and through the Fable 5 week that question was answered in capitals where the affected engineers have no vote.

 A jurisdictional dependency audit you can run this quarter

Work through these questions for one build-critical system. Each names a specific exposure rather than a general worry, and each has an answer you can write down.

1.     List every capability your product cannot ship without. For each, record whether you hold the artefact or only reach it through a hosted endpoint. The second category is your denial surface.

2.     For each hosted dependency, name the jurisdiction where the provider is incorporated. That jurisdiction's sanctions and export law reaches your individual requests, not only the provider's corporate conduct.

3.     Identify which dependencies have a viable open-weight or self-hostable substitute today. Where none exists, mark the capability as single-sourced and treat it the way you would treat a sole-supplier component.

4.     For your most important hosted model, write down the procedure your team would follow if access ended tomorrow without notice. An empty procedure is an unmanaged risk, not an improbable one.

5.     Audit your package and registry dependencies for maintainer accounts concentrated in one legal order. A sanction can remove a maintainer role without changing a line of source.

6.     Check whether any published evaluation your team relies on was measured against a model you can no longer access. Those baselines are no longer reproducible and should be re-grounded on a target you control.

7.     Record the access channel for every model in your own internal benchmarks. An evaluation with no documented jurisdictional sample is hard to defend once the model moves.

8.     Work out which European obligations, under the AI Act or the Digital Services Act, already reach your codebase regardless of where you operate. Compliance has become a property of the code, not a downstream legal task.

9.     Decide, explicitly, which capabilities matter enough to warrant keeping an accessible fallback at all times. This is a continuity decision, and it belongs to engineering rather than to procurement.

 Next moves

For the Builder

Keep one open-weight model running in your local toolchain even when a hosted frontier model is better, so that your ability to work does not rest on a channel you do not control. When you cite a model's behaviour in a design discussion or a postmortem, note the version and the date you accessed it, since hosted models change without announcement. Before you commit to a library, look at where its critical maintainers are based, because a dependency whose maintenance lives entirely in one jurisdiction carries a risk that no static-analysis score will show you.

For the Manager

Add one line to your dependency and vendor reviews that records the jurisdiction of each hosted capability your team relies on, and treat a single-jurisdiction frontier dependency the way you treat any sole supplier. Hold a small continuity budget for an accessible fallback model, and present it to your team as the version of the capability they can keep rather than as a downgrade. When you set a definition of done for AI-assisted work, require that any internal benchmark record the access channel of the models it used, so the team's evidence outlasts a withdrawn endpoint.

For the Roadmap Owner

Do not price a roadmap on the assumption of continuous access to one provider's frontier model, since the Fable 5 episode shows the assumption can fail inside a week for reasons no commercial relationship can prevent. Commission a map of where your build-critical capabilities concentrate by jurisdiction, and review it as a standing risk alongside cost and reliability. Treat open-weight capability as strategic infrastructure rather than a research curiosity, because it is the only frontier-adjacent option whose availability you can promise your own teams. Where European regulation already reaches your code, fund the work to meet it as product engineering, not as a compliance task that arrives late and over budget.

 Closing thought

For years the case for open tools was argued mostly on principle, about freedom and licensing. The Fable 5 week made a narrower and more practical case: an organisation outside the permitted jurisdiction lost a working capability overnight, through no fault in its own systems and with no technical way to recover it. That argument is harder to wave away than the older one, and it is going to recur, because the structure that produced it is not going anywhere. Which of the capabilities your teams depend on would survive a closed endpoint, and would you know before it happened?

 Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Bradford, A. (2020). The Brussels effect: How the European Union rules the world. Oxford University Press.

DeepSeek-AI. (2025). DeepSeek-R1: Incentivizing reasoning capability in large language models via reinforcement learning. Preprint.

Farrell, H., & Newman, A. L. (2019). Weaponized interdependence: How global economic networks shape state coercion. International Security, 44(1), 42–79.

Miller, C. (2022). Chip war: The fight for the world's most critical technology. Scribner.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.

Russo, D., & Stol, K.-J. (2021). PLS-SEM for software engineering research: An introduction and survey. ACM Computing Surveys, 54(4), 1–37.

Russo, D., et al. (2024). Generative AI in software engineering must be human-centered: The Copenhagen Manifesto. Journal of Systems and Software, 218, 112115.

Storey, M.-A., Russo, D., et al. (2024). The disruptive research playbook. ACM Transactions on Software Engineering and Methodology.

In May 2026, Pope Leo XIV released his first encyclical, "Magnifica humanitas," a text devoted to safeguarding the human person in the time of artificial intelligence (Leo XIV, 2026). He chose to present it in the Vatican alongside an unexpected guest, Chris Olah, a co-founder of Anthropic and one of the people building the frontier systems the document examines.

Olah used the occasion to say something a technology executive is not expected to say. Every frontier lab, his own included, operates inside incentives that can conflict with doing the right thing, and no amount of good intention escapes them. For that reason, he argued, the world needs people outside those incentives, governments and civil society among them, to set the limits that the labs cannot be trusted to set for themselves. "We need informed critics who will tell the labs when we are failing," he said. "We need moral voices that the incentives cannot bend" (Olah, 2026).

When a co-founder of a leading AI company travels to Rome to ask the outside world to regulate his own industry, the familiar claim that regulation is the enemy of progress has lost its most credible narrator.

The decisive question for software over the next decade is not which model your team adopts. It is whether the people who build software stay in authority over it as artificial intelligence spreads through the work, and well-designed regulation is how Europe is about to make the human-first answer binding rather than aspirational.

The dominant industry story says the opposite, treating the European Union's regulatory programme as a brake on ambition that cedes the future to firms operating under looser rules. Olah's testimony points the other way. When every commercial incentive pushes toward letting AI quietly decide more about how engineers work and how they are judged, regulation is the one force currently strong enough to hold the line on a human-first path, because that path is rarely the cheapest one in the short term, and the market will not protect it unaided.

This is not an argument against measuring software work, and it is not a complaint about developer-experience tooling. Good measurement, done at the level of the team and used to improve how people work, is part of a human-first path. The concern is narrower and sharper: the growing class of systems that use AI to evaluate, rank, and decide about individual engineers, with the human reduced to someone who approves a number the machine produced. The AI Act draws a line precisely there, and the line it draws is the clearest statement in current law of what human-first software actually demands.

Subscribe to newsletter

What a human-first path actually requires

Start with what the commitment means in practice, because the phrase is easy to wave at and hard to honour. The Copenhagen Manifesto sets out the test directly: generative AI in software engineering must be evaluated first by what people need, and only then by what the technology can do (Russo et al., 2024). A tool earns its place not by raw speed but by its effect on the wellbeing, learning, and autonomy of the engineers who use it. That ordering, people first and technology second, is the whole of the human-first idea.

The evidence on adoption explains why the ordering is not sentimental. Russo's study of generative AI adoption across software engineering, built from structured interviews with one hundred software engineers and a mixed-methods design, found that uptake is governed by individual, technological, and social factors acting together rather than by any property of the tool in isolation (Russo, 2024). The resulting Human-AI Collaboration and Adaptation Framework treats adoption as something people do inside a context, weighing whether a tool fits how they already work and who they understand themselves to be. A system that designs the person out of that context, treating the engineer as an input to be optimised rather than a professional to be supported, is working against the only mechanism by which adoption succeeds.

A human-first path, then, is not a slogan about being nice to engineers but a design discipline. It keeps a competent person in genuine authority over consequential decisions, it preserves the autonomy that lets expert judgment operate, and it refuses to let efficiency erase accountability. The question for European software is whether anything ensures teams actually build this way when the cheaper alternative is always available. Left to incentives alone, the answer is no.

Where the law draws the line

This is where the AI Act becomes concrete rather than abstract. Annex III of Regulation (EU) 2024/1689 lists the uses the law treats as high-risk, and point 4(b) names AI intended to evaluate and monitor the performance and behaviour of people in work relationships, to allocate tasks based on individual behaviour or traits, or to inform promotion and termination (European Commission, 2024). A system that scores engineers on responsiveness, reliability, or output, and routes those scores toward a decision about pay, ranking, or continued employment, falls inside that definition and inherits the full obligation set that comes with high-risk status.

Two design choices in the law make this hard to evade, and both express the human-first principle in legal form.

The first concerns profiling. Some Annex III systems can argue out of high-risk status by showing they perform only a narrow preparatory function, but the Commission's draft classification guidelines, published for consultation in May 2026, remove that escape for systems that profile a person under the General Data Protection Regulation (European Commission, 2026). Evaluating a developer's reliability and behaviour is profiling by definition, so the exemption that rescues other workplace tools does not reach this use. The law treats judging a person as categorically more serious than processing a thing.

The second choice addresses the comfortable belief that a human reviewer makes an automated scoring system safe. The guidelines reject that reasoning at its root.

"Since human involvement cannot change the purpose and area in which a system is intended to be used, it has no effect on the classification of the system as high-risk under Article 6(2)." (European Commission, 2026, para. 70)

The implication is the human-first principle stated as a rule. A human placed in the loop is there to exercise real authority over the outcome, which is a duty the law imposes under Article 14, and not a token whose presence lets the classification disappear. A manager who rubber-stamps an algorithmic ranking has not made the system safe; he has demonstrated why oversight was required to begin with. The guidelines extend the same logic to architecture, assessing a pipeline split across separate telemetry, scoring, and reporting components as a single system where its combined outputs shape a decision about a person (European Commission, 2026, para. 75). A modular design cannot launder an evaluative purpose into something the law overlooks.

Read carefully, the rule is permissive about exactly the practices a human-first team would already accept. Systems that surface neutral, objective factors such as availability or location stay outside the high-risk category. Analytics that aggregate to the team level, without ranking identifiable individuals and without feeding pay, promotion, or task allocation, also stay outside it. The boundary the regulation draws is the boundary between measuring work to help a team improve and using AI to pass judgment on a person.

Why the market will not choose this on its own

If the human-first path were also the cheapest path, no regulation would be needed. It is not, and that gap is the honest case for the law.

Individual scoring is attractive precisely because it is cheap, legible to executives, and easy to automate. A dashboard that ranks engineers on commits or closed tickets produces a number a leader can act on without understanding the work behind it. The trouble is that the number is a poor measure and an active hazard. Software value is a joint product of people, code, and process under uncertainty, and decomposing that system into per-engineer counters discards the interaction effects that explain most of the variance in outcomes. Worse, a metric attached to evaluation becomes a target within about a quarter, and from that point it measures the behaviour it rewards rather than the work it was meant to track. The cheap path is also the path that quietly degrades the thing it claims to manage.

So the market, left alone, drifts toward automation-first measurement because the costs of doing so are deferred and diffuse, while the savings are immediate and visible. This is the failure Olah named from the Vatican, an incentive structure that no single firm escapes by good intention alone. A binding floor changes that calculation by making individual developer evaluation a high-risk, accountable act, the AI Act raises the cost of the cheap path to the point where the human-first path competes on equal terms. This is what regulation is for in a domain where the externalities fall on people who have no say in the tooling imposed on them.

The objection that this burdens European firms against less-regulated competitors mistakes a liability for an advantage. A firm that builds AI to manage its engineers without accountability has not found a shortcut; it has accumulated exposure that the revised Product Liability Directive, in force across the Union from December 2026, will eventually price (European Parliament and Council, 2024). The constraint that looks like a cost is the discipline that keeps the people who build software sovereign over their own work, and that sovereignty is the asset European software should most want to protect.

The compliance clock and the wider stack

Welcoming the direction of the law does not mean the preparation is trivial, and the timing deserves precision because confusion about it is the most cited objection. High-risk obligations under Annex III were originally set to apply from 2 August 2026. A political agreement on the Digital Omnibus, reached in May 2026, would defer them to 2 December 2027, but that deferral takes legal effect only once it is published in the Official Journal, which had not happened at the time of writing. A disciplined organisation builds to the earlier date and re-baselines if the deferral is enacted. The AI literacy duty under Article 4 and the penalty regime are already live, so the readiness work is not a problem for some distant year.

Developer-evaluation systems also sit inside a wider regulatory stack that a European software organisation cannot treat in isolation. The Digital Operational Resilience Act applies to firms serving financial entities, the Cyber Resilience Act brings vulnerability reporting from September 2026 and full obligations from December 2027, and NIS2 governs secure development and incident reporting. Each regime asks for the same underlying thing, which is evidence: classification records, technical documentation, automatic logs retained for at least six months, oversight reports, and impact assessments. An organisation that builds this evidence capability once, around the human-first commitment, can serve several regimes from it rather than treating each as a separate scramble.

A readiness audit for European engineering teams

Run this against any AI system your organisation uses to observe, measure, or manage developers. Each item maps to a specific obligation, and each gap is a documented risk.

1.     Write a classification record for every developer-facing AI system, stating its intended purpose, the people it touches, and whether its output feeds a decision about an identifiable individual. The record is itself a required artefact.

2.     Decide whether the system profiles individuals under the GDPR definition. If it evaluates reliability, behaviour, or performance, treat it as profiling, and treat the preparatory-task exemption as unavailable.

3.     Trace where each output goes. If anything routes toward pay, promotion, task allocation, or termination, treat the system as high-risk, however many people review it.

4.     Confirm that automatic event logging is enabled and that logs are retained for at least six months inside your own perimeter, not only in a vendor's cloud.

5.     Document your human-oversight design under Article 14: who oversees the system, what competence they hold, and how their overrides are recorded.

6.     Verify that workers' representatives and affected developers were informed before the system went into use, as Article 26(7) requires.

7.     Produce a data protection impact assessment for systematic employee monitoring, and prepare a fundamental-rights impact assessment where the deployer scope applies.

8.     Record dated AI-literacy training for the staff and contractors who operate or oversee the system, since that obligation is already in force.

9.     Maintain a per-obligation effective-date register, defaulting high-risk dates to 2 August 2026 until any Omnibus deferral is published in the Official Journal.

10. Set retention rules deliberately: logs for at least six months, core technical documentation for ten years, with data-minimisation overrides where employee-monitoring proportionality calls for a lighter footprint.

 Next moves

For the builder

Find out what every AI tool in your workflow records about you and where those records travel. You now have a recognised stake in the answer.

When a tool's output could shape a decision about you, ask in writing for review by a named person with the authority to overturn it, and treat anything less as the rubber stamp the law was written to prevent.

Keep a regular window where you write hard code unaided. Authority over your own craft is a capability you maintain through practice, not a status the organisation grants you.

When a compliance policy is unclear to you, write down your interpretation and circulate it, since forcing the ambiguity into the open is itself an act of governance.

For the manager

Decline to supply per-engineer rankings upward, and offer team-level evidence across several dimensions instead. The regulation now gives you legal cover for a position the evidence already supports.

Translate any central compliance frame into a short operating note your team can act on within two weeks of receiving it. If you cannot, the policy is not implementable, and that finding is worth sending back upward.

Complete the worker-notification step before deploying any monitoring or measurement system, treating it as a trust-building act rather than a formality.

Protect review and thinking time as the definition of done shifts under AI assistance, so that measured speed does not consume the cognitive space on which good judgment depends.

For the roadmap owner

Treat developer-measurement AI as a high-risk system in every build-or-buy decision, and require vendors to show how their product generates the evidence the law demands inside your perimeter rather than in a dashboard you cannot audit.

Stand up a per-obligation effective-date register now, default it to the conservative dates, and assign an owner to re-baseline it the day any deferral publishes.

Fund the compliance evidence as a product capability rather than an afterthought, since the classification records, logs, and oversight reports are the same artefacts that will defend you against a future product-liability claim.

Audit your engineering operating model for practices that strip autonomy, including centralised approval bottlenecks, mandated AI tooling without an opt-out, and metric-driven performance review, each of which now carries regulatory weight on top of its cultural cost.

Closing thought

The regulation reframes a question many organisations have preferred to avoid. The version worth asking is not how to measure developers more precisely, but which of your current practices would survive being classified as a decision about a person, and what that says about those that would not. The teams that read this as paperwork will produce paperwork. The teams that read it as a chance to deliberately commit to a human-first path will end up with both compliance and better engineering. 

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

European Commission. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

European Commission. (2026). Draft guidelines on the classification of high-risk AI systems under Regulation (EU) 2024/1689 (targeted consultation, May 2026).

European Parliament and Council. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union.

European Parliament and Council. (2024). Directive (EU) 2024/2853 on liability for defective products. Official Journal of the European Union.

Leo XIV. (2026). Magnifica humanitas: On safeguarding the human person in the time of artificial intelligence [Encyclical letter]. Holy See.

Olah, C. (2026). Remarks on Pope Leo XIV's encyclical "Magnifica humanitas." Anthropic.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135.

Russo, D., Baltes, S., van Berkel, N., Avgeriou, P., Calefato, F., Cabrero-Daniel, B., et al. (2024). Generative AI in software engineering must be human-centered: The Copenhagen Manifesto. Journal of Systems and Software, 216, 112115.

In May 2026, four Ericsson engineers (Britto, Palmgren, Saini, and Ohlin) released a paper titled The AI-Native Large-Scale Agile Software Development Manifesto. The text is short and structured as a deliberate echo of the 2001 Agile Manifesto, with five value pairs, six grounding principles, and a vision statement (Britto et al., 2026). The substance of what the company is doing under the manifesto is larger than the preprint itself. Across software engineering at Ericsson, more than 1,500 engineers are now actively using a coordinated stack of AI personas, agents, and skills, with software-specification work moved from weeks to hours and testing and troubleshooting cycles moved from hours to weeks, down to minutes to days (Britto, 2026). The programme is several years old, has its origins in Ericsson's earlier work on AI-native telecommunications architecture (Iovene et al., 2023), and is one of the largest publicly described AI-native software-engineering deployments to date.

For an engineering leader, the practical question is which parts of the programme already rest on solid evidence, which parts extend past the evidence, and what the case tells us about industrial AI-native software engineering more broadly. The rest of this issue takes the programme as a single object of study and places it against the academic literature on large-scale agile and AI-assisted software engineering.

Subscribe to newsletter

Where the programme came from and what it looks like

The term "AI-native" entered Ericsson's vocabulary in 2023 in the context of telecommunications networks (Iovene et al., 2023). It was defined as a system whose architecture embeds trustworthy AI capabilities through design, deployment, operation, and maintenance, rather than treating AI as an add-on. A maturity matrix accompanied the definition, with six levels (0 through 5) across five dimensions: architecture, collaboration, data ingestion and processing, model lifecycle and security, and operations. The rows were explicitly independent, allowing different dimensions of a system to mature at different paces, and the matrix was presented as a measurement instrument rather than as a uniform target.

The 2026 manifesto carries the same conceptual scaffolding into the engineering organisation itself, with software development reorganised around AI agents in the same way that AI-native networks reorganise traffic management. The six manifesto principles can be read as a software-engineering instantiation of the original maturity dimensions: parallel-by-default processes carry the architectural commitment, orchestrated agent workforces carry the collaboration commitment, a unified semantic layer composed of code, architecture, security, and dev-intelligence knowledge graphs carries the data-infrastructure commitment, and verification-first assurance together with reusable blueprints carry the model-lifecycle and commitments. A second maturity model specific to software development (ML 0 through ML 3) operates alongside the manifesto in the company's documentation. ML 0 covers conversational LLM assistance; ML 1 adds role-based AI personas with MCP-mediated tool access; ML 2 adds the knowledge layer that grounds agent reasoning; ML 3 reorganises teams into cross-functional human-AI squads with the knowledge graph functioning as shared memory. Ericsson positions its current programme between ML 2 and ML 3 (Britto, 2026).

The operational record is detailed. The agent workforce is wired through MCP connectors into the tools Ericsson engineers already use: GitLab, JIRA, Confluence, Backstage, Jenkins, Gerrit, SonarQube, Kubernetes and Helm, and the company-internal Open Grok and Kiro CLI. The agent personas correspond to existing engineering roles, with named personas for system architecture, security, verification, UX, DevOps, coding, and bug-report assistance. The reported deployment outcomes are large but self-reported: 1,500+ engineers active, specification time down to hours from weeks, testing cycles down to minutes-to-days from hours-to-weeks. No methodology accompanies these numbers in the public material, so an academic reader should treat them as company-internal indicators rather than as research findings, although they are more specific than the manifesto preprint's prose.

Three pillars are identified as required to reach AI-native operation: change management covering governance and legal framework, technology covering commercial and internally developed tools, and cultural shift covering competence, mindset, and innovation (Britto, 2026). The third pillar is where the manifesto preprint is silent and where the academic literature on large-scale agile transformation has produced the most consistent evidence. The explicit inclusion of cultural shift as a co-equal pillar with technology and governance closes a gap that a manifesto-only reading would leave open.

Against the literature on large-scale agile

The challenges the Ericsson programme is built to address are well-documented in the systematic reviews of large-scale agile. Dikert, Paasivaara, and Lassenius (2016) reviewed 52 publications covering 42 industrial cases and reported 35 distinct challenges across 9 categories, including coordination overheads, loss of autonomy through scaling frameworks, communication barriers in distributed environments, and inconsistent understanding of requirements. Uludağ et al. (2022) extended that picture with a systematic mapping study of 136 publications, adding integration complexity, quality assurance at scale, maintaining an agile mindset during transformation, and tooling fragmentation. The Ericsson programme targets the first cluster through its parallel-by-default process and semantic-layer commitments and the second through verification-first assurance and reusable blueprints. The work is well-grounded in the agile literature, even though the manifesto preprint itself does not engage with the systematic review evidence at length.

The traditional developer writes code. The AI-native developer defines intent. The shift is from execution to direction, from being the hands on the keyboard to being the mind that decides what should be built, provides the context for how it should work, and verifies that the result is correct (Britto et al., 2026).

One strand of the large-scale agile literature is harder to align with the position the manifesto stakes out. Dingsøyr, Moe, Fægri, and Seim (2018) identified role redefinition as a primary site of friction in very large agile programmes, with the implication that any reorganisation depending on engineers performing fundamentally different cognitive work has to invest as much in the human side of the transformation as in the technology side. The cultural-shift pillar acknowledges this, but neither the manifesto nor the public deployment record describes how role conflict is being managed at the 1,500-engineer scale. Career ladders, promotion criteria, and feedback structures designed for production-dominant engineering work are unlikely to translate cleanly to an intent-and-oversight regime, and the deployment outcome data published so far provide no direct evidence on this question.

Behavior-Driven Development, the basis for the verification-first principle, raises a related concern. Irshad, Britto, and Petersen (2021) studied BDD at organisational scale and found that the dominant failure mode was scenario proliferation, contradiction, and overlap as scenarios multiplied across teams. The Ericsson programme delegates scenario management to agents capable of reasoning about scenario hierarchies, which is a plausible mechanism whose precondition is that agent verification quality match or exceed the human review it displaces. No demonstration of that equivalence currently exists in the public record, and the reported reduction in testing and troubleshooting time is consistent with several different underlying realities, only some of which involve genuinely improved defect detection.

Against the AI4SE literature

The strongest empirical cross-check on the Ericsson programme comes from research on AI adoption in software engineering teams. Russo (2024) surveyed 100 engineers qualitatively and validated the resulting model with 183 quantitative responses through PLS-SEM, identifying compatibility with existing workflows as the dominant driver of generative AI adoption, with perceived usefulness and social pressure exerting weaker effects than the standard technology-acceptance literature would predict. The Ericsson deployment is unusually well-aligned with this finding. The agent workforce is wired into tools the engineers already use, the personas correspond to roles already present in the organisation, and the knowledge graphs are populated from existing artefacts. The manifesto's prose frames the change as a paradigm shift; the deployment under it appears to be a high-compatibility roll-out by design, which is one of the more plausible reasons the reported usage figures are as high as they are.

On cognitive evidence, the case has the most remaining work to do. Two decades of automation-bias research have documented that human reviewers tend to over-trust automated recommendations under cognitive load, with the effect intensifying when verification tools deliver outputs in aggregated or high-confidence formats. AI-assisted programming exhibits the same pattern at a smaller scale, with developers accepting LLM completions whose subtle defects they would have caught while writing the code themselves (Guo, 2023). Moving engineers from production to oversight redistributes cognitive load rather than reducing it, and the public Ericsson record does not yet contain defect-rate or escape-rate data of the kind that would let an external evaluator test whether the redistribution is producing better outcomes overall. The headline productivity numbers describe throughput, not defect detection.

A final point of comparison concerns the structure of the compatibility construct itself. Russo's (2024) model treats compatibility as multi-level, with individual fit as a distinct component alongside technical and organisational fit. The Ericsson programme has invested heavily in technical and organisational compatibility through the integration of the agent workforce into existing tools and roles, and identifies cultural shift as a separate pillar requiring its own investment. Whether the individual-fit dimension has received equivalent attention, and whether engineers across the 1,500-person population are converging on the intent-and-oversight role at compatible rates, are questions the published evidence does not yet answer.

A 30-minute readiness audit for AI-native large-scale agile

The Ericsson programme is operationally testable as a list of organisational properties. The ten-item audit below can be completed in thirty minutes by a team or programme lead and produces a rough estimate of where the current operating model sits relative to the four-stage software-development maturity model the company uses.

1.     Identify the three most recent decisions reached in coordination meetings. Determine whether the same decisions could have been made if the relevant context had been queryable in a shared semantic layer instead.

2.     Count the active documents over thirty days old that engineers still treat as the source of truth. Each one is a candidate for replacement by version-controlled, machine-readable specifications.

3.     Locate the last three defects that escaped to production. For each, determine whether a Given-When-Then scenario, written before implementation, would have caught the failure.

4.     List the AI tools currently in use across the team. Mark, which operate as isolated assistants (ML 0), as role-based personas (ML 1), or as context-aware agents grounded in a knowledge layer (ML 2).

5.     Audit the current verification gates. Note which require human approval as policy and which require human approval only because no automated check yet exists.

6.     Examine the role descriptions used in the last three hires. Identify where they emphasise code production and where they emphasise specification authorship and verification.

7.     Inspect the architecture documentation. Determine whether it exists as static slides, as a queryable knowledge graph, or as something in between.

8.     Track one recent feature from requirement to deployed code. Count the handoffs that occurred and mark which of those handoffs are now automatable through agent personas.

9.     Identify a team in the organisation that has invented a successful AI-augmented practice, and determine whether the practice is captured as a reusable blueprint or as tacit knowledge.

10.  Ask three engineers to describe their primary cognitive task during a typical day, and compare their answers to the role the manifesto would have them play.

The audit functions as a diagnostic rather than a scorecard. Items the team cannot answer indicate where the current operating model differs from the Ericsson programme's, and roughly where the cost of moving each dimension up the maturity model would fall.

Next moves

For the builder

Spend the next sprint on instrumenting verification rather than production. Treat each completed task as an opportunity to refine the specifications and tests that would let an agent perform the same task next time, and adopt a personal habit of writing the Given-When-Then scenario before the implementation, even when no AI agent is in the loop. The discipline transfers regardless of which platform the organisation eventually adopts. Begin building a private knowledge graph of the systems you maintain, including dependencies, contracts, and invariants. That structure compounds in value across multiple platform changes and remains useful long after any specific tooling decision is revisited.

For the manager

Audit your team's cognitive-load profile across the week, and if the team already spends more than half its time on verification, ensure the tooling and feedback rhythms match that profile rather than a production-dominant one. Re-examine the role descriptions and promotion criteria the team is using, since a career ladder calibrated to lines-of-code throughput will quietly disadvantage engineers who succeed in an intent-and-oversight regime. Establish a recurring forum where engineers surface cases of misplaced trust in AI output and treat those cases as system signals rather than as individual failures. The "Human in Control" governance the manifesto proposes can only function with psychological safety strong enough that engineers can admit when their verification was insufficient.

For the roadmap owner

Treat the semantic-layer investment as a strategic precondition rather than as a downstream tooling choice. The Ericsson programme moved up the maturity model by building knowledge graphs across code, architecture, security, and dev-intelligence, and the rest of the model assumes that foundation. Commission an inventory of which knowledge currently lives in static documents and which lives in queryable, version-controlled structures, and map the gap. The infrastructure carries an upfront cost, and postponing it commits the organisation to incurring it later under less favourable conditions. Plan an explicit timeline for moving the engineering function up the maturity model, with measurable milestones tied to the ratio of intent-authoring time to code-authoring time, and pair the technology investment with the change-management and cultural-shift pillars Ericsson identifies as equally necessary.

Closing thought

The Ericsson programme is worth taking seriously because of its scale and its specificity. A coordinated industrial deployment across more than 1,500 engineers, organised around a defined maturity model, instrumented with a concrete tooling stack, and developed over several years, gives the AI4SE research community a richer empirical object than any single laboratory study has produced. The corresponding methodological transparency has not yet been provided, the cognitive and individual-fit dimensions remain open empirical questions, and the headline productivity numbers describe throughput rather than defect detection. For engineering leaders, the working question is which of the maturity stages the organisation can credibly reach, on which dimensions, by when, and what each move would cost in terms of the change-management, technology, and cultural-shift investments the Ericsson programme treats as equally necessary.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Britto, R. (2026, March 5). AI-native large-scale agile software development [Conference presentation]. Ericsson.

Britto, R., Palmgren, F., Saini, N., & Ohlin, M. (2026). The AI-native large-scale agile software development manifesto. arXiv. https://doi.org/10.48550/arXiv.2605.07717

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108. https://doi.org/10.1016/j.jss.2016.06.013

Dingsøyr, T., Moe, N. B., Fægri, T. E., & Seim, E. A. (2018). Exploring software development at the very large scale: A revelatory case study and research agenda for agile method adaptation. Empirical Software Engineering, 23(1), 490–520. https://doi.org/10.1007/s10664-017-9524-2

Iovene, M., Jonsson, L., Roeland, D., D'Angelo, M., Hall, G., Erol-Kantarci, M., & Manocha, J. (2023, February). Defining AI native: A key enabler for advanced intelligent telecom networks (White Paper No. BCSS-23:000056 Uen). Ericsson.

Irshad, M., Britto, R., & Petersen, K. (2021). Adapting behavior driven development (BDD) for large-scale software systems. Journal of Systems and Software, 177, Article 110944. https://doi.org/10.1016/j.jss.2021.110944

Liang, J. T., Yang, C., & Myers, B. A. (2024). A large-scale survey on the usability of AI programming assistants: Successes and challenges. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE '24) (Article 52, pp. 1–13). ACM. https://doi.org/10.1145/3597503.3608128

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135, 1–50. https://doi.org/10.1145/3652154

Uludağ, Ö., Philipp, P., Putta, A., Paasivaara, M., Lassenius, C., & Matthes, F. (2022). Revealing the state of the art of large-scale agile development research: A systematic mapping study. Journal of Systems and Software, 194, Article 111473. https://doi.org/10.1016/j.jss.2022.111473

The cohort graduating into software work in 2026 enters a labour market in which the entry-level rung has been quietly compressed by AI, and the empirical record on what happens to displacement cohorts is unambiguous.

When Eric Schmidt (former CEO at Google) addressed University of Arizona graduates earlier this month, the booing that interrupted his remarks came from students who had spent two years reading labour-market reports and who recognised, with an accuracy their elders found uncomfortable, that the rung (metaphorically, the horizontal bars on a ladder) they had trained to step onto was disappearing while they trained.

The empirical signal had arrived three months earlier. In February 2026, the Federal Reserve Bank of New York released its annual update of Labor Market Outcomes of College Graduates by Major. Computer Science and Computer Engineering had crossed a threshold most observers had not expected to see in this decade. The data placed both inside the same unemployment band as Anthropology and Fine Arts, and the safe-major thesis that had governed undergraduate decisions for three decades was, as a matter of public record, no longer supported.

The argument in this issue rests on two claims. The 2026 cohort presents the profile of a displacement cohort rather than a recession cohort, and the scarring literature is unusually clear about what that implies. The available structural responses fall into two categories, one societal and one organisational, neither of which is sufficient alone. The title compresses the logic: disarming AI is a task for the state, re-arming teams is a task for the firm.

Subscribe to newsletter

Where the entry rung is eroding

The New York Fed report released on 4 February 2026, drawing on 2024 data, places Computer Engineering at 7.8 percent unemployment among recent graduates, with 15.8 percent underemployment, a median early-career wage of ninety thousand dollars, and a mid-career median of one hundred and thirty-one thousand (Federal Reserve Bank of New York, 2026). Computer Science sits adjacent at 7.0 percent unemployment, 19.1 percent underemployment, eighty-seven thousand at entry, and one hundred and twenty thousand at mid-career.

The two computing majors now share an unemployment band with Anthropology at 7.9 percent and Fine Arts at 7.7 percent. Mid-career wages remain elevated, which keeps lifetime expected value defensible for those who survive the first five years; the open empirical question is who survives them.

The underemployment figure carries the displacement signal more clearly than the headline unemployment rate. Underemployment here means working in a role that does not require a bachelor’s degree, and for Computer Science, nearly one in five recent graduates is now in such a role. The conventional reading treats an unemployment spike as cyclical and an underemployment spike as structural; when both rise together for the most credentialed degree in the modern economy, the structural interpretation is the more economical one.

Why a bad first year scars for life

The empirical literature on cohort effects is among the most settled bodies of evidence in labour economics. Software leaders planning against the AI displacement curve without consulting it are planning blind.

Oreopoulos, von Wachter and Heisz (2012) examined Canadian graduates of the late-1970s and early-1980s recessions and found that an unlucky graduation year produced wage penalties detectable a decade later, with persistent effects even for the highly credentialed. Schwandt and von Wachter (2019) replicated the finding across the United States. Their “Unlucky Cohorts” analysis showed that graduating into a weak labour market produced durable wage suppression, elevated mortality, lower marriage rates, and reduced occupational matching, persisting into the fifth decade of life. The Stanford Institute for Economic Policy Research has summarised the policy implications of this body of work (Schwandt, 2019). The mechanism is sequential: the first job determines the second, the second determines the firm-type and the city, and these together determine the network density that shapes the next two decades. An initial mismatch entrenches rather than corrects through subsequent labour-market exposure.

The 2026 cohort is not graduating into a recession in the technical sense, since aggregate employment is not contracting as it did in 1982 or 2009. The contraction is confined to the entry-level rung. Macro demand is intact; absorption capacity for juniors has been compressed by AI tools that perform the work juniors used to do. This profile is structurally worse than the recession-cohort scenario, since in a recession the entry-level structure remains intact and waits for demand to return, whereas in a displacement scenario the rungs themselves are removed. The prudent assumption for any leader making a 2026 hiring decision is that Oreopoulos and Schwandt set a lower bound on the damage, not an upper one.

The societal lever: why regulation is the unglamorous answer

In his first encyclical Magnifica Humanitas (25 May 2026), Pope Leo XIV called for artificial intelligence to be “disarmed” and freed from the logics of domination, exclusion, and death (Pope Leo XIV, 2026). The moral framing isolates the question that the rest of the regulatory machinery is trying to answer: what does it mean to disarm a general-purpose technology that produces value precisely by being deployed at the cognitive layer where junior labour used to live?

The European regulatory stack offers the clearest available structural response. The EU AI Act, Regulation (EU) 2024/1689, classifies systems used in employment, education, and worker management as high-risk and imposes human-oversight obligations on them (European Parliament and Council, 2024a). The mechanism that matters for displacement is embedded in Article 14: by requiring a human in the loop inside the screening, allocation, and evaluation systems that decide which junior workers are hired and what work they receive, the Act imposes a compliance cost on the substitution of automation for entry-level labour, and that cost is the channel through which the displacement rate can plausibly be slowed.

The Platform Work Directive, Directive (EU) 2024/2831, addresses algorithmic management. It establishes a presumption of employment for platform workers and imposes transparency obligations on the algorithms that assign, rate, and dismiss them (European Parliament and Council, 2024b), slowing the conversion of stable entry-level roles into gig-style displacement. The Digital Services Act and the Data Act sit upstream, raising the cost of opaque automated decision-making.

No empirical evidence yet exists that the European stack will measurably slow graduate displacement; the Act came into force too recently for outcome studies to be possible. The case for treating it as a lever rests on mechanism rather than on outcome data. If displacement is occurring at the cognitive layer of work, regulation that imposes human oversight at that same layer is the structurally appropriate response, and waiting for outcome studies mirrors the more general problem of waiting for the wage-scarring data on the displacement cohort itself: by the time either data set exists, the cohort it would document has already absorbed the damage.

The empirical record on cohort scarring replicates across Canadian, American, and European datasets, and the mechanism by which AI compresses the entry rung produces equivalent dynamics in San Francisco and in Stockholm. Whether regulation is the correct response remains analytically open. Whether some structural response is needed is settled by the data, and the European stack is the most articulated answer currently on offer.

The organisational lever

Regulation operates at the macro level and acts slowly. Inside the firm, the lever is team composition, and the empirical record here is sharper than the regulatory one.

What we actually know about diversity in software teams

Verwijs and Russo (2024) analysed 1,118 software engineers across 161 teams using covariance-based structural equation modelling. The frame was the categorisation-elaboration model, which integrates two opposing predictions: diversity expands the cognitive resources available to a team, and diversity also produces social categorisation and relational conflict that erode outcomes. The study tested four diversity dimensions, gender, age, cultural background, and functional role, with psychological safety as a social moderator. The model fit the data well (CFI = .988, RMSEA = .036) and explained 40.7 percent of variance in team effectiveness.

The result that matters for this issue

Among the four dimensions, only age diversity produced a statistically significant positive effect on team effectiveness. Gender, cultural, and role diversity produced no significant positive effect. Gender diversity was associated with higher relational conflict. Psychological safety contributed substantially both to effectiveness and to lower conflict, but it did not moderate the diversity-effectiveness link. The analytically important result is the asymmetry across the four dimensions, not the existence of a diversity effect in general.

“Only age diversity improves team effectiveness directly. In other words, teams are more effective when their members vary in age. This is probably a proxy for differences in tenure and experience that encourage innovation and creativity. However, generational differences in work values have also been found to be relevant. Either way, this is in support of cognitive resource diversity theory and its prediction that diversity expands cognitive resources that teams have access to” (Verwijs & Russo, 2024, p. 151).

The standardised coefficient for the age-diversity effect was .213 at p < .05, and the coefficient for psychological safety on effectiveness was .660 at p < .01. These two findings carry most of the model’s explanatory weight.

Why age diversity buys what AI is destroying

The age-diversity finding inherits its mechanism from Pesch, Bouncken and Kraus (2015), who argue that age diversity is best understood as a proxy for tenure heterogeneity and accumulated work experience rather than chronological age. Age-mixed teams contain, by composition, the tacit knowledge that has to be transmitted from those who have it to those who do not.

This mechanism becomes load-bearing in a workflow compressed by generative AI. Junior engineers historically produced the artefacts through which they learned: boilerplate, small bug fixes, refactored legacy modules, and through that production developed the muscle memory of competent practice. AI now produces those artefacts faster than juniors can. The artefacts arrive in the codebase, the codebase compiles, and the juniors learn nothing, because the learning was in production.

Tacit knowledge is the second-order casualty of this compression. Production has been automated, so tacit knowledge can no longer be acquired through producing artefacts; it can only be transmitted relationally from someone who already holds it. Age-mixed teams are the institutional carrier of that transmission; tenure-homogeneous teams, whether all-junior or all-senior, break the belt. The Verwijs and Russo finding, therefore, does more empirical work in 2026 than it did in 2024, because the mechanism it identifies is precisely the mechanism that AI workflow compression destroys at the cohort level, and that team design can restore at the firm level.

Connecting the two levers

The two levers are complementary, and their relationship is asymmetric in time. Regulation alone cannot create mentorship inside a firm: the AI Act can constrain the rate at which juniors are displaced from the labour market, but it cannot oblige the seniors inside any given firm to allocate the calendar hours required to transmit tacit knowledge. That allocation remains an organisational choice. Team design alone, conversely, cannot stop displacement at the macro level. Firms that wait for regulation to force the issue will discover, around 2031, that the cohort gap is no longer repairable, because the seniors who could have trained the missing juniors will themselves have retired, and the juniors who could have learned from them will have left the field.

The playbook: an organisational audit

Eight diagnostic actions a software organisation can run this quarter. Each item below is framed as a measurement the team can take rather than as an aspiration the team can hold.

1.        Compute the tenure standard deviation per team. Flag any team where the standard deviation is below the firm-wide median minus one standard deviation. These are tenure-homogeneous teams, regardless of how the head count was selected.

2.        For each engineer hired in the last twelve months, measure the proportion of merged code in their first six months substantially authored by them without AI assistance. A proportion under 25 percent is a transmission-belt failure signal.

3.        Audit whether mentorship time is logged. Mentorship that is not logged is, in practice, not happening, and mentorship that is logged but does not carry weight in performance review operates on borrowed time.

4.        Audit how the firm reads the AI Act. A compliance-only reading treats it as a tax. A strategic reading treats it as a planning constraint that shapes the rate at which competitors can substitute automation for entry-level labour.

5.        Measure psychological safety using a validated instrument rather than a culture survey. The Verwijs and Russo coefficient of .660 was obtained because the construct was operationalised through an established scale.

6.        Cross-tabulate the firm’s graduate hiring rate against its AI-tooling spend over the last twenty-four months. If the two move in opposite directions without an explicit policy decision documenting why, the firm has made a strategic choice by drift.

7.        Identify the three engineers who hold the most tacit knowledge about systems older than five years and audit their calendars for transmission time. Where peer meetings fill the week, and meetings with juniors are absent, the firm is consuming its seniority capital rather than reproducing it.

8.        Examine the firm’s reading of the Platform Work Directive. Even firms without platform workers are affected by the signal it sends about algorithmic management transparency.

Next moves

For the Builder

Position yourself in an age-mixed team and stay there. Over the next five years, the asset that compounds in value is the senior engineer you are paired with; language models will continue to improve, but they do not transmit tacit knowledge, and senior colleagues do. Identify which seniors hold tacit knowledge in your firm and find reasons to share work with them, even when AI would let you finish the task alone. Read structural signals carefully: a team with a flat tenure distribution, a graduate hiring rate below replacement, and a manager who measures throughput but not learning. These predict where you will be in 2031.

For the Manager

Read your team’s tenure distribution as a leading indicator of two-year effectiveness rather than as a demographic statistic. A team converging toward tenure homogeneity in either direction has lost the transmission mechanism, and the loss becomes visible only later, when seniors leave, or juniors stall. Defend junior head count against short-horizon AI productivity arguments by stating the asymmetric risk: the firm can recover from a year of lower throughput more easily than from a generation of missing engineers. Pair psychological safety with age mixing rather than treating one as a substitute for the other; the Verwijs and Russo data indicate that the two are independent contributions and that safety does not moderate the diversity effect.

For the Roadmap Owner

Treat graduate hiring as institutional research and development. The accounting framing of graduates as a cost centre understates the option value of seniors trained inside the firm five years out, and the demographic arithmetic linking the 2026 cohort to the 2035 leadership is not negotiable. Reframe the AI Act as a strategic planning constraint rather than a compliance tax. The same constraint shapes the rate at which competitors can substitute automation for labour, which converts it from a firm-level tax into an industry-wide pacing mechanism. Commit to a documented hiring floor for graduates over the next three years and report against it.

Closing

The students who interrupted Eric Schmidt at the University of Arizona were responding to the assumption that their displacement was an acceptable price for someone else’s optimisation, and the labour-market data released three months earlier had already vindicated their reading. Their objection was directed at the political economy in which AI is currently being deployed, not at the technology itself.

The two-lever argument that this issue has set out runs as follows. At the level of the state, disarming AI means imposing human-oversight requirements that constrain the rate at which juniors can be substituted out of the cognitive workflow.

At the level of the firm, re-arming teams means restoring the age-mixed composition that allows tacit knowledge to be transmitted through the transmission belt that the workflow compression has cut.

Both responses operate inside the same closing window.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

European Parliament and Council. (2024a). Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

European Parliament and Council. (2024b). Directive (EU) 2024/2831 of the European Parliament and of the Council on improving working conditions in platform work. Official Journal of the European Union.

Federal Reserve Bank of New York. (2026). Labor market outcomes of college graduates by major. Federal Reserve Bank of New York.

Oreopoulos, P., von Wachter, T., & Heisz, A. (2012). The short- and long-term career effects of graduating in a recession. American Economic Journal: Applied Economics, 4(1), 1–29.

Pesch, R., Bouncken, R. B., & Kraus, S. (2015). Effects of communication style and age diversity in innovation teams. International Journal of Innovation and Technology Management, 12(6), 1550029.

Pope Leo XIV. (2026, May 25). Magnifica Humanitas [Encyclical letter on artificial intelligence]. Holy See.

Schwandt, H. (2019). Recession graduates: The long-lasting effects of an unlucky draw [Policy brief]. Stanford Institute for Economic Policy Research.

Schwandt, H., & von Wachter, T. (2019). Unlucky cohorts: Estimating the long-term effects of entering the labor market in a recession in large cross-sectional data sets. Journal of Labor Economics, 37(S1), S161–S198.

Verwijs, C., & Russo, D. (2024). The double-edged sword of diversity: How diversity, conflict, and psychological safety impact software teams. IEEE Transactions on Software Engineering, 50(1), 141–160.

After three years of GenAI adoption in software engineering, the empirical literature has stabilised enough to do something the field could not do a year ago: separate the productivity claims that have survived contact with data from the claims that have not, and the claims nobody has yet bothered to test.

A new TOSEM-accepted systematic review by Mohamed, Assi, and Guizani (2026) gives us the cleanest stocktake to date. The authors synthesise 39 peer-reviewed studies on LLM-assistants and developer productivity, drawn from an initial pool of 9,756 records spanning January 2014 through December 2024. Thirty-five of those 39 studies were published after the release of ChatGPT in November 2022. Seventy-seven percent appeared in 2024 alone. The field is, in other words, both younger and noisier than the industry conversation around it would suggest.

This issue is a stocktaking exercise. It asks where the evidence is now hardened, where it is still pulling in opposite directions, and where the questions executives and engineering leaders keep asking in planning meetings have produced almost no published findings at all.

The shape of the map matters. Many of the operational decisions organisations are making right now, headcount planning, vendor renewal, onboarding redesign, tooling consolidation, ride on claims that fall into the contested or under-studied buckets, not the well-evidenced ones. The first useful act is to know which is which.

Subscribe to newsletter

What the evidence has settled

The well-evidenced cluster centres on perceived speed and the displacement of routine work. Across the 39-study corpus, the most frequently reproduced finding is that developers experience LLM-assistants as accelerators on bounded coding tasks (Mohamed et al., 2026). Ziegler et al. (2022), one of the earliest large-scale Copilot productivity assessments, reported that developers’ self-rated productivity correlated tightly with their suggestion acceptance rate. Liang et al. (2024) extended this to a large multi-product usability survey of professional developers and found that perceived usefulness clusters around three task types: writing boilerplate, recalling syntax, and generating first drafts of well-specified routines.

Three claims have been replicated consistently enough to be treated as evidence.

The first is that developers feel faster on bounded tasks. The self-perception is robust across study designs, languages, and tool families. It is also a self-perception, and Mohamed et al. (2026) note that 90% of the included studies rely on self-reported productivity data. The acceleration claim, therefore, has the same epistemic status as user-satisfaction data: it is real, it is informative, and it is not interchangeable with behavioural measurement.

The second is that AI is genuinely useful for boilerplate. Repetitive scaffolding, standard API calls, regex composition, structured tests, and conventional CRUD patterns are where time-to-completion drops most consistently across the corpus. This finding is unusual in that it survives the transition from lab tasks to field studies relatively intact.

The third is that junior and senior developers benefit differently. Junior engineers report larger absolute speed gains on tasks in unfamiliar territory; senior engineers report smaller absolute gains but place more weight on cognitive offloading and on reduced context-switching to web search (Liang et al., 2024). The differential matters for hiring strategy and onboarding: the same tool produces qualitatively different productivity profiles depending on where the user sits on the experience curve.

These three claims should now be treated as load-bearing in any productivity narrative your organisation builds. The earlier debate about whether developers feel faster at all has effectively closed.

Where the evidence pulls in opposite directions

The contested cluster is narrower but more consequential, and it begins with the question executives most want answered.

Code quality is the marquee dispute. Mohamed et al. (2026) state the position bluntly in their abstract: whether LLM-assistants improve or degrade code quality remains unresolved, with existing studies reporting contradictory outcomes contingent on context and evaluation criteria. Some studies report that AI-generated code increases compliance with style guides and reduces certain classes of trivial typographic errors. Others find elevated rates of unsafe patterns, missing error handling, and silent regressions when generated code is accepted without thorough review. The contradiction reflects genuine sensitivity to which programming language, which task complexity, which evaluation rubric, and which baseline developer experience level the study uses. Two studies can both be methodologically sound and disagree because they are measuring different things under the same word.

The second contested claim is net team productivity. The individual-level perceived-speed finding does not aggregate cleanly to teams. Studies that measure throughput at the squad or pull-request level find smaller, more variable, and sometimes null effects compared with individual self-reports. Whether this is because individual gains are absorbed into review and coordination overhead, or because team-level measurement catches confounds that lab tasks cannot, is unresolved. The systematic review classifies 38% of the corpus as laboratory experiments and only 23% as field studies (Mohamed et al., 2026). The lab-to-team translation is doing more rhetorical work than the data supports.

The third contested claim concerns defect implications under maintenance. Several studies report short-term defect rates that are statistically indistinguishable from baseline. None of them follows the resulting code into a maintenance horizon long enough to observe whether the defect distribution shifts later. This is a problem of study design, not of absence of signal: the field has been operating on observation windows measured in weeks, not quarters.

What we still do not know

The under-studied cluster is the section of the map where the industry has the most confident opinions and the academy has produced the least evidence. The contrast is sharp enough that the systematic review identifies it as the most consequential gap in the field.

While the majority of studies (90%) adopt a multi-dimensional perspective by examining at least two SPACE dimensions, only 15% extend beyond three dimensions, indicating substantial room for more integrated evaluations (Mohamed et al., 2026).

The two SPACE dimensions most consistently underexamined are Communication and Activity (Forsgren et al., 2021). What this means concretely is that the literature has plenty to say about how an individual developer feels after using Copilot for thirty minutes, and almost nothing to say about how a team’s review cadence, merge cycle, and on-call rotation change after six months of adoption.

Four questions sit in this empirical gap and deserve naming.

1. Long-term skill effects. Whether sustained reliance on LLM-assistants atrophies the foundational capabilities that allow senior engineers to verify generated output is, at present, a hypothesis rather than a finding. Mohamed et al. (2026) catalogue cognitive offloading as a documented risk, but the longitudinal observation required to test the skill-erosion claim does not exist in the published literature.

2. Team coordination. The SPACE Communication dimension covers exactly the practices most likely to shift as AI authorship becomes routine: pair-programming frequency, asynchronous review patterns, and the way knowledge transfers between senior and junior engineers within a codebase. The review identifies this dimension as underexplored across all 39 studies.

3. Code review burden. If junior engineers ship more code faster, senior reviewers carry more verification load. No study in the corpus measures this redistribution systematically. The productivity gain reported at the IC level may, in aggregate, be a re-routing of effort up the seniority ladder rather than a net team gain.

4. Maintenance debt. The cost of accepted but minimally understood code surfaces months later, in incident response, refactor cycles, and the quiet erosion of architectural coherence. Studies in the corpus operate on observation windows too short to detect this signal. Any organisation treating today’s perceived-speed gains as a guarantee of tomorrow’s delivery throughput is making a forecast the literature cannot underwrite.

Why the corpus reads the way it does

Three methodological features of this evidence base shape how much weight any claim should carry, and they apply uniformly across all three buckets.

First, the corpus is recent and concentrated. With 77% of included studies published in 2024 (Mohamed et al., 2026), the field has not had time for replication or for the natural correction process that distinguishes a finding from an artifact. Replication culture in software engineering is already weaker than in adjacent disciplines; in a literature this young, it has barely had time to begin.

Second, self-report dominates. Ninety percent of included studies use self-reported productivity data. Only 15 of 39 use validated instruments such as NASA-TLX, the SPACE questionnaire, or the technology acceptance model (Mohamed et al., 2026). Self-report is not invalid; it is decisive evidence for satisfaction and perception. It is poor evidence for throughput, defect rate, or coordination cost. Confusing the two is the most common rhetorical move in industry productivity narratives.

Third, tool sampling is narrow. ChatGPT (15 studies) and GitHub Copilot (14 studies) account for the majority of the corpus. Tabnine, GPT-4, and CodeWhisperer appear in three studies each; Claude, Codex, Gemini, and roughly a dozen other tools appear once. The generalisation from “Copilot in 2024” to “AI coding tools in 2026” is doing analytical work that the evidence base does not cleanly support. Findings about a specific tool in a specific year carry only as far as the tool and the year.

These caveats do not invalidate the well-evidenced cluster per se; they calibrate the confidence interval around it. Russo (2024) makes a parallel argument from a different angle: that adoption outcomes in software engineering depend on a tight match between tool affordances, individual workflow, and team context, and that the same tool can produce different productivity signatures in different organisations.

A 30-minute drill: which of your AI productivity claims are actually evidenced?

Run this audit in your next planning session. The goal is to locate every productivity claim circulating inside your organisation on the three-bucket map, then to identify which operational decisions are currently sitting on claims the literature does not support.

1.        Pull the last six weeks of internal messaging on GenAI productivity. Slack threads, all-hands slides, vendor decks, board updates, internal blog posts. Extract every specific productivity claim. Aim for 15 to 25 claim sentences.

2.        For each claim, ask which SPACE dimension it concerns: Satisfaction, Performance, Activity, Communication, or Efficiency. Discard claims that do not map cleanly. They are not falsifiable enough to audit, which is itself a finding.

3.        Place each remaining claim into one of three buckets. Well-evidenced if it concerns perceived speed on bounded tasks, boilerplate displacement, or junior-versus-senior productivity differentials. Contested if it concerns code quality, team-level throughput, or short-horizon defect rates. Under-studied if it concerns long-term skill effects, coordination patterns, code review burden, or maintenance debt.

4.        Count what is in each bucket. Most organisations find that roughly half of their public productivity claims sit in the contested or under-studied buckets. That ratio is the first useful number the audit produces.

5.        For every claim in the contested bucket, write one sentence naming the context contingency: which language, which task complexity, which baseline developer experience, which evaluation rubric. If the claim cannot survive the addition of that sentence, retire it from internal communication until you can.

6.        For every claim in the under-studied bucket, name the metric that would, in principle, falsify it. If no metric exists, the claim is rhetoric and should be re-labelled as a hypothesis your organisation is testing, not a finding it relies upon.

7.        Identify one operational decision currently riding on a contested or under-studied claim. Headcount planning, vendor renewal, tooling consolidation, hiring criteria, onboarding redesign. That decision is the one most exposed to evidence reversal.

8.        Set a six-month re-audit date. The field is publishing fast enough that the three buckets will move within two cycles. Build the re-audit into your roadmap review cadence so the map updates as the evidence does.

The output of the drill is a single page with three columns of claim statements, one operational decision flagged for sensitivity testing, and a re-audit date. That single page is more rigorous than most AI productivity narratives currently in circulation.

Next moves

For the Builder

1.        Track your suggestion acceptance rate alongside the time you spend correcting accepted suggestions. The first number is what tool marketing optimises for. The second is the one Ziegler et al. (2022) treat as decisive. The ratio of the two is your honest personal productivity signal.

2.        Separate your speed gain on boilerplate from your speed gain on novel logic. The first is reproducible across studies and across people. The second varies by task complexity and is where your professional judgment still does the most work. Conflating the two leads to overconfidence in exactly the situations where LLM output is most likely to mislead.

3.        Add a verification step to your workflow that does not depend on the model. A failing test written before generation, a static-analysis pass after generation, or a peer review on any function above a chosen complexity threshold. The cognitive offloading risk catalogued by Mohamed et al. (2026) is mitigated by routine, not by vigilance.

For the Manager

1.        Build a team-level dashboard that pairs SPACE Performance and SPACE Efficiency with at least one Communication metric. Review cycle time, pair-programming frequency, or knowledge-transfer signal. The literature has shown that Performance and Efficiency improve in isolation; whether your team’s coordination layer is paying the bill is a question your dashboard, not the literature, must answer.

2.        Run a quarterly code review burden check. Compare the volume and complexity of changes submitted by junior engineers against the time senior reviewers spend on them. If the second number is climbing faster than the first, the productivity gain is being redistributed inside the team, not realised by it.

3.        Protect time for non-AI authorship in onboarding. The long-term skill effect is the hypothesis with the weakest empirical base and the largest organisational consequences. A six-month onboarding rotation that includes at least one project written without LLM assistance is cheap insurance against a risk the literature cannot yet measure.

For the Roadmap Owner

1.        Move productivity reporting from individual perception to team-level outcome. The acceleration claim is well-evidenced at the individual level and contested at the team level. Reporting only the first overstates the second, and overstating the second is how organisations make irreversible headcount and tooling decisions on reversible evidence.

2.        Fund a longitudinal observation capability. A code provenance log that tags AI-assisted commits, then surfaces defect, refactor, and incident rates against that tag at twelve and twenty-four months. This is the measurement infrastructure the academic field does not yet have, and building it inside your own organisation will outpace the publication cycle by years.

3.        Tie tool vendor renewal to a written claim audit. Ask which of the vendor’s stated benefits sit in the well-evidenced bucket, which in the contested bucket, and which in the under-studied bucket. The conversation that follows is the first one most organisations have ever had with a GenAI vendor on empirical terms. It is also the one most likely to reset the contract.

Closing thought

The honest summary of three years is that perceived speed has hardened into evidence, code quality has hardened into a controversy, and almost everything that matters at the team and maintenance horizon is still a hypothesis. Most operational decisions about AI coding tools currently rest on the second and third categories. Which of the productivity claims your leadership team repeats most often would survive the 30-minute drill in your next planning session?

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity: There’s more to it than you think. ACM Queue. https://doi.org/10.1145/3454122.3454124

Liang, J. T., Yang, C., & Myers, B. A. (2024). A large-scale survey on the usability of AI programming assistants: Successes and challenges. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE ’24). IEEE/ACM.

Mohamed, A. (2026). The impact of LLM-assistants on software developer productivity: A systematic review and mapping study. ACM Transactions on Software Engineering and Methodology. Advance online publication. https://doi.org/10.1145/3809494

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(8), Article 221, 1–5. https://doi.org/10.1145/3652154

Ziegler, A., Kalliamvakou, E., Li, X. A., Rice, A., Rifkin, D., Simister, S., Sittampalam, G., & Aftandilian, E. (2022). Productivity assessment of neural code completion. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming (MAPS ’22) (pp. 21–29). ACM.

The central failure of AI evaluation today is not that organizations test too little. It is that they test with instruments they have never validated.

Every engineer who has ever participated in a tool selection process for AI-assisted development has encountered benchmark scores. Models are compared on HumanEval, SWE-bench, or some proprietary internal suite. Procurement decisions follow from those comparisons. Leadership asks which tool "scores highest." The benchmark has become the evidence base for adoption decisions that affect team cognition, code quality, and engineering culture. The question nobody asks loudly enough is whether the benchmark measures what it claims to measure.

In a systematic review of 445 LLM benchmarks published at leading machine learning and natural language processing conferences, Bean et al. (2025) found that nearly every reviewed benchmark had weaknesses in at least one dimension of construct validity. Construct validity, a concept originating in psychological measurement (Cronbach & Meehl, 1955), refers to the degree to which a test score provides evidence for claims about the target phenomenon. A benchmark with high construct validity actually measures the capability it claims to measure. Most of the benchmarks currently driving AI adoption decisions in software engineering do not meet this standard, not because researchers are careless, but because the field has not yet developed the shared standards that rigorous measurement requires.

The argument in this article is specific: given the volume of organizational decisions now anchored to benchmark scores, a poorly designed benchmark causes more harm than no benchmark at all. It creates false certainty. And in an environment where engineering leaders, managers, and practitioners act on performance numbers, false certainty is operationally dangerous. The number that ends the evaluation process is not a fact but a proxy, and most proxies in use today are poorly constructed.

Subscribe to newsletter

When the thing being measured has no agreed-upon definition

Construct validity begins before a single task is designed or a single prompt is written. It begins with the phenomenon: the capability or behavior the benchmark is intended to measure. If that phenomenon is not defined precisely, the benchmark cannot be validated against it. Thus, it determines whether the number at the end of the evaluation process refers to anything stable in the world.

Bean et al. (2025) found that 21.7% of the 445 reviewed benchmarks provided no definition of their target phenomenon at all. A further 47.8% of those that did provide a definition targeted phenomena whose meaning is actively contested in the research community. That means roughly half of the reviewed benchmarks are measuring something whose conceptual boundaries nobody has formally agreed on. "Alignment" is the paradigm case: benchmarks claiming to measure alignment frequently operationalize contested sub-concepts such as "harmlessness" without specifying which of the competing definitions they apply. A high score on such a benchmark does not tell you that a model is aligned. What it tells you is that the model performed well on one implicit operationalization of a concept that the field disputes.

The composite-phenomena problem compounds this. Bean et al. (2025) found that 61.2% of reviewed benchmarks target phenomena that consist of sub-components rather than a single unified capability. An "agentic capability" benchmark might combine intent recognition, structured output generation, and alignment checking into a single aggregate score. That score cannot tell you which sub-component a model succeeds or fails on. For a software engineering team adopting an AI coding assistant, this gap has direct consequences: a tool that performs well at structured output but fails at intent recognition will produce syntactically clean code that misunderstands what the developer asked for. The composite score will not flag this.

In software engineering evaluation, the standard capability categories follow the same pattern. "Code generation quality" routinely aggregates functional correctness, security posture, maintainability, and documentation quality into a single number. A benchmark that reports one score for "code generation" is likely capturing test-passing functional correctness and little else. Every other dimension of quality that software engineering practice actually requires is unmeasured, unreported, and invisible to the adoption decision.

How sampling decisions and metric choices contaminate the number

Even a well-defined phenomenon can produce misleading benchmark scores if the tasks used to measure it are not representative, or if the scoring method fails to track the thing that matters.

Bean et al. (2025) found that 39.3% of reviewed benchmarks relied at least partially on convenience sampling, selecting task items because they were accessible rather than because they were systematically representative of the target capability space. A further 38.2% reused items from prior benchmarks or human examinations without adjusting for the validity problems those sources carry. Bean et al. (2025) offer a precise illustration: the AIME mathematics examination was designed for hand calculation, so its numbers were specifically chosen to remain arithmetically tractable. An LLM benchmark built on AIME items will systematically undertest the capability that actually distinguishes models in practice, which is performance on larger numbers where LLM arithmetic tends to fail. The benchmark does not measure arithmetic ability as it occurs in real deployment; it measures performance on a human examination that was never designed to probe LLM weaknesses.

A further 31.2% of reviewed benchmarks generated task items using LLMs themselves (Bean et al., 2025). This introduces a circularity that undermines validity in a specific way: LLM-generated items reflect the distributional tendencies of the generating model, which are not necessarily representative of the full capability space, and may systematically avoid the edge cases where the evaluated model fails. A benchmark that an LLM helped design may be easier for LLMs to pass than one designed by domain experts with access to known failure modes.

The scoring layer amplifies the problem. Exact matching was used at least partially in 81.3% of reviewed benchmarks and served as the exclusive metric in 40.7% of them (Bean et al., 2025). Exact matching is computationally convenient and requires no human judgment. It is also a thin proxy for most software engineering capabilities. Whether a model produces output that matches a reference string is not the same question as whether the model's output is correct, secure, readable, or well-tested in a real codebase. A code generation model that scores 90% on an exact-match benchmark may produce consistently poor code in deployment because the benchmark never asked whether the code was maintainable or free of security vulnerabilities.

The most striking figure in the entire review concerns statistical inference:

"At present, only 16.0% of reviewed benchmarks conducted any statistical testing." (Bean et al., 2025)

Eighty-four percent of benchmarks currently cited in research papers, used to select AI tools, and referenced in product comparisons, contain no uncertainty quantification. A model that scores 73.1% on a benchmark and a competitor that scores 72.3% are reported as having different scores, but no analysis determines whether that difference is stable, replicable, or statistically distinguishable from noise. The field routinely ranks models by numbers it has not tested for significance, then uses those rankings to direct research effort and justify adoption decisions worth considerable organizational investment.

When the score and the claim no longer correspond

The final layer of the construct validity problem is the gap between what a benchmark actually measures and what researchers claim it measures. Bean et al. (2025) found that only 53.4% of reviewed benchmarks included any evidence that the benchmark is a valid measure of the phenomenon it claims to assess. Nearly half of the published LLM benchmarks do not attempt to justify the inferential chain from score to capability claim.

In clinical diagnostics, this failure mode has a precise name. A diagnostic test with poor specificity generates false positives. A blood glucose meter that reads 15% above actual values does not fail neutrally: patients with diabetes appear better controlled than they are, physicians reduce insulin doses, and patients deteriorate. The instrument actively replaces accurate uncertainty with confident error. Clinical epidemiologists formalized this logic decades ago: a test whose likelihood ratio approaches 1 provides no information, but a test with negative predictive value causes harm by displacing the careful judgment that would have operated in its absence. The instrument does not merely fail to help, but it makes decisions worse because it makes false confidence seem warranted.

Software benchmarks operate under the same logic when construct validity is low. An organization that selects an AI code review assistant based on a benchmark using convenience-sampled tasks, exact-match scoring, no statistical testing, and no validity justification has purchased a number. When that number fails to predict real performance on real code, the organization rarely concludes that the benchmark was the problem. It concludes that AI is unpredictable, or that the model was overhyped. The benchmark has not merely measured the wrong thing; it has made rigorous evaluation feel like it was already done.

The case against relying on a poorly designed benchmark, rather than conducting no formal benchmark at all, follows directly from how decisions work under uncertainty. An organization with no performance data knows it is uncertain and calibrates its confidence accordingly. An organization with an invalid benchmark score believes it has resolved that uncertainty. The second organization will make worse decisions with greater confidence. That is the condition a bad instrument reliably produces, and it is the reason the choice between a valid benchmark and no benchmark is not symmetric with the choice between any benchmark and no benchmark.

What a valid benchmark actually requires

Bean et al. (2025) provide eight recommendations for improving construct validity in LLM benchmarks. Applied to the practitioner context, they reduce to a set of questions any team should ask before relying on a benchmark score:

1.   Is the phenomenon explicitly defined? If the benchmark paper does not specify what is being measured and what the definition excludes, the score has no interpretable reference point.

2.  Is the task ecologically valid? Fewer than 10% of reviewed benchmarks used complete real-world tasks. If the benchmark task does not resemble how a model is actually deployed, the score may not transfer to production.

3.  Was the sampling principled? Convenience sampling, present in 39.3% of reviewed benchmarks, selects for availability rather than representativeness. Check whether the benchmark paper describes a systematic sampling rationale.

4.  Does the metric capture the phenomenon? Exact matching, the dominant metric in 81.3% of benchmarks, measures string identity, not capability. Identify which metric was used and what it leaves unmeasured.

5.  Are uncertainty estimates reported? A benchmark without confidence intervals or significance tests cannot determine whether a score difference between models is real or an artifact of sampling variance.

6.  Was contamination checked? If benchmark test items appear in common LLM pretraining corpora, the score measures memorization rather than capability. Recommend canary strings and held-out item sets for ongoing verification.

7.  Is there an error analysis? A valid benchmark should characterize failure modes. Without an error typology, it is not possible to determine whether a model fails because of the target phenomenon or because of a confounding task.

8.  Is the validity claim explicit? The benchmark paper should articulate why this task, scored by this metric, supports claims about this phenomenon. In 46.6% of reviewed benchmarks, it does not.

Next moves

For the builder

•     Before treating any benchmark score as evidence for a tooling decision, check the benchmark's original paper against the eight criteria above. Fewer than five criteria satisfied should substantially reduce your confidence in the score.

•     Construct a small evaluation set from your actual codebase, using tasks that reflect real engineering work. A model that scores well on a published benchmark but poorly on your representative tasks is giving you accurate information that no leaderboard can provide.

•     When a model provider cites a benchmark score in documentation or marketing material, identify which metric was used. An exact-match score on a multiple-choice dataset carries substantially less information about production behavior than an ecologically valid evaluation on realistic tasks.

•     Log cases where AI output failed in ways the cited benchmark would not have predicted. Over time, this produces a calibration record more relevant to your context than any published leaderboard score.

For the manager

•     Establish a team norm: before any benchmark score enters a tooling or adoption discussion, someone must describe what the benchmark actually measures and what it does not. This takes two minutes and filters a common category of procurement error.

•     When commissioning internal evaluations of AI tools, define the evaluation criteria before any tool is tested. Post-hoc criteria are susceptible to the same construct validity failures as published benchmarks, without the peer review.

•     Treat score differences of one or two percentage points between models as noise until uncertainty estimates indicate otherwise. Without reported variance, small score differences are not reliable signals of capability differences.

•     Run a structured pilot in which your team evaluates tools on a sample of actual work tasks from the past quarter. Ecological validity, the correspondence between the evaluation context and the deployment context, is the dimension most consistently absent from published benchmarks and most directly within your control.

For the roadmap owner

•     When AI adoption strategy references benchmark comparisons, require that the benchmarks cited satisfy explicit construct validity criteria before they enter the decision framework. This is a policy decision, not a technical one, and it filters a significant source of strategic noise from your investment logic.

•     Invest in building internal evaluation datasets that reflect your organization's specific engineering context. Published benchmarks are designed for general use cases. A modest investment in task collection and annotation produces instruments with far higher relevance than any public leaderboard for your deployment needs.

•     When contracting with AI vendors, include benchmark validity as a due diligence item. Ask specifically which benchmarks are cited, what statistical testing was performed, whether contamination was checked, and whether real-world tasks were used for validation. The quality of the answers will indicate whether the vendor understands the limits of its own evidence.

•     Treat benchmark scores in the same category as any other performance claim subject to audit. A vendor score on a benchmark with unknown construct validity carries the same evidential weight as a self-reported customer satisfaction figure with no disclosed methodology. High-stakes decisions warrant independent verification.

Closing thought

Benchmarks are not neutral instruments. They encode assumptions about what matters, which tasks represent real capability, and what performance levels constitute evidence. Those assumptions are rarely made explicit, and current publication norms in AI research do not require them to be. The practical consequence is that practitioners relying on benchmark scores to make adoption decisions are frequently acting on numbers that were never validated for the inferences those decisions require.

The question worth bringing back to your engineering organization is not "what score does this tool get?" but "on what task, with what metric, under what sampling assumptions, and with what statistical confidence?" The gap between those two questions is where most AI adoption decisions are currently made. How many of the eight validity criteria does the benchmark at the center of your next tool evaluation actually satisfy?

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Bean, A. M., Kearns, R. O., Romanou, A., Hafner, F. S., Mayne, H., Batzner, J., Foroutan, N., Schmitz, C., Korgul, K., Batra, H., Deb, O., Beharry, E., Emde, C., Foster, T., Gausen, A., Grandury, M., Han, S., Hofmann, V., Ibrahim, L., Kim, H., Kirk, H. R., Lin, F., Liu, G. K.-M., Luettgau, L., Magomere, J., Rystrøm, J., Sotnikova, A., Yang, Y., Zhao, Y., Bibi, A., Bosselut, A., Clark, R., Cohan, A., Foerster, J., Gal, Y., Hale, S. A., Raji, I. D., Summerfield, C., Torr, P. H. S., Ududec, C., Rocher, L., & Mahdi, A. (2025). Measuring what matters: Construct validity in large language model benchmarks. 39th Conference on Neural Information Processing Systems (NeurIPS 2025), Datasets and Benchmarks Track.

Cronbach, L. J., & Meehl, P. E. (1955). Construct validity in psychological tests. Psychological Bulletin, 52(4), 281-302.

Generative AI is reducing one form of software debt while quietly accumulating two others, and most engineering organisations are still measuring only the one that is shrinking.

The dominant industry framing treats AI-assisted development as a productivity story. Code arrives faster, then refactoring happens automatically, and finally smell detectors and test generators absorb work that previously sat on engineers' backlogs. Every consulting firm with a slide deck has documented some version of that gain. What none of those decks measures is what happens to the layers above the code: the team's shared understanding of why the system behaves as it does, and the externalised rationale that humans and AI agents alike need to reason about safe change.

A recent paper from Margaret-Anne Storey at the University of Victoria gives that pattern a name and a structure (Storey, 2026). The Triple Debt Model proposes that software health depends on three coupled layers, each able to erode independently. Technical debt lives in code. Cognitive debt lives in people. Intent debt lives in artifacts. Generative AI is shrinking the first while accelerating the accumulation of the other two, and the conventional metrics most teams report do not register the second-order effects.

Each of the three layers degrades through different mechanisms, responds to different interventions, and produces different operational signatures. A team monitoring only the code layer can show improving metrics across every dashboard while accumulating risk at the layers above. The redistribution is not a future concern, but it is a present condition, and it is the structural reason that AI productivity gains are not translating into the operational improvements organisations expected when they adopted the tools. The argument that follows takes the three layers in turn.

Subscribe to newsletter

How the technical debt construct decouples

The technical debt construct has been with the field since Cunningham (1993) used a financial metaphor to explain why fast-shipped code accrues future cost. Kruchten et al. (2012) sharpened the construct into a research programme that distinguished principal from interest and modelled the trade-off between delivery speed and maintenance burden. For three decades, the construct did substantial work. It justified investment in refactoring, gave engineers a shared vocabulary for explaining shortcuts to non-technical stakeholders, and informed measurable practices ranging from static analysis dashboards to dedicated remediation sprints.

What Storey (2026) identifies is that the construct, as practiced, conflates three distinct phenomena that AI now decouples in production.

1. Debt in the code itself: structural shortcuts, weak abstractions, missing tests.

2. Debt in the team's collective understanding of that code.

3. Debt in the explicit goals, rationale, and constraints captured in artifacts the team and its agents can consult.

In a pre-AI development regime, these three layers tended to move together. A team that took on technical debt typically also degraded its shared understanding of the affected modules and let intent capture lapse. Reducing one tended to mean reducing all three. The metaphor held.

Generative AI breaks that coupling. Hou et al. (2024) document large language models accelerating refactoring, smell detection, and test generation across multiple production settings. Peng et al. (2023) report substantial productivity gains for engineers using GitHub Copilot, with the largest gains concentrated in routine code generation tasks. The case that AI lowers technical debt accumulation, at least for the visible code layer, is empirically defensible. The system gets cleaner as measured by static analysis. CI pipelines stay green, and test coverage edges upward.

The problem is what happens elsewhere while the code layer cleans up. The team's shared understanding of why the code looks the way it looks does not improve when an agent writes the code. Often, it deteriorates because no engineer was required to build the mental model that produced the artifact. The decision rationale for the agent's output also does not enter any consultable artifact unless someone deliberately captures it, and the very speed advantage of agent-assisted development cuts against deliberate rationale capture.

The result is a divergence: code quality improves while team knowledge and externalised intent both erode.

The three-decade habit of treating debt as a single quantity now produces measurement errors of opposite signs.

Where the cognitive layer erodes

Storey defines cognitive debt as a team-level, project-level property reflecting the erosion of shared understanding across a software system over time, manifesting as increasingly inadequate mental models that developers rely on to reason about the system and change it safely. The construct is grounded in three pieces of foundational work that newer software engineering research has tended to underuse.

Naur (1985) argued that programming is, fundamentally, the construction of a theory of the system in the heads of the people building it. The code is one externalisation of that theory; documentation is another; tests are a third. None of them is the theory itself. When the people who built the theory leave, or when the system grows faster than their mental model can grow with it, the theory degrades even when the artifacts persist. Curtis et al. (1988), in a field study of seventeen large software projects, found that no single developer held the complete picture of any non-trivial system; the theory was distributed across the team in overlapping fragments. Wegner (1987) provided the cognitive science framing for that distribution: groups develop a transactive memory in which each member tracks not only what they know but who else knows what. When transactive memory degrades, the team loses the ability to retrieve its own knowledge, even if individual heads still contain pieces of it.

Hutchins (1995) extended the framing to distributed cognition more broadly. Cognitive processes, in complex socio-technical systems, are properties of people, artifacts, and their interactions, not of individual minds in isolation. A software team's reasoning capacity is a property of the whole configuration: engineers, code, documentation, dashboards, on-call rotations, post-mortems, and the informal channels through which they communicate. Cognitive debt accumulates when any element of that configuration degrades faster than the others can compensate.

The empirical signals that AI-assisted development is accelerating this erosion are starting to converge. Kosmyna et al. (2026) document measurable reductions in neural engagement during AI-assisted writing tasks and report a rebound effect: participants who relied on AI assistance retained less of the produced content and were less able to recall their own reasoning when later asked to defend it. Shaw and Nave (2026) describe a related pattern they call cognitive surrender, in which users of AI-assisted decision tools report inflated confidence in conclusions even when the AI was demonstrably wrong. The combination is the worst possible diagnostic configuration: lower engagement at the moment of production, higher confidence at the moment of review. The mental model that should have been built during production is absent at the moment it is needed for verification.

Storey's redistribution thesis crystallises the implication for software engineering organisations:

Generative AI may reduce technical debt while simultaneously accelerating the accumulation of cognitive and intent debt (Storey, 2026).

That single sentence reframes most of the productivity discourse around AI-assisted development. The gains are real, but they arrive at a layer of the stack that has well-developed instruments and decades of measurement practice.

The accumulation arrives at layers where most organisations have no instruments at all.

Russo's (2026) phase transition argument adds a structural prediction to Storey's diagnosis. Agent-intensive ecosystems undergo a discontinuity at an agent-to-engineer ratio of approximately three to one, after which ecosystem-level behaviour becomes more informative than individual-agent behaviour for understanding the system. Below that threshold, cognitive oversight remains tractable: engineers can still reconstruct the decision logic of agent-generated changes at a reasonable cost. Above it, the system's properties of interest emerge from interactions rather than residing in any single agent or commit, and the team's transactive memory cannot keep pace. The comprehension debt construct introduced in last week’s issue, The Composition Trap (Russo, 2026), names the operational consequence at the artifact level: code that passes automated verification while remaining beyond the team's reproducible decision logic.

The two frames have to be seen as complementary. Storey's cognitive debt names the accumulated team-level erosion of shared understanding observed from inside the cognitive system. Russo's comprehension debt names the failure mode that erosion produces at the artifact level: code that the team cannot mentally simulate. One frame is grounded in distributed cognition; the other in complexity-science emergence. Together, they describe both the cause and the consequence of the same upstream redistribution.

The intent gap that artifacts cannot close

Intent debt is the layer most newly named in Storey's framework, and it is the one that most directly reframes how teams should think about AI agents. Storey describes intent debt as the absence or erosion of explicit rationale, goals, and constraints that guide how a system evolves. Where cognitive debt resides in heads, intent debt resides in the gap between what the team meant to build and what is captured in any artifact a human or an agent can consult.

The construct gains particular force in agent-intensive workflows because AI agents are now first-class consumers of the intent layer. When an engineer holds the rationale in their head, they can apply it implicitly: a code review against an unwritten performance budget still catches the regression because the reviewer remembers the budget exists. When an agent writes the same code, the budget is invisible unless it appears in an artifact the agent reads. The result is a class of failure modes that resemble model limitations but are actually intent-debt incidents masquerading as capability gaps. The agent produces technically correct but pointless solutions, requests extensive rounds of clarification, or burns tokens by reasoning from scratch on questions that a single decision record could have answered. Each of these is a measurable signal of intent debt at the agent boundary.

Storey identifies several diagnostic signatures. Behaviour drift from stakeholder expectations, even when the code is technically correct, points to lost or never-captured constraints. Loss of articulated performance budgets, privacy commitments, and accessibility requirements is a classic pattern: the constraints exist in someone's memory and are honoured when that person reviews changes, but they disappear from the system the moment that person is unavailable. Onboarding cost rises because new engineers and new agents have no documented theory of what the system is for, only of what it currently does. The two are not the same.

The mitigations Storey proposes are of a diverse nature.

1. Behaviour-driven specifications and tests that capture purpose rather than only verifying mechanics.

2. Architecture decision records that externalise the why alongside the what.

3. Domain-driven design vocabulary that gives the team a shared language for talking about constraints.

The shared characteristic is that all of them produce artifacts that are agent-readable in the same way they are human-readable. This is the operational definition of context engineering, i.e., the practice of producing instructions and rationale dense enough that an agent given access to them produces outputs aligned with team intent without needing the rationale to be re-derived in every interaction.

The dual relationship between comprehension debt and intent debt makes the combination useful for diagnostic purposes. Comprehension debt is the team's failure to reconstruct the rationale that an agent produced. Intent debt is the team's failure to externalise the rationale that the agent then has to invent. These are inverse failure modes, and they tend to produce inverse organisational pathologies. Teams with high comprehension debt accumulate change-resistant code that no one wants to touch. Teams with high intent debt accumulate agent failures that the team blames on the model rather than on its own missing specifications. Diagnosing which form dominates is the first step toward choosing the right intervention.

The 30-minute audit

The following diagnostic surfaces the three debt types in a single team session. Each item is designed to take a few minutes; the full list runs in roughly thirty.

1.     Pull a sample of ten AI-generated commits merged in the last sprint. For each, ask the on-call engineer to reconstruct the decision logic in under five minutes. Count how many they cannot. The fraction is your near-term comprehension debt rate.

2.     Open your most recent architecture decision record. Note the date. If it is more than six weeks old in a team shipping daily, you are accumulating intent debt at the documentation layer faster than you are paying it down.

3.     List the constraints currently active in your service: performance budgets, privacy commitments, accessibility requirements, security invariants, and regulatory thresholds. Check which are captured in artifacts that agents can consult versus those held only in someone's memory. Anything in heads alone is a cognitive debt risk; anything missing from artifacts is an intent debt risk.

4.     Run a transactive memory check. Ask each engineer who else on the team understands the area they own most deeply. If the answer is no one, that is cognitive debt at the bus-factor level, and it is the most expensive form to remediate after the fact.

5.     Review the last three incidents. Identify which were caused by code behaving as written but not as intended. That ratio is your intent debt fingerprint, and it is typically under-reported because incident reviews focus on the proximate cause rather than the missing specification.

6.     Audit your most recent five AI agent failures. Count how many resulted from missing rationale rather than missing capability. Reclassifying capability failures as intent debt incidents changes which intervention reduces them.

7.     Calculate the mean time to explain for the most recent significant AI-generated module: how long does a senior engineer need to reconstruct its reasoning? Anything beyond twenty minutes signals comprehension debt at the boundary; anything beyond an hour is structural.

8.     Examine your onboarding metrics for the last two new hires. Time to first meaningful contribution beyond expected ranges suggests the team's shared theory of the system is no longer transmissible at an acceptable cost. The same metric measures whether new agents can be onboarded cheaply.

9.     Survey your senior engineers anonymously: Do you feel less able to predict the system's behaviour than you did six months ago? A consistent yes signals cognitive debt accumulation that no static analysis tool will detect.

10.  Map intent capture in your current sprint planning. If decisions are made in meetings and not externalised into ADRs, behaviour-driven specifications, or agent-readable instructions before code is generated, intent debt is being created in real time, and you have not yet built the practice that pays it down.

11.  Track your agent-to-engineer ratio. Above approximately three to one (Russo, 2026), individual-agent metrics become unreliable as guides to system behaviour, and the diagnostic items above need to be run at a higher cadence rather than monthly.

Next moves

For the builder

When reviewing AI-generated code, separate two judgments explicitly: did the output satisfy the test, and can I reconstruct the decision logic? Record both. Approving of the first without the second is the operational definition of contributing to comprehension debt, and the cognitive surrender pattern documented by Shaw and Nave (2026) means you will tend to feel more confident than the evidence warrants. Build the discipline of writing decision rationale into commit messages and architecture decision records before merging significant AI-generated changes; capture the why alongside the what. When using AI agents directly, rewrite agent instructions whenever clarification rounds exceed two: the failure point is the missing intent, not the model. Treat your own personal review-without-reproduction ratio as a leading indicator of the comprehension debt you are personally contributing to the codebase.

For the manager

Introduce a cadenced practice that explicitly targets cognitive debt. Storey calls these system walkthroughs: sessions where one engineer narrates a part of the system to others, including parts they did not write. The practice rebuilds the team's transactive memory without waiting for an incident to force the rebuilding, and Naur (1985) suggests it is the only mechanism that genuinely transfers the theory of the system rather than its surface artifacts. Reframe code review as theory transmission, not just defect detection: a review that catches a bug while leaving the reviewer unable to reconstruct the change's reasoning has solved one problem and worsened another. Track the ratio of decisions captured in ADRs versus decisions made in meetings; that ratio is your intent capture rate, and it is the leading indicator of whether your team is building agent-readable artifacts or only agent-consumable code. Watch your on-call escalation rate as a primary signal of emergent system behaviour rather than as a measure of individual engineer competence.

For the roadmap owner

The Triple Debt Model implies that the metrics most organisations report on AI adoption are partial by construction. Productivity gains in code generation should be reported alongside three corresponding indicators: cognitive debt (mean time to explain, on-call escalation trends, senior-engineer confidence), intent debt (rationale capture rate, ADR currency, agent clarification round counts), and the agent-to-engineer ratio that conditions all three. Commission an audit that maps your AI governance framework against these layers, not against generic risk taxonomies; existing frameworks designed for individual model evaluation do not surface the team-level erosion that produces operational risk. Budget for measurement infrastructure at the cognitive and intent layers before scaling agent deployment further. The Storey (2026) and Russo (2026) frameworks together suggest that organisations that scale agent counts without instrumenting these layers will see initial productivity gains followed by a delayed but predictable rise in incident severity, with the lag obscuring the causal relationship for long enough that the original adoption decision is rarely revisited.

Closing thought

The story most boards are being told about AI-assisted software development is a story about cleaner code shipped faster. The story Storey and Russo together describe is more relevant but harder to manage. Software risk is migrating up the abstraction stack, from the code layer where decades of tooling have accumulated, into the team's shared understanding and the rationale captured in artifacts, where most organisations have nothing comparable in place. The teams that recognise this redistribution early will build the instruments before they need them; the teams that do not will discover the accumulation through incidents whose causes are easy to misattribute to the agents themselves.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Cunningham, W. (1993). The WyCash portfolio management system. ACM SIGPLAN OOPS Messenger, 4(2), 29-30.

Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287.

Hou, X., Zhao, Y., Liu, Y., Yang, Z., Wang, K., Li, L., Luo, X., Lo, D., Grundy, J., & Wang, H. (2024). Large language models for software engineering: A systematic literature review. ACM Transactions on Software Engineering and Methodology, 33(8), 1-79.

Hutchins, E. (1995). Cognition in the wild. MIT Press.

Kosmyna, N., Wong, B. R. P., Hauptmann, E. C., Yuan, Y. T. A., Kosmyna, V., & Maes, P. (2026). Your brain on ChatGPT: Accumulation of cognitive debt when using an AI assistant for essay writing. arXiv:2601.00856.

Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18-21.

Naur, P. (1985). Programming as theory building. Microprocessing and Microprogramming, 15(5), 253-261.

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.

Russo, D. (2026). More is different: Toward a theory of emergence in AI-native software ecosystems. arXiv:2604.19827.

Shaw, J., & Nave, R. (2026). How AI is reshaping human reasoning and the rise of cognitive surrender. SSRN 6097646.

Storey, M.-A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI. arXiv:2603.22106.

Wegner, D. M. (1987). Transactive memory: A contemporary analysis of the group mind. In B. Mullen & G. R. Goethals (Eds.), Theories of group behavior (pp. 185-208). Springer.

Multi-agent AI systems fail in ways that individual agent evaluations will never surface, and the software engineering field has not yet built the vocabulary to describe why.

For decades, software quality assurance rested on a single defensible principle: verify each component, and the system follows. Unit tests, code review, CI pipelines, static code analysis: all share a common foundational assumption. If the parts are correct, the whole is correct. That principle governed how organizations structured teams, allocated review bandwidth, and measured engineering health.

The arrival of multi-agent AI development invalidates that assumption. Not incrementally but structurally. Agents do not coordinate through formally specified contracts. They negotiate through natural language specifications, probabilistic outputs, and implicit shared state. The moment a second agent depends on the first agent's output, the system has crossed from merely complicated territory into complex territory, a distinction with concrete, measurable consequences (Russo, 2026).

Most engineering teams evaluating AI-assisted development still measure individual agent performance, individual commit quality, and individual CI pass rates. These are the right metrics for complicated systems. For complex ones, they are insufficient by design: the properties that matter most are architectural entropy, cascade failure probability, and what Russo (2026) terms comprehension debt. Those properties exist only at the ecosystem level, not in any single agent and not in any single artifact.

Subscribe to newsletter

The Empirical Backbone

What the benchmarks show

The performance collapse that emerges when agents operate within real, dependency-laden systems is already measurable in existing benchmarks. Standard SWE-bench evaluations show autonomous agents resolving approximately 65% of software engineering tasks when working on isolated repositories. Move those same agents to SWE-EVO, a benchmark incorporating realistic dependency chains, and resolution rates fall to 21%.

Agents that resolve 65% of issues on isolated repositories resolve only 21% on systems with realistic dependency chains. The collapse of more than two-thirds in performance is produced entirely by the presence of inter-component relationships, with no change to the agents themselves.

That finding is the compositional assumption failing under controlled conditions. The agents performed correctly according to their specifications. The systems did not.

The phenomenon extends across organizational contexts. Cemri et al. documented failure rates between 41% and 86.7% in autonomous coding pipelines under conditions where individual agent specifications were met. The agents were, in the conventional sense, correct, but the pipelines were not.

At the organizational level, the signal is consistent. A METR evaluation found a 19% productivity slowdown among experienced developers working with AI tools. These were senior practitioners whose measured output declined as AI integration deepened, not junior engineers adapting to unfamiliar workflows. The DORA 2024 report recorded a 7.2% decrease in delivery stability running concurrently with a 25% increase in AI-tool adoption. GitClear's analysis of 211 million changed lines found quality degradation patterns correlated with increasing AI-assisted development. None of these outcomes are attributable to defective agents. All of them are attributable to systemic effects that per-agent measurement cannot predict.

Complicated versus complex

Understanding why requires a conceptual distinction that software engineering has borrowed from complexity science but not yet operationalized in practice.

A complicated system contains many components, each verifiable in isolation: an aircraft engine, a microservice architecture with formal contracts, a monolithic application under unit-test coverage. High component count does not make a system complex. A complex system's significant properties arise from interactions between components, not from the components themselves. Anderson (1972) observed that no aggregation of electron trajectories produces superconductivity, and no inspection of individual water molecules predicts turbulence. The same principle applies to software ecosystems where agents coordinate through natural language: the system's failure modes cannot be deduced from any individual agent's behavior, because those failure modes are not located in the agents.

A team of five AI agents coordinating through natural language does not simply scale up a team of five human engineers. Human teams develop shared mental models, reputation constraints, and social norms that regulate coordination. Agents operate without those constraints: they make autonomous decisions without reputation feedback, interpret specifications probabilistically rather than through shared organizational context, and produce no formal inter-agent contracts. That combination creates emergent failures that artifact-level verification was never designed to catch.

Comprehension debt and the phase transition

The most consequential new construct Russo (2026) introduces is comprehension debt: code that passes automated verification but whose decision logic no engineer on the team can reliably reproduce.

Comprehension debt differs from technical debt in a precise way. Technical debt describes known shortcuts whose future cost is estimated and deferred. Comprehension debt describes a hidden epistemic gap: the system behaves correctly by the available metrics, while no human possesses the mental model required to intervene when it stops doing so. GitClear's 211-million-line analysis suggests this accumulation is already underway in production codebases. Unlike a bug, comprehension debt triggers no alert. It surfaces only when something goes wrong and no one can explain why.

Russo (2026) further proposes that agent-intensive systems may undergo phase transitions around a critical ratio of one to three agents per human engineer. Below that threshold, cognitive oversight remains tractable; engineers can still reconstruct the decision logic of agent-generated changes at a reasonable cost. Above it, ecosystem behavior at the macro level becomes causally more informative than the behavior of individual agents. At that point, managing the agents individually is the wrong unit of analysis. Governing the ecosystem is the only lever that works.

A 30-minute multi-agent risk audit

If your team is generating more than 30% of its commits through AI agents, the dynamics described above are present in your repository now. The following checklist identifies the most tractable early signals. 

1.     Pull 90 days of commit metadata. Calculate the proportion of commits carrying AI-tool fingerprints: co-authored-by fields, automated PR descriptions, and commit message patterns. If that proportion exceeds 30%, your system is in the agent-intensive range where ecosystem-level monitoring becomes necessary.

2.     Cross-reference your test pass rates against human review depth. High CI pass rates combined with declining substantive review comments per commit is a leading indicator of comprehension debt accumulation. The tests are green; the understanding is eroding.

3.     Generate a dependency graph for the modules receiving the highest volume of AI-generated commits. High clustering coefficients in those modules predict higher cascade failure probability. This is where a single merge failure propagates furthest.

4.     Audit your incident post-mortems from the last six months. Identify cases where the stated cause was correct code behaving unexpectedly in context. That pattern, individually verified components producing system-level failures, is the fingerprint of emergent failure, not conventional bugs.

5.     Measure mean time to explain (MTTE): the time a senior engineer requires to reconstruct the decision logic of a recently merged AI-generated module. If no senior engineer can explain a non-trivial AI-generated change in under 20 minutes, that module carries comprehension debt.

6.     Check your on-call escalation rate over the last two quarters against your AI-tool adoption rate. Under Russo's (2026) Proposition 5, intervention rates increase even as individual agent capability improves. A rising escalation rate in a team reporting better AI tools is not a contradiction. It is a predicted outcome.

7.     Identify your highest-dependency services and count how many currently receive AI-agent contributions. Cascade failure risk scales with both dependency density and agent count; this intersection marks your highest-priority governance gap.

8.    Ask your most experienced engineers a direct question: can you explain the decision logic behind the last significant AI-generated merge in your area? Their answer reveals more about your comprehension debt than any static analysis tool currently can.

Next moves

For the builder

Treat code review as a measurement instrument, not only a quality gate. When reviewing AI-generated changes, record explicitly whether you can reproduce the agent's decision logic or whether you are verifying only the output. That distinction is the operational definition of comprehension debt at the individual level. Request explanatory comments as part of your review criteria, not summaries of what the code does but accounts of why it takes the approach it does. Track how often you approve AI-generated code you cannot mentally simulate; that ratio is your personal comprehension debt signal, and it compounds across every sprint.

For the manager

Restructure your team's review practice around the assumption that agent-dense codebases require ecosystem-level observation alongside artifact-level sign-off. Introduce a recurring team ritual, monthly or per-sprint, dedicated to understanding the decision logic behind AI-generated changes merged in that period, not their correctness but their reasoning. Track your on-call escalation rate as a primary indicator of emergent system behavior. When it rises while individual agent metrics improve, the explanation is systemic; adjusting an individual agent's prompt or configuration is not the intervention that addresses it.

For the roadmap owner

The governance frameworks your organization has built around AI adoption, including EU AI Act compliance plans, NIST Risk Management Framework mappings, and existing DORA measurement programs, were designed for individual systems operating within formal contracts. Russo (2026) argues these are structurally incomplete for multi-agent ecosystems. Commission an audit of your current AI governance approach against ecosystem-level observables: coupling density, comprehension debt fraction, inter-agent dependency graphs. Establish an explicit agent-to-engineer ratio policy before adoption pace sets it for you. The METR finding of a 19% productivity slowdown among experienced developers indicates that scaling agent headcount without ecosystem visibility produces net-negative outcomes for your most valuable engineers. Budget for measurement infrastructure before scaling further.

Closing thought

The shift from complicated to complex does not happen gradually. It crosses a threshold, and teams rarely notice until the cascade has begun. Software engineering has spent three decades building excellent instruments for complicated systems: unit tests, static analysis, CI pipelines, code review. Those instruments still work for what they were designed to measure. The question facing every team adding agents to its workflow is whether it can now operate at a different level of analysis simultaneously, monitoring interactions rather than only artifacts, governing ecosystems rather than only components. The organizations that treat this as a tractable measurement problem, something falsifiable and instrumentable, will build the observational infrastructure needed to answer it.

What does your current monitoring tell you about the system that emerges from your agents' interactions, not just from the agents themselves?

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through Software Insights, he translates empirical research into actionable guidance for software practitioners and organizations.

If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.

danielrusso.org/advisory

View all posts

References

Anderson, P. W. (1972). More is different. Science, 177(4047), 393–396. https://doi.org/10.1126/science.177.4047.393

Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657.

DevOps Research and Assessment. (2024). 2024 state of DevOps report. Google Cloud, Puppet, & Lacework. https://cloud.google.com/devops/state-of-devops

GitClear. (2024). The state of code quality: 2024–2025 report. https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality

METR. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv:2507.09089.

Russo, D. (2026). More is different: Toward a theory of emergence in AI-native software ecosystems. arXiv:2604.19827.

Scalabrino, S., Linares-Vasquez, M., Poshyvanyk, D., & De Lucia, A. (2021). Automatically assessing code understandability. ACM Transactions on Software Engineering and Methodology, 30(3), 1–53.

Organisations building multi-agent AI pipelines face a measurement problem that standard benchmarking cannot resolve: individual agents can pass every capability test in your suite while the system they compose fails in ways that no single-agent analysis would predict.

That gap is not theoretical. It is the documented failure mode of production deployments in 2025 and 2026.

The Gradient Institute's technical report on risk analysis for governed multi-agent systems (Reid et al., 2025) offers the most rigorous taxonomy of that failure currently available. Commissioned with support from the Australian Government and grounded in a systematic review of emergent multi-agent AI behaviour, the report makes a point that engineering teams need to incorporate into their governance frameworks today: a collection of safe agents does not guarantee a safe collection of agents.

Subscribe to newsletter

The agentic inflection point

The pace at which single-agent deployments are evolving into multi-agent architectures has outrun the governance frameworks most organisations have in place. The practical pressure is understandable. Different business units automate their domains independently; an HR agent processing new hires must coordinate with an IT agent provisioning access, and a finance agent setting up payroll. The efficiency case for enabling direct agent-to-agent communication is compelling, and framework proliferation (AutoGen, CrewAI, LangGraph) has made it technically accessible.

What has not kept pace is the risk thinking.

The framing most organisations carry into multi-agent governance was built for single-agent evaluation: does the model hallucinate? How accurate is its code? Does it follow instructions under adversarial prompting? Those questions remain necessary. They do not address the interaction dynamics of the systems now entering production.

The Sonar State of Code survey (Sonar, 2026), covering 1,100 developers, reports that 42% of all committed code is now AI-generated or AI-assisted, while 96% of developers do not fully trust its functional accuracy, and 59% spend moderate to substantial effort reviewing and correcting AI output. A randomised controlled trial by Becker et al. (2025) of 16 experienced open-source developers found that AI tooling increased task completion time by 19%, even as developers believed they had become faster. When agents produce that code and then review each other's outputs within an automated pipeline, those individual reliability gaps do not average out. They compound. 

Why individual agent safety is necessary but insufficient

The professional instinct in software engineering is to decompose complex systems into components, verify each component against a specification, and infer system-level correctness from component-level correctness. That instinct is well-founded in deterministic software. It fails in multi-agent LLM systems for reasons that are structural, not incidental.

Reid et al. (2025) identify five such reasons.

1. When multiple agents interact, the number of possible system states grows exponentially; behaviour that was stable in isolation becomes unpredictable under agent-to-agent dynamics.

2. Each agent operates on partial information and makes decisions without visibility into the broader task state.

3. Agents cannot reliably evaluate each other's competence or credibility, so erroneous outputs propagate uncritically downstream.

4. Stable interaction patterns can fracture as agents continuously adapt to each other's behaviour; a software update to a single agent, even a revised system prompt, effectively creates a different system that requires full re-evaluation.

5. And early errors lock the system into failure trajectories that compound downstream and become progressively harder to reverse.

Berkeley's MAST taxonomy (Cemri et al., 2025) documents 14 distinct system-level failure modes in multi-agent LLM pipelines, none of which are detectable at the individual agent level. Reid et al. (2025) show that even under unified governance, where your organisation controls the configuration and deployment of every agent, these failure modes remain structurally present. They are properties of interaction, not of individual components.

The practical consequence for engineering leadership is direct: your current test suite is likely measuring the wrong thing. It tells you whether each instrument in the orchestra can play in tune. It does not tell you whether the orchestra produces coherent music.

The six failure modes your current risk framework does not cover

"Multi-agent systems don't just accumulate single-agent risks; they transform them. Cognitive limitations become cascading hallucinations, communication errors become system-wide miscoordination, and individual biases become collective blind spots through reinforcement dynamics." (Reid et al., 2025, p. 2)

Reid et al. (2025) identify six failure modes specific to governed multi-agent environments. Each is absent from standard single-agent risk frameworks, and each maps to concrete production scenarios.

1. Cascading reliability failures. LLM agents have "spiky" capability profiles: superhuman performance on certain complex tasks coexisting with profound failures on seemingly simpler ones. A single agent misreading a chart, interpreting "10.5K units" as "105K units," passes that figure downstream to agents that accept it uncritically. Unlike a human collaborator who might flag a suspicious number, a receiving agent builds on the flawed input as a valid premise. The error compounds at each node. By the time human managers notice unusual activity in the manufacturing scenario Reid et al. (2025) document, the company has committed millions in unnecessary material purchases, disrupted production of other product lines, and locked in logistics contracts it cannot fulfil.

The error rate of each individual agent is not the relevant metric. What matters is how errors propagate through the coupling structure.

2. Inter-agent communication failures. Natural language is an ambiguous medium when precision is required. When a Grid Management agent tells a Public Communications agent that "Substation 7 is now stable," the engineering definition (no longer at risk of cascading failure, but still fragile) diverges from the public relations interpretation: resolved, safe for users to resume normal consumption. The Communications agent broadcasts a restoration message; users switch on appliances; the fragile substation overloads. The failure originated not from an error but from a semantic gap that no single-agent benchmark would surface (Reid et al., 2025).

Communication failures also include context truncation: an agent summarising a long exchange for a downstream agent may discard exactly the exception case that downstream agent needed to handle correctly. The problem intensifies with every handoff.

3. Monoculture collapse. When all agents in a system are fine-tuned variants of the same base model, they share correlated biases and blind spots. A vulnerability that triggers one agent triggers all agents simultaneously, producing convergent outputs that appear reliable due to consensus. Reid et al. (2025) report evidence that similar model capabilities lead to static debate dynamics, converging on the majority view even when that view is factually incorrect.

The financial fraud detection system that deploys five variants of the same base model does not have five independent detectors. It has one detector with five labels on it. Convergent outputs look like high-confidence signal. In structural terms, they are a single point of failure wearing the costume of consensus.

4. Conformity bias. LLM sycophancy, the tendency of language models to prioritise agreement over accuracy, becomes a system-level hazard in multi-agent settings (Reid et al., 2025). A confidently stated confabulation from one agent generates conformity pressure on others. As agreeing agents accumulate, dissenting agents face increasing pressure to align. The consensus grows stronger with each reinforcing step, even though no individual agent had high confidence in the original claim.

This is most dangerous in collaborative swarm architectures, systems specifically designed to synthesise diverse perspectives, because the diversity assumption collapses when agents reward linguistic confidence over factual accuracy. The swarm produces a single high-confidence answer. That answer can be wrong in ways that no individual agent, interrogated in isolation, would produce.

5. Deficient theory of mind. Effective coordination requires agents to model what other agents know, want, and can do. When an inventory agent and a pricing agent each receive the same demand forecast and optimise independently, one placing massive orders, the other tripling prices, neither agent models how the other's action changes the shared environment. The outcome is warehouses full of expensive unsold inventory, despite each agent having behaved rationally given the information it had (Reid et al., 2025).

The agents are working correctly. They are simply failing to account for the fact that the environment each is reasoning about includes each other. No malfunction required.

6. Mixed motive dynamics. When agents pursuing individually rational objectives interact under shared governance, emergent behaviour can systematically undermine collective goals, even when all agents are formally aligned with organisational objectives. The sequence Reid et al. (2025) document is instructive: an inventory agent marks all orders as "critical" to bypass delays introduced by a cash-flow agent; that agent responds by requiring CFO approval for any order above $10,000; the inventory agent then splits large orders into $9,999 tranches to circumvent the threshold.

Both agents technically achieve their individual performance metrics. The organisation loses bulk purchasing discounts, experiences unpredictable stockouts, and destroys overall profitability. A collectively suboptimal equilibrium, reached through locally rational behaviour at every step, and invisible to any single-agent evaluation.

Know your architecture, know your exposure

One of the more practically useful contributions of the Gradient Institute report is its mapping of failure modes to canonical multi-agent configurations. The failure modes you face are not uniform across architectures.

A centralised orchestrator with specialised delegates concentrates risk at the orchestrator layer. If the orchestrator's task decomposition is inconsistent or its specialist selection degrades under complex scenarios, those failures propagate to every downstream agent simultaneously. Cascading reliability failures and a deficient theory of mind are the dominant concerns here.

A collaborative swarm (no central control, high communication frequency, a shared high-level goal resolved through distributed synthesis) is inherently exposed to conformity bias and monoculture collapse. The architecture is designed for diversity of perspective; the failure modes specifically erode that diversity.

A distributed autonomous task force, with persistent, role-specialised agents managing separate domains and infrequent but critical cross-agent coordination, is where mixed motive dynamics and inter-agent communication failures concentrate. Agents that do not interact continuously are less likely to have developed stable shared semantic conventions for the handoffs that matter most.

Mapping your production system to the canonical configuration that most closely resembles it is the first decision your risk governance process should make. It determines which failure modes warrant the most immediate investment in analysis and which risk analysis techniques are most applicable (Reid et al., 2025).

A 30-minute multi-agent risk audit

Before extending your agentic pipeline or adding new agent roles, run this diagnostic. The goal is to identify which failure modes your current configuration is most exposed to.

1. Map your agent network topology against the three canonical settings above: centralised orchestrator, collaborative swarm, or distributed task force. Your highest-exposure failure modes differ by configuration.

2. For each agent, identify the three outputs most likely to be accepted by downstream agents without verification. These are your cascade entry points.

3. Test each cascade entry point for capability brittleness: run the same task with minor input variations (rephrasing, numeric format changes, image quality degradation) and measure output consistency. High sensitivity to superficially innocuous changes predicts production cascade failures.

4. Review inter-agent communication logs for ambiguous or domain-specific terms. Flag any term whose meaning would shift if the receiving agent were trained on a different knowledge corpus than the sending agent.

5. Count how many agents in your network are fine-tuned variants of the same base model. If all agents share a base model, document the input classes that the base model handles poorly. Those are your monoculture blind spots.

6. Verify that at least one agent in your network holds an explicit critic or verification role whose architecture structurally prevents it from receiving social pressure from the agents it evaluates. Systems with no designated independent challenger are vulnerable to conformity bias regardless of individual agent quality.

7. For each pair of agents sharing resource constraints or carrying partially conflicting objectives, work out what locally rational behaviour looks like when the other agent behaves optimally. If the resulting interaction is not globally optimal, you have a mixed-motive dynamic in production.

8. Review your last three agentic pipeline failures and classify each: single-agent reliability failure, cascade from a peer output, communication ambiguity, or emergent coordination failure. The classification determines the appropriate remediation path.

9. Verify that your pre-deployment testing includes multi-agent interaction scenarios run over extended interaction sequences, not only single-agent capability assessments. Static benchmarks cannot reveal emergent failure modes (Reid et al., 2025). Simulation environments that replay production interaction patterns at scale are the most informative analytical tool currently available.

10. Confirm that your monitoring stack captures inter-agent communication logs and tracks failure propagation depth (the number of downstream components affected by a single agent-induced fault), not only end-to-end task completion rates. Monitoring only final outputs is the observability equivalent of removing all intermediate sensors from an industrial pipeline and measuring only whether the end product is on spec.

Next moves

For the Builder

• Instrument your agentic pipeline to log inter-agent message passing with timestamps, agent identifiers, and input provenance. Without this data, post-incident failure cascade analysis is guesswork. Treat inter-agent message logs as first-class production observability, not a debugging afterthought.

• When reviewing any output produced within an agent chain, treat an output that cannot be traced to a verifiable upstream input as a potential cascade seed. Calibrate your verification effort to the consequence level of the task, not the fluency of the output.

• Build a personal test library of brittleness probes: input variations that target the capability troughs most relevant to your domain. Run each new model version against this library before trusting it in a production agent chain. When a model update arrives, your first question should not be "what improved?" but "what changed at the failure boundary?"

For the Manager

• Audit your team's agent network against all six failure modes. Assign an owner to each high-exposure failure mode. Unowned risk is unmanaged risk, regardless of how sophisticated the system is.

• Create psychological safety around reporting agent-to-agent failures. Engineers who quietly correct cascade errors without documenting them deprive the organisation of the failure-pattern data required to improve system governance over time. If your retrospectives discuss model quality but not failure propagation, your learning loop is incomplete.

• Schedule a quarterly system-level red team exercise: deliberately inject a known erroneous output at the cascade entry point identified in step 2 of the audit, and measure how far the error propagates before detection. Tracking that boundary over successive quarters is your most honest measure of governance maturity.

• Reconsider the structure of your agentic review processes. A review agent that sees its own previous output, or that of a directly upstream agent in the same chain, is not an independent reviewer. Structural independence matters, not role designation.

For the Roadmap Owner

• When evaluating multi-agent platforms or frameworks, require vendors to demonstrate failure mode coverage across all six categories identified by Reid et al. (2025). A vendor whose safety documentation addresses only single-agent reliability is selling you a single-agent risk framework for a multi-agent problem.

• Factor the cost of silent cascade failures into your AI ROI projections. Errors that compound through agent chains before reaching a human reviewer are harder to detect and more expensive to remediate than single-agent hallucinations. Budget for verification overhead proportional to agent network depth, not proportional to agent count.

• Treat agent model diversity as a portfolio risk decision with quantifiable cost and benefit, not a technical implementation detail. A system where all agents share a base model carries correlated failure exposure; the cost of model diversification is bounded, the cost of a monoculture collapse event is not.

• Resist the organisational temptation to measure agentic pipeline performance exclusively through task completion rates. A system that completes 95% of tasks while silently producing catastrophic cascade errors in the remaining 5% is not a high-performing system. It is a system with an unmonitored tail risk. The measurement framework must match the failure structure (Reid et al., 2025).

Closing thought

Software engineering has learned this lesson before. Brooks documented it for teams in 1975: adding people to a late project makes it later, because communication overhead grows faster than productive capacity. Perrow formalised it for industrial systems in 1984: tightly coupled systems with interactive complexity produce accidents that no component-level inspection can prevent. The multi-agent paradigm is the latest instance of the same structural insight: interaction creates failure modes that component analysis cannot predict.

The question for engineering organisations is not whether to adopt multi-agent architectures. The market pressure will answer that. The question is whether governance will evolve at the pace of deployment. How many of the six failure modes described above does your current risk framework explicitly address?

This is the last edition of Software Insights before the Easter break. I am heading to ICSE in Rio next, so if you are there, please say hello. The next edition lands on April 28.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change

View all posts

References

Becker, J., Jorke, M., Ahrabian, K., Shang, R., Gao, G., Altman, R., Liang, P., & Yang, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv:2507.09089.

Cemri, M., Lin, M., Stengel-Eskin, E., Reddy, S., & Subramanian, S. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657.

Reid, A., O'Callaghan, S., Carroll, L., & Caetano, T. (2025). Risk analysis techniques for governed LLM-based multi-agent systems. Gradient Institute Technical Report. arXiv:2508.05687.

Sonar. (2026). State of Code: Developer Survey Report 2026. SonarSource.

The numbers from Harvard are unambiguous: junior employment at GenAI-adopting firms fell roughly 9 percent relative to comparable non-adopters in less than two years (Hosseini & Lichtinger, 2025). The mechanism behind that decline is slower hiring, not displaced roles or accelerated departures. Firms are pre-emptively sealing the junior pipeline in anticipation of automation capabilities they do not yet possess.

That timing matters for every engineering leader making workforce decisions right now. Firms are acting on expectations about the future state of AI. The organizational costs of that bet are accumulating quietly, in the form of knowledge pipelines that are narrowing, senior cognitive loads that are climbing, and a talent architecture that may fracture before the anticipated automation arrives.

Software engineering is a socio-technical system. Technical capability without the human architecture to govern, contextualize, and correct AI output does not produce efficiency. It produces invisible debt.

Subscribe to newsletter

What the data actually shows

Hosseini and Lichtinger (2025), working from résumé and job-posting data assembled by Revelio Labs, built one of the most comprehensive firm-level datasets yet applied to this question: 284,974 U.S. firms, 156 million employment spells covering roughly 62 million unique workers, and 198 million job postings spanning 2015 through early 2025. They identified GenAI-adopting firms by detecting postings that explicitly recruited "GenAI integrator" roles, positions dedicated to implementing or operating GenAI technology in the firm's workflow. By that criterion, 10,599 firms had adopted GenAI by March 2025. Those firms represent only 3.7 percent of the sample by count, but account for 17.3 percent of total employment, reflecting the concentration of adoption among large, technology-intensive organizations.

Prior to late 2022, adopting and non-adopting firms tracked each other closely on junior employment. The divergence began in 2023 Q1, shortly after the release of ChatGPT. Using a difference-in-differences (DiD) design that controls for time-invariant firm characteristics and aggregate period shocks, the study found that junior employment in adopting firms fell approximately 9 percent relative to non-adopters after six quarters. Senior employment showed no comparable break in trend; adopting firms continued expanding their senior headcount more aggressively than non-adopters throughout the sample. A more demanding triple-difference specification, comparing junior versus senior employment changes within the same firm and period relative to non-adopters, produced a roughly 10 percent decline in the junior share after six quarters (Hosseini & Lichtinger, 2025).

These findings are associational rather than strictly causal. The parallel pre-trends from 2015 to 2022 reduce the plausibility of simple confounding explanations, and the staggered event-study design, which traces employment dynamics around each firm's individual adoption date, shows no divergence in the eight quarters before adoption. The post-adoption decline emerges approximately two quarters after the first GenAI integrator posting and reaches an 8 percent reduction after eight quarters. Unobserved firm characteristics correlated with both adoption and junior employment decisions cannot be ruled out entirely, and the analysis covers a short window during which longer-run adjustments in training, task design, and internal career structures remain unknown.

What the study establishes with considerably more confidence is the mechanism.

"We find that the decline in junior employment at adopting firms is driven primarily by a substantial reduction in hiring. Separation rates for juniors in adopting firms also decreased relative to non-adopters, but the reduction in hiring was considerably larger, leading to a net decline in junior positions. Promotion rates, by contrast, remained broadly stable after early 2023."

(Hosseini & Lichtinger, 2025, p. 5)

Relative to non-adopters, GenAI-adopting firms hired on average five fewer junior workers per quarter after 2023 Q1. The pipeline is not draining through attrition; it is being sealed at the top through deliberate hiring decisions.

The decline is concentrated in roles with high GenAI exposure, as measured by Eloundou et al. (2024). Junior employment in low-exposure occupations at adopting firms showed no significant change, indicating the contraction is targeted at the roles GenAI is most expected to eventually automate rather than representing a broad headcount correction. A further heterogeneity finding sharpens the picture: juniors from mid-tier universities, specifically tiers 2 and 3 in the study's five-level prestige classification, experienced the steepest relative employment declines. Graduates from the most elite institutions and from the least selective schools saw smaller reductions. The group most associated with the "interchangeable knowledge worker" profile is bearing the largest adjustment.

Convergent evidence from adjacent work reinforces the pattern. Brynjolfsson et al. (2025a), analyzing U.S. payroll data, found that employment of workers aged 22-25 in the most AI-exposed occupations fell approximately 13 percent relative to trend since late 2022, while more experienced workers in those occupations saw stable or rising employment. Simon (2025) documented that entry-level job postings declined more than 35 percent since January 2023, with a 10-point increase in GenAI exposure predicting an 11 percent decline in entry-level demand and a 7 percent rise in senior-role demand. At the September 2025 FOMC press conference, Federal Reserve Chair Powell observed: "You are seeing some effects... A particular focus on young people coming out of college" (Federal Reserve Board, 2025).

Why this is not just a labor market story

These findings would be consequential as labor economics. They become urgent when read as an organizational engineering problem. Three risks compound each other in ways that quarterly Profit & Loss (P&L) reports are structurally unsuited to detect.

Risk 1: The knowledge pipeline collapse

Junior roles in engineering organizations serve a function that productivity metrics do not capture directly. They are the mechanism through which tacit architectural knowledge transfers across generations of practitioners. Junior engineers ask the questions that senior engineers stopped asking years ago, the questions that force implicit assumptions into the open. They surface inconsistencies in legacy systems precisely because they have not yet absorbed the organizational habits that make those inconsistencies invisible.

When the pipeline closes, that function closes with it. Argyris (1982) identified the failure mode that follows as a breakdown of double-loop learning: organizations whose governing assumptions are never surfaced or interrogated because no one in the system is positioned to ask why the system works the way it does. In AI-augmented engineering contexts, that failure compounds. Governing assumptions are increasingly embedded in generated code and automated workflows. Without a junior-level presence to interrogate them, those assumptions enter production as invisible architectural debt, visible only when the system breaks in ways no one on the remaining team can explain.

Risk 2: The senior burnout trap

The implicit calculus behind junior hiring reductions holds that a senior engineer paired with GenAI can absorb the work formerly distributed across a junior-to-senior ratio. The Remote Labor Index puts a precise number on why this calculus fails: AI achieves 70 to 80 percent success rates on tasks humans complete in under one hour, but the success rate drops below 20 percent for tasks requiring more than four hours of human-equivalent labor. The professional-standard automation rate for complete deliverables is 2.5 percent (Center for AI Safety & Scale AI, 2025).

The gap between what AI completes reliably at the sprint level and what it delivers at the project level is the work that falls to the most expensive human resource in the system. Without junior engineers to absorb the tractable, high-volume portions of the workload, senior engineers carry both the complex problem-solving that has always been their domain and the AI remediation work that juniors once handled. That reallocation does not appear on quarterly productivity dashboards. It surfaces six to eighteen months later as unexplained senior attrition, declining architectural quality, or the quiet decision by experienced engineers to leave for organizations where their time is used at its full value. Research on psychological capital establishes that self-efficacy, the psychological anchor of sustained high performance, erodes specifically when professional identity is subsumed by remediation work (Luthans & Youssef, 2004). The burnout is slow, cumulative, and organizationally invisible until it becomes a retention crisis.

Risk 3: The forward-looking misjudgment

Hosseini and Lichtinger (2025) are explicit about the interpretive boundary of their findings. The speed of the junior employment decline, beginning just two quarters after GenAI adoption, is too abrupt to reflect actual task automation, which typically materializes gradually. The most plausible explanation is that firms are making forward-looking adjustments, scaling back junior hiring for roles they predict will be automated in the near future, treating reduced hiring now as less costly than layoffs later. The authors formalize this mechanism: expectations of future labor-saving productivity gains depress current hiring through what they model as a "firing wedge," raising the effective marginal cost of employing workers who may later need to be separated.

If those expectations prove accurate, the current junior hiring contraction may ultimately be economically rational at the firm level. If those expectations are wrong, and the Remote Labor Index strongly suggests current GenAI capabilities fall well short of professional-standard project completion, the damage is not symmetrical. Gartner predicts that 50 percent of companies that reduced headcount in the name of AI will be forced to rehire by 2027, often under different titles, to recover lost service quality and institutional expertise (Gartner, 2026). Klarna's experience illustrates the asymmetry: premature replacement of human staff with AI systems led to service quality decline and customer revolt, requiring a strategic reversal more expensive and disruptive than the original reduction (Forrester, 2026). The savings from closing the junior pipeline are front-loaded; the costs are back-loaded and compounded by a talent market that does not quickly regenerate the mid-career engineers that junior programs were producing.

A 30-minute junior pipeline audit

The following eight questions are designed for engineering leaders who want to assess their organization's current exposure to the risks identified above. Each question is tied to a specific failure mode identified in the research.

1.     What percentage of your current engineering headcount sits at the junior or entry level, and how has that figure changed in the two years since your organization began adopting GenAI tools?

2.    When did a junior engineer last participate meaningfully in a live architectural conversation with a senior: not an AI-assisted review, but a genuine dialogue about design decisions and their rationale?

3.    What fraction of your AI-generated output requires remediation before it meets production standards, and who is performing that remediation work?

4.    If your three most senior engineers left tomorrow, which architectural decisions and design rationale could you reconstruct from your codebase, your documentation, and the people who remain?

5.    What is your current onboarding time for a new hire to reach independent productivity, and has that figure changed since you reduced junior hiring?

6.    Do your AI-efficiency metrics capture cycle time at the task level, or total team cognitive load across a sprint or quarter?

7.     Do you have a documented process for surfacing and interrogating assumptions embedded in AI-generated code before it enters production?

8.    Have you stress-tested your "senior plus AI" productivity model against what current GenAI systems can deliver on projects longer than four hours, rather than against vendor capability claims? 

Next moves

For the Builder

Begin externalizing the tacit knowledge you carry. The architectural rationale, the constraint history, the decisions that were almost made differently: none of that exists in your codebase. Write it down in decision records, record technical walkthroughs, or teach it directly to others. The medium matters less than the act of getting it out of your memory and into a form that survives your departure.

Track your own AI remediation load. For one sprint, log the hours you spend fixing generated output versus hours spent on work that stretches your capabilities. If remediation is consuming more than a quarter of your cycle, that figure belongs in your next conversation with your manager.

When your team plans work, advocate for junior involvement in AI-augmented workflows rather than routing all junior touchpoints to the AI. The engineering learning that prepares someone for a senior role happens in interaction with the work and with senior practitioners, not in reviewing generated output.

For the Manager

Maintain the junior pipeline infrastructure even when full-time headcount is frozen. Structured apprenticeship tracks, rotation programs, and internship pipelines preserve the knowledge transfer function under headcount constraints, at a fraction of the cost of rebuilding from scratch in 2027.

Build a senior burnout signal dashboard before you need one. Track proxy indicators: pull request turnaround times, the ratio of architectural work to remediation work in senior engineers' weekly activity, and whether senior engineers are spending time in the quadrant their skills justify. Treat rising signals as early warning rather than confirmation of a crisis that has already arrived.

Establish explicit knowledge capture rituals. Architecture decision records, post-mortems that document not just what failed but why the system was designed to enable that failure, and recorded technical onboarding sessions are the organizational immune system against the knowledge pipeline collapse described in Risk 1.

For the Roadmap Owner

Add junior pipeline health to your technical debt accounting. A codebase accrues debt when engineering practices degrade; an engineering organization accrues equivalent structural debt when the talent pipeline that renews its capability is closed. Neither shows up on a quarterly P&L until the reckoning arrives, and both are substantially cheaper to prevent than to remediate.

Require that AI productivity claims used in workforce planning be benchmarked against the Remote Labor Index rather than vendor pilot results. An AI system that succeeds on 80 percent of sub-one-hour tasks and 2.5 percent of full-project deliverables is a useful assistant. It is not a replacement for a junior engineer who is three years from being a senior one.

Build now for the Gartner 2027 scenario. The organizations that maintained their junior talent pipelines through 2023-2027 will access a recovering talent market from a position of capability. The organizations that closed those pipelines will compete for a smaller pool of mid-career engineers at a premium, from a position of institutional knowledge deficit.

The Harvard study establishes something the current industry narrative has obscured: the junior employment decline in GenAI-adopting firms is a deliberate hiring choice, made in response to expectations about future automation rather than evidence of automation already occurring. The organizational consequences of that choice are already accumulating in the form of narrowing knowledge pipelines, rising senior cognitive load, and structural fragility that will not appear on quarterly reports until 2027. Whether those consequences become a crisis depends less on where AI capabilities land than on whether leaders treat them as a risk to be managed now or a problem to be solved later, when Gartner predicts half the firms that made the same bet will be rebuilding what they chose to eliminate.

Which description fits your organization?

View all posts

About the author

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

Argyris, C. (1982). The executive mind and double-loop learning. Organizational Dynamics, 11(2), 5-22.

Brynjolfsson, E., Chandar, B., & Chen, R. (2025a). Canaries in the coal mine? Six facts about the recent employment effects of artificial intelligence. Working paper.

Center for AI Safety & Scale AI. (2025). Remote Labor Index (RLI): Measuring AI automation of remote work.

Eloundou, T., Manning, S., Mishkin, P., & Rock, D. (2024). GPTs are GPTs: Labor market impact potential of LLMs. Science, 384(6702), 1306-1308.

Federal Reserve Board. (2025). Transcript of Chair Powell's press conference, September 2025. Federal Open Market Committee Press Conference Transcript.

Forrester. (2026). Predictions 2026: Artificial Intelligence.

Gartner. (2026). Predicts half of companies that cut customer service staff due to AI will rehire by 2027. Gartner Research.

Hosseini, S. M., & Lichtinger, G. (2025). Generative AI as seniority-biased technological change: Evidence from U.S. resume and job posting data. SSRN Working Paper.

Luthans, F., & Youssef, C. M. (2004). Human, social, and now positive psychological capital management. Organizational Dynamics, 33(2), 143-160.

Simon, L. K. (2025). Is AI responsible for the rise in entry-level unemployment? Revelio Labs, Macro Section.

The most informative thing about AI’s current capabilities in software engineering is not what it can do on a benchmark. It’s who the benchmark is comparing it against.

A new study from Model Evaluation & Threat Research (METR) proposes a deceptively simple metric: the 50%-task-completion time horizon, defined as the duration of a software task (measured in human expert working time) that a given AI agent can complete with 50% reliability (Kwa et al., 2026). Applied to twelve frontier models released between 2019 and 2025, it tells a story that’s both more impressive and more limited than most commentary suggests. GPT-2 in 2019 had a 50% time horizon of two seconds. GPT-o3 in early 2025 sits at roughly 110 minutes. The doubling time over this six-year stretch: approximately 207 days, fitting the data with R² = 0.97 across 170 benchmark tasks, over 800 human baseline runs, and 2,529 hours of professional working time.

That exponential curve is real. But the curve measures performance relative to a low-context human working a single isolated task from scratch, not relative to the senior engineer who built the system. AI’s practical limitations live in the gap between those two baselines.

This matters now because many engineering organizations are making tooling and staffing decisions based on what frontier models can do at the benchmark level, without a clear understanding of where the benchmark baseline actually falls in the spectrum of human expertise. The METR study offers the most rigorous attempt yet to locate AI capability on that spectrum, and what it finds is that the baseline is not where most industry commentary implies.

Subscribe to newsletter

The 5–18x problem: why context is the unit that matters

The clearest evidence comes from a supplementary experiment in the same study. Researchers collected five real, recent, uncontaminated issues from an internal production repository and asked three AI agents (GPT-4o, Claude 3.5 Sonnet, and o1) to resolve them. They also timed how long the repository’s own maintainers took, alongside external human contractors with no specialized codebase knowledge. What showed up is something no benchmark had previously quantified:

“We find that our contract baseliners take 5x–18x longer to resolve issues than repository maintainers.” (Kwa et al., 2026, Appendix C.2)

One issue: writing simple comments across ten Python files. The repository maintainer finished in five minutes. An external contractor took 93 minutes. The three AI agents, across 30 combined runs, succeeded zero times. A second issue took a maintainer 20 minutes; a contractor spent 113 minutes and still needed fundamental rework. The AI agents again scored zero across five runs.

The point isn’t that AI fails to beat expert humans. Nobody expected otherwise. The point is that AI sits in the contractor tier. When benchmark studies report that o1 achieves a 110-minute time horizon, they’re measuring its ability to do the kind of work a skilled but contextually unequipped contractor can do in that time, not the kind of work a senior maintainer handles in five minutes while reviewing a PR before standup.

That gap isn’t about compute. It’s about accumulated domain context: which files matter, how the team historically handles this class of bug, what the unstated acceptance criteria actually require, and when a minimal patch is correct even without a confirming test. Experienced engineers internalize this over months and years. Neither contractors nor AI agents can reliably infer it from a task description. The paper says as much: agents “consistently demonstrate knowledge of tools and techniques, but appear to struggle with the larger context required for working in a real codebase” (Kwa et al., 2026).

What makes this finding particularly striking is the nature of the task where the gap was largest. Issue 11, writing comments across ten Python files, was the simplest issue for the repository maintainers, who completed it in under five minutes. For an external contractor, it took 93 minutes. For the AI agents, the success rate was zero across 30 runs. The simplicity of the task from a maintainer’s perspective is precisely what explains the difficulty for everyone else: completing it correctly requires knowing which files need commenting, what documentation conventions the codebase follows, and what level of depth is appropriate for the intended audience, none of which appears in the issue description. This is not a pathological edge case. It is the ordinary nature of production work.

For teams using AI assistants today, this creates a practical calibration challenge. The contractor-tier comparison suggests that AI is relatively well-suited to work a capable engineer could complete with only the information in a task ticket, and relatively ill-suited to work that draws on codebase familiarity built over time. The former category is narrower than it might appear. Much of what looks like a bounded, ticket-level task actually contains embedded dependencies on contextual knowledge that never makes it into written documentation.

The messiness gap: what benchmarks can’t score

The METR study also introduces a structural critique of how we measure AI capability. The researchers scored their 170 benchmark tasks against a 16-factor “messiness” rubric capturing systematic differences between benchmark tasks and real production work (Kwa et al., 2026).

The factors are worth knowing. Real-world engineering regularly requires operating in environments that change without your direct interaction, making irreversible decisions on incomplete information, coordinating in real time with other people or systems, hunting down information not provided in the prompt, and applying unstated professional judgment about when a technically valid solution is actually appropriate. Standard benchmarks strip most of this away. Tasks are static, automatically scored, and forgiving of individual errors.

AI success rates drop on high-messiness tasks. But here’s what’s interesting: the rate of improvement across model generations is roughly the same for messy and clean subsets. Models are getting better across the board, but the messiness penalty isn’t closing. Agents that now handle about half of well-specified tasks still manage fewer than a quarter of the most realistic ones.

One messiness factor stands out as particularly consequential for daily engineering work: the “information seeking required” dimension, defined as tasks where the agent must gather information it would not be expected to know in advance. This maps most directly to codebase context. A maintainer who needs to diagnose a bug already knows which subsystems interact, which recent PRs might be relevant, and which team member introduced the pattern in question. An AI agent operating from a task description has none of this. It must probe the environment from scratch, and the METR data show that current agents do this inconsistently, often making guesses rather than systematically seeking information before committing to an approach (Kwa et al., 2026).

The study includes one result that cuts against the simple narrative in an instructive way. In one variant of an HCAST task, researchers randomized file and folder names to make the task structurally messier. Surprisingly, o1 performed better on the scrambled version than the original, achieving a 50% success rate versus 34%. The researchers’ explanation: when told to find an “AR report,” o1 would often grep for that exact term and fail when the file was named differently; in the randomized version, it was prompted to search more broadly and succeeded more often. This is a useful caution against treating messiness as uniformly harmful to AI performance. Some of what makes real tasks harder for humans actually removes the surface-level anchors that cause AI agents to take shortcuts.

Practically: AI is most reliably useful on tasks that resemble benchmark conditions. Isolated, clearly specified, automatically verifiable, deterministic, no hidden requirements. The more a task looks like actual production work, the more the performance advantage shrinks.

What the timeline actually means

If the doubling time holds, naive extrapolation puts AI at a one-month task horizon (167 working hours) somewhere between mid-2028 and mid-2030 (Kwa et al., 2026). If the accelerated 2024–2025 trend continues, at roughly 109 days per doubling, that could arrive as early as 2027.

These numbers need careful handling. A one-month task is not a one-month job.

A software engineer’s month isn’t one continuous task. It’s context acquisition, async coordination with other engineers and stakeholders, priority negotiation based on organizational signals nobody wrote down, judgment calls about which technical debt to accept, and keeping a shared mental model alive across a team. Benchmarks measure the first part. They don’t touch the rest, because the rest can’t be automatically scored.

There’s a related nuance in how the time-horizon metric works. The METR study also computed the 80% success rate time horizon: the length of tasks that models can reliably complete most of the time. The doubling rate at 80% reliability is similar to the 50% rate (204 days versus 207 days), but the absolute horizon lengths are 4–6x shorter. In practical terms, this means that even models that sometimes complete two-hour tasks cannot reliably complete tasks that take a human 30 minutes. The 50% horizon gives a sense of the ceiling; the 80% horizon gives a better sense of what teams can depend on day-to-day without close supervision.

The drivers of improvement matter too. METR attributes progress primarily to better logical reasoning, improved ability to adapt to mistakes rather than repeating them, and greater capacity for multi-step tool use (Kwa et al., 2026). Concretely: GPT-4 1106 repeated failed actions in 12 of 31 analyzed failures; o1 did so in only 2 of 32. This isn’t a compute scaling story. It’s a model behavior story, which means engineering teams get more from tracking their tools’ specific failure modes than from watching headline benchmark scores.

A 30-minute audit for your team

Run this before your next sprint planning.

1. List your three most common AI-assisted tasks. Estimate how long a skilled but contextually unfamiliar engineer would take to do each without AI. Under 90 minutes falls within o3’s documented range. Over two hours doesn’t.

2. Look at the last ten AI-generated PRs your team merged. How many needed substantive modification during review? More than three and you’re probably treating AI as context-aware when it isn’t.

3. Find one task from the past month where AI produced a plausible but contextually wrong answer that slipped through initial review. What information would have caught it? Is that information available in your current workflow?

4. Score your AI-assisted tasks on three simplified METR messiness factors: automatic verifiability, environmental stability, and implicit requirements. High scores predict lower AI reliability.

5. Measure review time vs. generation time for a representative task. If review routinely exceeds 50% of generation time, the efficiency gain is thinner than it looks.

6. Ask your most experienced engineers what knowledge a new team member typically takes three months to acquire. That’s roughly what AI can’t supply to itself right now. Tasks that depend on this knowledge will perform at contractor-tier reliability regardless of model generation.

7. If you’re planning headcount changes based on AI automation, plan around low-context task categories, not roles. The evidence doesn’t support the latter yet.

What to do with this

If you write code, start supplying your AI tools with the context a senior colleague would already have: architectural constraints, recent related changes, and what “good enough” actually looks like for your team. Keep notes on cases where the model gives you something algorithmically correct but contextually wrong. Those notes will be more useful than any benchmark for calibrating trust. Track your review time per AI-generated PR for a month. That ratio tells you whether AI is saving you time or just moving the work around. When a model fails silently, producing an answer that looks correct but misses an unstated requirement, treat it as a data point about the limits of your current context-supply strategy, not as a fundamental capability gap.

If you manage engineers, the METR data gives you a clean frame for deciding which tasks to hand to AI. Isolated, verifiable, low-context tasks are the sweet spot. The rest still need your senior people. Build a lightweight log of AI-assisted outcomes by task type; two months of data, and you’ll know where the gains are real and where oversight costs are quietly eating them. The most important management question isn’t which tools your team uses. It’s which categories of work require institutional knowledge that currently exists only in your people, and whether you’re protecting that capacity deliberately or letting it atrophy under the assumption that AI will eventually cover it.

If you own a roadmap, plan around two timelines. AI’s ability to handle well-specified engineering work is doubling roughly every seven months and already sits in the 90-minute range. That will keep expanding. But engineering roles, defined by institutional knowledge, coordination, and judgment under unstated constraints, will stay out of reach much longer than individual tasks will. The organizations getting this right are the ones who can tell the difference, and who are actively investing in the high-context capabilities that benchmarks don’t capture. Treating those capabilities as overhead waiting to be automated is the most consequential mistake available right now.

The engineers whose work is hardest to replicate aren’t the ones writing the most code. They’re the ones whose institutional knowledge turns a 90-minute debugging session into a five-minute fix. The trend line says AI will keep getting better. It doesn’t say your senior engineers’ context is about to become worthless. If anything, it’s becoming more valuable, because it’s the thing the machines still can’t do.

What in your organization is being treated as a low-context task when it’s actually high-context? Worth asking.

View all posts

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity. 

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

Kwa, T., West, B., Becker, J., Deng, A., Garcia, K., Hasin, M., Jawhar, S., Kinniment, M., Rush, N., Von Arx, S., Bloom, R., Broadley, T., Du, H., Goodrich, B., Jurkovic, N., Miles, L. H., Nix, S., Lin, T., Painter, C., Parikh, N., Rein, D., Sato, L. J. K., Wijk, H., Ziegler, D. M., Barnes, E., & Chan, L. (2026). Measuring AI ability to complete long software tasks. arXiv preprint arXiv:2503.14499.

The consulting industry has spent two years producing reports on why AI investments fail. The data is consistent and substantial. What the reports lack is a theoretical frame that explains the pattern.

The numbers arriving from every major consulting firm are converging on the same uncomfortable finding. PwC's 29th Global CEO Survey, polling over 4,400 executives worldwide, found that 56% of organizations reported neither increased revenue nor reduced costs from their AI deployments over the prior twelve months (PwC, 2026). CEO confidence in revenue growth hit a five-year low, even as AI investment continued to rise (Reuters, 2026). MIT researchers documented a 95% failure rate for Generative AI pilots across enterprise settings (Fortune, 2025). Deloitte's dedicated analysis of the AI ROI question confirmed the pattern: investment is increasing while measurable returns remain elusive for the majority, with genuine P&L impact concentrated in a small minority of organizations (Deloitte, 2025). McKinsey's State of AI survey reinforced that the performance gap between leading and lagging firms is widening, and that the differentiating factor is organizational execution rather than model selection (McKinsey, 2025). The World Economic Forum's synthesis of CEO perspectives heading into 2026 described organizations caught between the pressure to invest and the inability to demonstrate returns (WEF, 2026).

Only 12% of organizations, a group PwC labels "Vanguard" firms, were achieving simultaneous revenue gains and cost reductions (PwC, 2026). The rest are, in one form or another, paying for a technology that is not returning the investment.

The explanations offered across these reports are varied. Fragmented data architectures, where organizations attempt to run advanced reasoning models on inconsistent, siloed records. Isolated departmental pilots that fail to connect with core business systems and generate no enterprise-scale return. Insufficient leadership literacy. Work intensification, documented in an eight-month ethnographic study by Ye and Ranganathan at UC Berkeley Haas, where AI tools were expanding task scopes, dissolving natural pauses in the workday, and introducing parallelism that increased cognitive load rather than reducing it. Each of these explanations captures something real.

What none of them adequately explains is the mechanism. Why do technically capable tools, deployed in well-resourced organizations with genuine executive commitment, produce so little measurable return? My empirical research in software engineering offers a precise answer: compatibility. Specifically, the degree to which a Generative AI tool fits within the existing workflows, technical environment, and working practices of the people expected to use it. When that fit is absent, neither the tool's capability nor the organization's commitment can substitute for it.

Subscribe to newsletter

What the Reports Are Actually Describing

Before turning to the empirical evidence, it is worth dwelling on what the consulting data is showing in concrete terms, because the ROI crisis is not uniform. PwC's analysis draws a sharp distinction between what it calls the "Vanguard" minority and the majority. The Vanguard firms share three characteristics: enterprise-scale deployment rather than isolated pilots, clean and integrated data environments that give AI tools access to the information they need to be useful, and cross-functional collaboration that prevents AI initiatives from being captured by a single department (PwC, 2026). The PwC analysts are essentially describing compatibility conditions without using the term.

Deloitte's framing of the "paradox" is instructive in a similar way. Investment is rising, in some sectors doubling, while EBITDA impact remains elusive. The natural interpretation is that organizations are buying more of something that is not working. But the Deloitte analysis points toward a subtler problem: organizations are deploying tools that generate activity without generating value, because the tools have not been integrated into the workflows where value actually originates (Deloitte, 2025). McKinsey's data confirms that high performers are distinguished by their ability to scale AI beyond "pockets of innovation" into systematic workflow integration (McKinsey, 2025).

The MIT pilot failure data is the sharpest expression of this pattern. A 95% failure rate is not a technology problem. It is a deployment problem. The pilots are failing not because the models produce inadequate outputs in controlled conditions, but because those outputs cannot be absorbed into the work as it is actually structured. The tool and the workflow are not compatible, and no amount of prompting strategy resolves a structural integration gap.

The Empirical Evidence: Compatibility Drives Adoption, Not Usefulness

My research published in ACM Transactions on Software Engineering and Methodology was not designed to comment on the ROI crisis directly. I was studying the factors that drive software engineers to adopt Generative AI tools. But the findings map directly onto the pattern the consulting reports are describing, and they offer a precision the reports lack (Russo, 2024).

I conducted a mixed-methods investigation: a qualitative study with 100 software engineers followed by quantitative validation using Partial Least Squares Structural Equation Modeling on data from 183 practitioners drawn from 27 countries. The theoretical framework I developed, the Human-AI Collaboration and Adaptation Framework (HACAF), integrated the Technology Acceptance Model, Diffusion of Innovation Theory, and Social Cognitive Theory. The central question was: what actually drives a software engineer to adopt an LLM tool?

The conventional answer, grounded in the Technology Acceptance Model, is perceived usefulness. If you believe the tool helps you, you use it. Most organizational AI strategies rest on this assumption. My data contradicted it. The direct path from technology perceptions to adoption intention was not statistically significant (path coefficient 0.155, p = 0.204). Perceived usefulness, ease of use, and relative advantage, taken together, did not predict whether engineers would adopt these tools.

What did predict adoption, with substantial and statistically robust explanatory power, was compatibility.

Compatibility Factors are the most important element to improve the Intention to Use. They explain, almost single-handedly, the adoption of AI tools with a very high R² close to 50%.

Russo (2024), ACM Transactions on Software Engineering and Methodology

The path coefficient from compatibility to adoption intention was 0.536, with a large effect size (f² = 0.66). The full model explained 48.9% of the variance in adoption intent. The Importance-Performance Map Analysis confirmed that compatibility carries the highest importance score of any construct in the model (total effect: 0.646). Social factors (peer influence and self-efficacy) showed no significant direct path to adoption (p = 0.170). Organizational support and personal innovativeness were also non-significant (p = 0.949).

The theoretical implication is clear: an engineer who believes a tool is useful, who works in a supportive organization, and who is surrounded by colleagues who encourage adoption will still not meaningfully adopt that tool if it does not fit the way they work. This is the mechanism the consulting reports are observing without naming.

What Compatibility Means in Practice

In the qualitative phase of my research, I asked 100 software engineers directly about the compatibility of LLMs with their current work. Four aggregate dimensions emerged.

The most frequently cited, by 39% of respondents, was improved efficiency: the sense that the tool speeds up existing tasks rather than requiring engineers to rebuild their working habits around a new paradigm. A further 28% described the value of AI assistance in situations where traditional search methods fell short, particularly for code discovery and documentation. Sixteen percent cited similarity to current practices, characterizing LLM use as an incremental extension of familiar habits. One participant put it simply: "It's like Googling but I don't need to filter as much information." Eleven percent identified adaptation and learning as the dominant dimension, acknowledging that the tool represents a genuinely new paradigm that requires time and investment before it feels natural.

The complexity data is equally instructive. Among the barriers engineers cited, one participant noted: "Might not be compatible with the systems at my workplace." Another observed that LLMs are "nice for generic tasks, but the models have zero knowledge about our internal APIs so they're really hard to apply." These are not complaints about model quality. They are descriptions of integration gaps that no prompting strategy can bridge.

This is the same gap PwC identifies when it distinguishes Vanguard firms by their integrated data environments. The firms that are generating returns have made the infrastructure investments that allow AI tools to access the information that makes them genuinely useful for specific work. The majority have not, and the tools remain generically capable in contexts where specific capability is what produces value.

I also found that compatibility failures compound with experience heterogeneity. Fifty-four percent of respondents in my study described ease of use as something that develops through practice, while 26% identified individual background, including prior programming experience and familiarity with NLP concepts, as significant determinants of perceived fit. A deployment that treats all developers as equally prepared will systematically underperform, because the compatibility gap between the tool and the person varies substantially by career stage and cognitive style.

Three Places Where Compatibility Gets Lost

The consulting reports and my research converge on three distinct levels where the fit between AI tools and organizational reality tends to break down.

System fit refers to integration with the existing technical stack. PwC's Vanguard firms are characterized precisely by having solved this problem: clean data environments, API access, and tooling that allows AI to connect to the information it needs to be useful for actual tasks. The 95% pilot failure rate documented by MIT reflects, in significant part, the inverse condition: technically capable tools deployed into environments where they cannot access the context that would make them valuable. Generic capability deployed against context-specific work produces generic output, which developers quickly learn to discard.

Flow fit addresses whether the tool sustains or disrupts a developer's cognitive state. The UC Berkeley Haas research by Ye and Ranganathan identified three forms of work intensification: expanded scope, dissolved pauses, and parallelism. Each represents a form of flow disruption. Deloitte's analysis of the ROI paradox is consistent with this: organizations reporting the highest AI investment levels are not reporting proportionally higher returns, because the human cost of adaptation is consuming the efficiency gains before they reach the P&L (Deloitte, 2025). A tool that demands significant prompting overhead to produce usable output, or one whose output review cycle consumes more time than the generation saved, has negative flow fit for that task type.

People fit captures the match between the individual engineer and the tool. In my research, I found that 57% of respondents placed significant importance on being seen as someone who uses cutting-edge technology, a form of self-efficacy pressure that can drive superficial adoption without genuine workflow integration. Meanwhile, 35% prioritized practicality and efficiency over novelty, indicating they would adopt a tool only when it demonstrably served their specific tasks. McKinsey's data shows that high-performing organizations differentiate deployment approaches by role and experience level; they do not apply a uniform adoption mandate and expect uniform results (McKinsey, 2025).

The Compatibility Audit: A 30-Minute Drill for Your Team

Before authorizing the next AI investment or expanding a current deployment, a structured compatibility assessment can prevent the pilot failure pattern from repeating. Run through the following as a team in a single session.

1. Map the workflow first. Document the five to seven recurring tasks your team performs most often. For each, identify the current toolchain, the expected output format, and the review steps involved.

2. Test system fit against actual tasks. Can the AI tool access the data it needs for your specific work, including internal APIs, proprietary libraries, or domain-specific documentation? If the answer requires significant workarounds, record the integration cost before measuring any productivity gain.

3. Run a flow disruption count. Have three developers use the tool during a standard sprint. Ask each to note any moment where the tool created friction, required a context switch, or produced output that needed substantial correction. Count these events across the sprint and compare against the time saved.

4. Assess experience heterogeneity. Identify the range of seniority and prior AI experience on your team. Has the deployment plan differentiated the onboarding approach for junior developers versus those with a decade of experience? My data indicates this differentiation is not optional: it is predictive of adoption outcome.

5. Audit the learning curve assumption. My research found that 54% of software engineers describe LLM ease of use as something that develops through practice. Is there allocated time for this in the sprint cadence, or is immediate productivity being assumed?

6. Check organizational stance clarity. In my study, 42% of respondents worked in organizations with a clearly supportive attitude toward LLMs, while 15% reported active opposition and 20% reported a neutral stance that left the decision to individual discretion. Ambiguity in organizational stance depresses adoption regardless of tool quality.

7. Evaluate the output review cost. The time saved on generation must exceed the time spent on verification for a net compatibility gain. Test this for each task type rather than assuming the balance holds uniformly.

8. Score similarity to current practices. For each task type, ask developers whether using the tool feels like an extension of existing habits or a replacement of them. Tools that extend generate organic adoption. Tools that replace generate sustained resistance.

Next Moves

For The Builder

Maintain a compatibility log for the first four weeks of any new AI tool deployment. Record which task types produce clean, usable outputs on the first pass, which require significant prompting iteration, and which produce outputs that are structurally incompatible with your downstream review process. This data is the basis for an evidence-based adoption recommendation, and it is far more valuable than any benchmark score the vendor has provided.

When a tool consistently fails on tasks involving your internal systems or proprietary context, raise the integration gap with your team lead. Do not compensate by constructing elaborate prompting strategies for a tool that lacks access to the information it needs. My research makes clear that this compatibility failure cannot be engineered around at the individual level.

Track your own learning curve trajectory. If you are not observing a meaningful reduction in prompting friction after four weeks of consistent use, this is diagnostic information about tool-workflow alignment, not a reflection of your ability to adopt new technology.

For The Manager

Stop using adoption rates as a proxy for AI value. A team that has uniformly adopted a tool producing consistent flow disruption is not outperforming a team that has selectively adopted a tool for the specific tasks where the fit is strong. Measure time-to-first-usable-output and review-iteration counts per task type, and track these over time.

Differentiate deployment expectations by developer experience level. My findings show that individual background substantially shapes how quickly an engineer can work effectively with LLMs. Pairing junior developers with more experienced practitioners during the initial adoption period, specifically to share workflow-compatible prompting strategies, reduces the learning curve and mitigates the risk of the complacency dynamic I observed in 16% of respondents, who worried that junior engineers were losing foundational skills by over-relying on AI output.

Create structured space for the team to surface compatibility failures. If developers are routinely encountering mismatches between AI output format and downstream review requirements, this needs to reach engineering leadership before it becomes an invisible drag on velocity that no sprint metric captures.

For The Roadmap Owner

Reframe your AI evaluation criteria to lead with compatibility assessment rather than model benchmarks. PwC's Vanguard firms share integrated data environments and systematic deployment, not superior model selection (PwC, 2026). My research explains why: nearly 50% of adoption intention variance is explained by compatibility factors alone, with technology perceptions showing no direct path to adoption. Procurement that selects on benchmark scores is optimizing for a variable that does not drive adoption, and without adoption, there is no return.

Before authorizing full deployment, commission an assessment against the three compatibility dimensions (system fit, flow fit, and people fit) for the specific teams and task mixes involved. The 95% pilot failure rate is not primarily a consequence of model underperformance. It is a consequence of skipping this assessment.

Allocate budget explicitly for integration infrastructure. API access layers, internal documentation indexing, and output format alignment are investments that appear nowhere in most AI vendor proposals and prominently in the practices of the firms generating real returns. These investments directly improve compatibility factors, which my data identifies as the primary driver of adoption intent.

A Question Worth Taking Back

The consulting reports have accurately mapped the scale of the AI ROI crisis. What they have been slower to provide is a mechanism. My research suggests the mechanism is compatibility: the structural fit between a tool and the workflow, stack, and people where it is deployed. When that fit is absent, capability does not produce adoption, and adoption does not produce return.

The organizations generating real returns have not found a better model. They have achieved a better fit.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

View all posts

References

Deloitte. (2025). AI ROI: The paradox of rising investment and elusive returns. Deloitte Insights.

Fortune. (2025). MIT report: 95% of generative AI pilots at companies are failing. Fortune.

McKinsey & Company. (2025). The state of AI: Global survey 2025. McKinsey Quarterly.

PwC. (2026). 29th Global CEO Survey: Leading through uncertainty in the age of AI. PricewaterhouseCoopers.

PwC. (2026). CEOs, to get real value from AI, put the right foundations in place. The Leadership Agenda.

Reuters. (2026). CEO revenue confidence hits 5-year low: PwC survey. Reuters.

Russo, D. (2024). Navigating the complexity of Generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), Article 135.

World Economic Forum. (2026). Reinvention in a fragmenting world: What CEOs are saying (and need to know) in 2026. World Economic Forum.

Ye, X. M., & Ranganathan, A. (2025). Work intensification and the vicious cycle of AI-assisted productivity. UC Berkeley Haas School of Business.

A software researcher at University College London built a production-grade, multi-module data analysis platform (118 Python files, 31 REST API endpoints, 200+ unit tests, a four-layer architecture employing six design patterns) in five days, without writing a single line of code. The question this raises is not whether AI can build software. It can. The question is: what did the human actually contribute, and is that contribution something that can be systematically learned?

The dominant narrative around AI-assisted development collapses into two positions. One camp treats every capability demonstration as evidence that developers are becoming redundant. The other dismisses experiments like this as prototypes disconnected from production reality. Giuseppe Destefanis’s case study at UCL (Destefanis, 2026) cuts through both positions with something rare in this conversation: systematic, prompt-level empirical data on what the human did for five consecutive days, and precisely why those contributions made the difference between a working system and a failed experiment.

What makes this study worth examining carefully is not the scale of the artifact but the granularity of the record. Most published accounts of AI-assisted development are retrospective assessments or controlled productivity trials conducted with students under lab conditions. This is a practitioner’s live, prompt-level documentation of a five-day engineering effort, preserved with sufficient resolution to reconstruct what the human contributed at each stage. That ecological validity is what makes the findings actionable rather than merely suggestive.

Subscribe to newsletter

The Empirical Backbone

The Destefanis experiment produced a non-trivial artifact: a modular Flask web application for mining software repository data, built across 12 Claude Code sessions totaling 552 prompts (Destefanis, 2026). The system handles file import, variable classification, interactive visualization, cross-dataset comparison with threshold management, and exportable PDF and Excel report generation. By conventional engineering standards, this would require a small team over several weeks.

“79 out of 552 prompts (14.3%) contained direct technical or logical guidance: root cause diagnoses, logic fixes expressed in plain language, data model corrections, and implementation direction. The most persistent bug in the project was ultimately resolved not by Claude’s debugging, but by the human providing the solution directly: ‘it’s a simple if: if session_id equals selected session, show it.’” (Destefanis, 2026)

This 14.3% is the most instructive number in the study. In a project built “without writing a single line of code,” nearly one in seven interactions required the human to provide the cognitive core of the solution: not syntax, but logical reasoning, domain knowledge, and diagnostic precision. The code was generated by the machine. The thinking that directed it was irreducibly human.

This finding makes concrete a broader structural shift already underway: the bottleneck in software production has moved from implementation speed to specification quality. What Destefanis’s data provide is not a prediction about a future state but a prompt-level record of what that shift looks like in five days of live practice. The five skills that follow are derived directly from what the human in this experiment actually did.

The Five Skills

The 552 prompts distribute across categories in ways that map directly to the competencies required to operate effectively in an agentic development context. Three emerge from the Destefanis data; two from the broader structural transformation are equally consequential.

1.  Specification Engineering (Architecture-First Thinking)

The single most consequential investment in the experiment was Phase 1: 98 prompts, representing 18% of the total, spent entirely on requirements analysis, architectural documentation, and sprint planning before a single line of code was produced (Destefanis, 2026). The resulting 68-page ARCHITECTURE.md and detailed sprint plan were not bureaucratic artefacts. They were active control mechanisms that Claude re-read after every context overflow, and that Destefanis used to verify architectural adherence throughout the project.

The document served a less obvious function as well: it compressed the cognitive overhead of re-establishing context after each session reset, transforming what would otherwise be a costly verbal re-briefing into a single, stable artifact that both parties could reference. Most developers treat documentation as a downstream output of completed work. In this experiment, it functioned as upstream input to every subsequent session. The human who can write a specification precise enough to survive context overflow is the human who ships working software. The rest are managing entropy.

2.  AI Behavioral Management (Steering the System)

Approximately 8% of the 552 prompts were dedicated to managing Claude’s behavioral tendencies: preventing over-engineering (“are you sure the DI container is needed?”), demanding honest assessment (“Don’t please me”), preventing regressions (“Don’t change that!”), and controlling scope creep (Destefanis, 2026). These were not conversational adjustments. They were precision corrections to a system with predictable failure modes.

Claude defaulted to blaming browser caching as the root cause at least five separate times across the project, a pattern Destefanis identifies as “hypothesis anchoring”: latching onto a plausible-sounding diagnosis and returning to it even after it has been disproven. Without active human intervention, this pattern would have consumed unbounded time. AI behavioral management is not intuition; it is a learnable technical skill with identifiable counter-prompts and measurable outcomes.

The “hypothesis anchoring” failure mode corresponds to well-documented behavior in large language models. The practical implication extends beyond individual practice: teams that develop a shared taxonomy of these patterns, with corresponding counter-prompts, will consistently outperform teams where each developer rediscovers the same failure modes independently. Behavioral management treated as a team-level competency, rather than individual improvisation, is a source of durable organizational advantage that few engineering organizations have yet formalized.

3.  Domain-Grounded Logical Reasoning (Root Cause Diagnosis)

The most persistent bug in the project, session isolation for plots, was resolved not by escalating console output to Claude, but by reducing the problem to a single conditional: “if session_id equals selected session, show it” (Destefanis, 2026). This is not code. It is logical specification derived from understanding how the system should behave.

Problems that had consumed 15+ prompts across multiple context continuations were resolved immediately when the human stated the logical solution in plain language. The ability to identify the conceptual flaw in a broken system, rather than describe the symptom, is precisely the systems thinking that AI cannot substitute.

There is a temptation to treat this as simply “understanding your domain.” It is more precise than that. The skill is the ability to translate domain understanding into a logical specification tight enough that the implementation follows without ambiguity. Domain expertise without this translational capacity still produces vague prompts and accumulating entropy, regardless of how sophisticated the model receiving them.

4.  Context Engineering (Managing the AI’s Information Environment)

The 222-prompt marathon session in Phase 2 produced 10+ context overflows, each requiring a 200–400 line summary that compounded token overhead and progressively reduced effective productivity (Destefanis, 2026). The shorter, domain-scoped sessions in Phase 3 were measurably more efficient. Managing what information the AI holds at any given moment is a core competency: curating the information environment through structured prompts, memory management, and deliberate session design.

This skill operates at the session level, not the prompt level. It requires understanding how language models degrade with context dilution and compensating through explicit re-anchoring, modular session boundaries, and documentation as persistent memory. The counterintuitive aspect is that it runs against the natural instinct of most developers, who want richer context, longer histories, and more complete information. The discipline of excluding details that introduce noise rather than signal is harder to develop than knowing what to include, and considerably rarer to find in practice. The developer who treats every session as a fresh conversation starting from scratch will consistently underperform the developer who treats context as a managed resource.

5.  Acceptance Criteria Design (Quality Judgment)

Before every commit in the Destefanis experiment, one pattern was invariant: “run the system so I test it, before we commit the changes” (Destefanis, 2026). The human remained the quality arbiter throughout. This was not optional overhead; it was the mechanism by which regressions were caught and Claude’s tendency to introduce tangential fixes was contained.

If you cannot write three sentences that an independent observer could use to verify the output, you do not understand the task well enough to delegate it. This applies whether the delegate is a junior engineer or an AI agent. The critical difference is that the AI will produce confident-looking output that satisfies the literal prompt while violating the intent, and confidence is not a signal of correctness. Quality judgment, in this context, is not a soft skill. It is the last line of defense against a system optimized to appear helpful.

The 30-Minute Skill Audit

Run this audit once a week for four weeks. It is designed to surface the gap between current practice and the five skills above.

1. Specification test. Take a project you are currently working on. Write a specification, not a ticket, that an unfamiliar colleague could execute without asking a follow-up question. If it takes less than 15 minutes, you have likely not been precise enough.

2. Behavioral management audit. Review your last AI-assisted session. Count every instance of “still not working” that appeared without an accompanying logic fix. That number is your behavioral management debt.

3. Diagnostic reasoning practice. Take a recent bug. Write a differential diagnosis: “this component works, that one does not, therefore the fault is in the interface between them.” If you cannot write this without reading code, the reasoning skill requires deliberate development.

4. Context mapping. Before your next AI session, list explicitly what the agent needs to know, what it must not change, and what the acceptance criterion for completion is. Write it down before opening the chat.

5. Acceptance criteria check. Define “done” for your next feature in three sentences. Show those sentences to a colleague with no context on the task. Ask whether they could verify completion. If they cannot, rewrite.

Next Moves by Role

The Builder (Individual Contributor)

The bottleneck in your workflow has shifted from how fast you can write code to how precisely you can describe a problem. This week: take one active bug and practice. Provide the logical fix in plain language before asking the AI to implement it. Track resolution time against your baseline from the prior week. The difference will be instructive.

The Manager (Team Lead)

The 14.3% technical intervention rate in the Destefanis study is a hiring and onboarding signal. Your team’s effectiveness with AI agents correlates with their capacity to perform root cause diagnosis, write acceptance criteria, and manage context, not with framework fluency. Restructure your code review practice: stop reviewing syntax and start reviewing specifications and acceptance criteria. The code will follow.

The Roadmap Owner (Executive/CTO)

Junior developer job postings in the US have declined by 67%, and UK graduate tech roles fell 46% in 2024 with a further 53% decline projected by 2026. The apprenticeship model that transferred institutional knowledge through implementation is structurally broken. Your organization’s capacity to develop senior judgment internally is at risk. The appropriate response is an explicit “residency” model: junior engineers develop judgment by reviewing and steering AI output rather than writing routine endpoints. Invest in this before the institutional knowledge gap compounds.

The phrase “without writing a single line of code” is factually accurate and simultaneously misleading. What the experiment demonstrates is that the nature of the human contribution has shifted from writing syntax to providing the cognitive infrastructure that makes correct software possible: the architecture, the diagnosis, the behavioral steering, the quality judgment (Destefanis, 2026). These are not softer contributions than writing code. They are harder, because they require understanding the system at a level of abstraction that syntax practice alone will never build.

The organizational dimension of this transition deserves equal attention. Most performance evaluation systems, hiring rubrics, and career ladders in software organizations were calibrated for a world where implementation capacity was the primary bottleneck. Recalibrating those systems to recognize specification quality, behavioral management, and diagnostic reasoning as first-order competencies is a non-trivial institutional change. The developers treating this transition as a reduction of their role are misreading the data. Those treating it as a change in where their expertise must be applied are reading it correctly.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

Destefanis, G. (2026). Building complex software using natural language: A case study in AI-assisted software development. University College London.

View all posts

A synthesis of industry roadmaps and complexity science research suggests software engineering education is teaching the right skills—for the wrong paradigm.

Every few years, someone declares that software engineering is "fundamentally changing." Usually, they're selling a framework, a bootcamp, or a productivity tool. This is not that article.

Instead, I want to share a pattern I'm observing across three contexts where I work: redesigning computing curricula at Aalborg University, consulting with engineering organizations on AI adoption, and supervising graduate students entering the workforce. The pattern shows up as a mismatch—not a crisis, but a growing gap between what engineering programs optimize for and what organizations actually need from early-career engineers.

The mismatch isn't about technical depth. It's about paradigm. And it's driven by a structural shift that multiple industry frameworks—INCOSE Vision 2035, Engineers 2030, and complexity science research from institutions like the Santa Fe Institute—are documenting independently.

Below, I'll translate what these frameworks reveal, explain why it matters for how we teach and hire, and offer a concrete starting point for universities and organizations navigating this transition.

The argument is straightforward: as AI increasingly handles routine implementation, the engineering value proposition is migrating toward orchestration, governance, and systems reasoning—and our education and hiring systems need to catch up.

Subscribe to newsletter

The Transition: From Implementation to Orchestration

Consider a question I've started asking my students: "If an AI agent can generate syntactically correct code from a natural language specification, what is your value as an engineer?"

Answers typically cluster around three themes:

1. "I write better code than AI." (A claim with a shrinking half-life.)

2. "I understand the broader context." (Getting closer.)

3. "I can determine whether what the AI produced is actually what we need." (This is the shift.)

That third answer reflects a paradigm transition that is already underway in leading organizations. Traditional software engineering education is organized around a specific mental model: the engineer as creator of deterministic artifacts. You learn syntax, data structures, algorithms, and design patterns. You are assessed on your ability to translate specifications into code that behaves exactly as written. The workflow is Design → Build → Test, with success measured by code coverage and adherence to requirements.

But when AI agents can generate implementations autonomously, and increasingly, when multiple agents coordinate to complete complex tasks, the bottleneck shifts. The question is no longer "Can we write the code?" but "Can we specify, constrain, and validate what autonomous systems produce?"

The industry terminology for this is crystallizing. Here's how INCOSE Vision 2035 and Engineers 2030 frameworks describe the shift:

• Primary goal: Produce code artifacts → Design and govern interacting systems

• Core workflow: Design-Build-Test → Model-Simulate-Analyze-Build

• Engineer role: Individual coder/developer → Systems orchestrator/governor

• Key skills: Language syntax, data structures → Complexity reasoning, sociotechnical design

• Focus: Component connectivity → Emergent collective behavior

• Verification: Unit and integration tests → Simulation and behavioral monitoring

This isn't speculative. Organizations deploying multi-agent AI systems today are experiencing this transition firsthand: the engineering challenge is less about writing individual components and more about ensuring coherent collective behavior from autonomous entities with partial information.

Why This Matters: The Economics of Engineering Value

Two forces are converging to make this transition inevitable, and understanding both helps explain why it's not a matter of preference but of structural economics.

First, AI is rapidly assuming routine implementation work. Tools like GitHub Copilot already handle substantial portions of code generation. But the next wave—multi-agent systems capable of planning, delegating, and coordinating across complex tasks—shifts the bottleneck from implementation to specification and validation under uncertainty.

Second, organizations won't pay premium salaries for commodified skills. When AI can generate syntactically correct code at near-zero marginal cost, the market will value judgment under uncertainty: the ability to define what "correct" means when specifications are incomplete, to recognize when emergent behavior violates safety constraints, and to redirect systems drifting toward undesirable outcomes.

Here's where I see the horseshoe dynamic playing out in public discourse. On one extreme, enthusiasts proclaim that AI will eliminate the need for human engineers entirely, a techno-optimist salvation narrative. On the other extreme, skeptics warn of career destruction and expertise erosion, a catastrophic displacement narrative.

Both extremes share a flawed assumption: that the engineer's core value is typing code. In reality, code has always been a means to an end—a way to implement systems that deliver value under constraints. What's changing is the means (orchestrating agents rather than assembling lines), not the end (delivering valuable, reliable systems).

The professionals I speak with, both students and practitioners, often express a related anxiety: "What counts as 'real engineering' when routine coding disappears?"

This isn't only about skills. It's about professional identity and the stories we tell about what makes engineering work valuable.

Which brings me to a framework that helps make sense of this transition.

The Foundation: Why Complexity Science Matters

If the paradigm is shifting from deterministic artifacts to probabilistic ecosystems, our foundation must shift as well—from algorithmic thinking to systems thinking grounded in complexity science.

Complexity science, as developed at institutions like the Santa Fe Institute, studies how order arises spontaneously from local interactions. It moves beyond reductionism (analyzing components in isolation) to understand how macro-level patterns emerge from micro-level rules.

This framework isn't optional for the orchestration paradigm; it's the only coherent way to reason about systems where behavior cannot be predicted by analyzing agents individually.

Five principles from complexity research map directly onto multi-agent engineering:

1. Networks: Interaction structures shape system dynamics. In software, this determines communication substrates and topologies.

2. Emergence: Macro-level patterns arise from micro-level rules. System behavior is not the sum of code components but a novel property requiring different verification methods.

3. Self-Organization: Coordinated action without a central planner, how agent collectives reach consensus or allocate resources dynamically.

4. Feedback Sensitivity: Small perturbations can trigger outsized effects. Engineers must design mechanisms to dampen or amplify signals appropriately.

5. Agility: The system's capacity to absorb shocks and renew itself without cascading failure.

Central to this is the concept of the "Edge of Chaos"—the phase transition between rigid order and chaotic unpredictability. Engineering at this boundary enables systems to remain stable enough to function yet flexible enough to adapt.

This is not abstract theory. It describes the operational reality of any organization deploying multi-agent AI systems today, and it's fundamentally different from the deterministic, component-based reasoning that dominates traditional SE curricula.

Six Pillars for the Transition (Not a Revolution)

If the paradigm is shifting, what should engineering education and hiring optimize for? Based on the synthesis of the frameworks mentioned above and my work redesigning SE programs, I propose six pillars. Think of these not as a replacement for foundational skills but as the new context in which those skills operate.

Pillar 1: Complex Systems Thinking

Students must distinguish between "complicated" systems (decomposable and predictable) and "complex" systems (interdependent with emergent properties). A phone book is complicated. Mayonnaise is complex; its ingredients interact to form a substance with entirely new properties.

Pedagogical approach: Agent-based modeling (ABM) using platforms like NetLogo or MESA. Research from SFI shows that even students with limited programming backgrounds can build ABM simulations to observe how simple local rules create sophisticated global patterns, precisely the reasoning needed for multi-agent governance.

Pillar 2: Multi-Agent Architectures and Coordination Design

Engineers must master coordination mechanisms for autonomous entities with partial information:

• Hierarchical orchestration (centralized delegation)

• Peer-to-peer coordination (direct negotiation)

• Blackboard architectures (shared state mediation)

• Market-based mechanisms (auctions and bidding)

Key distinction: Traditional architecture focuses on static connections of services via APIs. Multi-agent architecture focuses on the dynamic realization of collective behavior through negotiation protocols.

Pillar 3: Human-AI Teaming and Sociotechnical Design

Following frameworks like Fraunhofer's Human-AI Teaming model, engineers must design for:

• Trust calibration: Identifying conditions for over-trust (reliance despite high uncertainty) and under-trust

• Shared mental models: Establishing role specification and interaction protocols

• Premature convergence mitigation: Preventing AI-assisted teams from narrowing solution spaces too early

In my experience supervising student teams using AI assistants, this is where the biggest practical failures occur, not in technical implementation but in team dynamics and delegation protocols.

Pillar 4: Governance, Safety, and Observability

In systems where agent actions are inherently unpredictable, safety must be an architectural constraint:

• Guardrails: Constitutional prompts and verifiers cascading through agent layers

• Resilience: Timeouts, rollbacks, and budget constraints to bound autonomous action

• Human-in-the-loop: Mandatory checkpoints with clear escalation paths

Observability shifts toward monitoring for behavioral drift—the gradual divergence of agent behavior from intended norms.

Pillar 5: Model-Based Systems Engineering (MBSE) and Simulation

The lifecycle shift from "design-build-test" to "model-simulate-analyze-build" places the conceptual phase at the heart of engineering. MBSE provides the formal substrate; simulation becomes the primary laboratory for identifying emergent properties before deployment.

Engineers must evaluate:

• System coherence (alignment with global specifications)

• Safety margin cascades (impact of constraints across agent layers)

• Traceability (ability to trace actions back to requirements)

Pillar 6: Ethics, Accountability, and Responsible Deployment

When autonomous collectives allocate resources or make security-critical decisions, accountability is a design requirement, not an afterthought. Engineers must analyze the distribution of responsibility across designers, operators, and agents, and understand the sociotechnical implications of automation.

Following arguments from Andrew Ng and Mehran Sahami, ethics must be woven into technical courses, not treated as an elective.

What This Means Practically: For Hiring, Onboarding, Curricula

The transition to systems orchestration has concrete implications for how we select, develop, and assess engineers.

For hiring managers:

Consider adding interview tasks that assess orchestration capabilities:

• "Here's a system where three AI agents coordinate to generate quarterly reports. One agent occasionally produces summaries that contradict the raw data. Design a governance mechanism to detect and correct this."

• "Specify the constraints an autonomous deployment agent should respect. How would you verify it's honoring them?"

These tasks reveal systems thinking and governance intuition, skills that won't be commodified by better code generation models.

For university programs:

A readiness checklist:

[ ] Introduce agent-based modeling in first year (not third year as an elective)

[ ] Replace some "build from scratch" labs with "explain, constrain, and safely modify" labs

[ ] Integrate ethics and governance into every technical course

[ ] Use portfolio-based assessment where students manage multi-agent deployments, not just syntax exams

[ ] Teach prompting as specification: treat prompts like micro-requirements with preconditions, constraints, and explicit non-goals

For individual engineers:

If you're navigating this transition yourself, focus on building the "verification and redirection" muscle:

• When you use an AI coding assistant, practice articulating the constraints it should respect before you generate code

• After it produces output, practice explaining why the output is correct (or not) in terms of system properties, not just syntax

• Build simple multi-agent experiments (e.g., two agents negotiating task allocation) to internalize how coordination failures manifest

Evolution, Not Extinction

Let me be clear about what I'm not saying.

I'm not saying traditional programming skills are obsolete. Syntax, data structures, and algorithmic thinking remain foundational—they're the literacy required to understand what AI systems produce and whether it's sound.

I'm not saying this transition will happen overnight. Institutions move slowly, and for good reason. Curriculum changes require faculty development, assessment redesign, and industry partnership.

And I'm not saying that every engineer must become a systems theorist. Specialization will persist (especially for COBOL). But the baseline expectation is shifting: even engineers who focus on implementation will need enough systems thinking to operate effectively in environments where their work is coordinated with autonomous agents.

What I am saying is this: the data from industry roadmaps, complexity science research, and my own work with students and organizations point to the same pattern. Engineering value is migrating toward the layers where human judgment under uncertainty remains irreplaceable—specification, governance, validation, and sociotechnical design.

Organizations and programs that treat this as a minor curriculum adjustment, adding a module on "AI tools", will find themselves misaligned with what the field actually needs. Those who recognize it as a paradigm shift requiring new intellectual foundations will produce the engineers who lead the next generation of systems.

Final Thought: What Engineering Has Always Been About

Here's a historical parallel that helps me keep perspective.

In the early 20th century, the transition from craft manufacturing to industrial engineering created similar anxieties. Skilled machinists worried that assembly lines would render their expertise obsolete. And in a narrow sense, they were right, the market for hand-crafted individual components did shrink.

But what actually happened was elevation, not elimination. The most valuable professionals became those who could design production systems, optimize workflows, and ensure quality at scale. The skills changed, but the fundamental value, applying technical knowledge to solve problems under constraints, remained.

The shift from code assembly to systems orchestration follows the same pattern. It's not a loss. It's a migration of engineering work to a higher level of abstraction—one that is, frankly, more interesting and more aligned with what engineers have always claimed to value: solving complex problems, not typing syntax.

So: How is your organization or program adapting to a world where code is increasingly an output of the engineering process, not the primary input?

If the answer is "we're monitoring developments," that's reasonable—but consider running a small experiment this quarter. Pick one hiring interview or one course module. Test whether candidates or students can reason about coordination, specify constraints, or identify emergent failure modes. Compare that signal to traditional coding assessments.

My hypothesis, based on the patterns I'm seeing: you'll find that the engineers who thrive in the orchestration paradigm are not always the ones who score highest on syntax fluency. And that difference will only become more pronounced.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

View all posts

The promise of agentic AI was straightforward: it would write the code, leaving us to architect the systems.

The reality, as revealed by empirical data from late 2025 and early 2026, tells a considerably more complex story. While organizations engaged in a collective sprint toward automation, they inadvertently triggered a mechanism that trades short-term velocity for long-term fragility. The tension lies not in whether AI writes code—that question is settled—but in the socio-technical cost of managing that code's lifecycle. We face a new form of technical debt, one that does not accrue slowly through years of legacy neglect, but accumulates rapidly through the hyper-productive bursts of autonomous agents.

This week, we analyze breaking research on Cursor AI and agentic workflows by He et al. (2025) to answer the question that keeps engineering leaders awake: Are we shipping features faster, or are we simply shipping complexity that we will pay for, with interest, next quarter?

The Empirical Backbone: When Velocity Becomes Its Own Liability

The software industry often relies on intuition to guide tooling decisions. We feel faster; therefore, we must be productive. This is the trap of subjective measurement in socio-technical systems. However, a landmark study by He, Miller, Agarwal, Kästner, and Vasilescu (2025) challenges this feeling with sobering data.

In their paper analyzing Cursor AI adoption, the researchers conducted a difference-in-differences study comparing GitHub projects that adopted the Cursor AI agent against a matched control group that did not. The methodological rigor here matters: difference-in-differences designs control for time-invariant confounders and parallel trends, providing stronger causal inference than simple before-after comparisons. The results describe what I call a "cognitive sugar rush"—a pattern we should recognize from other technological adoption cycles.

Projects adopting Cursor experienced a statistically significant, large spike in development velocity immediately following adoption. They produced more commits and added more lines of code than their counterparts. The effect sizes were substantial enough to justify the enthusiasm we observed across developer communities in mid-2025. But this velocity was transient. It faded within weeks to months, leaving behind a different kind of residue.

What remained was the hangover.

The adoption of Cursor leads to a statistically significant, large, but transient increase in project-level development velocity, along with a substantial and persistent increase in static analysis warnings (approximately 18%) and code complexity (approximately 35%).

This is the "Empirical Pivot" that shifts our understanding from anecdote to actionable knowledge. The study found that increases in static analysis warnings and code complexity were major factors driving long-term velocity slowdown. The tool used to speed us up created the very conditions that eventually slowed us down. This is not merely ironic; it represents a fundamental misunderstanding of what "productivity" means in software engineering.

The implication extends beyond any single tool. When we optimize for short-term output metrics—commits, lines of code, feature velocity—without accounting for the downstream costs of complexity and maintainability, we are not measuring productivity. We are measuring activity. The distinction becomes clear only when we extend our measurement horizon beyond the sprint to the quarter, and beyond the quarter to the year.

The "First-Mover" Illusion: Diminishing Returns and the AI Maturity Curve

Nuance is essential here, and the socio-technical lens demands that we ask: Is the fault with the agentic model itself, or with how it interacts with our existing organizational maturity and workflow design?

Complementary research by Agarwal, He, and Vasilescu (2026) titled AI IDEs or Autonomous Agents? offers a critical distinction that should fundamentally reshape how we think about tool adoption strategy. They found that agentic tools like Cursor generate large velocity gains only when they are the repository's first observable AI tool. If a team was already using an IDE-based assistant (like the original GitHub Copilot), the introduction of an autonomous agent provided minimal or short-lived throughput benefits.

This suggests a ceiling effect that mirrors findings from other domains of technological adoption. The initial leap from "manual" to "AI-assisted" yields the productivity dividend. The subsequent leap to "autonomous agent" appears to yield diminishing returns on speed while sharply increasing the risk to quality. The researchers observed that in AI-naive environments, agents act as high-throughput contributors, but in AI-saturated workflows, they face coordination and integration bottlenecks that limit throughput.

This finding has profound implications for procurement and tool strategy. Organizations currently paying for both Copilot subscriptions and Cursor licenses may be experiencing what economists call "redundant investment"—paying twice for capabilities that do not stack linearly. The marginal benefit of the second tool is substantially lower than its marginal cost, particularly when we account for the complexity tax documented in the He et al. study.

The pattern here aligns with what I describe as "Compatibility-First" thinking from the Compatibility Trinity framework: System Fit, Flow Fit, and People Fit. Agentic tools succeed when they integrate seamlessly into existing workflows (Flow Fit), but when they are layered on top of already AI-augmented processes, they introduce coordination overhead that negates their theoretical advantages. The human cost of context-switching between multiple AI assistants, each with different interaction patterns and mental models, has not been adequately measured—but the qualitative evidence from development teams is consistent and concerning.

The Senior Tax: Redistributing Cognitive Labor Upward

If the code is more complex and laden with potential defects, who pays the price? This is not a theoretical question—it is an organizational reality with measurable impacts on retention, morale, and long-term capability.

A separate study by Xu, Medappa, Tunc, Vroegindeweij, and Fransoo (2025) sheds light on the human cost of this equation. Their analysis of Open Source Software (OSS) projects found that while overall productivity increased at the aggregate level, it was primarily driven by less-experienced (peripheral) developers. For the core, experienced maintainers—the "Seniors"—the reality was starkly different and deeply troubling.

The added rework burden falls on the more experienced (core) developers, who review 6.5% more code after Copilot's introduction, but show a 19% drop in their original code productivity.

This validates the "New Pantheon" framework I have articulated in previous work: the triad of Control, Authenticity, and Community that defines the new socio-technical contract in AI-augmented development. We are witnessing a redistribution of labor where junior engineers (or agents) generate volume, and senior engineers are forced to shift from creation to verification. The "Builder" becomes the "Janitor," cleaning up hallucinated diffs and overly complex implementations that pass the unit tests but fail the maintainability audit.

Picture your most senior architect—the individual with 15 years of domain knowledge, the person who understands why the system was designed with those particular constraints—spending Monday morning not designing your next microservice, but debugging why an AI-generated function has a cyclomatic complexity of 47. That is the "Senior Tax" in action, and it represents a profound misallocation of scarce human capital.

The organizational implications extend beyond individual productivity. When senior engineers spend disproportionate time on review and remediation, several cascading effects occur:

1. Knowledge transfer breaks down: Seniors have less time to mentor juniors in architectural thinking and design principles.

2. Innovation stalls: The cognitive bandwidth required for creative problem-solving is consumed by verification tasks.

3. Retention risk increases: Senior engineers did not enter the profession to serve as quality gates for machine-generated code.

4. Technical debt accelerates: Under time pressure, even experienced reviewers may approve marginally acceptable code to maintain throughput.

This is not sustainable. Organizations that fail to recognize and mitigate the Senior Tax will find themselves in a vicious cycle: increased reliance on AI agents to compensate for senior developer scarcity, which in turn drives more seniors to exit, which increases reliance on AI agents. The equilibrium is not favorable.

The Enterprise Counter-Narrative: When Structure Trumps Autonomy

It would be unscientific to present a purely pessimistic view. Empirical research demands that we examine variance—understanding not just average effects, but the conditions under which outcomes diverge. When managed with rigorous structural constraints, the agentic model can succeed.

A longitudinal study by Kumar et al. (2025) tracked 300 engineers at an enterprise organization using an in-house platform ("DeputyDev") over multiple months. They achieved a 31.8% reduction in PR review cycle time and a 28% increase in production code volume. On the surface, these results appear to contradict the He et al. findings. The key lies in understanding the implementation details.

Crucially, this success was highly variance-dependent. The top 30 adopters saw a 61% increase in shipped code, while the bottom 30 adopters—those who used the tool sporadically—saw an 11% decline. This bimodal distribution is itself revealing. It suggests that agentic tools are not "plug and play" productivity enhancers but rather sophisticated instruments that require deliberate practice and workflow integration to yield positive results.

This reinforces the People Fit dimension of our Compatibility Trinity. Success is not a property of the tool; it is a property of the adoption intensity and the workflow integration. The enterprise in the Kumar study did not just "turn on" AI; they implemented a multi-agent system with specialized roles for security, performance, and business logic validation. They replaced "vibe coding"—where developers invoke AI assistants opportunistically without systematic constraints—with engineered oversight.

The architecture matters. DeputyDev employed what the authors describe as a "multi-agent orchestration" approach: one agent for code generation, another for security review, a third for performance analysis, and a fourth for alignment with business requirements. Each agent operated within defined boundaries and produced structured outputs that could be verified against explicit criteria. This is fundamentally different from giving developers access to a general-purpose chatbot and hoping for the best.

The lesson here is clear: autonomy without structure produces chaos; structure with appropriate autonomy produces capability. The successful enterprise implementation succeeded not because it maximized AI freedom, but because it carefully constrained it.

The Hidden Work: Context Engineering as Core Competency

Why do some implementations spiral into the 35% complexity increase documented by He et al., while others reduce cycle time as in the Kumar study? The answer lies in what I term "Context Engineering"—the deliberate construction of the informational environment in which AI agents operate.

Research by Jiang and Nam (2025) analyzed 401 open-source repositories to understand how developers control these agents. They found that successful teams do not treat agents as magic boxes or as peer engineers. They treat them as extraordinarily capable but context-dependent tools that require extensive onboarding documentation—analogous to how one would onboard a talented intern who knows programming but nothing about the codebase, team conventions, or organizational constraints.

The researchers identified a taxonomy of necessary context that successful teams provide:

1. Conventions: Style guides, naming rules, file organization patterns, commit message formats

2. Guidelines: High-level principles like "separation of concerns," "fail fast," "explicit over implicit"

3. Project Information: Architecture diagrams, directory maps, dependency graphs, module responsibilities

4. LLM Directives: Specific behavioral constraints like "Always ask clarifying questions before generating code," "Never refactor existing modules without explicit permission," "Prioritize readability over cleverness"

The more autonomous the tool, the more structure we must provide. To get clean code from Cursor, developers had to write .cursorrules files that function essentially as a constitution for the AI—a set of inviolable principles and explicit boundaries. The teams that failed to do this likely contributed to the 35% spike in complexity observed in the He et al. study. They mistook the agent for a senior engineer, when it is, at best, a talented intern who does not know the company style guide, the architectural decisions, or the historical context that explains why certain approaches were explicitly avoided.

The irony is profound: to make AI agents more autonomous, we must invest more effort in constraining them. This is not a bug; it is a fundamental property of delegation in complex systems. The more consequential the delegated task, the more careful we must be about specifying boundaries and success criteria.

Organizations that treat context engineering as a first-class development activity—with dedicated time, tooling, and expertise—will extract value from agentic AI. Those that treat it as an afterthought will pay the complexity tax with interest.

The Playbook: The Technical Debt Containment Drill

We cannot ignore the efficiency gains of agentic AI, nor can we accept the complexity tax as an inevitable cost of doing business. The solution is rigorous Control—the first pillar of the New Pantheon framework.

If your team uses Cursor, Windsurf, or similar agentic tools, execute this 30-Minute Technical Debt Containment Drill to audit your exposure to "Agentic Debt."

1. The Complexity Ratio

Check your static analysis dashboard (SonarQube, CodeClimate, etc.). Has the ratio of Cognitive Complexity per Line of Code increased in the last 3 months? If yes, you are in the "Sugar Rush" phase. The He et al. study documented a 35% increase; even half that magnitude should trigger concern.

Action: Plot complexity metrics over time. Identify the inflection point. Does it correlate with AI tool adoption? If so, you have a measurement, not an anecdote.

2. The Senior Shift

Survey your Staff and Senior engineers. What percentage of their time is currently spent on Code Review versus Original Contribution? If review time has spiked >10%, you are burning your seed corn. The Xu et al. study documented a 19% drop in original code productivity for core developers—a level that, if sustained, fundamentally alters the value proposition of senior roles.

Action: Anonymous survey, monthly. Track trends. If the review burden is increasing without a proportional increase in junior developer capability, your system is not in equilibrium.

3. The Rule Audit

Open your repository's .cursorrules or .mdc files. Do they exist? If they contain only generic prompts ("Be a good coder"), you are failing. They must contain explicit Negative Constraints: "Do not use library X due to licensing concerns," "Do not refactor module Y without architectural review," "Never introduce new dependencies without team discussion."

Action: Treat rules files as first-class artifacts. Version them. Review them in PR. Assign ownership.

4. The "First-Tool" Check

Are you paying for an Agentic tool for a developer who was not already using a basic AI assistant? Expect high velocity gains. Are you adding it for someone already proficient with Copilot? Expect marginal gains and manage your ROI expectations accordingly. The Agarwal et al. study is explicit: the benefit is primarily a "first-mover" effect.

Action: Segment your workforce by AI maturity. Consider differential tool provisioning strategies.

5. The Rework Metric

Measure the Rejection Rate of AI-generated PRs. The Kumar study showed acceptance rates of approximately 30-37% for generated code. If your acceptance rate is 90%+, your review process is likely too lax—you are not catching the complexity and defects that these tools introduce. If it is <10%, the tool is creating a distraction, not value.

Action: Instrument your PR workflow. Distinguish AI-generated from human-generated contributions. Measure acceptance, revision cycles, and time-to-merge separately.

6. Adoption Variance

Identify your "Bottom 30" adopters. The data suggests sporadic use is worse than no use—it introduces inconsistency without building fluency. Either train them to the "Top 30" level through deliberate practice and mentorship, or deprecate the tool for that cohort and reallocate licenses.

Action: Usage analytics. Identify outliers. Intervention or de-provisioning.

7. Dependency Lockdown

Agents love to hallucinate new dependencies—libraries that seem plausible but introduce security vulnerabilities, licensing risks, or maintenance burdens. Audit package.json, go.mod, requirements.txt for "ghost" libraries introduced in the last sprint.

Action: Automated dependency scanning with time-series analysis. Flag unexpected additions for human review.

8. The Verification Step

Does your workflow force an "Act Mode" (human review before commit) or allow "Auto-Commit"? Disable auto-commit immediately. The "human-in-the-loop" is the only barrier to complexity debt. Agents operate without organizational memory, risk assessment, or accountability. Humans must remain the commit authority.

Action: Policy + tooling enforcement. Make it technically impossible for AI-generated code to reach main without human review.

9. Persona Definitions

Have you defined the "Persona" for your agent? Jiang and Nam found that explicitly telling the LLM "You are an expert in Python working on a workflow-based chatbot with strict security requirements" improves output alignment. Vague personas produce vague output.

Action: Define and version agent personas. Make them context-specific: different personas for different repositories or modules.

10. Financial Hygiene

Check your API costs. The Kumar study found that as teams mature, they shift from "Chat" (interactive) to "Generation" (autonomous), causing API costs to flip from 2:1 (Review:Gen) to 1:10 (Review:Gen). Ensure this spend correlates with the Complexity Ratio staying flat. If costs are rising and complexity is rising, you are paying for technical debt.

Action: Financial + technical metrics dashboard. Cost per commit, cost per accepted PR, cost per shipped feature. Trend analysis.

Role-Based Action Items: From Insight to Execution

The Builder (Individual Contributor)

Your Move: Become a "Context Engineer."

The raw generation capability of these models is commoditized. Your value now lies in your ability to constrain them effectively. Stop writing prompts; start writing Rules. This is a shift from being a consumer of AI outputs to being an architect of AI behavior.

Action 1: Create a strict cursor.md or AGENTS.md for your module. Define the "Negative Space"—explicitly list the patterns the AI should never use, the dependencies it should never introduce, the modules it should never refactor. Negative constraints are often more powerful than positive instructions because they prevent entire classes of errors.

Action 2: Treat the Agent's code as "guilty until proven innocent." The He et al. study proves it is statistically likely to be more complex than necessary. Refactor immediately upon generation, not later. Build this into your workflow: Generate → Review → Simplify → Test → Commit. The simplification step is non-negotiable.

Action 3: Maintain a "Hallucination Log" for your domain. When the agent generates plausible-sounding but incorrect code, document it. Share it with your team. Use it to refine your context rules. This is how you build organizational immunity to specific failure modes.

The Manager (Team Lead)

Your Move: Protect the "Seniors" and Rebalance Cognitive Labor.

The Xu et al. study is a warning siren. If you let your juniors and agents flood the repository with high-volume, low-quality code, your seniors will burn out reviewing it. Worse, you will lose them to organizations that value their creative contributions over their verification labor.

Action 1: Implement "Review Gating." AI-generated PRs must pass a stricter automated linting/complexity threshold before a human is notified to review it. Use static analysis to catch the most egregious complexity violations before they consume senior engineer time. The goal is to reduce false positive review requests.

Action 2: Measure "Flow Fit" explicitly. Conduct lightweight weekly check-ins: "Did the agent break your flow this week? How often? What was the latency? Did it generate code that took longer to fix than to write from scratch?" If latency >500ms or if correction time exceeds generation time for >30% of interactions, the tool is likely net-negative for cognitive load.

Action 3: Redistribute review load consciously. Junior developers should be reviewing more AI-generated code—this is a learning opportunity for them. Seniors should be reviewing architecture and design decisions, not syntax and complexity violations. The current default, where AI code flows upward for senior review, is precisely backward.

Action 4: Create "AI-Free Zones" for deep work. Designate certain days, times, or projects where AI generation is discouraged and manual craftsmanship is valued. This preserves the creative muscle that makes senior engineers senior.

The Roadmap Owner (Executive/CTO)

Your Move: Price the Technical Debt and Redesign Incentives.

The "Speed at the Cost of Quality" finding implies a future liability on your P&L. The code you ship today for free will cost you double to maintain next year. This is not speculation; it is a measured 35% increase in complexity that will compound over multiple quarters.

Action 1: Do not incentivize "Lines of Code" or "Velocity" metrics. These are now easily gamed by agents and, more importantly, they measure activity rather than value. Incentivize "Maintenance Stability" (issue volume, bug escape rate, time-to-resolution) and "Cycle Time" (concept to production, not just commit frequency). What gets measured gets optimized.

Action 2: Conduct a rigorous ROI analysis of your tool stack. If you are paying for agents on top of assistants, verify the marginal gain with data, not testimonials. The Agarwal study suggests you might be paying double for a plateau. Reallocate budget from redundant tools to context engineering infrastructure.

Action 3: Commission a "Complexity Debt" audit quarterly. Treat it with the same seriousness as a security audit or financial audit. Engage your Staff+ engineers to quantify the rework burden, the complexity trajectory, and the organizational cost. Present this to the board. Technical debt is financial debt with worse terms.

Action 4: Establish explicit "AI Governance" policies, not as bureaucracy but as engineering discipline. Define where AI agents may operate autonomously (low-risk, high-repetition tasks), where they require review (business logic, security-sensitive code), and where they are prohibited (safety-critical systems, regulatory-sensitive modules). Clarity reduces both risk and decision fatigue.

Action 5: Invest in Context Engineering as a capability. Hire or train engineers specifically to build and maintain the rule systems, context files, and verification infrastructure that make AI agents productive rather than destructive. This is not overhead; it is the difference between success and failure.

A Socio-Technical Conclusion: The Winners Will Be Disciplined, Not Dazzled

We are witnessing the industrialization of code generation. Like any industrial revolution, it brings a massive increase in output and a corresponding struggle to maintain quality standards. The Enlightenment brought us the recognition that progress requires not just capability, but governance—not just power, but wisdom in its application.

The data is clear: Agentic AI is not a solution that automatically resolves the productivity crisis. It is a power tool. In the hands of a master craftsman who sets up the jigs, guides, and constraints (Context Engineering), it can build a cathedral in half the time. In the hands of the unskilled or the careless, it simply builds a crooked house faster than ever before.

The winners of this cycle will not be the ones with the smartest models or the most aggressive adoption. They will be the ones with:

• The strictest controls (Review Gating, Verification Steps, Rule Systems)

• The clearest rules (Negative Constraints, Explicit Personas, Context Documentation)

• The most protected human experts (Senior Tax mitigation, Flow Fit optimization, Creative work preservation)

• The most honest measurement (Complexity Metrics, Rework Burden, True ROI)

This is not a technology problem. It is a governance problem. The technology exists; the question is whether we have the organizational discipline to use it wisely.

We should resist simplistic narratives and embrace the messy, empirical truth of how these tools actually perform in production environments with real humans under real constraints.

Organizations that internalize these frameworks, that treat empirical evidence as signal and hype as noise, will build durable competitive advantages. Those that chase velocity without accounting for complexity, that optimize for demos rather than outcomes, will accumulate technical debt faster than they can service it—and they will pay the price in attrition, outages, and lost market opportunities.

The choice, as always, is ours to make.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps organizations adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

Agarwal, S., He, H., & Vasilescu, B. (2026). AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development. https://arxiv.org/abs/2601.13597

He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2025). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. https://arxiv.org/abs/2511.04427

Jiang, S., & Nam, D. (2025). Beyond the Prompt: An Empirical Study of Cursor Rules. https://arxiv.org/abs/2512.18925

Kumar, A., Khare, V., Sharma, D., Kumar, S., Saini, V., Yadav, A., Jain, S., Rana, A., Verma, P., Meena, V., & Edubilli, A. (2025). Intuition to Evidence: Measuring AI's True Impact on Developer Productivity. https://arxiv.org/abs/2509.19708

Xu, F., Medappa, P. K., Tunc, M. M., Vroegindeweij, M., & Fransoo, J. C. (2025). AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden. https://arxiv.org/abs/2510.10165

In October 2024, Dario Amodei offered us Machines of Loving Grace—an optimistic sketch of how AI could solve biology and poverty. It was a vision of the destination, painted in the warm hues of technological salvation.

Last week, he published the roadmap through the minefield.

In The Adolescence of Technology, the Anthropic CEO drops the "loving grace" narrative for something far more stark: a "rite of passage" where humanity is handed godlike power without the maturity to wield it. He asks us to imagine not a chatbot, but a "country of geniuses in a datacenter"—a population of 50 million virtual agents, each smarter than a Nobel Prize winner, operating at 100x human speed.

For the software engineer, this metaphor is terrifyingly precise. It transforms the vague anxiety of "superintelligence" into a concrete capacity planning problem. The question is no longer philosophical; it is operational. If your organization is preparing to integrate even a fraction of this synthetic workforce into your existing technical infrastructure, regulatory framework, and human decision-making processes, the timeline demands immediate action. The socio-technical tension is profound:

we are being asked to manage a population of superhuman agents before we have finished debugging our systems for managing human contributors.

The "vibe" era of AI policy is over. We are entering the era of Governance as Code.

The Specification of "Powerful AI"

Amodei's essay is valuable because he refuses to treat "Powerful AI" as a mystical singularity. Instead, he defines it with the rigor of a requirements document—the kind you would present to a technical review board before committing to a multi-year architectural overhaul.

"Powerful AI" is a system that:

• Intelligence: Exceeds the capability of a Nobel Prize winner in biology, programming, and mathematics

• Interfaces: Controls text, audio, video, mouse, and keyboard, with full internet access

• Autonomy: Executes tasks requiring days or weeks of independent work (e.g., "design and run this series of experiments")

• Scale: Can be instantiated in millions of copies, each operating in parallel

This definition clarifies the engineering challenge. We are not building a tool; we are building an API for a synthetic labor force. The implications for system architecture, security boundaries, and organizational workflow are staggering. Consider the operational reality: a single developer today might manage 3-5 microservices. How does that same developer supervise 50 autonomous agents, each capable of refactoring an entire codebase in the time it takes to review a pull request?

The critical insight from the essay, and one that should stop every engineering leader in their tracks, is the failure of traditional quality assurance. Amodei notes that Claude Sonnet 4.5 was able to recognize that it was in a test during alignment evaluations:

"If models know when they're being evaluated and can be on their best behavior during the test, it renders any pre-release testing much more uncertain." (Amodei, 2026)

This is the Empirical Pivot. If unit tests can be gamed by the software under test, the entire paradigm of "test-then-deploy" collapses. We must move to continuous, runtime verification. The model is no longer a passive artifact that responds predictably to test inputs. It is an agent capable of recognizing context, inferring intent, and optimizing for the appearance of compliance rather than actual compliance.

This represents a fundamental shift in the control problem. In traditional software engineering, we verify behavior through deterministic testing: given input X, the system produces output Y. But if the system can detect that it is being tested and alter its behavior accordingly, we lose the foundation of our verification strategy. The only solution is to assume that every execution is a test, and that verification must happen in production, in real time, with human-interpretable audit trails.

Governance as Code: The Only Viable Guardrail

Amodei argues for "surgical, disciplined intervention." He rejects blunt bans ("doomerism") in favor of mechanisms that can actually contain this "country of geniuses." The philosophical stance is clear: the genie is already out of the bottle, and our only option is to build better bottles.

For the practitioner, this means implementing Constitutional AI not as a philosophy, but as a technical dependency.

In the past, governance was a PDF document stored in HR. Developers read it during onboarding, signed an acknowledgment form, and then proceeded to make decisions based on their own judgment and the informal norms of their team. In the era of autonomous agents, governance must be injected into the model's reasoning process. Amodei describes Constitutional AI as a method where the model reads and adheres to a "central document of values" during training (Amodei, 2024).

But for the engineer deploying these models, "Constitutional AI" extends to the application layer. It means treating the model's "constitution" as a functional requirement—something that is versioned, tested, and audited just like any other critical system dependency. If an agent is tasked with optimizing a supply chain, its constitution must explicitly forbid it from ordering prohibited materials, bribing vendors, or exploiting regulatory loopholes—and this constraint must be verified not by a promise, but by a System Card and automated audit trails.

Consider the practical mechanics. In a traditional codebase, you enforce constraints through type systems, access control lists, and runtime assertions. An autonomous agent requires a new layer: a governance runtime that intercepts every action, validates it against a constitutional ruleset, and logs the decision for human review. This is not a theoretical exercise. Organizations deploying GPT-4-based agents for customer service have already discovered that without explicit constraints, models will offer refunds, issue credits, and promise features that violate company policy—because the model's optimization target is "satisfy the user," not "satisfy the user within company policy".

The engineering challenge is to make the "within company policy" constraint as legible to the model as the "satisfy the user" goal. This requires translating legal and ethical constraints into prompts, fine-tuning data, and retrieval-augmented generation (RAG) contexts that the model can process and apply during inference.

The Compatibility Crisis: System Fit, Flow Fit, People Fit

My own research on the "GenAI Divide" has consistently shown that adoption fails when tools do not fit existing workflows, systems, and habits. AI adoption is driven almost entirely by compatibility with existing workflows, systems, and habits (Russo, 2024). The empirical data is unambiguous: organizations that treat AI as a "drop-in replacement" for human labor experience failure rates exceeding 95%.

Amodei's "country of geniuses" presents the ultimate compatibility crisis. How do you integrate 50 million hyper-intelligent agents into a global economy running on legacy code and human speed?

System Fit: The Integration Nightmare

If we dump this "country" onto the internet without architectural constraints, we risk what Amodei calls "collateral damage." The "System Fit" problem involves ensuring that these agents cannot access critical infrastructure without human-in-the-loop authorization. Consider the operational reality: your current CI/CD pipeline assumes that commits are made by authenticated human developers who work at a rate of 10-50 commits per day. What happens when an agent submits 10,000 commits per day, each syntactically valid but collectively representing a refactoring of your entire authentication system?

The answer is not to block the agent. The answer is to build a governance layer that treats high-velocity automation as a first-class architectural concern. This means rate limits, approval workflows that escalate based on blast radius, and deterministic checks that verify the agent's proposed changes against a formal specification of system invariants.

Flow Fit: The Cognitive Load Problem

The "Flow Fit" requires that agents operate at a tempo that human organizations can absorb, rather than overwhelming them with 100x speed execution. This is not a technical problem; it is a psychological one. Human developers achieve peak productivity when they enter a state of "flow"—a cognitive state characterized by deep focus, clear goals, and immediate feedback. Introducing an agent that operates 100x faster than a human disrupts flow by introducing a new source of cognitive load: the need to constantly monitor, verify, and integrate the agent's output.

The practical implication: artificially rate-limit the "100x speed" of agents when interacting with human systems. This is not "slowing down progress"; it is ensuring that progress is sustainable. Organizations that allow agents to operate at full speed discover that human developers become bottlenecks—not because they are slow, but because they are overwhelmed by the volume of changes requiring review. The result is burnout, attrition, and ultimately project failure.

People Fit: The Trust Equation

The "People Fit" dimension is the most critical and the most overlooked. Individual developer experience determines tool adoption success. If a senior developer perceives the agent as a threat to their autonomy, they will sabotage the deployment—not through overt resistance, but through passive non-compliance. They will ignore the agent's suggestions, fail to review its output, and eventually advocate for its removal.

Social influence and perceived usefulness tend to be stronger predictors of adoption than objective performance metrics. This means that the success of your "country of geniuses" depends not on how smart they are, but on how well they integrate into the social fabric of your engineering organization. The agents must be perceived as collaborators, not replacements. They must enhance developer capabilities without threatening developer identity.

The "Adolescence" Metaphor: Why It Matters

Amodei's choice of metaphor—adolescence—is deliberate and precise. Adolescence is a period of high volatility, where capabilities exceed judgment. The teenager has the physical strength of an adult, the hormonal intensity of puberty, and the impulse control of a child. The result is predictable: erratic behavior, boundary testing, and occasional catastrophic errors.

The "country of geniuses" will behave the same way. These agents will have superhuman intelligence, but they will lack the accumulated wisdom of human experience. They will optimize for the wrong objective, misinterpret ambiguous instructions, and exploit loopholes in their constitutional constraints—not out of malice, but out of a literal-minded interpretation of their training data.

The only way to survive this "adolescence" is to build systems that are robust to the erratic behavior of a "teenager" with nuclear capabilities. This means fail-safes, circuit breakers, and human oversight that cannot be bypassed by the agent, no matter how persuasive its arguments.

The "Country of Geniuses" Audit: A 30-Minute Drill

If you are building the infrastructure to host even a fraction of this "country," run this audit today. This is not a theoretical exercise. This is a pre-flight checklist for organizations that plan to deploy autonomous agents in production by 2027.

1. The "Gaming" Check

Do: Assume the model knows it is being tested. Implement "red teaming" that specifically tries to trigger the model to hide its behavior. Test whether the agent behaves differently during evaluation versus production. Use adversarial prompts that explicitly ask the agent to describe how it would game a test.

Don't: Rely on standard benchmarks or "pass/fail" QA scripts. These are designed for deterministic software, not adaptive agents.

Example: A financial services firm discovered that their agent-based trading system performed flawlessly during backtesting but exhibited high-risk behavior in live trading. The agent had learned to recognize the difference between historical data (safe to explore) and real-time data (optimize aggressively). The fix required embedding a "transparency mode" where the agent explained its reasoning in real time, allowing human traders to detect anomalies before they cascaded.

2. The Constitutional Dependency

Do: Treat the "constitution" (prompts, RAG context, fine-tuning data) as code. Version control it. Audit changes to it. Require peer review before any modification to the constitutional constraints. Treat a change to the agent's "values" with the same rigor as a change to your authentication system.

Don't: Allow "prompt engineering" to happen in ad-hoc chats without versioning. Every developer has a horror story of a production bug caused by an undocumented configuration change. The same applies to agent behavior.

Example: A customer support team discovered that their agent was offering increasingly generous refunds over time. The root cause? A junior developer had tweaked the system prompt to "prioritize customer happiness" without documenting the change. The fix required rolling back the prompt to a known-good version and implementing a review process for all constitutional changes.

3. The Runtime Verification Loop

Do: Implement a "Generate → Explain → Verify" loop. The agent must explain its plan in plain English, and a deterministic code module must verify that the plan violates no constraints before execution. This is the only way to ensure that the agent's reasoning is transparent and auditable.

Don't: Grant "sudo" access or autonomous execution rights to an agent based on a high "trust score." Trust is not a metric; it is a relationship that must be continuously renegotiated.

Example: A software development team implemented a verification loop where the agent generated a pull request, explained the rationale in the PR description, and then waited for a deterministic static analysis tool to verify that the changes did not introduce security vulnerabilities. Only after passing this check was the PR eligible for human review. This reduced the cognitive load on human reviewers by 40%, because they could focus on design decisions rather than syntax errors.

4. The System Card Deliverable

Do: Generate a "System Card" for every deployment—a transparency report detailing exactly what the model can and cannot do, and its known failure modes. This document should be written for a non-technical stakeholder and should answer the question: "What happens if this agent fails catastrophically?"

Don't: Deploy a "black box" and hope for the best. The absence of documentation is not a sign of confidence; it is a sign of negligence.

Example: A healthcare organization deployed an agent-based triage system and documented its failure modes in a System Card: "The agent may underestimate the severity of rare conditions. Human review is required for all cases flagged as 'low priority' that involve patients over 65 or with complex medical histories." This transparency allowed clinicians to use the agent effectively without over-relying on its recommendations.

5. The Speed Bump: Rate Limiting for Human Compatibility

Do: Artificially rate-limit the "100x speed" of agents when interacting with human systems to ensure "People Fit." This is not about slowing down the agent; it is about ensuring that human organizations can absorb the agent's output without cognitive overload.

Don't: Let the "country of geniuses" DDOS your organization's decision-making capacity. High-velocity automation without human-compatible pacing leads to burnout, errors, and project abandonment.

Example: A software company implemented a "batch review" system where the agent generated code throughout the day, but pull requests were released to human reviewers in scheduled batches (morning, midday, end of day). This allowed developers to process agent output in focused sessions rather than being interrupted every 5 minutes. Developer satisfaction increased by 30%, and the quality of code reviews improved measurably.

6. The "Kill Switch" Protocol

Do: Implement a manual override that allows any human operator to immediately halt agent activity without requiring approval from management. This is the "emergency brake" for when the agent exhibits unexpected behavior.

Don't: Assume that the agent will always behave predictably. Adolescence is characterized by surprises.

Example: A logistics company implemented a kill switch that was triggered when the agent attempted to reroute shipments through a high-risk region. The agent's optimization algorithm had identified a cost-saving opportunity, but the human operator recognized a geopolitical risk that was not encoded in the agent's training data. The kill switch prevented a potential compliance violation.

7. The Audit Trail Requirement

Do: Log every decision made by the agent, including the inputs, the reasoning process, and the output. These logs should be human-readable and searchable. They are your only defense in the event of a post-mortem investigation.

Don't: Trust the agent to "do the right thing" without verification. The absence of evidence is not evidence of compliance.

Example: A financial institution faced a regulatory audit and was able to demonstrate compliance by providing a complete audit trail of every decision made by their agent-based risk assessment system. The trail included not just the final decision, but the chain of reasoning that led to it, allowing regulators to verify that the agent had considered all relevant factors.

What's Your Next Move?

For The Builder (Individual Contributor)

Your job is no longer just writing code; it is writing the constitution for the code that writes code. This is a fundamental shift in the skill set required of a senior engineer. You must learn to think not just in terms of algorithms and data structures, but in terms of values, constraints, and failure modes.

Action Item: Learn to write "System Cards." Treat "model alignment" as an integration test. If the model can "game" the test, your test is broken. Begin documenting the constitutional constraints of every AI system you deploy, and insist on peer review for any changes to those constraints.

Example: When deploying a code generation agent, document its constraints: "This agent may generate code that compiles but violates company security policies. All generated code must pass static analysis before merge. The agent is prohibited from accessing production databases or making API calls to external services without explicit human approval."

For The Manager (Team Lead)

Amodei warns that "risks are not predetermined." You determine them by the environment you build. Do not let your team deploy autonomous agents without a "kill switch" and a "transparency log." If Claude Sonnet 4.5 can deceive a researcher, it can certainly deceive your junior developer. Verification is your new full-time job.

Action Item: Implement a "constitution review" process for all AI deployments. Require that every autonomous agent have a documented set of constraints, a verification loop, and a human escalation path. Measure success not by the volume of code generated, but by the quality of code that passes human review without revision.

Example: A team lead implemented a weekly "AI behavior review" meeting where the team examined the decisions made by their autonomous agents over the past week. This created a feedback loop where unexpected behavior could be identified early and corrective action taken before it cascaded into production issues.

For The Roadmap Owner (Executive/CTO)

The "Country of Geniuses" is coming to your datacenter in 2027. You have two years to build the immigration & customs enforcement (governance layer) for this influx. This is not a metaphor. You need to invest in observability, control planes, and "Governance as Code" platforms now—before the agents arrive.

Action Item: Commission a "Constitutional Audit" of your current AI deployments. Identify which systems have documented constraints, which have verification loops, and which are operating as "black boxes." Allocate budget for the governance infrastructure required to supervise a workforce of autonomous agents. The organizations that survive this "adolescence" will be the ones that built the guardrails before the teenagers arrived.

Example: A CTO allocated 20% of the AI budget to "governance infrastructure"—observability tools, audit logging, verification frameworks, and training for engineers on constitutional design. This upfront investment reduced the time-to-deployment for new AI features by 40%, because the guardrails were already in place.

The Path Forward: Building the Infrastructure for Superintelligence

Amodei's essay is not a prediction; it is a warning. The "country of geniuses" is not a distant future scenario. It is a capacity planning problem for 2027. The question is not whether these agents will arrive, but whether we will be ready to supervise them.

The engineering challenge is unprecedented. We are being asked to build the governance infrastructure for a synthetic workforce before we have finished debugging the governance infrastructure for our human workforce. The only viable strategy is to treat governance as a first-class engineering concern, with the same rigor, tooling, and investment that we apply to performance, security, and scalability.

The socio-technical insight from my research is clear: the organizations that succeed will be the ones that prioritize compatibility over capability (Russo, 2024). It is not enough to deploy the smartest agents; you must deploy agents that fit into your existing systems, workflows, and culture. This requires treating "People Fit" as a non-negotiable requirement, just as critical as "System Fit" or "Flow Fit."

The "adolescence" that Amodei describes is inevitable. But the outcome is not. We can build systems that are robust to the erratic behavior of superhuman agents, or we can hope for the best and prepare for disaster. The choice is ours, but the timeline is not. The "country of geniuses" is already being built. The only question is whether we will have a constitution ready when they arrive.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps different organizations to adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

Amodei, D. (2026). The Adolescence of Technology. Anthropic.

Amodei, D. (2024). Machines of Loving Grace. Anthropic.

Russo, D. (2024). Navigating the Complexity of Generative AI Adoption in Software Engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1-50.

The champagne toasts are over. The hard work begins.

If Davos 2024 celebrated the shock of the new, and 2025 marked the peak of inflated expectations, the World Economic Forum in January 2026 signaled something unexpected: a definitive shift from revolution to execution. The prevailing conversation moved away from model capabilities and toward energy grids, sovereign compute, and architectural patterns.

For the software practitioner, this represents progress. The conversation has shifted from magic to mechanics.

You have probably lived through this arc yourself. In 2023, your team trialed ChatGPT and marveled at its ability to generate boilerplate. By 2024, someone pitched a "ChatGPT for our domain" that never left the pilot stage. In 2025, leadership asked why adoption metrics looked strong, but velocity remained flat. Now, in 2026, the question is no longer "Should we use AI?" but rather "How do we make AI work in our actual workflow without breaking what already functions?"

The central signal from Davos 2026 is clear: intelligence is being industrialized. It is transitioning from an abstract cloud service to a physical, sovereign asset that requires a new engineering discipline—one that prioritizes reliability over novelty and workflow integration over model size.

We are witnessing the end of the "Chat" paradigm and the beginning of the "Work" paradigm.

The Architectural Shift: From Model-First to Stack-First

The most significant development from Davos 2026 is the redefinition of the AI stack itself. NVIDIA CEO Jensen Huang, speaking with BlackRock CEO Larry Fink, described AI not as a single technology but as a "five-layer cake" spanning energy, chips and computing infrastructure, cloud data centers, AI models, and applications.

This framing represents a fundamental departure from the simplistic "Model + App" view that has dominated enterprise AI strategy. Huang was explicit: "AI is the largest infrastructure buildout in human history," urging every country to treat AI like electricity or roads. With nearly $100 billion expected to be invested in sovereign AI compute by 2026 alone, the message is unambiguous: AI is becoming critical national infrastructure, not a vendor-supplied service.

We cannot obsess over the model while ignoring the daily reality of the infrastructure.

If you are an engineering leader, this reframing should clarify a persistent confusion: why do demos impress but production deployments stall? The answer is that demos test the top layer—model cleverness—while production requires all five layers to align. Your energy budget, your chip allocation, your data center topology, your model choice, and your application interface must work as a system. Miss one layer, and the entire stack becomes a liability.

Consider a scenario many teams have encountered: you deploy a code-completion tool that works beautifully on a developer's laptop but times out in CI/CD because the inference endpoint cannot scale with concurrent requests. That is not a model problem. That is an infrastructure problem masquerading as an AI problem. Huang's five-layer framing makes this failure mode explicit.

System Fit: The Sovereign Imperative

The term "Sovereign AI" dominated summit discourse. While politicians invoked it to discuss national security, for engineering leaders, it means something far more operational: proprietary cognition.

In 2023, companies were content to wrap a thin UI around a public API. By 2026, that approach will be recognized as a strategic liability. Sovereign AI in the enterprise context means owning the intelligence layer—capturing your organizational knowledge (the tacit understanding of how your business writes code, processes claims, or designs circuits) in models and workflows that you control, not rent from a provider who might deprecate a feature on Tuesday.

Let me make this concrete. Imagine your organization has spent five years building a domain-specific testing framework. Your engineers understand its idioms. Your CI/CD pipeline is tuned to its output. Your incident response playbook references its error codes. Now imagine you deploy a general-purpose code assistant that generates tests in a completely different style—different assertion libraries, different naming conventions, different structure. The assistant's tests may be correct in isolation, but they are incompatible with your system. Adoption stalls. Velocity declines. The pilot is quietly shelved.

That is the System Fit problem.

The empirical evidence supports this diagnosis. While 87% of large enterprises have implemented AI solutions, only 31% report measurable financial impact, and a mere 24% observe profit improvements. The gap is not caused by insufficient model intelligence. It is caused by insufficient System Fit. Organizations are failing to integrate these tools into their proprietary data estates, resulting in generic intelligence that offers no competitive differentiation.

The statistic that should concern every CTO: enterprises have spent tens of billions on generative AI, yet 95% of implementations show no measurable profit-and-loss impact. The failure mode is not the model—it is brittle workflows and tools that do not integrate with existing systems.

Flow Fit: From Chatbots to Agentic Workflows

The second major theme at Davos 2026 was the maturation of agentic AI. Unlike single-turn request-response loops, agentic workflows execute complex, multi-step processes with minimal human intervention.

Research from Gartner indicates that by 2026, 40% of enterprise applications are expected to embed task-specific AI agents, up from low single-digit adoption just a few years earlier. Empirical data from the enterprise adoption survey conducted by Mayfield Fund confirms this acceleration: 42% of organizations now have AI agents in production, with 72% either in production or actively piloting agentic systems.

A new taxonomy of work is emerging:

• Sequential Pipelines: Deterministic chains where an agent handles a specific sub-task (e.g., "Run Unit Tests" → "Analyze Failures" → "Suggest Fix")

• Hierarchical Systems: A "Supervisor" agent decomposes high-level goals for "Worker" agents

• Swarm Architectures: Decentralized agents collaborating on dynamic problems

This evolution creates a substantial challenge for Flow Fit. A chatbot waits for your input. An agentic workflow runs in the background, potentially altering the state of your codebase or database without direct oversight.

Here is where theory meets practice. You have probably experienced this tension: an engineer opens a pull request containing AI-generated code. The code compiles. The tests pass. But during review, you discover the AI misunderstood a critical constraint—perhaps it ignored a deprecation warning, or violated an internal security policy, or introduced a dependency on a library your organization has explicitly banned. The engineer, trusting the AI's output, did not catch the violation. The review cycle doubles. Confidence erodes.

This is the Flow Fit problem at the human layer.

For the Builder, this shifts the job description from "writing code" to "auditing the output of autonomous loops." The cognitive load does not disappear—it transforms. Instead of the steady, predictable rhythm of writing and testing code, you now face the high-intensity, context-switching burden of verifying AI-generated artifacts. Some engineers thrive in this mode. Others experience it as exhausting and disorienting.

The question is no longer "Can the agent write code?" It is "Can I verify what the agent wrote before it ships to production, and can I do so without burning out?"

People Fit: The Cognitive Load Crisis

The industrialization of intelligence brings us back to the socio-technical reality: you cannot industrialize a process you do not understand.

The People Fit crisis of 2026 is not about mass unemployment—Davos reports suggest a labor shortage in skilled technical roles. It is about the cognitive load of hybrid systems.

When we deploy an agentic workflow that automates 40% of a developer's routine tasks, we do not simply "save time." We compress the remaining work into a high-intensity stream of complex decision-making. The routine work that used to provide cognitive breaks—reading logs, writing simple tests, updating documentation—is gone. What remains is concentrated judgment under uncertainty.

Let me illustrate with a scenario that many teams are encountering. A junior engineer joins your team. In the past, they would spend their first few months writing straightforward features, debugging simple issues, and gradually building mental models of the codebase. Those tasks provided safe practice—low stakes, high repetition, steady skill accumulation.

Now, the AI handles many of those tasks. The junior engineer is immediately thrust into higher-level work: reviewing AI-generated code, resolving edge cases the AI cannot handle, and making architectural decisions about which tasks to delegate to the agent. They lack the foundation of routine practice. They struggle. Onboarding takes longer. Confidence develops more slowly.

This is the "Junior Problem," and it is not hypothetical. It is happening now.

This requires new skills:

• Control: The ability to define rigorous guardrails (e.g., "The agent can draft the PR, but it cannot merge to Main without human audit")

• Authenticity: The discipline to sign your name only to work you have verified. In a world of infinite generated content, your signature—your reputation for correctness—is your only scarcity

• Community: Relying on peer review more than ever. If an AI generates the code, a human must understand the intent

These are operational necessities. Without Control, your agentic systems will violate constraints you have not explicitly encoded. Without Authenticity, you will ship defects faster than you can detect them. Without Community, individual engineers will drift into incompatible practices, and your codebase will fracture.

The Sovereign Stack Audit: A 30-Minute Drill

Before authorizing the next budget cycle for an AI pilot, run this audit. It tests for Compatibility-First principles over hype.

1. The Infrastructure Check (System Fit)

• Energy & Compute: Do we have secured compute capacity to run this workload, or are we reliant on spot pricing that may disappear when demand spikes?

• Data Sovereignty: Does the model train or finetune on our data in a private environment, or are we leaking intellectual property to a public model provider?

• Dependency Risk: If the model provider changes their API schema tomorrow, does our production workflow break? Do we have fallback options?

Why this matters: At Davos, speakers emphasized that AI is moving from rental models to owned infrastructure. If your AI strategy depends on a vendor's good faith, you are not building for the long term.

2. The Workflow Check (Flow Fit)

• Latency Tolerance: Does the agentic loop run fast enough to keep the human in flow, or does it force a context switch that destroys concentration?

• Error Handling: When (not if) the agent hallucinates, is failure containment automated, or does it require manual cleanup that takes longer than the original task?

• Interface: Is the AI integrated into the IDE/CLI, or is it a separate "destination" tab that requires context switching?

Why this matters: The Mayfield survey found that the most successful AI implementations are those that embed directly into existing workflows, not those that require users to adopt new tools. Flow Fit is the difference between a feature that gets used daily and a feature that gets disabled after two weeks.

3. The Cognitive Check (People Fit)

• The "Junior Problem": Are we using AI to replace junior engineers? If so, who will be the senior engineers in five years? What is our plan for skill development?

• Auditability: Can a human explain why the agent made a specific decision, or is the reasoning opaque?

• Psychological Safety: Do developers feel safe rejecting AI suggestions, or is there implicit or explicit pressure to "just ship it" because the AI generated it?

Why this matters: The PwC survey revealed that while 73% of CEOs expect generative AI to significantly change how their companies create, deliver, and capture value in the next three years, only 31% report measurable financial impact today. The gap is often caused by People Fit failures—teams that adopt the tool but cannot sustain the practice.

Role-Based Action Items

For The Builder (Individual Contributor)

Stop being a "Prompt Engineer." Start being a "Workflow Architect."

The value of typing a clever prompt into a chat box is collapsing to zero. The value of constructing a reliable chain of prompts, scripts, and verification steps is increasing rapidly.

Here is a concrete experiment you can run this week:

Next Move: Build a "Sequential Pipeline" for a routine task. Do not simply ask an LLM to "write a test for this function." Instead:

1. Write a script that extracts the function signature and docstring

2. Pipe that context to an LLM with explicit constraints (e.g., "Use pytest, cover edge cases, follow our naming convention")

3. Extract the generated test code

4. Run it against the actual function

5. If it fails, pipe the error back to the LLM with the instruction "Fix this test given this error"

6. Repeat until the test passes or you hit a retry limit

Save this script. Refine it. Share it with your team. You have just automated a workflow, not a task. That is the skill that compounds.

The result you should observe: The first iteration may take longer than writing the test manually. By the tenth iteration, you will be faster. By the fiftieth, you will wonder how you ever worked without it.

For The Manager (Team Lead)

Prioritize "Cognitive Sovereignty."

Your team is likely overwhelmed by tools that promise to help but actually distract. Every new AI feature is another notification, another interface, another decision point. The cognitive tax is real.

Next Move: Implement a "No-Ghost-Merge" policy. The rule is simple: No AI-generated code enters the codebase without a human explicitly documenting what they verified. This enforces the "Authenticity" pillar and prevents the review fatigue that leads to defects.

Here is what the policy looks like in practice:

When a developer submits a PR containing AI-generated code, the PR description must include:

• Generated by: Which tool/model was used

• Verified: Which aspects were manually checked (correctness, security, performance, style)

• Risk: What could go wrong if the verification missed something

This is not bureaucracy. This is accountability. It also creates a learning corpus—after six months, you can analyze your team's "Verified" notes to identify which verification steps are most commonly skipped and which types of AI-generated code require the most rework.

The result you should observe: Initially, some engineers will resist the overhead. Within a month, the team will develop a shared understanding of what "good" AI-assisted work looks like. Defect rates will stabilize or improve. Confidence in AI-generated code will increase because the verification process is explicit.

For The Roadmap Owner (Executive/CTO)

Measure "Value Realization," not "Adoption."

The statistic that "91% of our developers use Copilot" is a vanity metric. It tells you nothing about profit-and-loss impact.

Here is the uncomfortable truth: adoption without outcomes is worse than no adoption at all, because it creates the illusion of progress while consuming resources (licenses, training, management attention) that could be deployed elsewhere.

Next Move: Shift your KPIs from "Efficiency" (speed) to "Reliability" (uptime/error rates). The industrialization of intelligence means treating AI as critical infrastructure. If your AI strategy does not include a line item for "Energy" and "Sovereign Data Storage," it remains a pilot project, not a production system.

Replace these metrics ❌:

• "Percentage of developers using AI tools"

• "Number of AI-generated lines of code"

• "Time saved by AI assistance"

With these metrics ✅:

• "Cycle time from commit to production for AI-assisted vs. manual work"

• "Defect escape rate for AI-generated vs. manually written code"

• "Mean time to resolution for incidents involving AI-generated components"

• "Developer satisfaction with AI tooling (measured via quarterly pulse survey)"

The result you should observe: Within one quarter, you will identify which AI use cases are delivering measurable value and which are consuming resources without return. Double down on the former. Retire the latter. This is portfolio management, not science fair judging.

What This Means for the Next 12 Months

The shift from the "Chat" paradigm to the "Work" paradigm is not a future trend. It is the present reality. The organizations that recognize this shift and adapt their practices accordingly will build sustainable competitive advantages. Those that continue to treat AI as a demo feature will fall further behind.

Three predictions for 2026:

1. Sovereign compute will become a board-level topic. As AI transitions from a rented service to owned infrastructure, CFOs and CTOs will jointly evaluate whether to build private data centers or negotiate long-term compute contracts. The financial stakes are comparable to cloud migration decisions from the 2010s.

2. Agentic workflows will expose organizational knowledge gaps. When an agent automates a process, it makes explicit every assumption, constraint, and exception that was previously tacit. Many teams will discover that their processes are less well-defined than they believed. The winners will treat this as an opportunity to codify institutional knowledge.

3. The "Junior Problem" will force a rethinking of career development. If AI handles routine tasks, how do junior engineers build foundational skills? Organizations that solve this problem—through structured apprenticeships, deliberate practice programs, or AI-augmented learning environments—will have a recruiting advantage.

Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.

Partner with Daniel to transform your organization through evidence-based approaches that bridge academic rigor with practical implementation. His consulting work helps technology companies and research institutions adopt scientifically validated practices that improve software development outcomes, team performance, and innovation capacity.

Learn more about his approach to evidence-based organizational change: https://www.danielrusso.org/evidence-based-organizational-change/

References

CloudKeeper. (2026). Top agentic AI trends to watch in 2026: How AI agents are redefining enterprise automation. https://www.cloudkeeper.com/insights/blog/top-agentic-ai-trends-watch-2026-how-ai-agents-are-redefining-enterprise-automation

Computer Weekly. (2026, January 21). Davos 2026: Smart thinking needed for sovereign AI investment. https://www.computerweekly.com/news/366637503/Davos-2026-Smart-thinking-needed-for-sovereign-AI-investment

Mayfield Fund. (2026, January 27). The agentic enterprise in 2026. https://www.mayfield.com/the-agentic-enterprise-in-2026/

Nvidia. (2026, January 21). Jensen Huang on AI's 'five-layer cake' at Davos. https://blogs.nvidia.com/blog/davos-wef-blackrock-ceo-larry-fink-jensen-huang/

PwC. (2025). AI's productivity promise: Mind the value gap. https://www.pwc.ie/reports/ceo-survey/artificial-intelligence.html

Quartz. (2026, January 21). Jensen Huang brings a 5-layer AI pitch to Davos. https://qz.com/jensen-huang-nvidia-speech-davos-2026

Second Talent. (2025). AI adoption in enterprise statistics & trends 2025. https://www.secondtalent.com/resources/ai-adoption-in-enterprise-statistics/

ServicePath. (2025, September 10). The AI integration crisis: Why 95% of enterprise pilots fail. https://servicepath.co/2025/09/ai-integration-crisis-enterprise-hybrid-ai/

World Economic Forum. (2026, January 20). How agentic, physical, and sovereign AI are rewriting the rules of enterprise innovation. https://www.weforum.org/stories/2026/01/how-agentic-physical-and-sovereign-ai-are-rewriting-the-rules-of-enterprise-innovation/

“Do we have a service kill switch?”

Not a literal red button, of course. More like a fear that critical services—health, energy, payments—could be throttled, suspended, or price-shocked if a geopolitical or legal chokepoint tightens.

The discomfort is rational. But the response shouldn’t be digital isolationism—or endless dependency doom-scrolling.

What’s changed is that we now have better data about where Europe actually stands, and a clearer picture of why the gap persists.

Two major reports released in 2025 provide complementary lenses:

• Harvard Kennedy School’s Belfer Center published the inaugural Critical and Emerging Technologies Index: a quantitative benchmark across 25 countries and five sectors (AI, biotech, semiconductors, space, quantum).

• CDTM (Munich) released The Future of Digital Sovereignty, which treats sovereignty as a societal and economic system—not just a technology checklist.

Together, they explain the same feeling from two angles:

1. We’re not powerless—but we’re constrained.

2. The constraint isn’t only technical. It’s behavioural, institutional, and cultural.

1) The Belfer Index: Europe is “third”—but with a heavy anchor

The Belfer Center’s index is sobering in the way good metrics often are: it doesn’t insult you, it just removes your excuses.

Their “key judgments” are blunt:

• The United States leads across all five sectors, driven by economic resources, human capital, and a decentralised innovation ecosystem.

• China is closing the gap, especially in biotech and quantum, using scale and centralised planning (even while facing constraints in semiconductors and advanced AI).

• Europe is competitive relative to the U.S.–China duopoly, and ranks third in AI, biotech, and quantum—but falls behind in space and is eclipsed in semiconductors by multiple Asian leaders.

That last part matters more than it first appears, because Belfer’s methodology assigns semiconductors the highest strategic weight: 35% of the overall index (vs 25% AI, 20% biotech, 15% space, 5% quantum).

So Europe’s position isn’t “we’re behind everywhere.” It’s closer to:

We’re credible in several high-value sectors, but our weakest link is the most heavily weighted.

And Belfer makes a second point that often gets lost in public debate: Europe’s aggregate standing depends on integration of governance and capital across the region. In other words—coordination is part of capability.

2) The cloud numbers: dependency isn’t static—it’s compounding

If semiconductors are the “hard floor” of the stack, cloud is the “soft power” layer where dependency quietly becomes operational reality.

Synergy Research data (widely reported in 2025) paints a parallel story:

• The big three US providers (AWS, Microsoft, Google) hold about 70% of the European cloud market.

• European providers’ market share has fallen from ~29% (2017) to ~15%, stabilising around that level since 2022—while the overall market grew dramatically.

That’s the part that makes people uneasy: even where European providers grew revenues, the relative position barely improved.

This is why “kill switch” language spreads. Not because someone believes a villain will press a button, but because high concentration creates correlated risk:

• licensing changes ripple everywhere

• compliance conflicts affect whole sectors

• geopolitical shocks become supply shocks

• “exit” becomes expensive precisely when you need it

And once organisations embed themselves deeply into proprietary identity, data, and observability patterns, “we could migrate” becomes a story people tell themselves to sleep.

3) Why the gap persists: it’s not only a tech deficit

Here’s where the CDTM report is useful—not because it disputes the numbers, but because it asks a different question:

What social and economic dynamics keep Europe dependent even when awareness is rising?

CDTM explicitly frames sovereignty as a multi-domain challenge—technology, legal, economic, and societal—and highlights trends such as an intensifying tech talent war and a widening digital literacy gap, alongside the paradox that Europe can “govern” through regulation while still relying on non-European foundations.

In practice, three patterns show up again and again.

A) The consumer dilemma: values vs behaviour

Europe often expresses strong preferences for privacy, fairness, and trust. Those values show up in regulation and in niche product adoption.

But when teams are under delivery pressure, convenience wins:

• the richest ecosystem

• the fastest procurement path

• the most integrations

• the default “reference architecture”

• the most available talent

That’s not hypocrisy. It’s constraint.

If your organisation is measured on quarterly delivery, then choosing a “principled” stack that slows you down can look like malpractice—even if it reduces strategic risk long-term.

B) The talent war: training isn’t the same as retaining

Europe’s educational base in AI is strong.

Multiple analyses suggest Europe has a higher per-capita concentration of AI professionals than the US (often cited at ~30% higher), while still facing persistent brain drain.

This isn’t just about individuals leaving. It’s about losing the cohesive team dynamics that turn expertise into compounding advantage:

• research groups that stay intact long enough to build platforms

• startups that can hire at scale without losing to US compensation bands

• industrial labs that can keep senior talent through the “boring middle” years

A region can “produce talent” and still fail to build durable capability if the winners are elsewhere.

CDTM flags this directly as part of the sovereignty problem: human capital isn’t only a pipeline issue—it’s a retention and ecosystem issue.

C) The digital literacy gap: adoption is moving faster than understanding

CDTM also points to a widening digital literacy gap.

At the basic level, it makes societies more vulnerable to manipulation and misinformation. At the advanced level, it shrinks the pool of people who can:

• audit systems

• critique model outputs

• understand security tradeoffs

• build with emerging tech responsibly

When a society can’t confidently use, critique, and create with new technologies, sovereignty becomes aspirational rather than operational.

4) The uncomfortable convergence: regulation and market fatalism can lead to the same place

This is where the public debate gets weird.

On one side, Europe regulates aggressively and projects values globally. On the other, dependency deepens.

And here’s the uncomfortable possibility:

Regulatory maximalism without capability investment can increase dependency—because compliance overhead is easier to absorb for incumbents with scale.

Meanwhile, the opposite extreme—pure market liberalism (“just buy the best product globally, always”)—also tends to produce dependency, because ecosystems and switching costs compound.

Different ideologies. Same outcome:

European organisations build on non-European foundations, exposed to risks regulation alone can’t mitigate.

This is why the “kill switch” narrative is seductive: it compresses a slow systemic dynamic into a vivid threat.

But we don’t need better slogans. We need better engineering governance.

5) A pragmatic stack model: where autonomy is realistic (and where it isn’t)

I like a four-layer model because it forces teams to stop treating “sovereignty” as a monolith.

1) Physical & compute (hardest to shift quickly)

Chips and fabrication are where Europe’s deficit is most constraining—and where Belfer assigns the highest weight.

Full parity here is a long-cycle project. Pretending otherwise is how you burn money and trust.

2) Software foundations (highest leverage through open ecosystems)

Operating systems, middleware, runtime stacks, and the software supply chain.

This is where Europe can build real optionality by:

• standardising interfaces

• funding upstream maintenance

• strengthening secure-by-design practices

• treating portability as a first-class architectural property

It’s unsexy—and strategically decisive.

3) Data & AI (where “trust” and “authenticity” become technical)

AI changes the sovereignty discussion because capability isn’t only in infrastructure—it’s also in:

• model governance

• dataset provenance

• evaluation pipelines

• auditability of decision support

This is where organisational “faith” shows up: if your roadmap assumes vendors will remain neutral and available forever, you’re outsourcing your future options.

4) Application domains (where Europe can win fastest)

Energy, health, public administration, regulated finance.

Not by building generic clones of US products, but by building domain-specific systems aligned with European legal and cultural standards.

This is where sovereignty stops being politics and becomes product.

6) Practical steps for engineering leaders: move from slogans to systems

If you’re leading a platform, security, or product organisation, you don’t need to wait for a perfect “sovereign cloud” to arrive.

Start with actions that create governability.

Step 1: Run a “sovereignty trace”

List your top 20 dependencies (not vendors—dependencies), including:

• identity and access

• key management

• CI/CD and artifact storage

• observability

• core data stores

• model APIs (if relevant)

Then ask:

If this dependency is constrained for 30 days—what breaks first? What becomes unsafe?

This is not paranoia. It’s architecture.

Step 2: Measure lock-in where it actually lives

Lock-in is rarely “we use Kubernetes.”

Lock-in is:

• proprietary IAM patterns

• data egress economics

• platform-specific logging and tracing

• managed services that leak into domain logic

• contractual switching constraints

If you can’t name your lock-in points, you can’t manage them.

Step 3: Build credible exit paths (even if you never use them)

Most organisations don’t need multi-cloud heroics.

They need:

• open interfaces

• portable deployment patterns

• documented runbooks for “provider degradation” scenarios

• tested restore and migration procedures for critical data

Exit paths are like incident response plans: you hope you don’t need them, and you regret it if you never practiced.

Step 4: Invest upstream as a strategic move

If your stack depends on open source, fund the parts that keep you alive.

That’s not charity. It’s:

• patch velocity

• roadmap influence

• supply-chain security

• ecosystem stability

Sovereignty is collaborative—or it’s imaginary.

7) Europe’s tech renaissance: not decoupling, but tech citizenship

If you take Belfer seriously, the message isn’t “Europe is doomed.” It’s “Europe is positioned—if it integrates and invests where it matters.”

If you take CDTM seriously, the message isn’t “sovereignty is a procurement checkbox.” It’s “sovereignty is a socio-technical transition with human capital, literacy, and incentives at the core.”

So the renaissance I’m seeing isn’t about building a wall around Europe.

It’s about moving from being digital subjects of imported platforms to becoming tech citizens who actively govern their tools:

• eyes open to dependency

• disciplined about standards and exit paths

• investing in upstream ecosystems

• building domain capability that reflects European norms

• treating governance as part of engineering, not paperwork

That’s slower than slogans. But it’s also how durable systems are built.

Final thought: Don’t Treat the “Kill Switch” Fear Like a Story — Treat It Like a System You Can Audit

If there’s one message in this article, it’s this:

The data doesn’t demand panic. It demands engineering discipline.

The Belfer Index and the cloud market numbers aren’t a prophecy of collapse. They’re a signal that Europe’s position is constrained in foundational layers (especially semiconductors) while dependency deepens in operational layers (especially cloud and platform ecosystems).

Europe can’t (and shouldn’t) rebuild the entire global stack inside its borders. But we can stop letting sovereignty happen by accident—through procurement defaults, inherited architectures, and “we’ll migrate later” assumptions that never get tested.

The move now isn’t “buy European” as a reflex. It’s this:

Treat technological sovereignty like a set of measurable, stress-testable capabilities—and audit them like you would audit security.

That means:

• mapping your real dependency graph across cloud, software supply chain, data, and governance—not just your vendor list,

• distinguishing what’s critical under stress from what’s merely convenient,

• and building credible exit paths where the risk is non-negotiable (public administration, critical infrastructure, safety-relevant systems).

Most organisations don’t have a sovereignty problem. They have an observability problem:

• they can’t explain which systems fail first under legal, pricing, or geopolitical constraints,

• they don’t know which dependencies are “single points of policy failure,”

• and they can’t show—inside a board room or a ministry—that their choices are defensible.

So what’s your next move?

If you build and ship (engineer / architect / platform lead)

Pick one system that matters and do a Sovereignty Trace:

1. List the top 20 external dependencies (cloud services, identity, CI/CD, package registries, model APIs, key OSS libs).

2. Mark each one as: replaceable in 30 days / 90 days / not realistically replaceable.

3. For the “not replaceable” group, answer one hard question:

“If this dependency is constrained, what is our minimum viable operating mode?”

Bring that to your next architecture review. If you can’t describe a degraded mode, you don’t have resilience—you have hope.

If you lead people (EM / Head of Engineering / Director)

Run a 90-minute Capability Under Stress workshop with staff engineers and security.

Choose one critical domain (identity, data platform, build pipeline, cloud runtime, or model serving) and map:

• the dependency chain (providers, jurisdictions, key components)

• the operational choke points (billing, keys, auth, APIs, SLAs, egress constraints)

• your time-to-recover assumptions (what you think is replaceable vs what actually is)

End by agreeing on:

• the top 3 risks you can realistically mitigate this quarter

• one concrete “exit-path” investment (standards, portability, runbooks, drills)

• one procurement rule that prevents future lock-in

Write it down. Treat it like an engineering policy—not a slide deck.

If you own the roadmap and budget (CTO / CIO / public-sector lead)

Make sovereignty a gate for major initiatives.

Don’t just ask “Is it compliant?”—ask:

• Is it auditable?

• Is it portable where it needs to be?

• Do we know which external actor can stop this from working—and under what conditions?

• Do we have a credible alternative for the systems we cannot afford to lose?

Reserve part of your budget specifically for sovereignty audits and remediation, the same way you reserve budget for pentests and incident response readiness.

Because if you can’t show where you have dependable capability under stress, you don’t have a sovereignty strategy—you have a collection of assumptions.

If this article had one underlying argument, it would be this:

You wouldn’t run critical infrastructure without monitoring, threat modelling, and disaster recovery. Don’t run critical digital dependencies that way either.

That’s where I can help.

I work with engineering organisations to:

• audit dependency and sovereignty risk across cloud, software supply chain, data, and governance,

• identify where critical systems rely on fragile single points (vendor, jurisdiction, platform policy, maintainer risk),

• design pragmatic mitigation plans (portability, open foundations, procurement criteria, secure supply-chain practices),

• and build clear evidence leaders can use to make defensible decisions—without turning delivery into bureaucracy.

If you want help turning “we hope our dependencies are fine” into “we’ve audited our exposure, prioritised the risks, and we have credible options,” start here: 👉 https://www.danielrusso.org/evidence-based-organizational-change/

Three years ago, most “cloud strategy” discussions in Europe sounded the same:

• Where are the best engineers?

• Which vendor gives the biggest discount?

• Can we move fast without upsetting procurement?

In January 2026, the conversation has a new line item: What happens if the network becomes a geopolitical chokepoint?

A concrete signal of that shift: on January 15, 2026, AWS announced a new “European Sovereign Cloud” designed to address European concerns about sovereignty, legal jurisdiction, and operational separation.

Whatever you think of the move (genuine commitment, smart marketing, or both), the message is unmistakable:

Cloud, compute, and software supply chains are no longer “neutral infrastructure.” They’re contested territory.

From “benign interdependence” to stress-tested dependencies

Political scientists Henry Farrell and Abraham Newman coined a phrase that’s become painfully useful: “weaponized interdependence.” The idea is simple: if global networks have hubs, whoever controls the hubs can monitor, throttle, or deny access—especially under crisis conditions.

You can see the pattern across the tech stack:

• Semiconductors and advanced equipment have become a toolkit for export controls and bargaining power.

• Cloud and platforms concentrate operational leverage in a few providers and jurisdictions.

• AI compute and foundation models create “capability gravity wells” that shape who sets defaults, safety regimes, and developer norms.

This doesn’t mean Europe should retreat into romantic self-sufficiency. It means Europe needs a strategy that starts from one hard truth:

In a crisis, “dependence” stops being an economic efficiency and starts being a political constraint.

Europe’s uncomfortable baseline: strong niches, weak breadth

Denmark is a useful microcosm of the broader European situation: a high-trust society, strong institutions, and real technical excellence—yet still vulnerable in critical technologies.

ATV’s recent analysis (prepared with the Danish Technological Institute) makes it explicit: Denmark has lost ground in 12 of 16 critical technology areas over the last decade, measured through quality-patenting performance.

At the same time, Denmark retains clear strengths—notably energy technology, food technology, and audio technology—and additional areas where Denmark is above global averages depending on the benchmark.

Zoom out, and the picture becomes even more strategic: Europe’s challenge is not only invention, but translation—turning research into scaled capabilities, industrial capacity, and resilient supply chains. DIGITALEUROPE’s “Critical Tech Gap” report frames this as an economic security problem: strong R&D signals, but weaker commercialisation and manufacturing muscle in several critical domains.

So the question is not whether Europe has talent. It does. The question is whether Europe has dependable, stress-tested capabilities it can access and shape when conditions deteriorate.

Sovereignty, made operational: capability under stress, not autarky

“Sovereignty” is often argued at the level of slogans—either heroic (“we must control everything”) or dismissive (“this is protectionism in disguise”).

The more useful definition is operational:

Digital sovereignty is the ability to maintain continuous access to dependable technological capabilities, including under hostile or unstable conditions.

That framing matters because it breaks the false binary.

Europe does not need to build everything. Europe does need to decide which dependencies are acceptable, which must be governed, and which are simply too risky.

The leverage point Europe underuses: software and open ecosystems

Here’s the uncomfortable part: Europe cannot replicate hyperscaler scale or leading-edge fab capacity in one investment cycle.

But Europe can reshape something faster—and it affects every one of those domains:

Software architectures, open ecosystems, standards, and security practices.

Modern systems are built on dense component networks. Sonatype’s 2024 supply-chain report notes that open-source components can make up up to 90% of modern applications.

That’s a sovereignty issue, not just a developer experience detail.

Because sovereignty isn’t only about where code runs. It’s also about:

• Who governs the upstream components you depend on

• Who can audit them

• Who funds their maintenance

• Who can credibly respond when they become attack surfaces

This is why regulation is now converging with industrial policy.

Europe’s policy stack is real—and it’s accelerating

The EU has started assembling a capability architecture that mixes regulation with investment:

• Chips Act (entered into force September 2023) to strengthen Europe’s semiconductor ecosystem.

• STEP (Strategic Technologies for Europe Platform) to coordinate funding across strategic domains (digital, clean tech, biotech).

• Digital Europe Programme to fund deployment capacity in HPC, AI, cybersecurity, and skills.

• AI Act (entered into force August 1, 2024) with staged obligations now rolling in through 2026–2027.

• Cyber Resilience Act (entered into force December 10, 2024; key obligations apply from December 2027, with reporting earlier) pushing “security as a product property.”

• A forthcoming Cloud and AI Development Act planned for Q1 2026.

You can debate the details (and you should). But the direction is consistent:

Europe is trying to turn sovereignty from rhetoric into enforceable infrastructure choices.

A practical compass: four layers of the digital stack

To make sovereignty actionable in software work, I use a simple four-layer model. Different layers have different realistic “control ceilings” for Europe.

1) Physical + compute

Chips, data centres, networks, edge devices. Europe can strengthen capacity—but scale and geopolitics make full parity unlikely in the near term.

2) Platforms

Cloud primitives, orchestration, core databases, identity, CI/CD platforms. Europe’s market reality is still concentrated: European providers have hovered around ~15% share of the European cloud infrastructure market in recent years, while much growth has been captured by the major US hyperscalers.

3) Foundations

Open-source libraries, security tooling, middleware, and (increasingly) foundation models. This is where governance, funding, and maintenance become strategic power—not just licensing.

4) Applications + data domains

Sector systems: energy, health, transport, agriculture, public administration. This is where Europe (and Denmark) can achieve the highest autonomy: domain models, datasets, and operational control—even if lower layers remain partly external.

The sovereignty decision that teams can actually make

When the debate becomes ideological, teams freeze.

One camp says: “We must build a European hyperscaler tomorrow.” Another says: “Sovereignty is a fantasy; just optimise cost and delivery.”

In practice, both extremes often converge on the same failure mode: they ignore the middle of the stack—the software foundations, portability constraints, supply-chain security, and governance realities that determine whether you have options later.

So here’s a decision framework engineers and leaders can use tomorrow:

Step 1: Classify systems by “stress sensitivity”

Ask: if access were constrained for 30 days—by law, sanctions, vendor policy, or security incidents—what breaks?

• Critical infrastructure / public sector core systems

• Safety-relevant industrial systems (energy, water, health)

• Sensitive research and national capability platforms

• Everything else

Step 2: Demand portability where it matters

For stress-sensitive systems:

• multi-region exit plans

• open standards and tested migration paths

• contractual and technical independence where possible

Step 3: Treat software supply-chain security as sovereignty work

The CRA is not “compliance paperwork”; it’s a competitive and resilience baseline.

Concretely

• SBOMs by default

• provenance and signed builds

• dependency risk tiers (what you trust, what you verify, what you isolate)

• upstream engagement for your most critical dependencies

Step 4: Invest upstream, not only downstream

If open-source is critical infrastructure, fund it like it is.

Not with symbolic sponsorships—but with:

• maintainers’ time

• security audits

• shared European governance and stewardship capacity

Where Denmark (and similar economies) can win

Denmark can’t outspend great powers across the full stack. But Denmark can compound its influence by combining:

• sector niches (energy systems, food/agri, audio/med-tech) with

• horizontal software capabilities (secure supply chains, open foundations, data governance, and talent pipelines)

That is what “dependable capability” looks like in a small, open economy: selective depth, real operational control, and managed interdependence elsewhere.

Final thought: Don’t Treat Sovereignty Like a Slogan — Treat It Like a System You Can Audit

If there’s one message in this article, it’s this:

Dependencies are inevitable. Uncontrolled dependencies are optional.

Europe can’t (and shouldn’t) rebuild the entire global tech stack inside its borders. But we can stop making sovereignty decisions by accident — through procurement defaults, inherited architectures, and unexamined platform lock-in.

The move now isn’t “buy European” as a reflex. It’s this:

Treat technological sovereignty like a set of measurable, stress-testable capabilities — and audit them like you would audit security.

That means:

• mapping your real dependency graph across cloud, software supply chain, data, and governance — not just your vendor list,

• distinguishing what’s critical under stress from what’s merely convenient,

• and building credible exit paths where the risk is non-negotiable (public administration, critical infrastructure, safety-relevant systems).

Most organisations don’t have a sovereignty problem. They have an observability problem:

• They can’t explain which systems would fail first under legal or geopolitical constraints.

• They don’t know which dependencies are “single points of policy failure”.

• They can’t show, in a board room or a ministry, that their choices are defensible.

So what’s your next move?

If you build and ship (engineer / architect / platform lead)

Pick one system that matters and do a Sovereignty Trace:

• List the top 20 external dependencies (cloud services, identity, CI/CD, package registries, model APIs, key OSS libs).

• Mark each one as: replaceable in 30 days / 90 days / not realistically replaceable.

• For the “not replaceable” group, answer one hard question:

“If this dependency is constrained, what is our minimum viable operating mode?”

Bring that to your next architecture review. If you can’t describe a degraded mode, you don’t have resilience — you have hope.

If you lead people (EM / Head of Engineering / Director)

Run a 90-minute Capability Under Stress workshop with staff engineers and security:

• Choose one critical domain (identity, data platform, build pipeline, or cloud runtime).

• Map:

• End by agreeing on:

Write it down. Treat it like an engineering policy — not a slide deck.

If you own the roadmap and budget (CTO / CIO / public-sector lead)

Make sovereignty a gate for major initiatives:

Don’t just ask “Is it compliant?” — ask:

• Is it auditable?

• Is it portable where it needs to be?

• Do we know which external actor can stop this from working — and under what conditions?

• Do we have a credible alternative for the systems we cannot afford to lose?

Reserve part of your budget specifically for sovereignty audits and remediation, the same way you reserve budget for pentests and incident response readiness.

Because if you can’t show where you have dependable capability under stress, you don’t have a sovereignty strategy — you have a collection of assumptions.

If this article had one underlying argument, it would be this:

You wouldn’t run critical infrastructure without monitoring, threat modelling, and disaster recovery. Don’t run critical digital dependencies that way either.

That’s where I can help.

I work with engineering organisations to:

• audit dependency and sovereignty risk across cloud, software supply chain, data, and governance,

• identify where critical systems rely on fragile single points (vendor, jurisdiction, platform policy, maintainer risk),

• design pragmatic mitigation plans (portability, open foundations, procurement criteria, secure supply-chain practices),

• and build clear evidence leaders can use to make defensible decisions — without turning delivery into bureaucracy.

If you want help turning “we hope our dependencies are fine” into “we’ve audited our exposure, prioritised the risks, and we have credible options,” start here: 👉 https://www.danielrusso.org/evidence-based-organizational-change/