AI Won’t Save
You From Your
Engineering Culture

There is a version of the AI adoption story that goes like this: your team is slow, disorganised, and producing inconsistent quality. You roll out AI tools. Developers get faster. Output increases. Problems resolve themselves in the wash of productivity gains.

I have watched enough teams go through this to tell you that version is false. Not just incomplete - actively misleading. The data now backs this up comprehensively.

The 2025 DORA report, which surveyed thousands of engineering teams worldwide, arrived at a conclusion that every engineering leader should read carefully: AI does not fix a team. It amplifies what is already there. Strong teams use it to become significantly better. Struggling teams find that AI highlights and intensifies their existing problems.

This is not a reassuring finding for organisations that have been hoping AI tooling would paper over process debt.

The amplifier, not the equaliser

The framing I hear most often from leaders planning AI adoption is essentially equalising: bring everyone up, close the gap between high and low performers, lift output across the board. It is an appealing picture. It is not what tends to happen.

DX’s 2025 research, covering over 135,000 developers, found that 91% had adopted AI tools - and that weekly time savings had plateaued at around 3.6 hours per developer. That sounds meaningful until you read the rest of the finding: meetings, interruptions, review delays, and CI wait times cost developers more time than AI saves. The individual productivity gains were real. The organisational bottlenecks were larger.

In other words, teams that already had functioning review processes, clean CI pipelines, and minimal meeting overhead captured genuine value from AI adoption. Teams that did not found that AI accelerated their throughput while leaving the downstream constraints exactly as congested as before. You can ship code faster into a review queue that does not move any quicker.

The Faros.ai AI Productivity Paradox report, which analysed 1,255 teams and over 10,000 developers, found a version of this in the numbers: developers on high-AI-adoption teams merged 98% more pull requests, with average PR size growing 154%. Bug rates per developer increased 9%. More code went out. More of it broke things.

That is not an argument against AI adoption. It is an argument for getting the organisational infrastructure right before you scale the tooling.

What “amplifier” actually means in practice

The DORA finding has a specific implication that is worth sitting with: if AI amplifies existing conditions, then the question of whether your AI adoption programme succeeds is largely determined before the tools are deployed.

Teams with these characteristics tend to see genuine gains:

• 1 Small, reviewable pull requests as a norm - before AI arrives
• 2 Automated testing with meaningful coverage, not just line coverage metrics
• 3 Fast feedback loops: CI that runs in minutes, not hours
• 4 A review culture where rejection is normal and not a social failure
• 5 Clear architectural standards that reviewers can apply consistently

Teams without these tend to see AI make existing problems worse. Review queues get longer because there is more to review. Defect rates climb because volume increases faster than quality controls. Senior engineers burn out on review load that was already unsustainable before AI doubled the throughput.

The DX research puts it bluntly: the biggest opportunity comes from adopting modern engineering practices first. Continuous delivery, small batch sizes, automated testing, fast feedback loops. AI makes their presence more valuable and their absence more costly.

The governance gap that most leaders are ignoring

There is a specific finding in the 2025 data that I find uncomfortable to read as an engineering leader, because it describes a failure mode I have seen and I suspect most of my peers have too.

Nearly 90% of engineering leaders report that their teams are actively using AI tools. According to Cortex’s 2026 Engineering Benchmark Report, only 32% have formal governance policies with enforcement in place - 41% rely on informal guidelines and 27% have nothing at all.

That gap - between what teams are doing and what leaders have thought through - is where the most significant risks sit. Not the dramatic risks, the visible incidents and the obvious security failures, but the quiet ones. The accumulation of AI-generated code that nobody has calibrated their review processes to evaluate. The junior engineers building habits around tools that nobody has structured for learning. The metrics that look fine because they are measuring the wrong things.

Most AI governance efforts I observe are reactive: something goes wrong, a policy appears. The teams I have watched handle adoption well inverted this. They treated governance as a precondition of scale, not a response to failure.

This does not mean elaborate policy documents. It means three things in particular:

First, a shared definition of what good AI-assisted development looks like on your team. Not in the abstract - specifically. What does an AI-assisted PR need to demonstrate before it is ready for review? What areas of the codebase require additional scrutiny? What does “I accepted this AI suggestion” need to mean in terms of the engineer’s understanding of it?

Second, review processes that have been deliberately updated, not just inherited. Most code review processes were designed for human-written code. AI-generated code has different failure modes - more surface correctness, more context blindness, more subtle logic errors - and reviewing it well requires a different posture. Teams that run the same review process they used two years ago are applying the wrong lens.

Third, metrics that measure outcomes rather than activity. More on this below.

The cultural dimension that process cannot fix

Process matters. Governance matters. But there is a dimension of this that sits underneath both, and it is the one that separates teams where AI adoption takes hold constructively from teams where it creates new problems.

Psychological safety.

Harvard Business Review’s 2025 research on organisational AI adoption barriers identified fear of replacement, rigid workflows, and entrenched power structures as the primary reasons AI initiatives fail - not technical barriers, not tool quality, not budget. The cultural environment in which people are using these tools determines whether they use them honestly.

An engineer who is worried about their job security will use AI to produce output volume, not to do better work. An engineer who is worried about looking incompetent will not admit when an AI suggestion confused them. An engineer in a culture where the review process is experienced as adversarial will route around it rather than subject AI-generated code to the scrutiny it needs.

This is not a soft concern. It has hard consequences. The teams I have watched accumulate the most hidden technical debt from AI adoption are not the ones with the worst tools or the weakest processes. They are the ones where people do not feel safe being honest about what the tools are doing and not doing for them.

McKinsey’s 2025 State of AI research found that high-performing organisations are three times more likely to have senior leaders who actively demonstrate ownership of AI initiatives - not just sponsorship, but genuine engagement. Leaders who are seen using the tools, acknowledging the difficulties, and being honest about what is working and what is not.

This matters because it sets the cultural tone. If the message from leadership is “AI is transforming our productivity” and the message from engineers’ daily experience is “this is complicated and sometimes makes things harder,” the disconnect does not resolve itself. It drives the honest signal underground.

The metrics trap

One of the most consistent findings across the 2025 data is that the metrics most commonly used to track AI adoption are the ones least likely to tell you whether it is working.

DX found that daily AI users merge 60% more pull requests. This is the number that ends up in board slides. It is also, as the researchers noted, a measure of motion rather than progress - a proxy that breaks down entirely when you are not controlling for what is in those pull requests, how long they take to review, and what happens after they merge.

Velocity metrics tracked without outcome metrics will systematically mislead you. The organisation looking at PR volume and seeing it climb is not looking at review cycle time, incident rate, or junior engineer progression. By the time those lagging indicators surface, the cost of reversing course is significantly higher.

The metrics that actually tell you something in 2025 and 2026:

Review cycle time - not whether it is short (fast review is not always good review) but whether it is appropriate and stable. A review cycle time that is climbing tells you your review capacity has not kept up with output volume.

Change failure rate - the proportion of deployments that cause production incidents. This is the DORA metric with the clearest signal. If it is climbing while deployment frequency is also climbing, you are shipping faster into more failures.

Defect rate per PR - bugs found in QA or production, attributed back to the PR that introduced them. Harder to track than velocity, worth the effort.

Review hours per senior engineer per week - if this number is climbing, you have a sustainability problem. Senior engineers doing more review means senior engineers doing less of everything else, and it means the review load is heading toward burnout.

None of these are the numbers vendors will show you in a demo. All of them are the numbers you need.

What this means for your adoption plan

If AI amplifies what you already have, then before you scale your AI adoption, it is worth being honest about what you have.

The 2025 DORA report identified seven capabilities that consistently magnify the positive impact of AI adoption. These are not AI-specific capabilities - they are organisational and engineering practices that the presence of AI makes more consequential:

• 1 A clear organisational strategy - explicit policies and guidelines for AI tool adoption
• 2 A healthy data ecosystem - reliable, well-structured internal information
• 3 Accessible internal knowledge - quality documentation and searchable repositories
• 4 Foundational engineering practices - mature version control, code review, development standards
• 5 User-centric development - focus on user outcomes rather than purely technical outputs
• 6 Platform engineering - standardised environments, deployment pipelines, infrastructure services
• 7 Small batch working - incremental changes that improve review quality and reduce deployment risk

If your organisation has most of these, AI adoption will likely accelerate genuine capability. If it has few of them, the most valuable investment is not better AI tooling - it is addressing the missing foundations first.

This is not a comfortable message when you are under pressure to show AI adoption progress. But it is the honest one, and engineering leaders who prioritise the appearance of adoption over the conditions for it to work are setting themselves up for the outcome the data describes: more code, more failures, more burned-out reviewers, less trust in the programme.

“Adopting AI faster than you understand it is not progress.”

- The AI-Ready Engineering Team

The teams that will look back on this period as the one where they built something durable are the ones making deliberate choices now about their engineering culture - not just their engineering tools.

Research cited in this article

This article draws on findings from the 2025 DORA Report, DX’s Q4 2025 AI Engineering Impact Report (covering 135,000+ developers), Faros.ai’s AI Productivity Paradox Report (1,255 teams, 10,000+ developers), Cortex’s 2026 Engineering Benchmark Report, McKinsey’s State of AI 2025, and Harvard Business Review’s Overcoming the Organisational Barriers to AI Adoption. The frameworks for measuring what matters and building the right conditions for adoption are developed fully in The AI-Ready Engineering Team.

Russell Ward is an engineering leader and CTO with over 20 years’ experience building and scaling software engineering teams globally. He writes about engineering leadership, AI adoption, and distributed teams. Find him on LinkedIn.