AI-generated Code Security Risks: Why Incidents Per Pull Request Have Increased by 23.5%

Your teams are shipping faster than ever. Pull request volume is up. Deployment frequency is climbing. On paper, AI-assisted development is working exactly as promised.

So why are your production systems getting less stable?

This is the problem most engineering leaders are facing right now. The AI tools that actually played a key role in increasing the output potential of individual developers are now quietly eroding the reliability of the system. This does not happen because of flaws in the tools but mainly because of the engineering systems around them that have not kept pace.

As more code is being written by developers, production systems are becoming unstable. Incidents per pull request have gone up by 23.5 percent. The failure rates on changes are on the rise with an increase in incidents after AI adoption.

This contradiction reveals what many engineering leaders are beginning to call the Productivity Paradox of AI-driven development: the same tools that increase coding velocity can also introduce instability at scale if the underlying engineering systems are not prepared to handle the surge.

The issue is not the AI itself. The issue is that most businesses optimize only the top of the funnel, i.e., the coding interface. They do not focus on strengthening the rest of the development pipeline. Your primary goal should be to minimize code quality issues that come up because of AI.

What Does the Benchmark Data Reveal About AI Adoption?

To understand what is happening, it helps to look beyond anecdotes and examine the broader metrics emerging across engineering businesses. The data collected between Q3 2024 and Q4 2025 reveals a clear divergence between development output and system reliability.

At first glance, these numbers might appear mixed. Developers are clearly producing more output, and pull requests are slightly more likely to be merged successfully. But when viewed together, the data tells a very different story.

Developers are writing and submitting more code, yet the rate at which changes fail in production has increased dramatically. The answer to the question of why AI pull requests cause more bugs lies in the even cycle time. This is the total time it takes for a change to move from idea to production, which has increased.

This is the central paradox of modern AI-driven engineering. Individual developers are becoming faster, but the overall system is becoming slower and more fragile.

Why Do AI Pull Requests Cause More Bugs Despite Higher PR Success Rates?

One of the most deceptive metrics in this shift is the small 2% increase in PR success rate.

For many engineering leaders, this number appears encouraging. It suggests that code is passing through review pipelines more smoothly and that developers are collaborating efficiently. However, the increase in PR success rate is often a false signal created by AI-assisted tooling.

AI coders are also good at generating syntactically correct code. They do these automatically, correcting formatting errors, obeying laid-out rules, and creating test cases that pass automated tests. Subsequently, this code has a higher chance of meeting CI pipelines. Therefore, they can pass the review process.

However, a syntactically correct system is not necessarily correct. The failures that show up in production are not just syntax errors:

• Architectural incompatibilities that only surface at scale
• Ignored edge cases that fall outside the AI’s training context
• Unreleased dependencies between services or data layers
• Subtle logic defects that pass unit tests but fall under real user behavior

This means companies are combining code that seems right to an automated system but that performs erratically during production. The result is a pipeline that moves faster while quietly accumulating risk.

For engineering leaders and CTOs, the question is not whether AI code passes the review. It is whether your review process is designed to detect and identify the failures that AI code introduces to the system.

The Real Reason AI-generated Code Fails in Production

Another surprising metric in the benchmark data is the 9% increase in cycle time.

If AI tools make developers faster, why are changes taking longer to reach completion?

The answer lies in what many engineering teams now experience as a quality vacuum.

The time saved during code generation is being consumed elsewhere in the development lifecycle. Instead of spending hours writing code, engineers now spend that time debugging failed deployments, analyzing unexpected system behavior, and resolving production incidents caused by flawed changes.

In effect, the effort has simply shifted downstream. This problem becomes even more pronounced during incident response. Developers are increasingly asked to diagnose failures in code that they did not fully design or deeply understand. When a component is generated through prompts rather than built incrementally, the developer lacks the mental model needed to quickly reason about edge cases.

As a result, Mean Time to Recovery (MTTR) begins to increase. Production incidents take longer to diagnose and resolve because engineers are navigating unfamiliar code paths.

Speed at the coding stage is being offset by complexity during debugging.

How Do AI Development Quality Issues Still Slip Through Shift-Left Testing?

For more than a decade, many businesses embraced the philosophy of “Shift Left.” The idea was simple: push testing earlier into the development process and encourage developers to take full ownership of quality.

In theory, this approach promised faster releases and lower testing overhead. In practice, it has proven far more complicated. Research across large engineering businesses has revealed that developer-owned testing frequently fails due to three systemic factors.

Cognitive Overload

The current software development is already a cognitively challenging process. The engineers need to balance the details of implementation, distributed architecture, cloud infrastructure, and the delivery schedule. Full testing is another source of complications. Testing needs to be done properly. This should include edge cases, environmental variations, and dependencies between integration and failure cases that need evaluation.

When developers are under pressure to prioritize these two responsibilities, testing is pushed aside by feature shipping. When the pressure is not high enough, the coverage of tests would be incomplete, and minor flaws would be missed.

Misaligned Incentives

The reward structures that are engineered are normally focused on feature delivery. The capacity to deliver palpable improvements to the customers usually forms the basis of performance reviews, promotions, and leadership recognition.

On the other hand, testing is very much invisible. The developer who delays a release to write defensive test cases rarely receives recognition equal to the engineer who launches a new feature.

This imbalance naturally pushes developers to prioritize output over validation.

The Happy Path Bias

Developers are builders. Their mental model focuses on how a system should behave when everything works correctly. Quality engineers approach the problem differently. Their job is to find the scenarios where the system fails.

This difference in mindset matters. Asking developers to thoroughly break their own creations creates a natural conflict of perspective. In some cases, businesses eliminate committed positions of quality assurance that are not substituted by an organized approach to quality. A vacuum emerges in which no one is mandated to test the assumptions systematically.

What Are the Hidden Risks of AI-generated Code in CI/CD Pipelines?

As AI accelerates code generation, weaknesses in CI/CD pipelines are becoming more visible.

One of the most damaging issues is the widespread presence of flaky tests. Flaky tests fail randomly without corresponding defects in the codebase.

In an environment where code volume increases, flaky tests create enormous friction. This eventually leads to:

• Developers quickly lose trust in pipeline results and begin rerunning the tests till they pass.
• The “rerun until green” culture normalizes the process of ignoring failures rather than investigating them.
• Pipelines become unreliable, they stop functioning as safety mechanisms, and start behaving like obstacles.

In the long run, this culture erodes engineering discipline and allows defects to slip through unnoticed. When this happens, CI/CD no longer remains a quality mechanism. It becomes a compliance checkbox, and defects pass through it reliably. For engineering leaders, the question is whether your pipelines are actually identifying failures or rerouting around them.

How do AI Coding Tools Impact Software Quality and Architectural Consistency?

Beyond testing and pipelines, many businesses are facing a deeper structural problem: AI tool fragmentation. The use of AI is pervasive, but it is not common to have standardization.

The choice of assistant that various teams use is usually at their own discretion or based on the nature of the project. One can be based on GitHub Copilot, another on Cursor, and the third on bots that were developed internally using various models. The systems have different interpretations of prompts, and they can be guided by different design assumptions.

This fragmentation over time results in inconsistent code patterns, conflicting architectural choices, and non-diagnostic dependencies. A codebase develops slowly to become a patchwork of styles created by different systems of AI operating in diverse settings. Unless there is centralized control, AI tools only enhance inconsistency rather than minimize it.

What Security Vulnerabilities Are Emerging from Shadow AI?

What makes matters worse is the absence of regulation regarding the use of AI. In most businesses, there are still no formal policies on the use of AI tools, or only part of them. Few companies implement definite regulations regarding model homepages, data management, or immediate security. In this vacuum, vendors usually pick up the tools on their own.

This phenomenon, known as Shadow AI, occurs when engineers use AI tools outside official procurement channels. In many cases, developers subscribe to AI services using personal accounts or credit cards, bypassing enterprise oversight entirely.

The consequences can be severe. Sensitive proprietary code may be shared with external models, architectural details may be exposed through prompts, and security teams may have little visibility into where critical information is being processed. Businesses effectively lose control over their own engineering data.

AI Code vs Human Code: Why Is Institutional Knowledge Lost in AI-Assisted Development?

Perhaps the most subtle but dangerous consequence of AI-driven development is the erosion of institutional knowledge. Traditionally, engineers gained system expertise by slowly navigating legacy codebases, understanding design decisions, and learning why certain constraints existed.

This process was often painful, but it built the deep architectural understanding required to maintain complex systems. AI-generated code short-circuits that learning process. When developers rely on prompts to refactor modules or generate new components, they may never fully explore the historical context behind those systems.

With time, there are decreasing numbers of engineers who are aware of the underlying design concepts that have provided the platform with cohesion. The system remains effective in the short term, although its strength becomes weak.

In complicated accidents, there is a shortage of engineers with the knowledge to establish root causes fast. Businesses are in danger of losing the same expertise in order to transform their systems in a safe way.

Reducing the Change Failure rate for engineering teams in AI-driven development

The growing instability in AI-driven development does not mean businesses should slow their adoption of AI tools. Instead, it highlights the need for more deliberate engineering leadership.

A number of strategic changes can be used to regain the balance between speed and stability.

Make Observability an Investment

As codebases grow more complex, troubleshooting capabilities must improve as well. Logging, observability, monitoring, and runtime diagnostics should become first-class engineering investments rather than afterthoughts. When engineers can quickly understand system behavior, they can resolve incidents faster and reduce downstream disruption.

Standardize the AI Development Stack

Companies are supposed to define precise guidelines for AI-enhanced development. This ensures that AI-created code matches common architectural principles, teams can centralize tooling decisions, and establish acceptable workflows. Due to standardization, the fragmentation of context is decreased, and codebases remain consistent.

Reintroduce Dedicated Quality Strategy

Quality cannot exist without ownership. Engineering businesses should ensure that experienced QA leaders guide testing strategy, risk analysis, and validation processes.

This does not mean returning to rigid waterfall testing models. Instead, it means ensuring that a dedicated perspective exists to challenge assumptions and identify hidden risks.

Align Incentives With Stability

Engineering success has to be reassessed by businesses. The measures of velocity, like pull request volume and deployment frequency, need to be balanced with stability measures like incident rates, reliability of pipelines, and test coverage. Promoting stability in the system through the incentive of engineers stimulates long-term resilience and not temporary output.

How to Review AI-generated Code to Reduce AI Code Quality Issues?

With AI increasingly becoming a part of the everyday workflow, the need to review the quality of the code becomes critical. Although AI can write correct code syntactically, the errors show up in the form of hidden errors, inconsistencies, and vulnerabilities. The following steps will help you reduce the risks of AI-generated code and change failure rates.

Validate Problem-solution Alignment

AI-generated code often solves the immediate issue, but it lacks the necessary depth to align with the border requirement. During the review process, engineers should focus on identifying if the intended problem is solved. They should also explore the assumptions in this AI-generated logic. This step is necessary because AI can generate solutions that look correct but fail under production conditions.

Examine Edge Cases and Failure Conditions

AI always tends to optimize for the “happy path” This means that the code can break during the test case scenario. The different areas that you should check include input validation and error handling, boundary conditions, and integration failures. This step is necessary to prevent issues from reaching the production stage.

Review Security Implications

AI-generated code can bring about AI coding risks when dealing with authentication and API integrations. Testers should evaluate unsafe dependency usage, injection risks, and improper authentication. Security reviews are typically important to minimize public repositories that are not designed with enterprise security standards.

Evaluate Code Maintainability

AI-generated code works well in most cases. However, it may not be suitable for upcoming junior engineers to understand or maintain them. This is where reviewers should check on the clarity of the function structure, duplication of logic, and unnecessary complexity. Maintaining readability is necessary to eliminate the long-term risks associated with AI-generated code.

How does QASource help engineering teams reduce AI code risks

The challenges described above are not theoretical risks in the future roadmap. They are operational checkpoints and business risks that engineering leaders are navigating currently. Engineering teams that have adopted AI development tools generally face a predictable set of quality challenges.

QASource partners with engineering businesses to close the gap between AI development velocity and production system stability. This helps lower the customer impact of these AI issues and stabilize the cost of instability.

AI-Specific Code Review and Validation

QASource engineers are trained to review AI-generated code through the lens of what AI consistently gets wrong. They not only focus on syntax and formatting but also on architectural alignment, edge case coverage, security implications, and long-term maintainability. For organizations where the review process has not been updated to account for AI-generated code patterns, QASource provides both the expertise and the process redesign to close that gap.

CI/CD Pipeline Reliability Assessment

QASource conducts structured pipeline audits to identify software reliability with AI, flaky tests, coverage gaps, and process bottlenecks that allow defects to pass through automated checks. For engineering teams where the culture of rerunning pipelines until they pass has taken hold, QASource provides both the diagnostic capability and the remediation roadmap to restore pipeline integrity.

Security and Compliance Testing for AI Code

AI-generated code that touches authentication, external APIs, and dependency management requires explicit security validation. QASource security testing teams specialize in identifying the vulnerability patterns most commonly introduced by AI code generation, such as injection risks, improper authentication, and unsafe third-party dependencies. They work with coverage designed for the enterprise security requirements that public AI models are not trained to enforce.

Quality Strategy and QA Leadership

For organizations that have reduced dedicated QA headcount in the shift to developer-owned testing, QASource provides experienced QA leadership to own AI testing challenges, risk prioritization, and validation standards. This is not a return to sequential waterfall testing. It is the restoration of quality ownership with a mandate to find what AI and developers consistently miss.

Change Failure Rate Reduction Programs

QASource works directly with engineering leadership to measure and reduce change failure rate through structured quality interventions. This eventually helps in improved test coverage, better pre-production validation, and tighter feedback loops between testing and deployment. For organizations where incident per pull request metrics have moved in the wrong direction, QASource provides the measurement framework and execution capability to reverse that trend.

Conclusion

The surge in AI adoption has fundamentally changed how software is built. Development velocity has increased dramatically, but speed alone does not guarantee progress.

If businesses focus exclusively on output metrics, they risk amplifying instability throughout their systems. This will eventually lead to AI-generated code security risks that affect the overall performance of the system.

The data behind the 23.5% increase in incidents per pull request serves as a warning. AI tools are powerful accelerators, but they amplify the strengths and weaknesses of the engineering environments in which they operate.

Sustainable velocity requires strong foundations: reliable testing pipelines, robust observability, clear ownership structures, and experienced engineers who understand the systems they maintain.