Shift left is dead. For more than two decades, it has been the default philosophy of secure software development: Catch problems as early as possible, and everything downstream gets faster, cheaper, and safer. That philosophy no longer holds, because AI-driven development has broken the assumptions it was built on.

The concept was introduced in 2001 by software engineer Larry Smith, who argued that testing and quality assurance should move earlier in the development process rather than be left until the end. It went on to become one of the most influential ideas in the software development ecosystem. In the security niche specifically, it helped dev teams find and fix vulnerabilities during design and coding rather than waiting for testing or deployment, turning security from a roadblock into an accelerator of rapid, secure releases.

That’s because AI-driven development has introduced a new category of risk that shift left was never built to address: Exposure that happens before a single line of code is generated. The moment a developer connects an untrusted agent, installs a malicious package, or exposes a secret in a prompt, risk has already entered the pipeline, no code has run yet, and there’s nothing to “check” earlier because the vulnerable step already happened. Shift left’s core flaw is that it’s fundamentally reactive: It waits for code to exist before it can act. Security now needs to be proactive, shaping and securing what agents can access and do before they ever generate that first line.

Recent research among more than 400 CISOs and security practitioners demonstrates the scale of this transition. Every organisation surveyed confirmed that AI-generated code is already present in its codebase, yet 81% said they lacked full visibility of how and where AI was being used across the software development lifecycle. As a result, security teams are in the position of trying to apply established controls to development activity they cannot fully see.

Shift left was built for a world where humans wrote every line of code. That world is gone, and security needs a new model to replace it.

What AI-Driven Development is Changing

The impact of this change in approach is difficult to understate. As it stands, AI assistants can already generate substantial amounts of code from natural-language prompts, changing the volume of software that developers and security teams must oversee. Moreover, autonomous agents can take on activities that previously required separate human actions.

In security, this is something of a double-edged sword. Code is generated much more rapidly (which is a positive), but its inherent efficiency also creates the potential for a corresponding increase in vulnerabilities (a negative). One example is checkpoint-based security controls, which assess code at fixed stages in the development process and may struggle to keep pace with AI-generated changes.

Moreover, AI agents can influence the development process before code even reaches a conventional security checkpoint, through prompts, tool use, access to data and interactions with other systems. This creates additional risks around the information provided to AI tools and the permissions granted to agents. The clear implication is that security must instead govern AI activity throughout the lifecycle, rather than examining its output only after a defined stage has been completed and vulnerabilities may already have crept in.

From SDLC to ADLC

So, what needs to change? Well, the conventional Software Development Lifecycle (SDLC) describes the process through which software is designed, built, tested and released. AI-driven development has instead created an Agentic Development Lifecycle, or ADLC, in which, as we’ve described, AI assistants and agents participate in the creation and delivery of software.

The main difference from a security perspective is that the security model needs to extend much further back, starting at the developer endpoint, where agents access sensitive information and install files, through prompts, and on through the generation of code and deployment of applications into production. This means governing the AI tools and models developers can use, along with the information they can access. Their activity must also be monitored across that entire span, not just at the point code is checked in.

Security teams also need sufficient context to understand where AI-generated changes are being used and the potential consequences if something goes wrong. The objective should be to embed governance into the AI-enabled development lifecycle itself.

Visibility and Guardrails

To build the levels of visibility required, organizations need a clear view of the AI tools being used across their development environments. This should include AI services adopted outside approved processes, typically referred to as shadow AI. As many organizations are discovering, shadow AI can create blind spots where source code or other sensitive information is shared with tools that security teams have not assessed.

This provides a good basis for deciding which AI tools are approved for use in development. It also helps security teams understand what information those tools can access and where there are instances of AI use that fall outside their security and data-handling policies. Armed with this detail, the next requirement is to apply controls within the workflow, so potential issues can be stopped before they affect the codebase.

These controls come in the form of guardrails designed to block malicious packages before they are installed and prevent secrets or other sensitive information from being included in prompts before they are submitted to an AI model. They might, for example, block a developer from installing a package with known malicious code, block a developer from submitting a prompt containing a secret, or prevent an AI assistant from generating code that matches a known high-risk pattern. This helps developers use approved AI tools safely while also maintaining the speed that makes those tools valuable.

Governance and Accountability

This approach also lends itself to effective governance and accountability, based on an auditable record of the AI tools used in their software-development environment and the policies governing their use.

Fundamentally, this helps organizations demonstrate, to a high standard, that AI activity is subject to appropriate oversight, including in areas where code or sensitive information is involved. These records can also support internal risk management by helping security teams investigate an AI-related issue and understand its potential impact. As we are seeing on a fairly regular basis, the governance issues that have been predicted since GenAI came to market are now happening, for real, on a regular basis. Addressing these issues now is more important than ever.