August 21, 2026
The Next Frontier in Agentic Coding Isn’t Code Generation.
Hmmm, I originally started writing this post a couple months ago and based on the data I had at the time I was planning to title it: “AI…
By Gadi Bashvitz
10 min read
- 1 The Next Frontier in Agentic Coding Isn't Code Generation. It's Continuously Proving that the Written Code is Secure!
- 2 Secure-by-design isn't enough
- 3 Anthropic: security has to move at agentic speed
- 4 OpenAI States: don't just find the vulnerability, reproduce it
- 5 Microsoft Claims: the model isn't the product
The Next Frontier in Agentic Coding Isn't Code Generation. It's Continuously Proving that the Written Code is Secure!
Hmmm, I originally started writing this post a couple months ago and based on the data I had at the time I was planning to title it: "AI coding vendors haven't solved security. They need to figure out how to generate secure code before they talk about agentic coding". But alas I got distracted with running a startup and signing some AMAZING new partnerships so this took a back seat. Coming back to it now I updated all my research and as can be expected in the AI era many things have evolved, but some fundamental points still hold true… I will likely have to revisit this in a few months and update it.
Based on everything I see in the market, the race to agentic coding won't be won by the AI that writes the best code. It will be won by the systems that can continuously prove the code they write is secure! Then use that proof to make the next generation of code more secure.
The race to autonomous software development is accelerating much faster than I and most other people expected. AI coding tools have rapidly evolved from autocomplete, to copilots, to agents capable of taking an objective and independently planning, writing, testing, debugging and modifying significant amounts of software.
Anthropic says Claude now authors roughly 80% of the code merged at Anthropic. OpenAI is giving Codex increasingly long-running development tasks. Microsoft, Google and Cursor are all building toward a world in which software engineers spend less time writing code and more time defining intent, setting constraints and supervising fleets of coding agents.
For a while, I believed this transition faced a fundamental roadblock: How can we trust autonomous coding agents when AI-generated code still introduces a very high volume of security vulnerabilities?
I assumed the AI coding companies would eventually have to make their models dramatically better at writing secure code before truly autonomous software development could become practical.
After looking closely at what Anthropic, OpenAI, Microsoft, Google and Cursor are actually building, I've changed my view.
They aren't waiting for AI to become incapable of writing vulnerable code.
They're building something potentially more powerful as a workaround: An autonomous security validation loop.
Understanding this leads to an even more interesting question.
If AI can continuously generate software, attack that software, prove which vulnerabilities are actually exploitable, fix them and then attack the software again to prove the fix worked, could those verified security outcomes eventually teach coding agents to stop making the same security mistakes in the first place?
I believe the answer is yes.
And that may become one of the most important feedback loops in the future of software development.
Secure-by-design isn't enough
The obvious solution to insecure AI-generated code is to make the models better at security.
Train them on secure coding practices. Give them security instructions. Provide examples of vulnerable and corrected code. Teach them OWASP guidance. Fine-tune them using security datasets. Add security-specific agents to review their work.
All of this is happening, but there are fundamental limitations:
- Software security is not purely a code-generation problem.
- The cost is extremely high.
Consider an authorization vulnerability.
The relevant code may look perfectly reasonable in isolation. The vulnerability only becomes apparent when you understand that a particular API is externally reachable, accepts a specific authentication state, interacts with another service in an unexpected way and ultimately allows one user to access another user's data.
Whether that vulnerability is real isn't simply a property of a few lines of source code.
It is a property of the running system.
That's why increasingly capable AI reasoning alone doesn't completely solve the problem.
And the major AI coding companies appear to be reaching the same conclusion.
Anthropic: security has to move at agentic speed
Anthropic provides perhaps the clearest example of how dramatically software development is changing.
Claude now authors about 80% of the code merged at Anthropic, according to the company's Deputy CISO. Anthropic says its engineers are shipping roughly eight times as much code per quarter as they did between 2021 and 2025. Blog post here: https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle?reference=FUZZ
That creates an obvious security problem. If AI increases development velocity by an order of magnitude while security review remains largely human, security becomes the bottleneck.
Anthropic's answer isn't simply to make Claude write better code. It has redesigned the security lifecycle around automation.
Security guidance is embedded directly into Claude's development process. Specialized security agents review changes. Traditional deterministic security tools still run. Humans remain involved at particularly important risk boundaries.
But one of Anthropic's most interesting recent decisions is to implement continuous AI-powered DAST in its staging environment.
The reason matters. Anthropic specifically points to system-level vulnerabilities where assumptions between multiple services are incorrect, the kinds of problems that can be difficult to discover by looking at source code alone.
In other words: Generate the application. Run it. Attack it. Observe what actually happens.
Security validation has to operate at the same speed as code creation.
OpenAI States: don't just find the vulnerability, reproduce it
OpenAI has arrived at a similar conclusion through Codex Security.
Codex Security starts by understanding the application and constructing a project-specific threat model covering things like entry points, trust boundaries, sensitive data and high-impact code paths. It then searches for realistic vulnerabilities.
But the important step comes next. Where possible, Codex Security attempts to reproduce the vulnerability inside an isolated environment.
If the vulnerability can be validated, Codex can generate a patch. Once the patch is merged, the system can revalidate the vulnerability.
The loop therefore becomes: Understand → Discover → Validate → Remediate → Revalidate
That is fundamentally different from asking an AI: "Does this code look secure?"
Instead we're asking: "Can you demonstrate that this application can actually be compromised?"
And after remediation: "Can you demonstrate that the attack no longer works?"
That's a much stronger security signal.
Microsoft Claims: the model isn't the product
Microsoft has perhaps articulated this shift most explicitly.
Its new multi-model agentic scanning harness, MDASH, orchestrates more than 100 specialized AI agents across multiple models. Different agents have different jobs.
Some discover potential vulnerabilities, others argue about whether those vulnerabilities are actually reachable and exploitable. Still others attempt to construct triggering inputs and prove the vulnerabilities exist.
Microsoft describes the system as moving through: Prepare → Scan → Validate → Deduplicate → Prove → Patch
Microsoft made an observation that I think will prove important well beyond security:
The model is one input. The system is the product.
That may ultimately describe the future of agentic software engineering itself.
We don't need a coding model that never makes mistakes.
We need a system capable of continuously detecting, validating and correcting those mistakes before they create unacceptable risk.
Google and Cursor are moving in the same direction
Google is approaching the problem somewhat differently.
Its agentic development environment increasingly combines autonomous coding, sandboxed execution and security context from Google's broader security stack. With Wiz now part of Google Cloud, coding agents can increasingly consume code-to-cloud security context, understand attack paths and feed validated security information back into remediation workflows.
Cursor is also building its own specialized security agents while remaining relatively open to an ecosystem of external security capabilities.
Cursor says its internal security agents review thousands of pull requests per week. Importantly, these agents aren't limited to reading code: they operate in executable development environments where they can write and run code to test assumptions.
Different vendors are assembling the pieces differently. But the architectural direction is remarkably consistent.
The industry has quietly agreed on the architecture
Put these efforts next to each other and a pattern emerges.
The future of secure agentic development increasingly looks like:
Generate → Inspect → Execute → Attack → Validate → Remediate → Attack Again → Verify → Deploy
That is an important development.
The industry is no longer betting entirely on making AI-generated code inherently secure.
Instead, it is building systems capable of proving security properties continuously.
But I think there is another step that could be even more important (you knew that was coming…).
What happens to everything the security system learns?
Imagine an AI coding agent creates an API. A traditional security tool might produce a result like: CWE-639: Potential authorization vulnerability.
That's useful.
Now consider what an autonomous dynamic security system could potentially produce:
- The coding agent was given objective P.
- It generated implementation X.
- The resulting application was deployed into environment C.
- Security testing discovered attack path A.
- The attack successfully produced unauthorized outcome R.
- The coding agent generated remediation Y.
- The application was rebuilt.
- Attack A was executed again.
- The attack failed.
- The application's expected functionality continued working.
- That's not just a security finding.
- That's ground truth.
- We now know that under a specific application context, the generated implementation was actually exploitable.
- We know how it was exploited.
- We know what change addressed the root cause.
- And most importantly, we have empirical evidence that the remediation eliminated the exploit.
That information could be enormously valuable to the next generation of coding agents.
Security validation can become a learning signal
Today we mostly think about security validation as a gate: Is this code safe enough to ship?
In an AI-native development world, we should start thinking about it as something else as well: a feedback signal.
Every validated vulnerability can potentially become an evaluation case.
Every confirmed exploit can become evidence about a security mistake the coding system made.
Every successfully validated remediation can become evidence about how that mistake should be corrected.
And aggregated across millions of generated applications, that creates something potentially extremely powerful: a continuous security learning loop.
The exact mechanism doesn't necessarily have to be foundation-model training.
The feedback could improve:
- model post-training;
- reinforcement learning;
- coding-agent evaluations;
- security-specific models;
- system prompts;
- secure coding skills;
- repository-specific memory;
- model routing;
- agent policies;
- or future model generations.
The implementation will evolve. The important thing is the feedback signal.
Code isn't enough to teach AI security
Most secure coding datasets ultimately describe relationships between code and vulnerabilities.
Vulnerable code → vulnerability classification → corrected code.
But security isn't ultimately about whether code resembles a known vulnerability.
It's about whether an attacker can make a system behave in a way its designers did not intend.
Dynamic validation provides something source code alone cannot: observable security outcomes.
- Was the endpoint reachable?
- Did authentication prevent the attack?
- Did authorization work?
- Could attacker-controlled data reach the sensitive operation?
- Could the vulnerability actually be exploited?
- Did the remediation stop the attack?
Those answers transform security from an inference problem into an empirical one.
Static analysis gives us evidence about code, AI reasoning gives us hypotheses, Exploitation gives us proof. And exploitation followed by remediation followed by failed re-exploitation gives us something even more valuable: verified security improvement.
The security flywheel
I believe this creates a flywheel that could become foundational to autonomous software development:
AI generates software → Security system attacks it → Real vulnerabilities are → validated → AI remediates them → Security system attacks again → The remediation is verified → The verified outcome becomes feedback → The coding system improves → Future software starts more secure → Repeat
At first, the primary benefit of this loop is obvious: stop vulnerable AI-generated software from reaching production.
But over time, the larger benefit could be that the system needs to intervene less frequently because coding agents learn from an expanding corpus of verified security outcomes.
That's when security stops being merely a gate around AI-generated code.
It becomes part of the mechanism that makes the AI better.
This is where dynamic security changes roles
I've spent years thinking about dynamic application security from the perspective of finding vulnerabilities. In the world we're entering, I think its role becomes considerably larger.
At Bright, the principle behind STAR has been simple:
Don't just predict whether a vulnerability exists. Prove it. Fix it. Then prove the fix worked.
That means running the application, attacking it, validating actual exploitability, remediating confirmed vulnerabilities and then re-attacking the application to verify the result.
Originally, the value proposition for that architecture was eliminating false positives, dramatically reducing developer work and accelerating remediation and reducing AI token costs. Agentic development creates another possibility.
The validated exploit/remediation/revalidation loop produces exactly the type of deterministic feedback that autonomous coding systems need. An AI coding provider already has the other half of the equation.
It knows: what the developer asked for → what the agent reasoned → what code the agent generated.
A dynamic validation system can provide: what attack worked → why it worked → what remediation was applied → whether the attack still worked afterward.
Connect those two datasets and you create a potentially powerful security learning system.
AI coding companies shouldn't have to build every security capability themselves (and realistically we don't want them to)
There's another lesson emerging from the current market. The major coding platforms are taking very different build-versus-partner approaches.
Microsoft is investing heavily in proprietary technology such as MDASH. OpenAI is building Codex Security. Anthropic is building substantial security-agent capabilities internally while also using external penetration testing and implementing continuous AI-powered dynamic testing. Cursor combines internal security agents with an external ecosystem.
Those approaches will continue evolving.
But coding-model providers have an extraordinary amount of work ahead of them: models, inference infrastructure, agent orchestration, developer environments, context management, sandboxing, identity, permissions, deployment and much more.
They don't necessarily need to reinvent every specialized security capability.
What they need is a way to consume high-quality security ground truth programmatically and at machine speed.
Moreover, do we really want to trust the security of our code to the agents generating the code without doing any external validation? Do we really believe that everything we have done over the past 50+ years around external validation of security & compliance goes away with agentic coding? I think not! We have to have external validation solutions!
That creates an opportunity for a new relationship between AI coding platforms and security companies.
Not: Coding platform + security scanner.
But: Coding intelligence + security validation intelligence.
The next benchmark may not be SWE-bench
For the last several years we've measured coding models primarily on whether they can write code that works. That was the right benchmark for the CoPilot era.
It may not be sufficient for the agentic era. Imagine evaluating an autonomous coding system on four dimensions:
- Did it build the requested functionality?
- Did the software pass its functional tests?
- Could an autonomous adversary exploit it?
- Could the agent autonomously remediate any vulnerability and survive re-testing?
That's a much higher bar (pun intended as a shoutout to my co-founder).
But that's also much closer to what enterprises actually mean when they say they want to trust autonomous software development.
The ultimate objective isn't: AI that can write code without humans.
It's: AI that can create software we can trust without requiring humans to inspect every decision it makes.
Those are very different goals.
The next frontier is proof
We've spent the last several years making AI dramatically better at creating software.
The next several may be about creating the systems that allow us to trust what it creates.
The major AI coding companies are already moving in that direction. Anthropic is implementing continuous AI-powered dynamic testing. OpenAI is validating vulnerabilities in isolated environments. Microsoft is building specialized agents whose job is to prove exploitability. Google is connecting coding agents with broader security and runtime context. Cursor is giving security agents executable environments and integrating specialized external capabilities.
They have reached the same fundamental conclusion: Agentic coding requires agentic security.
I think there's one more conclusion coming.
The security systems that continuously attack and validate AI-generated applications won't merely protect us from insecure AI-generated code.
They can teach AI what secure actually means.
And if we build that feedback loop correctly, the long-term result isn't simply AI that generates code faster.
It's AI that learns from every vulnerability it creates, every exploit that succeeds and every remediation that is proven to work.
That's when autonomous software development becomes not just possible.
That's when it becomes trustworthy.