AI Boosts Code Merging, Not Delivery

Most companies believe that if their developers use AI, the team delivers more. The reality is that each person produces more code, but the company doesn’t deliver more software. This discrepancy is starting to shape hiring decisions that can become costly later on.

Will AI allow for fewer developers by 2026?

Not yet, at least not at the team level. A report by Faros AI (2025), analyzing data from over 10,000 developers across 1,255 teams, found that those who heavily adopt AI merge 98% more pull requests, but there was no significant correlation between this adoption and improvements in company-wide delivery.

A pull request (PR) is a package of code changes a developer proposes, which another reviews before integrating it into the product. More PRs don’t equate to more functioning products in the customer’s hands.

What do the 2025-2026 data say about productivity with AI?

The numbers aren’t as contradictory as they seem. They measure different things.

Source (year)	What was measured	Result
Faros AI (2025)	10,000+ developers, 1,255 teams	+21% tasks completed, +98% PRs merged, +91% review time
METR (2025)	16 senior developers, 246 real tasks	19% slower with AI, though they believed they were 20% faster
DORA / Google Cloud (2025)	~5,000 professionals	90% adoption; throughput increases but so does instability
Stack Overflow (2025)	Global developer survey	84% use AI; 46% distrust the accuracy of its output
CoderPad (2026)	650+ developers and hiring leaders	54% would lose 10% or more productivity without AI

Throughput is the volume of changes a team manages to put into production. DORA summarizes it well: AI amplifies what already exists. An organized team accelerates. A disorganized team produces chaos faster.

Why doesn’t individual productivity translate to delivery?

Because the bottleneck has shifted. Previously, the limit was how much code a person could write. Now, the limit is how much code the team can review, test, and integrate.

Faros clearly shows this: with high AI adoption, the average size of each PR grows by 154%, review time increases by 91%, and bugs per developer rise by 9%. More is written, but someone has to read all that, and that someone is often the most expensive senior on the team.

Adding to this is the issue of “almost correct” code. According to Stack Overflow (2025), 66% of developers deal with “almost correct” AI solutions: they seem fine but fail in a detail. Finding that detail takes time, which doesn’t appear on any productivity dashboard.

Why is the perception of speed a planning risk?

The most uncomfortable data comes from METR (2025). Developers predicted AI would make them 24% faster. Upon completion, they estimated they had been 20% faster. Measurement showed they were 19% slower.

METR clarified in February 2026 that subsequent studies are less conclusive and that tools have improved. But the perception gap remains the point: developers feel they’re flying, managers report it, and headcount planning is based on that feeling.

This is already happening. According to Chief Executive (January 2026), 31% of companies use AI to reduce headcount. An Orgvue survey (2025) of 1,163 executives found that 55% of those who laid off staff due to AI admitted they made a mistake.

What profile is best for a team already using AI?

If the scarce resource is judgment, then hire for judgment. In over 500 processes we’ve managed in LATAM, we see that the profiles that perform best in AI-equipped teams share three traits:

1. They review better than they write. They quickly detect which part of the generated code doesn’t fit the existing architecture.
2. They break work into small pieces. A small PR is reviewed in minutes; a large one generated in one go is reviewed poorly or not at all.
3. They know when not to use the tool. In legacy code or with very specific business rules, sometimes writing by hand is faster.

This changes the interview process. Evaluating someone solely by how much they solve in 45 minutes rewards exactly what AI already does. Asking them to review a PR with subtle errors says much more about how they’ll perform on your team.

How to measure if AI has truly changed the team’s capacity?

Measuring PRs, lines of code, or closed tickets is measuring activity. To know if the team delivers more, it’s better to look at full-flow indicators:

• Lead time: how long a change takes from start to production.
• Review time: how many hours a PR waits before someone approves it.
• Change failure rate: what percentage of deployed changes cause an incident or need to be reverted.
• Rework: how much of the new code is rewritten in the following weeks.

Timing matters. What we see in practice is that the real picture emerges around the third month, when the initial enthusiasm fades and the review backlog starts to weigh. Deciding headcount based on data from the first few weeks is deciding with the most optimistic part of the curve.

The right question isn’t how many people are redundant

AI does change the equation for an engineering team. What hasn’t changed is that software is delivered by a system, not a sum of people writing quickly.

The companies that will come out on top won’t be the ones that cut first. They will be the ones that understood where the flow got stuck and hired to unblock it.