Our engineering output went from roughly 40 commits per developer per month to around 800. The security model did not simply get slower. Parts of it stopped making sense. This is what we changed, and where I think most application security programs are about to spend their money badly.
The commit number is the headline. The line count is the problem.
Anthropic published training and reference materials last week on AI SDLC, and it felt validating for everything we’ve been building around the same principles. I’m planning a deep-dive follow-up, but before that, I wanted to tell the story of how we lived this transformation inside our own engineering team.
Two numbers changed dramatically. We went from roughly 40 commits per developer per month to around 800. At the same time, code output moved from roughly 40K lines per developer per month to around 400K.
I like the first number. I’m much more cautious about the second — nonetheless, this is the speed at which we have to progress.
Shipping smaller changes faster is useful. Lines of code, on the other hand, are not a productivity metric. Here, they tell us something else: the amount of software passing through the engineering system changed by an order of magnitude.
Our security team did not become ten times larger. Neither did the number of hours available for code review.
That was the moment this stopped being a conversation about developer productivity for me. We had changed the economics of producing software without changing the economics of verifying it.
The obvious response would have been to automate more of the review. We did some of that. But I increasingly think that’s the wrong place to start. If AI can produce software much faster than humans can inspect it, building a faster inspection line doesn’t solve the underlying problem. You have to change what happens before the software reaches the inspection line.
We noticed it first in the review
In the first iteration, which I’m not covering here, the output quality was terrible and visibly AI-generated. We tried to prevent AI slop with structure, and agreed to become “sloperators” — a good kind — so AI becomes a tool serving us, not the other way around. Maybe it’s worth a new term: (security) Sloperators, because we can’t avoid working with AI today, but we can control how we use it and where it lives.
Compared to now — with intent, rule, scaffolding, and review — you can still notice AI’s fingerprints here and there, but the agent has taken on the style of each one of us, and our ability to act and fix is far beyond what we could do before. So we iterate faster than ever.
Regardless of before and after, there’s an undeniable fact: code arrives at a speed and volume that were unseen — 10 to 20x more. There was simply more software arriving than humans could meaningfully inspect. You can hide that behind tooling and process metrics for a while, but eventually the arithmetic wins.
Take the number of pull requests you merge every month. Multiply it by the amount of time you genuinely expect an engineer to spend understanding each change. Then compare that with the review capacity you actually have.
That calculation is more useful than most AppSec maturity assessments.
And this isn’t unique to us. Faros AI’s 2026 engineering data, drawn from telemetry across roughly 22K developers, reports that 31.3% of pull requests are now merging without human review.
I find that number more interesting than almost every AI productivity statistic I’ve seen this year. I don’t think thousands of engineering leaders collectively decided that code review no longer mattered. The volume changed underneath the control. Nobody switched it off. It stopped being able to run at the rate work arrived, and the dashboard kept reporting green because every pull request was, technically, reviewed.
A short note on the productivity argument
I’m deliberately not claiming AI makes every developer twenty times more productive. METR’s controlled study is a useful warning here: experienced developers actually took longer when using AI on the tasks they measured, even though they believed they had become faster.
But genuinely, we reclaim time to do more and design better, think more deeply about the features we want to deliver, and iterate faster based on customer feedback. That’s the bottom line everyone should be looking for, regardless of which faction they’re in — anti-AI or pro-AI.
AI makes producing things extraordinarily easy. That makes the system around generation — the planning, the constraints, the verification, the governance — more important, not less.
Where should the reclaimed time go
This is the part of the AI development conversation I think we’re getting wrong. We keep asking what developers should do with the time AI gives back. The obvious answer is: build more. I’m not convinced that’s the best answer.
Some of that time should go back into thinking. If an agent can implement in twenty minutes what previously took an engineer half a day, I don’t necessarily want that engineer immediately generating the next four features. I want some of that reclaimed time spent making the first decision better:
- Is this the right architecture?
- What data are we introducing?
- What trust boundary are we changing?
- Which dependencies are we allowing?
- What should the agent never be permitted to do?
- What does secure look like before we ask it to generate anything?
That’s a very different SDLC. The developer isn’t disappearing from the loop. The valuable part of the developer’s time is moving.
I think the same has to happen to AppSec. Security engineers should spend progressively less time processing the consequences of insecure decisions, and more time encoding the conditions under which secure decisions get made. Writing a threat model, a set of security requirements, and a project-level rule file prevents more vulnerabilities per hour than triaging the findings those same decisions would have avoided. I can’t prove that with a controlled study. I can tell you it matches what we measured internally when we moved the effort.
Our own rebalance — offered as our operating model rather than a benchmark: we used to spend about 70–80% of engineering time on building, testing, and fixing late-stage issues. We now spend closer to half on building and design, roughly a third on verification distributed through the lifecycle, and the remainder on governance and improvement.
The total security effort didn’t go down. I want to be clear about that, because “AI lets you do security with fewer people” is a claim I won’t make and haven’t seen substantiated anywhere. The effort moved earlier, into decisions with higher consequences.
Three things need protecting now, and most programs cover one
Traditional application security asks how quickly we can find insecure code. That question is still valid. It’s no longer sufficient, because the code isn’t the only thing an attacker can reach.
The software is being generated
Veracode tested more than 100 models across 80 coding tasks and found an OWASP Top 10 vulnerability in about 45% of generated code. Their March 2026 update found the security pass rate essentially flat across model generations.
The team here at Phoenix Discover Context was slowing down models and incurring higher token costs, especially when running triple-pass validation — checking the work with a judge, validating, and a verifier pattern. Check the results at ai-scan-cost.phoenix.security.
That last detail is the one worth sitting with. Models have gotten considerably better at writing code that works. They have not gotten better at writing safe code. There is nothing in that data to suggest the next release changes it, which means the constraint must come from outside the model.
The developer and the development environment
In March 2025, Pillar Security disclosed hidden Unicode bidirectional markers and zero-width joiners embedded in Cursor and Copilot rule files. The agent read them as instructions. The reviewer read them as metadata. Both were correct.
Nothing in that file would have failed a code review, because the malicious content was never rendered to the human at all. GitHub added a hidden-Unicode warning to its diff view that May, which helps, and which also tells you the platform vendors consider this a live problem rather than a research curiosity.
The agent and its supply chain
This is the part I worry about most, and it is the part almost nobody has budgeted for.
When four SAP CAP and mbt packages were poisoned in April 2026, the payload did not stop at stealing credentials. It wrote SessionStart hooks into the agent’s settings file and folderOpen triggers into the editor’s task configuration. Opening the repository was enough. The agent’s own configuration had become the persistence mechanism.
Our Supply Chain Acceleration Report 2026, built on two years of Phoenix malware package intelligence, tracked 59 campaigns across that period. Agent skills carry a 15.6% risk rate, more than double IDE extensions. None of those 59 campaigns had a CVE assigned to them.
If your dependency control is a scanner reading a CVE feed, it has no detection surface for any of them. The attacker did not exploit a vulnerability. The attacker exploited trust: a maintained package, a legitimate publisher, a valid CI identity.
Signing has not closed the gap either. The Bitwarden CLI compromise abused npm trusted publishing, and the npm worm that followed in May shipped with valid build provenance attached. Provenance tells you where something came from. It does not tell you what is inside it.
I find this genuinely difficult, and I do not think the industry has an answer yet. What I am confident about is that the answer is not another feed.
Why did we change at Phoenix?
None of this arrived as a strategy. It arrived as a sequence of things that stopped working.
Phoenix Purple came from a simple frustration. We had security guidance, and nobody read it when it mattered. If generating a feature takes one prompt and securing it takes six dashboards, three tickets, and a specialist workflow, security loses every time someone is under deadline pressure. So the security check had to live in the same session as the generation, invoked the same way, which, for us, became a single command plus project-level rules and hooks that determine whether anyone remembers to run anything. The token routing work came later, and for a boring reason: at $15 to $25 in provider tokens per AI-reviewed pull request, a control that sends everything to the most capable model available is one your CFO eventually switches off.
Phoenix Blue Shield came from realizing that secure code generation is irrelevant if the agent installs a malicious dependency thirty seconds later. Evaluating packages and skills behaviourally, at the moment the agent reaches for one, is the only point in the chain where refusing is cheap.
Phoenix Orange exists because preventing everything is impossible, and somebody still has to understand what matters once code is running. Attribution, code-to-cloud correlation, deduplication, and reachability are unglamorous, and they are what turn a queue into a program.
The Frontier-Ready Vulnerability Management Program we built with the Cloud Security Alliance describes the effect at scale: a 112,000-finding backlog reduced to roughly 300 items worth anyone’s attention.
Phoenix Green completes the loop because finding something without safely deploying the change is not remediation. Grouping matters more than autonomy here. A dependency bump touching forty services is one unit of work. A breaking change to an authentication path is a different object entirely and should be routed to the human who owns the consequences.
What we do not do
We do not let an agent approve its own work. Branch protection turns everything it writes into a pull request, and a code owner signs it off. We do not let an agent past the production gate. We do not run unattended remediation on anything with a breaking-change profile.
And I am not going to claim our throughput increase came with proven quality parity, because I do not yet have a change-failure number I would defend in public. When I have one, I will publish it, even if it is unflattering.
What I would do on next
Run the arithmetic first. Merged pull requests per month, multiplied by honest review minutes, against real reviewer hours. Whatever that number is, it is the strongest argument you have for changing anything else.
Then put your agent configuration under change control. Rules, skills, hooks, MCP server definitions and standing instructions belong in version control with named owners and a review path. They are executable, they govern what thousands of generated lines look like, and there is now documented exploitation of every one of those file types.
Then move one control from detection to prevention and measure the difference over ninety days. One security rule at project level, enforced rather than suggested. Anthropic’s own AI-native SDLC playbook arrives at the same distinction between advisory and enforced controls from a completely different starting point, which is a reasonable signal that the shape is not something a security vendor invented.
The old SDLC secured what developers built. The AI-native SDLC has to secure the system that builds it.
The data behind this article is available in full in the Phoenix Security Supply Chain Intelligence Report
