| Engineering Metric | Change Reported by Faros, Q2 2026 |
|---|---|
| Tasks completed per developer | +33.7% |
| Epics completed per developer | +66.2% |
| Bugs per developer | +54% |
| Incidents relative to merged pull requests | +242.7% |
| Code churn | +861% |
| Pull requests merged without review | +31.3% |
---
## Six Months Later, the Engineering Bottleneck Is Moving
Faros's newer Q3 2026 report, The Speed Trap, provides an important update to the original findings. The follow-up examines engineering telemetry as organizations deepen their AI adoption. Its results are particularly interesting because they don't show every metric continuing to deteriorate.
Some outcomes improved. Deployment frequency recovered, and the extreme code churn observed during the earlier adoption period declined substantially.
The incidents-to-pull-requests metric also improved. The original report identified a 242.7% increase, while the newer analysis reported a 14.5% increase within its own comparison.
The reports use different analytical comparisons, so these figures shouldn't be treated as a direct before-and-after measurement. Still, the newer findings suggest that some of the difficulties associated with AI adoption may ease as organizations adjust their workflows.
Other metrics tell a different story.
| Engineering Metric | Q3 2026 Faros Finding |
|---|---|
| Average pull request size | +71.8% |
| Pull requests merged without review | +76.3% |
| Time spent in QA | +300.6% |
| Work restarts | +66.7% |
| Monthly production incidents | +125.4% |
| Incidents relative to merged pull requests | +14.5% |
---
## Why AI Code Review Is Becoming an Engineering Bottleneck
Code review is one area where the changing distribution of engineering work becomes visible.
When a developer writes an implementation manually, much of the reasoning behind it develops alongside the code. Requirements are explored, design decisions are made, and potential problems are considered during implementation.
With AI coding agents, substantial changes can be generated before the developer has examined every decision involved. That changes the review process.
A reviewer may need to reconstruct the reasoning behind an implementation rather than simply evaluate changes made by someone who can explain each decision.
Why was a particular dependency introduced? Does the implementation preserve existing behavior? What assumptions does it make about data consistency or failure recovery?
These questions become more difficult as the size of a change increases.
Faros's Q3 findings show average pull request size increasing 71.8%. Larger changes can require more time to understand, particularly when they affect multiple components or introduce unfamiliar patterns.
The challenge isn't necessarily that reviewers lack the technical ability to evaluate the code. It's that the amount of work arriving for review may exceed the time available to evaluate it thoroughly. That creates an incentive to reduce review depth, delay feedback, or rely more heavily on automated checks.
The newer Faros research also offers a potential way forward. Teams making extensive use of agentic code review showed improvements in certain downstream metrics, including faster initial reviews and lower change failure rates. Those findings are correlational, so they don't establish that agentic review alone produced the improvements. But they suggest that AI-assisted verification may help organizations manage the increased volume of changes.
The important question is how that verification is structured. A routine documentation update doesn't require the same level of scrutiny as a change to transaction processing or authentication logic. Organizations can use automated checks for predictable issues while directing deeper review toward changes with greater operational consequences. That requires clear standards for review scope, automated validation, and escalation.
Simply adding another AI reviewer to every pull request won't necessarily solve the problem. Teams need to understand which checks provide useful evidence and which decisions still require deeper investigation.
---
## Why Engineering Judgment Matters More as AI Adoption Increases
The review challenges identified by Faros point toward a broader issue: understanding a change requires understanding the system it affects.
Consider a Go service that communicates with several downstream dependencies. An AI agent generates a new endpoint, adds request handling, implements database operations, and produces unit tests. Everything compiles, and the tests pass. But the implementation introduces retries without accounting for the downstream service's capacity.
During normal operation, the behavior appears correct. When the dependency begins responding slowly, concurrent requests trigger additional retries, increasing load on an already struggling service.
The failure isn't necessarily visible in the individual functions. It emerges from the interaction between components.
A reviewer needs to understand the service's timeout policies, concurrency behavior, and failure recovery strategy to recognize the risk. This is an example of why validation becomes more complex as AI-assisted development expands. The code can satisfy the immediate task while creating behavior that conflicts with the larger system's operational requirements.
The engineering challenge is identifying those conflicts before deployment. That doesn't mean every AI-generated change requires an extensive architectural review. It means teams need a reliable way to identify changes whose consequences extend beyond the local implementation.
In distributed systems, those consequences can involve resource contention, cascading failures, inconsistent state, or unexpected interactions between services. The value of experienced engineering expertise lies in recognizing which assumptions need to be tested and which failure modes deserve attention.
For organizations increasing their use of AI coding agents, this expertise becomes especially important when establishing review requirements, designing integration tests, and deciding which changes can safely move through automated workflows.
---
## How Engineering Leaders Can Turn AI Productivity Into Reliable Software
The Faros and New Relic findings give engineering leaders several practical areas to investigate.
The goal isn't to reduce AI adoption or introduce unnecessary approval processes. It's to identify where additional development output is creating pressure and adjust the workflow accordingly.
### 1. Measure Engineering Outcomes, Not Just Development Activity
Start by comparing delivery activity with operational results.
If completed tasks and merged pull requests are increasing, examine whether production incidents, work restarts, or review delays are changing at the same time.
Avoid interpreting a single metric in isolation.
For example, a higher code churn rate may reflect productive refactoring or repeated corrections. A lower incident-to-pull-request ratio may coexist with a higher total number of incidents.
The useful question is whether the organization is delivering more functionality without a disproportionate increase in the effort required to maintain it. Tracking throughput alongside change failure rate, incident volume, review latency, and time to restore service can help reveal where the additional work is accumulating.
### 2. Strengthen Validation Before Problems Reach Production
Verification should begin before an implementation reaches the final review stage.
For changes involving external dependencies, concurrency, data integrity, or security-sensitive functionality, teams should establish the expected behavior and failure conditions before generating code. Those requirements can inform automated tests and acceptance criteria.
Integration tests should verify how components interact, while performance and failure testing can expose behavior that ordinary unit tests miss.
Production observability provides another important layer.
New Relic found that 96% of surveyed technology leaders considered observability very or extremely important when working with AI-generated code. Logs, metrics, and traces help engineers investigate behavior that wasn't anticipated during development and determine whether a change is operating as expected.
### 3. Keep Changes Understandable and Reviewable
The increase in average pull request size identified by Faros deserves attention.
Larger changes aren't automatically lower quality, but they can make review more difficult and increase the amount of context needed to understand an implementation. Teams can address this by defining expectations around pull request scope.
Where practical, implementations should be divided into changes that can be reviewed and validated independently. This makes it easier to identify the source of a problem, evaluate dependencies, and understand what a change introduces.
The objective isn't to impose an arbitrary limit on every pull request. It's to prevent implementation speed from creating changes that are unnecessarily difficult to evaluate.
### 4. Use AI to Improve Review, Not Just Code Generation
AI-assisted review offers an opportunity to reduce repetitive verification work. Automated reviewers can identify common issues, check changes against established standards, and flag areas that may require closer examination.
The Q3 Faros findings suggest that teams using agentic review extensively may experience improvements in some delivery and quality metrics. Organizations should evaluate these tools based on the issues they catch, the false positives they generate, and whether they improve review effectiveness.
For example, an automated reviewer that repeatedly flags formatting issues already handled by a linter may add little value. A reviewer that identifies a missing error path or highlights a change affecting a critical interface may be more useful.
The goal is to make review more effective, not simply automate approval.
### 5. Preserve Engineering Expertise Where It Creates the Most Value
The increase in QA time and work restarts suggests that engineering organizations should examine how their teams are allocating technical expertise.
If experienced engineers spend most of their time resolving integration problems or investigating incidents, less capacity remains for design work and preventive improvements. That can create a cycle in which teams respond to problems without addressing the conditions producing them.
Engineering leaders should identify where specialized expertise is becoming a bottleneck. That might involve reviewing changes to critical services, improving test infrastructure, resolving architectural inconsistencies, or helping teams establish safer deployment practices.
The answer will vary by organization.
What matters is understanding where engineering capacity is constrained rather than assuming that faster implementation automatically increases the team's ability to deliver.
---
## Scaling Engineering Capability Alongside AI
The research highlights a capacity planning challenge for organizations adopting AI-assisted development. Implementation throughput can increase without a corresponding improvement in the processes responsible for integrating and operating that work. For some teams, the immediate need may be better automation or testing infrastructure. Others may need to address architectural complexity, review practices, or gaps in specialized engineering expertise.
At Ardan Labs, we help organizations address these challenges through engineering consulting, AI implementation, and experienced engineers who integrate directly into existing teams.
Our Staff Augmentation services provide engineers with production experience in Go, Rust, Kubernetes, and distributed systems. They work alongside internal teams to support development, address technical challenges, and help maintain the standards required for reliable software.
For organizations increasing their use of AI coding tools, that expertise can help strengthen the engineering processes surrounding implementation, particularly where existing teams are managing growing workloads or complex production environments.
The right solution depends on where the constraint exists.
Adding development capacity won't resolve an ineffective review process on its own. Likewise, stronger automation may not address an underlying architectural problem.
Understanding that distinction is an important part of scaling engineering organizations effectively.
---
## The Next AI Productivity Advantage Is Reliable Engineering
The Faros research shows that the effects of AI adoption are changing as organizations gain experience.
Some of the initial quality concerns appear to be easing. Deployment performance is recovering, and certain incident metrics have improved. At the same time, larger pull requests, longer QA cycles, and higher total incident volumes suggest that engineering teams are still adapting to the additional output.
That makes the next phase of AI adoption less about proving that coding tools can increase productivity and more about understanding how that productivity affects the entire development lifecycle.
For engineering leaders, the opportunity is to identify where additional work is accumulating and address those constraints before they become persistent operational problems.
The next meaningful improvement in AI-assisted development may come from reducing the effort between generating a change and confidently operating it in production.
That's where the latest research suggests engineering organizations still have substantial room to improve.
---
Is your engineering team keeping pace with AI-assisted development?
Talk with Ardan Labs about strengthening your engineering capabilities, improving production reliability, and scaling development with experienced engineers who understand the systems behind the code.
Research has found associations between higher AI adoption and increased defect and incident metrics, but it hasn't established direct causation. Faros AI's Q2 2026 report found bugs per developer increased 54% and incidents relative to merged pull requests increased 242.7%. Its Q3 findings showed improvement in the incident ratio within a different analytical comparison, although monthly incident volume remained elevated.
An implementation can satisfy its immediate requirements while making incorrect assumptions about the surrounding system. Problems involving concurrency, external dependencies, resource management, and failure recovery may not appear during basic testing. Integration testing, operational context, and appropriate review practices help identify these risks before deployment.
AI coding tools can increase the volume and size of changes requiring verification. Faros AI's Q3 2026 research found average pull request size increased 71.8%, time spent in QA increased 300.6%, and pull requests merged without review increased 76.3% relative to the study's comparison baseline. These findings suggest that review and QA processes may need to adapt as implementation throughput increases.
Teams should evaluate development throughput alongside operational metrics such as change failure rate, incident volume, review latency, work restarts, and time to restore service. Comparing these measurements helps identify whether AI adoption is improving overall delivery or shifting additional effort into verification and maintenance.
Organizations can establish clear acceptance criteria, strengthen integration and failure testing, keep changes reviewable, and use automated verification where appropriate. Production observability and risk-based review practices also help teams evaluate changes based on their potential impact rather than applying the same level of scrutiny to every implementation.