That does not mean the announcement is insignificant. Quite the opposite. It signals a shift towards security tooling that can reason about code, rather than simply pattern-matching against it.

But the more useful question is not whether AppSec is solved. It is this:

What are these tools actually good for, and how should security teams think about them within the wider AppSec ecosystem?

AI Code Scanning Is Significant — But Not New

Anthropic's announcement arrived with the usual fanfare: polished demos, confident messaging, and the suggestion that a major shift is underway.

And to be fair, it is significant. Reasoning models are already proving capable of identifying vulnerability classes that traditional rules-based static analysis tools often miss.

However, it is also worth keeping the development in perspective.

Anthropic is not the first organisation exploring this approach. Google released similar capabilities several months ago, and OpenAI has been developing comparable tooling for some time. The implementations vary, but the pattern is clear: major AI vendors recognise security code review as a strong use case for large language models.

That is why some of the reaction has felt slightly exaggerated. Beneath the excitement, there is also a considerable amount of product marketing.

AI SAST Is Powerful — But Cost and Scale Still Matter

In practice, AI-assisted code analysis can be extremely effective. Many teams have already experimented with this approach using internal workflows, custom tooling, or platforms built on top of large language models.

But "very good" does not mean "a complete replacement".

Two limitations are worth considering.

Large Codebases

As codebases grow, analysing them becomes more complex. The usefulness of AI-driven tools can vary depending on system architecture, context, and how much relevant information the model can realistically process.

Cost at Scale

Even when the output is impressive, the economics do not always scale well. If running AI analysis across large repositories costs significantly more than traditional tools, organisations are unlikely to replace their existing AppSec stack overnight.

For many teams, the realistic outcome is not replacement but augmentation. AI analysis becomes another layer alongside existing security tooling.

Why Integrated AI Tooling Is Attractive

The real appeal of these capabilities is not purely technical. It is organisational.

Introducing new security tools into large organisations is rarely straightforward. Procurement approvals, supplier onboarding, integration work, and internal resistance can slow adoption dramatically.

However, when organisations have already adopted an AI platform, and that platform expands into code generation, review, and security analysis, the adoption barrier drops significantly.

If developers are already working within an ecosystem powered by a frontier model, and that same ecosystem can review their code for vulnerabilities, the advantages are clear:

• Fewer tools to manage

• Less onboarding friction

• Faster developer adoption

But this convenience introduces a potential risk.

The Risk of AI "Marking Its Own Homework"

Relying heavily on a single platform across the software lifecycle raises an important question.

If the same underlying technology generates code and then reviews that code for vulnerabilities, the system may effectively be marking its own homework.

If a model struggles to prevent a particular vulnerability type during code generation, there is a reasonable chance it may also struggle to detect that same vulnerability during analysis.

This does not mean the technology is ineffective. Rather, it highlights the risks of relying too heavily on a single system.

The real challenge for organisations is understanding where tool consolidation improves productivity and where diversity in security tooling remains valuable.

Business Logic Vulnerabilities Remain the Hardest Problem

Much of the current excitement around AI AppSec tooling centres on its ability to identify business logic vulnerabilities.

These are some of the most difficult security flaws to detect.

Unlike injection vulnerabilities or validation errors, business logic flaws depend on understanding how a system is supposed to behave, not simply how it is implemented. They sit in the grey area between software engineering and business requirements.

Some examples are relatively simple. If an ordering system allows a user to purchase minus five items, that is clearly a logic error. A reasoning model may be capable of identifying that behaviour as incorrect.

However, most real-world examples are more complex.

Consider a lending application process. A customer might be prevented from continuing if they fail affordability checks. A business logic flaw might allow them to bypass a step in the process and continue regardless.

Identifying that issue requires more than analysing code. It requires understanding:

• The organisation's rules

• The intended user journey

• The implications of bypassing controls

This is why many business logic vulnerabilities remain difficult to detect automatically.

AI tooling may help identify some classes of logic flaws, but many will still require human understanding of both the technical system and the business context.

Are We Heading Towards Fewer AppSec Tools?

Possibly — at least to some degree.

Major AI vendors are increasingly packaging together capabilities such as code generation, code review, and AI-assisted SAST. This suggests some consolidation within the AppSec tooling landscape.

However, that does not mean the market will converge around a single platform.

Even if underlying models become similar, organisations will continue to have unique workflows, integration requirements, and niche security needs. That creates opportunities for additional tooling built around those models — wrappers, orchestration platforms, and specialised security tools.

In other words, the intelligence layer may consolidate, but the ecosystem around it will remain diverse.

Another factor is competition. The leading models continue to compete closely in capability, which means organisations are unlikely to become permanently locked into a single provider.

The Real Story Is the Pace of Change

The most important takeaway is not that a specific vendor has launched a new feature.

It is that the pace of change in application security is accelerating.

By the time one AI capability reaches the market, the next iteration is already being developed. Six months from now, the conversation may look very different.

Some of today's assumptions will inevitably change.

That uncertainty can be frustrating, but it is also what makes this moment interesting.

Application security teams will need to understand where AI genuinely adds value, where human expertise remains essential, and how to make informed decisions in an increasingly complex landscape.

Because while the tools are evolving rapidly, AppSec itself is far from a solved problem.