Security review was designed around a quiet assumption: a human wrote every line, at human speed, for human reasons. Break that assumption and the whole model stops working. AI broke it two years ago. Most security gates still run as if it never happened.

AI didn’t start the war between your security team and your developers. It handed the developers a machine gun and left the sentry at the gate checking IDs one at a time.

Here is the uncomfortable part. Both sides think the other one is the problem, and both are half right.

The Assumption Nobody Updated

The gate was calibrated for a throughput that no longer exists. When a senior engineer hand-wrote 200 lines a day, a human reviewer could hold the whole change in their head, ask the right questions, and sign off with real confidence. The control matched the flow.

Now the flow is a firehose. Sundar Pichai told investors in October 2024 that more than a quarter of new code at Google is AI-generated, reviewed and accepted by engineers. That share has only climbed since. The person at the gate did not get 4x faster. The author did.

Neither tribe has fully absorbed what that does to the model. So the misunderstanding runs in both directions, and it is worth naming each side honestly.

The Developer’s Blind Spot

Developers have quietly promoted “the AI wrote it” to the status that “it compiled” used to hold. Both are statements about whether something runs. Neither is a statement about whether it is safe.

The data on that gap is brutal and, more importantly, not improving. Veracode’s 2025 analysis of more than a hundred models found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability when the model had a choice between the secure and insecure pattern. The tempting rebuttal is “the next model fixes this.” It hasn’t. Veracode’s Spring 2026 follow-up found the security pass rate stuck near 55%, essentially flat across two years of GPT-5, Gemini 3, and Claude 4.x releases. The code got more fluent. It did not get more secure.

Endor Labs put a finer point on it in April 2026. Their agentic benchmark found the best-performing coding agent passed 84.4% of functional tests and 17.3% of security tests. The code works. The code is not safe. Those are different sentences, and velocity makes it dangerously easy to read the first as the second.

The velocity is also partly an illusion the author cannot see. I wrote about this in Everything Is a Skill Issue: developers routinely feel faster while shipping the same amount, or less, at higher risk. When speed feels like competence, security reads as latency. That is the developer’s blind spot in one line.

The Security Team’s Blind Spot

Now the other side, because it is just as real.

Your security team is being asked to govern a craft most of them stopped practicing years ago. They can read a dashboard. They can run the scanner. Ask them to read the actual diff, follow the data flow through three AI-generated helper functions, and reason about whether the machine just introduced a subtle authorization bug, and many cannot. They are auditing frameworks that shipped after their last real commit.

Their threat model quietly assumes a human author: human volume, human intent, human patterns of mistake. AI violates all three. It generates confident, idiomatic, well-formatted code that looks reviewed because it looks clean. Clean is not the same as safe, and the tells a veteran used to spot in a rushed junior’s pull request are not the tells a model leaves behind.

This is why the “shift left” slogan curdled. Tanya Janca has argued for years that marketing turned it into “buy our product and developers will magically fix everything.” Security became a purchase instead of a practice, and a gate at the end instead of a skill in the middle. AI just exposed the bill.

The Math That Turns a Gate Into Theater

Put the two blind spots together and you get an arithmetic problem, not a personality clash.

Faros AI studied teams leaning hard on AI and found they merged 98% more pull requests while review time rose 91%. Codacy’s data is starker: 31% of pull requests now merge with no review at all. When the queue doubles and the reviewer doesn’t, only two things can happen. Either the gate becomes a rubber stamp, which is theater, or it becomes a bottleneck everyone learns to route around, which is worse.

Joe Donovan named the failure mode precisely: “When security is framed as a gate, every release becomes a negotiation. Teams learn to route around you, exceptions multiply, and risk hides in shadow paths.” That is not a hypothetical. That is the equilibrium when machine-speed authorship meets human-speed review. The gate is already theater. Most organizations just haven’t said it out loud.

The Objections Worth Taking Seriously

Before the fix, the honest objections, because a provocation that dodges them is just noise.

“Security engineers shouldn’t have to write code.” Correct, and I am not asking them to. There is a real difference between writing production code every day, which no AppSec role requires, and being able to read a diff, trace a data flow, and reason about implementation-level risk, which the job now demands. You can retire from shipping features. You cannot retire from understanding what you are signing off on.

“AI helps the defenders too.” Also correct, and this is the strongest counter. AI-powered review, autonomous remediation, and agentic scanners genuinely scale with the volume. But notice where that leaves the human who cannot read the code. If defense is now machine-versus-machine, the manual gatekeeper is not saved by AI. They are routed around by it. The argument for automation is an argument against the human gate, not for it.

“This is an org problem, not a knowledge problem.” The most sophisticated objection, and partly true. A small central team as a mandatory checkpoint for many fast teams is a structural bottleneck no amount of upskilling fully cures. Fair. But a gatekeeper who cannot read AI-generated code is a worse bottleneck than one who can, in any org chart you draw. Structure explains the shape of the problem. It does not excuse the specific failure.

And yes, gates were arguably always theater. The difference is that theater you could survive at human commit rates becomes a live vulnerability at four times the volume.

Guardrails Were Always the Answer

Jason Chan, then running security at Netflix, gave a talk in 2013 called “From Gates to Guardrails.” The idea was simple: stop making security a checkpoint a human stands at, and start encoding it into the paved road everyone drives on. He was right a decade early. AI velocity is what finally made him non-optional.

A guardrail is not a nicer gate. Pixee put the distinction bluntly: if your “guardrail” just routes a finding to a developer as a notification, “that’s not a guardrail, that’s a gate with a softer name.” A real guardrail encodes the judgment once and applies it continuously, at the speed the code is being written, without a human in the critical path. That is the only kind of reviewer that scales with a machine author: another machine. I sketched what that looks like in practice in Validation Hooks, where deterministic controls run at commit speed instead of waiting for a review meeting.

Which means both tribes have to move, and neither wants to.

The security engineer has to re-enter the craft. Jason Frugé framed the generational shift well: “Cloud required DevSecOps. AI requires DevSecEng.” The job is no longer to stand at the gate and say no. It is to build the guardrail, write the policy-as-code, tune the automated remediation, and understand the tools well enough to know when they lie. That is engineering, not gatekeeping.

The developer has to carry the risk they used to hand off. The reviewer is no longer a safety net stationed downstream. When 31% of pull requests merge unreviewed, ownership of the vulnerability moves to whoever accepted the AI’s suggestion. As Simon Willison put it, “Our job is not to type code into a computer. Our job is to deliver systems that solve problems.” Solving the problem now includes owning what the machine wrote under your name. This is the same graduated-trust question I worked through in The Trust Ladder: autonomy has to be earned by the control around it, not granted by default.

The Part That’s Hard

None of this is a weekend migration. Retraining a security organization out of the gatekeeper identity is a multi-year cultural shift, and the incentives fight it the whole way. The gate is visible. It shows up in an audit. It feels like control. A guardrail that silently prevents the bad commit produces no meeting, no ticket, no evidence of heroism. You are asking people to trade the theater of control for the reality of it, and the reality is quieter.

Both sides also have to give up a comfortable story. Security has to stop pretending a human at the end can catch what a machine produced at the start. Developers have to stop pretending the machine’s confidence is their own competence. The velocity was never the achievement, and I made that argument at the org level in The Bottleneck Was Never the Code.

The machine gun is not going back in the box. The only real question is whether the thing standing between it and production is a person checking IDs one at a time, or a guardrail moving at the same speed as the threat.

---

The gate was built for a human. The code is not written by one anymore. Rebuild the gate, or admit you took it down.

For the org-level version of this same failure, see The Bottleneck Was Never the Code: the tool almost never fails, the organization around it does.

Find me on X @orestesgarcia or LinkedIn.