Three great pieces made this week showed us proof data points about the current state of engineering and security, and a glimpse of what’s to come. Gergely Orosz published a deep dive on what's actually happening to code review now that agents open most PRs, and Chris Hughes dropped two Resilient Cyber essays that complete the picture from the security side. Read together, they describe the same shift from three angles: the artifact humans author has moved up the stack, from implementation to intent. To stay relevant, AppSec has to move with it. Let's dig in.
This Week's Signals
Code review is fracturing. We finally have numbers to understand how.
Gergely Orosz surveyed how teams handle review now that agents generate most code, and the volume math is brutal: GitHub's own data shows PRs opened up have increased 5x in three years, nearly doubling since the end of 2025 alone. The dominant new pattern is humans reviewing the AI's review rather than the code, and risk-based triage is producing wild numbers: fifteen-person Duckbill went risk-based and merged 94% more PRs (80 to 154 per week), with median merge time of 1 hour for unreviewed changes vs 26 hours for human-reviewed ones. Weaviate's CTO describes his setup as 90% agents, with humans kept for scope decisions and exit criteria. The only teams that fully dropped human review are AI-native startups like Glide (4.5x more PRs merged), and even they built a gated rollout pipeline first: tests, evals, human sign-off, and an agent-monitored canary.
The data point worth sitting with: Duckbill's list of what still gets a human: public API and MCP, auth, design system, non-additive schema changes, and agent skills. That's a security-relevance list, written by an engineering team, without a security person in the room.
The most interesting pattern in Orosz's piece is the teams that stopped reviewing implementation entirely and moved the review to the before and after states. They grill the plan until it's specific enough to one-shot (Musixmatch's principal engineer: "After 3 hours of /grill-me, it better one-shot the implementation"), they review tests instead of code, and they treat the database schema as the one rigid thing worth human scrutiny because state outlives any implementation. Sigil's CEO frames it cleanly: business logic is now cheap and regenerable, so get the schema and the state machine right and let everything else churn. Even reviewers who still read code say their comments have become mini design reviews: reversibility, decision provenance, whether the tests test the right things.
Why this matters: This is the review surface converging on what security design review always cared about: intent, state, trust boundaries, and invariants. The industry is rediscovering it for throughput reasons rather than security reasons, but the artifact is the same.
Chris Hughes: the "left" in shift-left moved. Now your controls need to follow.
Hughes' new essay lands on the AppSec implication: shift-left was built for a human typing code into an IDE and opening a PR for a pipeline to scan, and that world is ending. The code is now written by an agent on a developer workstation with a shell, package manager, credentials, and MCP servers, taking hundreds of actions per task that no human reads, before any PR exists for your scanners to look at. Agents also quietly route around the hardened libraries and authenticated route abstractions your platform team built, writing raw code instead. Attackers noticed first: the Nx s1ngularity packages tried to use the victim's own local AI tools to hunt for secrets, and Shai-Hulud self-propagated through a compromised maintainer's other packages.
Why I'm flagging it: Most AppSec programs have exactly zero control points at the place where code now gets written. The PR-triggered pipeline still runs; it's just downstream of where the risk got created.
Discovery went industrial. The fix side is still human speed.
Hughes' companion piece assembles the discovery-side numbers into one uncomfortable picture: 35,364 CVEs published in H1 2026 (up 49.5% year over year, one every 7.4 minutes), Anthropic's Glasswing surfacing 10,000+ high or critical vulns across partners with a 90.6% true-positive rate on assessed findings, DARPA's AIxCC driving discovery cost to $152 per vuln, and the MOAK workflow going from a public React CVE to a working shell in 21 minutes with no human. Meanwhile the fix side hasn't moved: typical orgs remediate 1 in 10 backlog findings per month (Cyentia), median time to fully patch is 43 days (2026 Verizon DBIR), and two thirds of the labs' own verified findings are still unpatched. His answer is to stop playing per-finding whack-a-mole and eliminate entire vulnerability classes, prioritizing by exploitation, reachability, and business context instead of CVSS.
The numbers in context: Exploitation stayed flat at 1-2% of published CVEs, so this is a triage problem more than a threat explosion. But triage at machine speed requires context your scanner output doesn't carry.
Source: Verizon’s The DBIR’s Exploitation Era
So what’s the solution? Chris promotes the idea that CISA has been advocating for years through Secure-by-Design, which urges software producers to eliminate common vulnerability classes at the design time rather than playing catch up after code production. Threat modeling and design reviews are two pillars of secure-by-design.
My Take:
The Prompt Is the New Code
Here's the claim: the durable human-authored artifact in software is no longer the implementation. It's the prompt and everything that constrains it: the plan, the schema, the tests, the lint rules, the review gates. Code became a compilation target. And we've been here before: nobody reviews assembly output because we trust the compiler, but nobody should trust an agent the way we trust a compiler, which is exactly why the constraint layer is where scrutiny has to live.
The evidence from this week points the same direction from three independent angles. Engineering teams moved review to plans, tests, and schemas because reading code that is generated at machine speed is physically impossible for humans (Orosz, GitHub data). Security lost its control point because the risky actions happen on the workstation before a PR exists (Hughes, with s1ngularity as the proof attackers got there first). And the vulnerability pipeline now produces findings at $152 apiece while orgs fix 1 in 10 per month, which means per-finding review is dead as a scaling strategy no matter who does it.
So the work moves to the constraint layer. Duckbill's human-review list (auth, public APIs, schema changes, agent skills) mirrors what threat modeling has been doing for 20 years, and I think that's also the shape of AppSec's next decade: security review as design review of the artifacts that steer agents, not inspection of what they emit. This is obviously the thesis I'm building DevArmor on, so weigh my bias, but the engineering world arriving at the same artifact list for throughput reasons is the strongest independent confirmation I've seen.
The honest uncertainty: provenance. When an agent writes the code and another agent fixes it, I don't yet know what accountability looks like when the constraint layer itself was AI-drafted, and Hughes is right that HITL is doing a lot of unexamined work in everyone's answer. If you've found a review gate that actually holds at agent speed, reply and tell me what it looks like. I read every one.
Until Next Time
Somewhere this week an engineer approved a PR by reading an AI's summary of an AI's review of AI-written code. It worked fine. I can't decide if that's the punchline or the point.
Working on agent-era code review at your company? I'd love to chat. Hit reply.
Amir
Thanks for reading The AppSec Signal, DevArmor’s newsletter for security professionals.
Have feedback or ideas for what we should cover next?
Feel free to reach out - [email protected]
