AI now plays a role in more than half of the code produced within the organizations surveyed.
According to the Sembi Software Quality Pulse Report, respondents estimate that, on average, 53% of their organization’s code is AI-generated or AI-assisted.¹ For many teams, AI is already involved in producing a significant share of their code, and that is quickly becoming the reality of software development in 2026.
Image: Sembi Software Quality Pulse Report, First Edition, 2026
The tools that help developers write code have changed faster than many of the workflows built to review it. The immediate challenge is the volume and velocity of code outpacing the capacity available to assess it. Here is what the data says, what it means for security teams, and how organizations can adapt their application security workflows.
Review and remediation workflows, including how findings are triaged, assigned, fixed, and verified, were designed around a human-driven or manual code generation pace.
AI-assisted development changes that pace. A developer using an AI coding assistant can generate, revise, and test code faster than they could through manual development alone. The code still needs to meet the same security standards:
What has changed is how much code may arrive for review and how quickly it moves through the development process.
Security capacity does not automatically expand at the same rate. Teams already working with limited time and resources now have more code changes, dependencies, and potential findings to assess within the same release windows.
This pressure is also reflected in how organizations balance speed and risk. The Sembi report found that 37% of respondents say their organization slightly or strongly favors delivery speed over risk management.²
Image: Sembi Software Quality Pulse Report, First Edition, 2026
That does not mean teams do not care about security. It reflects the pressure to keep software moving. When review capacity is fixed and code volume increases, teams have to make more security decisions within tighter timelines.
It is worth being precise about what is breaking down because the detection tools are only one part of the problem.
Static application security testing and software composition analysis tools can scan code regardless of whether it was written by a developer or produced with AI assistance. A SQL injection pattern, hardcoded credential, or vulnerable dependency can still be identified based on the code itself.
That does not mean every scanner detects every issue equally well. Results still depend on factors such as language coverage, rule quality, configuration, data-flow analysis, and the types of vulnerabilities the tool was designed to find. AI-assisted code generation can also introduce unfamiliar patterns, inconsistent implementations, or unnecessary dependencies that teams are not prepared to assess at scale.
The larger bottleneck often appears after detection, when teams need to evaluate and act on the findings a scanner produces. As code volume increases, security teams may receive more results to review, which creates additional work to determine which issues are legitimate, which ones pose the greatest risk, who owns the fix, and whether remediation has been completed.
The challenge is therefore not limited to what security tools can detect. It also depends on whether the organization has enough capacity to process those findings at the pace development now demands. Broader scanning may increase visibility, but teams also need workflows that can absorb higher volumes without requiring security headcount to grow at the same rate.
Reducing alert noise is a major part of that effort because it allows the people reviewing findings to spend more of their limited time on issues that are relevant, actionable, and worth prioritizing.
That noise problem is measurable and it compounds the volume problem directly. Across the teams surveyed, respondents estimate that only 51% of detected security issues are true positives.³ That does not mean exactly half of every security team’s review time is wasted. It does mean teams are dealing with a substantial number of findings that may be irrelevant, duplicated, incorrectly classified, or not exploitable within the application’s actual context.
Each questionable finding still requires some degree of attention. Someone may need to inspect the affected code, trace the data flow, assess the surrounding context, document why the issue is not exploitable, or suppress it so it does not return during every scan.
As code volume increases, the effort required to validate questionable findings increases with it. The problem becomes especially difficult when review capacity remains constrained and a significant share of detected issues does not ultimately require remediation.
Time spent repeatedly evaluating false positives reduces the time available to investigate exploitable vulnerabilities. Important findings may be delayed or overlooked because the same team is working through a larger queue without additional capacity.
In that context, alert fatigue creates more than a productivity problem. It can weaken the team’s ability to identify and address the risks that matter most.
Teams adapting to higher code volume are not simply working more hours. They are restructuring their workflows around two goals: catching issues earlier and reducing what does not need manual review.
Full integration between security tools and DevOps workflows is still uncommon. Just over 9% of respondents report having fully integrated security tools within DevOps.⁴ Most teams report being mostly or somewhat integrated, which can still leave room for manual handoffs, disconnected dashboards, delayed feedback, or inconsistent enforcement.
Image: Sembi Software Quality Pulse Report, First Edition, 2026
The other 91% are not necessarily treating security as a completely separate final step. However, partial integration can make the volume problem harder to manage. When findings arrive after developers have moved on to other work, they can be more difficult to understand, more expensive to fix, and easier to deprioritize.
A practical response is to move security checks closer to where code is written and reviewed. Running scans in the IDE, repository, pull request, and CI/CD pipeline can give developers feedback while the surrounding code and intended change are still fresh.
Earlier detection does not eliminate the need for security oversight. It shortens the distance between the introduction of an issue and the developer best positioned to correct it.
Teams can also tune their security rules to match their applications, document accepted risks, suppress confirmed false positives, and prioritize findings based on severity and application context. The goal is not to hide issues or make reports appear cleaner. It is to prevent developers from repeatedly reviewing alerts that have already been assessed and determined not to require action.
The report also found that 19% of respondents selected AI-generated code risk as one of their top three security priorities.⁵
This concern is separate from attackers using AI or LLMs. AI-generated code risk focuses on insecure patterns, vulnerable dependencies, incorrect assumptions, or other issues introduced during development.
It ranks below concerns such as data breaches, cloud misconfigurations, and AI- or LLM-assisted exploits. Still, the finding confirms that security teams are beginning to account for the risks associated with AI-generated and AI-assisted development.
The answer is not to scan less carefully or apply a lower review standard to AI-assisted code. Security teams still need to evaluate that code with the same rigor they apply to code written entirely by developers.
The challenge is maintaining that standard as more code moves through the development process without security resources increasing at the same rate. To understand whether an AppSec workflow can keep up, teams should evaluate the quality of the findings they receive, where security checks occur, and whether scan coverage still reflects current development volume.
If an organization’s true-positive rate is close to the 51% industry average, tuning detection rules and reducing repeated noise could free up meaningful review capacity.
Teams should identify which rules produce the most dismissed findings, which alerts continue to return after they have already been reviewed, and whether confirmed false positives or accepted risks can be documented and suppressed appropriately. This helps reduce duplicate work without lowering the standard applied to legitimate vulnerabilities.
Findings that appear in the IDE, pull request, or CI/CD pipeline are easier to connect to the code change and developer responsible for them than findings delivered through a separate process later.
Teams should look for manual exports, disconnected dashboards, email notifications, or delayed scans that interrupt the path between detection and remediation. Bringing feedback closer to development can make issues easier to understand, assign, and resolve while the change is still fresh.
A scanning schedule designed around last year’s commit volume may no longer provide the same level of coverage as development accelerates.
Teams should review which repositories, branches, languages, dependencies, and applications are included in their security program. They should also confirm that scans run frequently enough to evaluate the amount of code currently moving through the organization, rather than assuming an existing cadence still provides sufficient coverage.
For related reading on where coverage gaps commonly appear between tools and teams, see our post on closing security gaps with integrated application security.
Data breaches led the report’s security priority list, with 39% of respondents selecting them as one of their top three concerns for the next 12 months.⁶
Higher code volume, alert noise, and incomplete integration do not directly cause a breach, but they can make vulnerabilities harder to confirm, assign, and remediate before the affected code reaches production. When security teams have to sort through a growing queue of low-value or irrelevant findings, important issues may remain unresolved for longer than they should.
AI-assisted development does not justify lowering the review bar. It increases the need for an application security workflow that can handle more code, prioritize actionable risks, and prevent meaningful findings from getting lost in a larger volume of alerts.
Kiuwan gives development and security teams SAST and SCA capabilities designed to help them identify risks in proprietary and open-source code earlier in the development process.
Configurable rules and false-positive management help teams reduce repeated alert noise. IDE and CI/CD integrations bring findings closer to developers before code reaches production. Kiuwan also provides reporting mapped to widely used standards, including PCI DSS, OWASP, CWE, CERT, and ISO 25000, with support for 30+ programming languages.
Teams can choose cloud, hybrid-cloud, or on-premises deployment options based on their infrastructure and security requirements. Kiuwan users can scan source code without leaving the organization’s premises, while encrypted analysis results are uploaded to Kiuwan.
Scanners evaluate the code in front of them regardless of how it was written. The difference with Kiuwan is the quality, timing, and management of the resulting security signal: helping teams surface relevant findings earlier and spend less time repeatedly evaluating noise.
See how Kiuwan approaches it.
