7 Impacts of AI Adoption on Developer Productivity and What to Do About It

Faros recently published a report on the impacts of AI adoption across the software development lifecycle, backed by telemetry data captured over two years from more than 22,000 developers across 4,000 organizations that opted into its platform.

They call the report “The Acceleration Whiplash” because the data raises concerning questions about the real impact AI-generated code is having on production systems. The promised gains in productivity and efficiency appear to be coming back as a whiplash later in the delivery process.

The report found that 80% of developers use AI daily, so adoption is commonplace in its dataset. However, some of the core findings are:

• Code throughput is increasing across several dimensions
• Code churn is surprisingly high
• PRs are getting larger and more complex
• Bugs and production incidents are increasing
• Developers are doing an unprecedented amount of work in parallel
• Review queues are growing
• Overall workflow speed is decreasing

The data shows strong associations between AI adoption and these delivery patterns, although it does not necessarily prove that AI alone caused every change. Team structure, process maturity and the types of work being performed may also affect the results.

Still, several findings are extraordinary. I am writing this article to propagate them, give my thoughts and propose some ideas for mitigating the risks.

The full report requires submitting a form:

The Acceleration Whiplash

Seven impacts of AI adoption

Below, I summarize the most interesting findings from the report and give my own interpretation of what they may mean for engineering teams.

1. Developers are working more in parallel

AI tools can spawn agents to work on individual tasks, loop and even create sub-agents that behave like mini teams. While developers wait for the first squad to finish Task 1, they can already prompt another squad to work on Task 2.

Do this a couple of times and it seems that you are making effective use of your time, right?

The report found a 67.4% increase in PR contexts handled per day and a 17.7% increase in daily tasks, showing that developers are working across more concurrent streams. However, 13.8% more work is restarted, while 26% more tasks in flight stall.

We can infer from this that developers may be struggling with context switching, to the point that some work is paused while other work is discarded altogether.

Context switching increases the cognitive load on developers. Each time they switch contexts, it takes a while to remember what they were doing, reconstruct the relevant information and decide what to do next. If they jump from one agent thread to another, they need to regain that context repeatedly.

This seems to align with the anecdotal reports of developers saying they feel more tired after work once they start orchestrating several AI tasks in parallel.

Here is the interesting bit: if engineers are losing context due to switching, how will they properly validate the generated code before publishing a PR?

The incentive may be to hand-wave that validation and let the PR process catch inconsistencies generated by the agents. We will see signs of this effect in other metrics.

2. Code throughput is increasing

More code is being created than ever. The report found an increase of:

• 33.7% in tasks per developer
• 66.2% in epics completed per developer
• 16.2% in PR merges per developer
• 210% in tasks completed per team with PRs

The fact is that developers are pushing more code. This cannot be denied.

For engineering leadership, the most impressive metric may be the 66.2% increase in epics completed per developer. The increase in tasks completed with PRs is also telling, because code production remains the primary use case targeted by providers of agentic AI tools.

However, producing and merging more code does not necessarily mean that more value is reaching production. The next metrics show why throughput alone is an incomplete measure of productivity.

3. Deployments are decreasing while code churn is rising

Despite the increase in code throughput, deployments per week decreased by 11.7%.

This may mean teams are becoming more careful and spending longer in QA. It may also indicate that failures during review or acceptance are delaying deployments.

More strikingly, code churn increased by 861%. In other words, substantially more recently produced code is being changed or deleted.

The authors propose three possible reasons:

• Generated code is accepted but proves insufficient, so the changes are reverted
• Developers are using their additional capacity to address large refactoring tasks that had been sitting in the backlog
• AI is accelerating the pace of code improvement, allowing developers to return to and redo implementations they were not satisfied with

The meaning of this churn depends on the context surrounding the deletions. If large deletions are accompanied by large additions, that may indicate refactoring. Large deletions without replacement may indicate reverted or abandoned features.

The study did not provide this level of granularity, but teams can measure it by examining their own commit and PR history.

The key point is that, because code has become cheaper to produce, developers may be more willing to create code that will never reach production. I would add two hypotheses that could help explain the increase:

• AI tools are being used to create POCs, prototypes or initial implementations that are later reworked with a proper design, causing the initial version to be discarded
• AI-generated code is often verbose, accepted and merged, then heavily cleaned up in a later iteration, reflecting the Hackathon Mentality I previously wrote about

4. Code changes are becoming more complex

As the volume of submitted code increases, so does the size and breadth of the changes. Some indicators of code complexity include:

• PR size: the larger the PR, the more logic reviewers must understand and the more opportunities there are for defects
• Number of files touched: this may indicate organizational complexity because more areas of the system must be changed to implement a feature
• Repositories changed: changes across multiple repositories may indicate broader domain and system relationships

The last point needs an asterisk. Many products already use separate repositories for the backend, frontend, infrastructure configuration and other components. An increase in repositories touched may simply mean developers can now modify several parts of a product within a single agent session.

Now to the numbers:

• 51.3% increase in average PR size
• 59.7% increase in the average number of files touched per PR
• 149.9% increase in files touched per developer per month
• 11.7% increase in repositories touched per developer per month

AI tends to generate verbose and overly defensive code, which increases the number of lines in a PR and, consequently, the amount of logic reviewers must evaluate. More things can break when more logic is involved.

The roughly 150% increase in files touched per developer may be a sign of engineering empowerment. Developers may now feel more comfortable modifying files they would not usually touch.

Alternatively, coupled with the roughly 60% increase in files touched per PR, it may indicate that subsequent iterations are adding hacks and shortcuts to the codebase while disregarding its design principles. That makes future features require changes across even more files.

This is the effect I discussed in this article. If my concerns are correct, the average number of files required for each change will continue to grow.

5. Code review is becoming more demanding

Another concerning finding is the quality and complexity of the code being submitted for review. The report found a 25% increase in comments per PR and a 22% increase in average comment length.

PR comments and open time can indicate poor code quality, higher complexity or both. Senior engineers responsible for protecting the quality of the system must spend more time understanding the changes and requesting corrections. This increases both the number of review threads and the time PRs remain open.

It is important to note that some PR reviews are also performed by AI agents and, as we know, they tend to be verbose. This may partially skew the average comment-length metric.

On the bright side, more comments may indicate that generated code is under heavier scrutiny. That is good for quality, even though it may create a tight bottleneck in the delivery process.

The report also found that 31.3% more PRs were merged without review.

There is an important caveat here. Some of these may be simple PRs with only a few lines of code that peers approve without leaving comments. That can be reasonable when the risk is low.

The worrying alternative is that reviewers are approving PRs with a quick LGTM to avoid slowing down the pipeline, allowing defects to slide through. The production metrics make this possibility difficult to ignore, even though they do not prove exactly how individual reviews were performed.

6. More bugs and incidents are reaching production

The production data is particularly concerning. The report found an increase of:

• 242.7% in incidents per PR
• 57.9% in monthly incidents
• 54% in bugs per developer
• 28.7% in bugs per PR
• 12.6% in reopened Jira tickets

Think about it: throughput is increasing, but incidents are also increasing on a per-PR basis. This means the rise in production problems cannot be explained only by teams shipping a larger number of PRs.

Reopened Jira tickets suggest that incomplete or incorrect features are being marked as finished and later require rework to address missing pieces.

The increase in bugs per developer and per PR is also concerning. It suggests that the review and validation process is not absorbing the additional volume of generated code effectively.

One possible explanation is that there is not enough review. Another is that review has become a rubber-stamp process in which peers approve changes without the necessary due diligence. A third possibility is that the changes have become too broad for reviewers to fully evaluate within the available time.

In every case, senior engineers must absorb the pressure created by a high volume of generated code.

7. Overall workflow speed is decreasing

At first, all these metrics may appear to point to productivity gains. Throughput is up, more PRs are being merged and developers are doing more work in parallel. Everything seems to be trending upwards.

Unfortunately, the end-to-end delivery data says otherwise.

Tasks tracked in Jira and similar systems are moving more slowly through the change pipeline. The report found a 225% increase in the time tasks spend in progress. It also found:

• 81.8% increase in the average time tasks remain in TODO
• 156.6% increase in the median time until first review
• 199.6% increase in average PR review time
• 480.4% increase in average time from code commit to production

With more work being done through parallel agents, it seems likely that more tickets are also being created. Even with the additional parallelism, the average time tickets spend in TODO increased by 81.8%.

The report does not mention the volume of ticket creation, but I suspect this is part of the issue. More work may be entering the system than the team can actually complete.

The median time until first review is another important metric. As the authors point out, it may reflect the amount of review work being handled by senior engineers.

They have more code to review, so a queue of PRs forms, increasing the delay before the first review. The 199.6% increase in average review time supports this hypothesis. Once a review begins, the senior engineer must spend more cognitive effort evaluating the increased complexity and breadth of the changes, then formulate useful feedback.

This PR review drag creates two consequences:

1. It slows the lead time from starting a task to finishing it, contributing to the 480.4% increase from commit to production.
2. It creates pressure to rubber-stamp PRs, which is consistent with the increase in unreviewed changes and production incidents discussed earlier.

Key takeaways

• Developers are doing more work in parallel with agents, touching more code and more repositories
• Code throughput is increasing, but deployment frequency is decreasing
• Changes are becoming larger, broader and more difficult to review
• Senior engineers and code owners are being overwhelmed by the review workload
• More bugs and incidents are reaching production, creating additional rework
• PRs touching more code and repositories increase the potential blast radius of each change
• Overall workflow speed is decreasing despite the increase in code production

What engineering teams should do

AI adoption should not be evaluated only by how much code developers produce. Teams also need to measure whether that code moves through review, deployment and production without creating additional rework.

My recommendations are:

Keep PRs small and focused

Small PRs have been a software engineering best practice for decades. They are easier to understand, review, test and troubleshoot.

This becomes even more important when agents are producing the changes. Give agents narrow tasks with clear boundaries instead of asking them to implement large features in a single pass.

Teams can enforce limits on PR size, files touched and unrelated changes. When a task requires a large implementation, break it into a sequence of independently reviewable changes.

Agents thrive when the scope is constrained. Reviewers do too.

Enforce a style guide and code quality standards

Agents bring their own assumptions about naming, architecture, error handling, abstractions and code organization. Without clear guidance, their output may be technically valid while remaining inconsistent with the rest of the codebase.

Take the time to document the standards agents and engineers must follow. This may include things like:

• Naming and formatting conventions
• Architectural boundaries
• Error-handling practices
• Testing expectations
• Rules for introducing dependencies
• Preferred patterns and known anti-patterns

These standards should be available in the repository and included in the context provided to coding agents.

Automated checks should enforce everything that can be verified mechanically. Human reviewers can then focus on design, maintainability and business correctness instead of repeatedly correcting style issues.

Review AI-generated changes before opening a PR

Opening a PR should not be the first time an engineer properly reads the generated code.

Engineers should review, run and validate every change before asking someone else to review it. They should understand the implementation, remove unnecessary abstractions, verify edge cases and confirm that the change follows the codebase’s existing design.

The engineer publishing the PR remains responsible for the code, regardless of whether it was written manually or generated by an agent.

This prevents senior engineers from becoming the first line of quality control for large amounts of unchecked code.

Reduce unnecessary parallel work

Running several agents at the same time can feel productive because many tasks appear to be moving. However, every additional thread increases the amount of context the engineer must retain.

Limit the number of concurrent tasks according to their complexity. Engineers should finish, validate or deliberately pause one unit of work before starting too many others.

Teams should also make paused work visible. A growing number of stalled branches, abandoned PRs and restarted tickets may indicate that parallelism is creating more unfinished work rather than more completed work.

The goal is not to maximize the number of active agents. It is to maximize the amount of valuable work that reaches production.

Protect the review capacity of senior engineers

If AI increases code production without increasing review capacity, senior engineers become the bottleneck.

Teams should reserve senior review for changes that carry meaningful architectural, security or operational risk. Low-risk changes can use lighter review paths when automated tests, static analysis and ownership rules provide enough confidence.

PRs should also include the information reviewers need:

• The problem being solved
• The chosen approach
• Important trade-offs
• Areas of risk
• Evidence that the change was tested
• Whether and how AI was used

This reduces the time reviewers spend reconstructing the author’s reasoning from the diff.

Track rework and delivery metrics

More commits, PRs and completed tickets do not necessarily mean the team is delivering more value.

Track metrics that reveal whether AI-generated work is moving through the complete delivery system:

• PR size and files touched
• Time until first review
• Total review time
• Code churn
• Reopened tickets
• Work restarted or abandoned
• Deployment frequency
• Change failure rate
• Incidents associated with recent changes

These metrics should be evaluated together. A rise in throughput accompanied by slower reviews, lower deployment frequency and more incidents is not a productivity improvement.

Track the metrics over time and compare them across teams, repositories and types of work. This can help identify where AI is useful and where it is creating additional friction.

Make AI-generated changes visible

Teams should know how much of their code is being created or substantially modified by agents.

Where possible, identify agent-generated work through commit metadata, PR labels or development tooling. This does not need to be used to punish engineers or reject AI usage. It provides the context needed to evaluate its actual impact.

Review these changes monthly or quarterly and compare them with churn, review time, reopened work and production incidents.

Without this visibility, teams may know that AI adoption is increasing without knowing whether it is improving the system.

Do not delegate trust to agents

Code review may become a bottleneck, but blindly approving more changes is not a sustainable way to make the pipeline faster.

Trust should be based on the risk of the change, the quality of the validation and the maturity of the surrounding systems.

High-impact changes should continue to require experienced human review. This includes changes involving architecture, authentication, billing, data integrity, security and critical production paths.

Lower-impact changes can receive more automated treatment when the team has strong tests, clear ownership, reliable CI and well-defined quality standards.

AI agents can produce code, tests and review comments, but they should not be the final authority on whether a change is safe to ship.

Conclusion

AI agents can increase the amount of code an engineering team produces, but code production is only one part of software delivery. If review queues grow, rework increases and more incidents reach production, higher output does not translate into higher productivity.

Codebases are organic systems built to evolve. If each change becomes more complex and requires touching more parts of the system, engineers and agents must retain more information in their context. This can eventually trigger problems such as context rot, as discussed in this article.

The two biggest risks are that senior engineers become overworked by the volume of generated code and that teams respond by weakening their review standards. Senior engineers must separate the wheat from the chaff, which increases review time and, paradoxically, makes the entire development workflow slower.

Engineering leaders should evaluate AI adoption across the entire delivery system, including PR size, review time, code churn, reopened work, deployment frequency and production incidents.

References

• The Acceleration Whiplash
• The Hackathon Mentality
• Single Generation vs. Organic Generation