The Problem With Faster Code
The productivity case for AI-assisted development is compelling. Engineers using tools like GitHub Copilot, which became generally available in June 2022, report meaningful increases in coding speed. For repetitive or boilerplate code, the productivity gains are substantial. For complex business logic requiring domain knowledge, the gains are more modest but still measurable.
What the productivity conversation rarely includes is the security implication of faster code production in environments where security review capacity has not grown proportionally. More code, written faster, means more attack surface, accumulating faster. If the security testing and review processes that catch vulnerabilities in that code do not scale proportionally, the net security posture of the application portfolio deteriorates even as individual engineer productivity improves.
This is the AppSec process gap that AI-assisted development is creating and accelerating, and it is getting worse faster than the tooling designed to address it. The application security tools available to enterprise teams are improving, but the rate of code production enabled by AI assistance is outpacing the rate at which those tools can cover the expanded attack surface.
Three Ways AI-Assisted Development Creates AppSec Risk
AI-assisted development creates security risk through three specific mechanisms, each requiring a different process response.
The first is vulnerability pattern generation. AI coding assistants are trained on large corpora of public code, which includes code with security vulnerabilities. The models learn to produce code that looks like the code they were trained on, including the vulnerability patterns present in that training data. Engineers using AI code completion who accept suggested code without security review may be introducing vulnerability patterns, such as SQL injection, insecure deserialisation, or authentication bypasses, that they themselves would not have written. The developer who would recognise a hand-written SQL injection is not necessarily equipped to recognise an AI-generated one that they did not write and may not be reading with the same scrutiny.
The second is developer trust in AI-generated outputs. Security training for developers has, over the past decade, built habits of sceptical review: check input validation, verify authentication patterns, scrutinise error handling. These habits were developed in the context of code the developer wrote themselves. AI-generated code sits in a psychological category that is different from code the developer produced: it was suggested by a tool, so it carries an implicit assumption of correctness that hand-written code does not. The same developer who would review their own code for SQL injection may not review AI-suggested code with the same scrutiny, because the suggestion carries an implicit authority that undermines the scepticism that security training aimed to build.
The third is deployment velocity compression. AI assistance compresses the time from concept to deployable code, which creates pressure on the intermediate processes, including security review, that exist in the time between concept and deployment. In organisations where security review is a manual process, the velocity increase enabled by AI assistance is experienced as an increase in the burden on the reviewers or as a decrease in review quality as reviewers are asked to cover more code in the same time. Neither outcome improves security posture.
Adapting AppSec Programmes for AI-Assisted Development
The AppSec programme adaptations that address these three mechanisms are different from each other, because the mechanisms are different.
Addressing vulnerability pattern generation requires extending automated security testing to cover the code that AI assistance produces. Static analysis tools that run in the IDE and in the CI/CD pipeline are not new, but their role in an AI-assisted development environment changes. They are no longer primarily a check on the developer’s coding practices; they are a check on the AI’s coding practices, covering vulnerability patterns that the developer may not have introduced and may not be equipped to recognise. The configuration of these tools, their false positive rates, and the integration of their findings into the developer’s feedback loop all require recalibration for the AI-assisted development context.
Addressing developer trust in AI outputs requires updating security training to include AI-specific content. The training that taught developers to be sceptical of their own input handling needs to explicitly extend to AI-suggested code: you are accountable for every line of code that goes into your pull request, regardless of how it was generated. This is not a complicated message, but it requires explicit inclusion in the security training curriculum that already exists, because the default assumption among many engineers using AI coding tools is that the tool has already checked the code for obvious problems.
Addressing deployment velocity compression requires moving security feedback earlier in the development process. The security review that exists as a gate before deployment cannot keep pace with AI-accelerated development velocity without becoming a bottleneck that either slows deployment or is bypassed. Security feedback in the IDE, in the pull request review, and in the CI pipeline keeps security engagement at the point where the engineer is still in context for the code being reviewed and the cost of remediation is lowest. The security team’s role in this model shifts from reviewer to tooling provider: the team that configures and maintains the security tools and training that enable developers to catch their own security issues.
The Process Changes That Are Not About Tooling
The tooling changes required to adapt to AI-assisted development are real but straightforward. The process changes are where most programmes will find the harder work.
AI coding assistant approval and governance is a process question that most organisations have not yet answered systematically. Which AI coding tools are approved for use in development environments that handle production code? What are the data handling implications of sending code to the AI service for completion? Are engineers aware that code sent to AI services may be retained and may be used to improve the model? These are policy and governance questions that the security and technology leadership need to answer before the tools are in widespread use, not after a code exposure incident surfaces the gap.
Ownership of AI-generated code in security incidents is a process question that organisations will face before they have answered it through policy. When a security incident traces to a vulnerability in AI-generated code, who is accountable for that vulnerability? The engineer who accepted the AI’s suggestion? The team that approved the AI tool for use? The organisation that failed to configure adequate security review processes? Establishing clear accountability before the incident is the process work that prevents the organisational conflict that follows when accountability is undefined.
The AppSec programmes that are ahead of this challenge are the ones that started treating AI-assisted development as a security programme concern when the tools became available, rather than waiting for the consequences to make the concern unavoidable.