DEV Community: Manos Saratsis

AI Agents Write 30% More Code. Finished Work Hasn't Moved. Review Is Why.

Manos Saratsis — Thu, 15 Oct 2026 19:32:51 +0000

Originally published on the Dromeas blog.

In short: A new Harvard working paper tracked about 700 companies as they rolled out AI coding tools. Once firms adopted coding agents, engineers wrote 30% more lines of code and opened 23% more pull requests. The number of finished tickets didn't significantly change. The authors trace the gap to code review: review time went up 49%, and the share of PRs sent back with changes requested nearly doubled. If you measure AI by commits, you're measuring the wrong step.

The study, briefly

Fiona Chen and James Stratton at Harvard used data from Jellyfish, an engineering analytics platform, covering roughly 700 firms and 700,000 workers from January 2021 to March 2026. That's commits, pull requests, Jira tickets and calendar events, about 300 million work events in all.

They compared firms before and after they adopted AI coding assistants (autocomplete-style tools) and AI coding agents (tools that take a task and produce changes on their own). Firms adopted at different times, partly because procurement takes longer at some companies than others, so they could compare adopters against firms that hadn't adopted yet.

It's the biggest look at AI in real engineering orgs I've seen this year, and it's built on what teams actually did, not what they said in a survey.

More code, same output

Here's what changed per engineer, per month, after a firm adopted coding agents:

Metric	Change	vs. baseline
Lines of code	+1,494	+30%
Commits	+4.57	+20%
Pull requests	+1.22	+23%
Jira issues resolved	+0.12 (not significant)	upper bound ~12%

Assistants showed smaller gains: commits up about 9%, and no significant change in lines or PRs.

The last row is the one that matters. The authors put it plainly: "productivity gains do not fully pass through to changes in software output or employment." Their confidence intervals rule out issue-output gains bigger than about 12% for agents, well below the 20–30% jump in code activity. Epics didn't move either, and tickets didn't get smaller or bigger to hide the effect.

Employment didn't move much in either direction over the period they could measure. So this isn't a story about AI quietly replacing engineers. It's a story about work piling up somewhere.

Where it piles up: review

The paper's answer is the step right after writing. As they put it, "Writing code is only one step in a multi-stage production process."

After agent adoption:

Time from PR to merge went up by 3.45 days, from a 7.03-day baseline. That's 49% longer.
The share of PRs with changes requested went from 13% to about 25%. The authors' words: "the share of pull requests with changes requested nearly doubles."
Review comments per PR rose 35%.
PR size didn't significantly change. So it isn't just bigger diffs taking longer.
The share of people doing code review went up 14%, while the share writing code stayed flat.

One junior engineer they interviewed summed it up better than any chart: "People could make a huge number of commits quickly, but code review was still the bottleneck."

The authors' model offers two reasons that stack. First, more draft code simply means more to review. Second, if each change carries more problems, every review takes more rounds. They don't measure defects directly, but more change requests and more comments on same-sized PRs point that way. That matches what I've written about behavioral bugs in AI code: agent-written code tends to look clean, so the problems surface in back-and-forth, not in the first glance.

AI review is already here, and humans are still in the loop

This part surprised me. By March 2026, nearly 80% of the firms in the sample had used some AI code review tool. Yet only 23.3% of review comments came from AI, and only 10.8% of pull requests got any AI-generated comment at all.

So AI review exists, but it's spread thin, and it hasn't cleared the queue. A senior engineer they interviewed put it this way: "Even with AI tools, you absolutely still need humans involved in the review process."

I agree with that. The question isn't human or AI. It's whether the review step gets the same investment the writing step just got.

What I'd take from this

Stop using commits as the AI scorecard. The paper notes that "Many managers rely on intermediate productivity metrics, such as lines of code or commits." Those numbers went up. Finished work didn't. If your AI rollout dashboard is lines and PRs, it's measuring the step that was never the constraint.

Measure the review queue. Time from PR open to merge, the share of PRs with changes requested, and review rounds per PR. These are the numbers that told the story in this study, and most teams already have them in their Git host.

Budget for review the way you budgeted for agents. The authors' discussion has the most practical line in the paper: "Realizing the benefits of AI adoption requires complementary investments in downstream review capacity." That can mean people, process or tooling, but it has to mean something. Rolling out agents and leaving review as-is just moves the pile.

Make the reviewer's first pass cheaper. If most of the extra time is rounds of "please change this," then catching those issues before a human opens the PR, and showing the evidence, is where the time comes back. I wrote about how review differs on PRs vs trunk if you're deciding where that check should sit.

Make AI review something people can trust. Nearly every firm in the study tried AI review, yet it touched only about one PR in ten. My guess is that's a trust problem more than a tooling one. Engineers don't skip their own pass because a bot left a comment, and they shouldn't. What builds trust is review that behaves like a good colleague. It uses specialized checks (security, quality, compliance) instead of one generic pass. Several independent models have to agree before something gets flagged, so one model's blind spot doesn't become your problem. And it learns: when your team says "not relevant here," that should stick, so the same noise doesn't come back next week. Review that gets quieter and more accurate over time is review people stop double-checking.

Watch the release, too. Review is the first bottleneck. The release is where all the reviewed changes land together, and it's the next one.

Where Dromeas fits

This is the problem Dromeas is built around. Every PR and trunk commit gets reviewed by specialized agents for security, code quality and compliance, and their findings go to a council of models from several providers that cross-check each other before anything is flagged. Each verdict comes with the evidence behind it, so a human reviewer starts from findings rather than a blank diff. When your team silences a finding, Dromeas turns that into a rule and stops raising the same noise, so review gets quieter over time instead of louder. On every tagged release, Dromeas runs readiness checks against the full release scope and issues a verdict with blockers and approvals. More on release management.

— Manos

Source: Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production," Harvard University working paper (not yet peer-reviewed), version of August 4, 2026. PDF

The AI Risk Gap Is a Release Gap

Manos Saratsis — Sat, 10 Oct 2026 08:00:00 +0000

Originally published on the Dromeas blog.

Gartner's latest quarterly has a line I keep coming back to: to protect the value you get from AI, plan to spend at least twice as much on derisking it as you spend on the tools themselves.

That's aimed at CEOs and CFOs. But if you run engineering or security, I think it lands on you faster than on anyone, because that's where AI output turns into something real. Agent-written code reaches production at the release. So that's where I'd look first.

A quick caveat. Gartner's numbers are about AI in general, not code. Everything below about releases is my reading, not theirs.

The gap, in Gartner's numbers

Their opening message calls the AI value gap "really an AI risk gap," and splits it into three pillars: cost, cybersecurity and trustworthiness. Miss one and you lose the value you were chasing.

Two data points from their CEO survey (203 executives, April to May 2026) stand out:

75% of CEOs are increasing spend on technology, data and IT. Only 28% are increasing spend on security and risk.
Only 37% say they're highly prepared for cyber escalation. For what Gartner calls AI industrialization, it's 20%.

And only 23% of CxOs say they're confident in their organization's generative AI outputs.

(Gartner is clear this is a survey of the people it asked, not the whole market. Take it as a signal, not a census.)

Why the release is the cheapest place to start

Derisking "AI" sounds huge. Governance frameworks, sandboxes, vendor contracts. Some of that is a company-wide job.

But for software, there's one point every change has to pass through: the release. It's the last moment you can still say no, and it's where you can attach evidence to the yes. Let me take Gartner's three pillars one at a time.

Trustworthiness: can you say why this release is safe?

If only 23% of leaders trust their AI outputs, "the agent said it was fine" isn't going to cut it. A trusted release has a verdict and the evidence behind it: what was checked, what was found, how confident we are, and who or what disagreed.

Cybersecurity: guardrails that don't depend on someone remembering

Gartner's advice to CISOs is automated guardrails and containment, rather than hoping reviewers catch everything. For agent-written code that means checks that run on every change and every release, scoped to what actually changed, so they're fast enough that nobody routes around them.

The 28% figure matters here. Most security budgets weren't sized for the volume of code agents produce. A gate that scales with the diff is one way to keep up without hiring a reviewer per agent.

Cost: the iceberg under the license fee

Gartner talks about a "hidden iceberg" of AI costs: energy, data engineering, observability, workflow redesign, compliance audits. They note only 45% of senior functional leaders stayed on their planned 2025 AI budget.

The engineering version is rework. Bugs and security findings caught after release cost far more than ones caught before. I'm not going to put a number on it, because I don't have a clean 2026 source for one. But the direction is not in doubt.

"Certify before you scale," as an engineering checklist

One recommendation I liked: no AI pilot should get scale funding until the CFO, CIO and general counsel jointly certify its cost structure, value potential, data provenance and risk controls.

Here's how I'd translate that for a team shipping with agents:

Know where agents touch your code. Including the ones people installed themselves.
Gate every release on a verdict, not a vibe. What was checked, what was found, who signed off.
Keep the evidence. An auditor, a customer or your own CFO should be able to ask "why did this ship?" and get an answer in minutes.
Know what's inside. DataGrail's 2026 privacy report found 63.6% of software vendors that advertise AI capabilities don't disclose an AI subprocessor. Your own software should have a bill of materials for its AI, which matters more if you're covered by the EU AI Act.
Budget for it. If the AI tooling line grows and the checking line doesn't, that's the gap Gartner is describing.

Where we fit

This is what we build at Dromeas: code review and release checks with a verdict, the evidence behind it, and the audit docs generated as a by-product. More on the compliance side.

— Manos

Sources: Gartner Business Quarterly 4Q26: "The AI Value Gap Is Really an AI Risk Gap" (Sallam, Mesaglio) and "CEO Watch 4Q26" (Furlonger), based on the 2027 Gartner CEO Survey (203 respondents, Apr–May 2026) and the 2026 Gartner C-Suite AI Survey · DataGrail, Privacy and AI Trends Report 2026

DORA and AI-Generated Code: What EU Financial Teams Need From Their Release Pipeline

Manos Saratsis — Fri, 09 Oct 2026 08:00:00 +0000

Originally published on the Dromeas blog.

In short: DORA doesn't care who wrote a change, human or AI. It wants proof that every ICT change was assessed, tested and approved, and that vulnerabilities are tracked to closure. For teams shipping AI-generated code, that means a review and release record you can show a supervisor.

DORA has applied since January 2025. For a lot of engineering teams at EU banks, insurers and payment companies, 2025 felt like a warm-up year. Compliance advisors are now describing 2026 as the year supervisors actually start using their powers: reviews, findings, and eventually penalties.

At the same time, a growing share of the code going into those systems is written by AI. Those two things meet in your release pipeline, and I think it's worth being clear on what DORA really asks for there.

The parts of DORA that land on engineering

DORA (the Digital Operational Resilience Act, Regulation 2022/2554) gets called a cybersecurity law, but it's really about resilience. It wants financial firms to be able to handle ICT disruptions, and to be able to show it. Three parts matter most for a software team.

ICT risk management. You need a documented framework, owned by the board. The detailed technical standards get specific. There's an article on vulnerability and patch management, and another, Article 17, simply called "ICT change management." It asks for documented procedures for how changes get approved, tested and recorded. In practice: have a real review and release process, and keep evidence that you followed it.

Third-party risk. This is the one people tend to underestimate. You keep a register of every ICT third-party arrangement (what it does, what data it touches, where, and under what contract). You look at concentration risk. And your exit plans have to be ones you could actually carry out. In November 2025 the European supervisors published their first list of 19 "critical" ICT providers, the big cloud and infrastructure names, which are now overseen directly at EU level. That list gets updated every year.

Penalties. A lot of explainers get this part wrong. For those critical providers, DORA sets the penalty itself: up to 1% of average daily worldwide turnover, charged daily for up to six months. For financial firms, each country sets its own maximums, and they vary a lot. A DLA Piper briefing from last November found turnover-based caps from 5% in Spain to 10% in Sweden, and fixed caps from €2 million in Czechia to €20 million in Italy. If you've seen a neat "2% or €1 million" figure somewhere, it doesn't match how DORA works.

Why AI-generated code makes this harder

DORA doesn't mention AI. It doesn't need to. A change to a production system is a change, whether a senior engineer wrote it or a coding assistant did. The obligations stay the same. The volume and speed of change don't.

I see two separate problems here.

Evidence isn't keeping up. Tricentis published their 2026 Quality Transformation Report in June, based on 2,501 people across six countries. Six in ten organizations said they deploy untested code to production. Financial services came out worst at 64%. And 30% said the sheer volume of AI-generated code is more than their teams can fully test. For a firm covered by DORA, "we shipped an AI-assisted change we didn't fully test" isn't just a quality issue. It's a hole in exactly the change management evidence Article 17 asks you to keep.

The AI tool is a third party too. If your engineers use a coding assistant, or you've wired a model into your review or release pipeline, that vendor usually belongs in your register like any other ICT provider. What does it do, what data can it see, where is that data processed, and could you switch if you had to? A handful of model providers dominate this market, which is exactly the concentration question DORA asks. The regulation doesn't spell this out. It's how the compliance advisors I've read apply DORA's existing third-party rules to AI vendors.

Put simply: AI-assisted development doesn't change what DORA asks of you. It makes the paper trail a lot harder to keep by hand. An approval from someone who didn't write most of the diff isn't strong evidence on its own.

Where Dromeas fits

Dromeas sits between AI-assisted coding and production, and a lot of what it produces happens to be the evidence DORA-covered teams need anyway. Every PR, trunk commit and local diff gets reviewed by a council of models from different providers that cross-check each other, and each verdict comes with the evidence behind it. Every tagged release gets a verdict across six checks, plus a changelog grounded in the real diff. See release management for how that works, and compliance for the frameworks we cover.

It doesn't replace your compliance team's reading of DORA. It means the evidence exists when they need it, instead of being pieced together afterwards.

— Manos

Sources: EIOPA, DORA overview · RTS 2024/1774 via Springlex · Morgan Lewis, critical ICT providers · DORA Article 35 · DLA Piper, DORA penalties · Tricentis 2026 Quality Transformation Report

NIST and AI-Written Code: The SSDF Gap and the New AI Agent Standards

Manos Saratsis — Thu, 08 Oct 2026 08:00:00 +0000

Originally published on the Dromeas blog.

In short: NIST's SSDF (SP 800-218) still holds up on outcomes, but it assumes people write and review the code. With AI at 42% of committed code, the gaps are non-deterministic output, review volume and the pipeline itself as a target. NIST's separate AI Agent Standards Initiative (Feb 2026) puts coding agents in scope, but nothing is final yet. You can act on both today.

If you sell software to the US government, or to anyone who borrows its procurement checklists, you've probably met NIST's Secure Software Development Framework. SSDF for short, SP 800-218 if you like numbers.

It's a sensible document. I mean that. It was also written for a world where a person writes the code and another person reads it before it merges. That world is shrinking fast. Sonar surveyed over 1,100 developers in January and found AI already accounts for 42% of committed code. Only 48% of those developers said they always check AI-assisted code before committing it.

So I wanted to look at where the SSDF still holds up, where it starts to creak, and what you can do while NIST works through it. NIST is also working on AI agents directly, and coding agents are clearly in scope, so this covers both.

Part 1: The SSDF gap

The SSDF in two minutes

It's split into four groups of practices:

PO, Prepare the Organization. Roles, requirements, training (PO.2), and PO.3, which is about having the right tooling in your pipeline to enforce everything else.
PS, Protect the Software. For example PS.3: archive every release so you can prove what shipped.
PW, Produce Well-Secured Software. PW.5 says follow secure coding practices. PW.7 says review or analyze the code for vulnerabilities. PW.8 says test the executable code.
RV, Respond to Vulnerabilities. Find them on an ongoing basis, fix them, and dig into root causes so they don't come back.

Nothing in there says a human has to write the code. Most of it is about outcomes, which is why it's aged better than you might expect. The trouble is the stuff between the practices. Training developers so they write secure code. Review sized for human output. Tools that give you the same answer twice. All of that assumes a human-paced pipeline.

Where it creaks

Sonar published a piece in June called "What NIST should know when updating the SSDF for AI." It's their opinion, not NIST's, but it names the problem well. I'd group it into three things.

Same input, different output. A traditional scanner gives you the same result on the same code every time. A model doesn't. Same prompt, same repo, and you can get a clean implementation today and a subtly broken one tomorrow. So you can't let the thing that generated the code also be the thing that signs off on it. Something outside that loop has to check, every time.

Volume. In the same Sonar survey, 38% of developers said reviewing AI-generated code takes more effort than reviewing a colleague's. GitClear's January report, based on 623 million code changes, found duplicated code blocks up 81% since 2023, and copy-pasted code now outpacing refactoring about five to one. More code is going in, less of it is getting cleaned up, and there are the same number of reviewers.

The pipeline as a target. This one isn't about code quality. Agents now have write access to repos and CI. A prompt injection hidden in an issue or a dependency, or a plausible-looking commit that quietly adds a backdoor, is a different kind of risk. The RV practices assume the vulnerability is in the code, not in the tool with credentials that's writing it.

What NIST is doing about the SSDF

NIST put out a draft of SSDF 1.2 on December 17, 2025, with comments open until January 30. It adds some useful things: PO.6 on continuous improvement, PS.4 on reliable updates (staged rollouts, safe rollbacks), and it expands RV.1.2 to cover testing default configurations, not just source code. As far as I can tell, it doesn't say anything specific about AI-written code yet.

One mix-up I keep seeing: SP 800-218A, the AI-specific SSDF profile from 2024, is about securely building AI models. It doesn't cover using AI to write your regular application code.

Part 2: NIST's AI agent standards

Most of the AI agent governance content I read imagines a bot booking flights or answering support tickets. So I was a bit surprised when the AI Agent Standards Initiative announcement listed "write and debug code" right up front among the things agents now do.

What NIST announced

The initiative launched on February 17, 2026, run by NIST's Center for AI Standards and Innovation (CAISI). It has three parts: helping industry develop agent standards (and keeping the US involved in international standards bodies), supporting open-source agent protocols, and funding research on agent security and identity.

A month earlier, NIST published a request for information on AI agent security. It covers systems "capable of planning and taking autonomous actions that impact real-world systems or environments," and it leaves out plain chatbots and RAG systems that don't take actions on their own.

That definition is a handy test. Does your agent change something outside itself? An agent that drafts a PR for a person to review is a gray area. An agent that merges to trunk, pushes its own fix, or edits your CI config is clearly in.

The RFI closed in March. A separate NCCoE concept paper on agent identity and authorization closed for comments in April. So where are we? Nothing is final. There's no agent standard yet, no benchmark, no certification. If someone tries to sell you "NIST AI agent compliance," they're ahead of NIST.

The research behind it

The first set of numbers you'll see quoted is from January 2025, a full year before the initiative. NIST researchers tested agent hijacking against Claude 3.5 Sonnet and found that new, purpose-built attacks pushed success rates from 11% to 81%. When they let each attack run 25 times instead of once, average success went from 57% to 80%. Good research, but it's from 2025. Plenty of articles this year present it as new.

The newer data is from March 2026. NIST ran a red-teaming competition with over 400 participants who made more than 250,000 attack attempts against 13 frontier models. Coding agents were one of the scenarios tested. Every model had at least one successful attack, and how vulnerable a model was didn't line up neatly with how capable it was.

Why coding agents are a special case

It has write access to the thing your business runs on.
Its "action" is a commit, a merge or a deploy, not a reply to a ticket.
It reads untrusted text all day. READMEs, issues, dependency manifests, CI configs. Any of those can carry instructions.

Does your CI bot hold a permanent admin token, or does it get a short-lived credential scoped to the one PR it's working on? You'd ask the same thing about a contractor with commit access.

What to do now, and what can wait

Do now	Why	Framework hook
Treat PW.7 and PW.8 as mandatory for AI-written changes	Volume is up and skims miss things	SSDF PW.7, PW.8
Don't let a single model grade its own homework	Same input, different output	SSDF PW.7
Keep a record for every change: what was checked, the verdict and why	That's your evidence six months from now	SSDF RV.1
Find where agents already touch your code or pipeline	You can't govern what you can't see	Agent initiative
Move agents onto scoped, short-lived credentials	Agents hold write access	Agent identity and authorization
Make every agent action that changes code or config leave a trail	What ran, what changed, and why	Agent initiative
Treat prompt injection as a design problem	Coding agents read untrusted text all day	Agent security RFI

Fine to wait on: picking an identity protocol stack (commentary points to OAuth, OpenID Connect, SPIFFE/SPIRE, SCIM and MCP as likely building blocks, with agent-to-agent delegation still open), and any certification. It doesn't exist yet.

Where Dromeas fits

We run agents too. That's what our review is. Every PR, trunk commit and local diff gets checked by a council of models from several providers that verify each other's findings, which is our answer to the "same input, different output" problem. Every tagged release gets a verdict across six checks, backed by evidence from the actual diff. If you're mapping that onto the SSDF, it lines up with PW.7 and PW.8 on the review side and RV.1 and RV.2 on the response side.

I'm not going to call us "NIST-compliant." There's nothing to comply with yet for agents, and the SSDF update is still a draft. More on code security.

— Manos

This is moving quickly. Treat it as a snapshot from September 2026.

Sources: NIST SP 800-218 · SSDF 1.2 draft · Cycode on SSDF 1.2 · Sonar, June 2026 · Sonar survey, Jan 2026 · GitClear, Jan 2026 · NIST AI Agent Standards Initiative · Federal Register RFI · NIST hijacking evaluations, Jan 2025 · NIST red-teaming competition, Mar 2026

What Is AI SAST? How Agentic Code Review Differs From Pattern-Matching Static Analysis

Manos Saratsis — Wed, 07 Oct 2026 08:00:00 +0000

Originally published on the Dromeas blog.

In short: classic SAST matches known-bad patterns, fast and repeatably. AI SAST adds reasoning about data flow and intent across files, which catches behavioral bugs rules miss, but it's less deterministic. It's best treated as a layer on top of rules, not a replacement.

	Classic SAST	AI SAST
How it finds issues	Rules and known-bad patterns	Reasons about data flow, intent and context
Same code, same result?	Yes	Not always, so it needs cross-checking
Strong at	Injection, secrets, known CWEs	Logic, authorization and cross-file bugs
Weak at	Business logic, behavior	Explaining itself unless evidence is required

"AI SAST" is everywhere this year. Checkmarx has a learn page on it, Augment Code wrote a 2026 guide, and plenty of other AppSec vendors have picked up the label. Some of that describes a real change in how code gets checked. Some of it is a rule engine with a chatbot bolted on.

I build a code review product, so I have a stake in this. Here's how I'd tell the two apart.

What classic SAST is good at

Static application security testing reads your source code without running it and matches it against a library of known bad patterns. A SQL query built by gluing strings together. A hardcoded API key. An outdated crypto function. It doesn't need to know what your code is for. It just needs to recognize the shape of a known problem.

That's useful. It's fast, it's cheap to run across a big codebase, and it's deterministic: same code in, same result out. As a CI gate that blocks obviously risky patterns before a person ever looks at the PR, rule-based SAST is still a good tool.

The limit is built in, though. A rule engine only finds what someone already wrote a rule for. Even the SAST vendors say this: if the rules are incomplete, things get missed.

What it can't reach

A lot of the bugs showing up in AI-generated code aren't known bad patterns at all. We went into this in our post on behavioral bugs. It's code that runs, passes the linter, looks fine in review, and then does the wrong thing for an input nobody tried. An off-by-one on a boundary. A null check on the wrong variable. Two functions that disagree about whether a list has already been deduplicated.

Nothing about that code is syntactically wrong, so there's nothing for a pattern to match. To catch it you have to understand what the code is supposed to do and compare that with what it actually does.

New Relic's 2026 State of AI Coding report shows what this looks like in practice. 94% of the tech leaders they surveyed rated AI-generated code as higher quality than human code at review time. And 82% had at least one major production failure tied to AI code in the previous six months. Code that looks good in review and breaks in production is exactly the kind of bug static analysis was never going to find.

What AI SAST actually adds

Augment Code's guide makes a useful distinction between two kinds of tools:

AI-assisted: the rule engine still does the detecting, and a model helps with triage, prioritization and fix suggestions.
AI-native: a model is the detector. It reads the code and reasons about what it does, more like a reviewer than a linter.

The second kind is the interesting one. A model can follow data across several functions and files, work out what a change affects downstream, and judge whether something is a real problem in context. Multi-step issues that only show up when you trace the whole path are within reach in a way they aren't for a fixed rule set.

Where it falls short

This is the part the marketing tends to skip.

It isn't deterministic. Run the same review twice and you can get two different answers. That's a problem if you need consistent results for an audit.

It costs more and it's slower. A model call per file or per PR costs more than a rule sweep, and it takes longer.

One model is still one opinion. A single model judging intent will produce false positives. They just look different from a rule engine's.

Developers already feel this. In Sonar's January survey, 96% said they don't fully trust that AI-generated code is functionally correct, and 38% said reviewing AI code takes more effort than reviewing a colleague's. If people don't fully trust a model's code, it's fair to ask why they'd trust a single model's verdict on a vulnerability.

Questions to ask a vendor

Is the model doing the detecting, or just triaging what the rules found?
What happens if you run it on the same PR twice?
Is more than one model checking a finding before it reaches you?
Does it look at what a change affects elsewhere in the codebase, or only at the diff?

Where Dromeas fits

This is why we don't send every finding through one model. Each PR, trunk commit and local diff reviewed by Dromeas is checked by a council of models (Anthropic, OpenAI's GPT-5, Google's Gemini 2.5 Pro, DeepSeek V4 Pro) that verify each other's findings before anything reaches you. They reason over a code map of your repo (files, symbols, call graph), so they see what a change actually touches, not just the diff on its own.

Known bad patterns (OWASP Top 10, CWE, supply chain) are covered on our code security side. The behavioral bugs that pattern matching can't reach are what Bug Tracing is for. They're aimed at different mistakes, and you want both.

AI SAST is a real shift. Just make sure whoever's selling it to you has a plan for checking the model too.

— Manos

Sources: Checkmarx, AI SAST · Augment Code, AI SAST 2026 guide · New Relic, 2026 State of AI Coding · Sonar survey, Jan 2026

ISO 42001 for Engineering Teams: What It Actually Asks You to Prove

Manos Saratsis — Mon, 28 Sep 2026 14:39:19 +0000

Originally published on the Dromeas blog.

In short: ISO 42001 is a voluntary, certifiable standard for managing AI systems. For engineering teams it's mostly about evidence: showing how AI-assisted changes are reviewed, tested and approved. It complements the EU AI Act and SOC 2 rather than replacing them.

Framework	Type	Question it answers
ISO 42001	Voluntary certification (3 years, with surveillance audits)	Is your AI governed?
EU AI Act	Law, with penalties	Does your AI meet legal obligations in the EU?
SOC 2	Attestation	Do your security controls work?

ISO 42001 keeps turning up in the same sentence as SOC 2 and the EU AI Act, usually on a slide that implies you need all three by next quarter. I wanted to know what it really asks of the people who write and ship code, so I sat down with it.

Short version: it's less about paperwork than I expected, and a lot more about evidence.

What it is

ISO/IEC 42001 is the international standard for an "AI management system." ISO published it in December 2023, and it's still the current edition. If you've been through ISO 27001, the shape will feel familiar: a set of clauses on how you run the system (the usual plan, do, check, act loop), plus an Annex A with 38 controls across nine areas. You pick the ones that apply and justify your choices in a Statement of Applicability.

The important bit: it's not a spec for how your model should behave. It's about how your company governs the AI it builds, buys or uses. Who's accountable, how you assess risk, where your data comes from, how you watch things once they're live, and what happens when something goes wrong. It applies whether you're building AI products or just letting your engineers use AI tools.

Who's going for it

It's early. BCG announced in January that it was among the first 100 organizations certified worldwide. Pega got certified in February for Pega Cloud and its GenAI features. I couldn't find a reliable global count of certified companies, and I'd be a bit wary of anyone who quotes one.

The trajectory looks a lot like SOC 2 a few years back. AI vendors selling into enterprise are the first to feel it, because it starts showing up in security questionnaires. If that's you, it's worth knowing what it'll ask before a customer asks first.

What an auditor actually wants to see

Certification happens in two stages. The first is a document review: your AI policy, your risk register, your Statement of Applicability. The second is the one that catches people out. The auditor checks that your controls actually run, which usually means interviews, watching processes, and pulling samples. They'll pick a feature or a date and ask you to show them the control working then.

For an engineering team, the Annex A areas that land on your desk are roughly these:

Lifecycle (A.6): design decisions, what you verified before deploying, what changed in each release.
Data (A.7): where your training, fine-tuning or RAG data came from, how you checked its quality, and what you did when problems showed up.
Impact assessment (A.5): done before launch, not written up after an incident.
Use (A.9): evidence the system is used within its intended purpose.
Suppliers (A.10): if you call a foundation model API, who's responsible for what.

The general rule auditors follow will sound familiar if you've done SOC 2. A record that was produced independently, timestamped and tied to a specific decision counts for a lot more than a policy saying the process happens. Policy says what should happen. Evidence shows it did.

How it fits with the EU AI Act and SOC 2

We've written about the EU AI Act before. It's law, with real penalties, and it applies if you serve the EU market. ISO 42001 is voluntary. You get certified by a third party, the certificate lasts three years, and there are surveillance audits in between.

They cover a lot of the same ground (data governance, risk, human oversight, transparency), but one doesn't satisfy the other. If you're building a high-risk system under the Act, a 42001 certificate is useful supporting evidence. It doesn't replace the legal obligation.

SOC 2 is a different question again. It tells a customer your security controls work: access, encryption, incident response. It says nothing about how you govern the AI itself. Some analysts are already describing ISO 42001 plus SOC 2 Type II as the new baseline for AI vendors selling to enterprise. That's one view, not a rule, but it gives you a sense of where things are heading. Three audits, three different questions: is your AI governed, are your security controls working, is your infrastructure secure.

Where Dromeas fits

We don't certify anyone. That's accredited third-party work, and it should stay that way.

What we do produce is the kind of record the Stage 2 auditor goes looking for. Every pull request and trunk commit gets reviewed. Every tagged release gets a verdict across six checks (quality, security, compliance, testing, docs, instrumentation), grounded in the actual diff and stamped with a date. If an auditor asks "show me what was verified before this release shipped," that's already sitting there. More on how we handle frameworks on our compliance page.

— Manos

Sources: ISO/IEC 42001:2023 · BCG, Jan 27, 2026 · Pega via Businesswire, Feb 3, 2026 · Konfirmity, Annex A controls · ISMS.online, ISO 42001 vs EU AI Act · Vanta, EU AI Act & ISO 42001 · Knowlee, ISO 42001 vs SOC 2 vs ISO 27001

Behavioral Bugs Are Still Slipping Through AI Code Review. Here's What Actually Catches Them.

Manos Saratsis — Thu, 17 Sep 2026 15:28:04 +0000

Originally published on the Dromeas blog.

The pull request looks clean, the linter's green, the tests pass — and the code still does the wrong thing the moment someone hands it an input nobody thought about. Not a crash, not a lint warning. Just the wrong answer, quietly.

I've been digging into why that keeps happening even as AI writes more and more of our code, and it turns out there's decent data on it now — not just vibes. So let's go through what the numbers actually say, why the tools most of us already run can't really catch this category of bug, and what I think actually works.

What the 2026 data says

First: people don't fully trust this code, and it's specifically about correctness, not whether it runs. Sonar's 2026 State of Code Developer Survey found 96% of developers don't fully trust that AI-generated code is functionally correct, and 61% agree that "AI often produces code that looks correct but isn't reliable." Only 48% say they always verify AI-assisted code before committing it. Worth sitting with that for a second: the complaint isn't "it doesn't compile." It's "it runs, it looks fine, and I don't actually know if it's right."

Second, when you break down what kind of bugs show up, it lines up with that. A 2026 empirical study ("Debt Behind the AI Boom") looked across five widely used AI coding tools — Copilot, Claude, Cursor, Gemini, Devin — and found code smells made up 89.3% of flagged issues (the stuff any linter catches fine). Correctness issues were a smaller slice, 6.0% — but the single most common one was "undefined variable or reference," almost 24,000 instances, which the researchers describe as code that "may look locally correct, but still fails to stay consistent with the surrounding context." That's a pretty good one-line description of the whole problem. More than 15% of commits from every single tool they studied introduced at least one issue, and 22.7% of the AI-introduced issues they tracked were still sitting in the repo, unnoticed, at the time of the study — some for nine months or longer.

Third, when this reaches production, it's not staying theoretical. New Relic's 2026 State of AI Coding report found 82% of organizations had at least one major production failure caused by AI code in the past six months, and 78% report a measurable spike in incidents tied to AI code overall — with AI-generated code introducing roughly 1.7x more critical runtime issues than human-reviewed code. CloudBees' 2026 State of Code Abundance report found something similar from a different angle: 81% of enterprise leaders report increased production issues tied to AI code, and their own summary of it stuck with me — "writing code is no longer the primary bottleneck, governing it is." Same conclusion, three separate 2026 surveys.

And the backdrop makes all of this harder to catch by hand. GitClear's 2026 research tracked eight quality signals across 623 million code changes from 2023 to 2026, and the trend lines aren't great: duplicated code blocks up 81% since 2023 (highest on record), copy-paste share of changed lines up from 9.4% to 15.7%, actual refactoring down about 70% over the same stretch. GitClear's own read on it: block duplication is the single risk signal most tied to defects and propagated bugs in the research they looked at. So more code is shipping, less of it is getting consolidated or re-examined, and reviewers have less bandwidth per line than ever.

Put simply: it's not that AI writes "bad" code. It clears the bars we're good at checking automatically — style, structure, the obviously dangerous patterns — and it's specifically weaker on whether the logic holds up for a real input, in a way that's now showing up as real production failures, not just review comments. That's worth being precise about, because it tells you exactly why the tools most teams already run don't solve it.

What these bugs actually look like

"Behavioral bug" is the term I keep reaching for, but it's worth knowing it's not the only name people use for this — you'll see the same basic idea called logic bugs or logic errors (the plain-English default), semantic bugs (more of an academic/compiler-literature term — the code is syntactically fine but means the wrong thing), correctness bugs or correctness issues (the term the arxiv paper above uses), business logic bugs or business logic vulnerabilities (the AppSec framing), and functional bugs (QA/testing terminology). Some people just call them silent bugs or silent failures, which honestly might be the most useful name of the bunch — it points at the actual property that makes them dangerous: nothing crashes, nothing throws, nothing shows red in CI.

In practice, most of what falls under that umbrella breaks down into a handful of recurring shapes:

Boolean logic bugs — an inverted condition, the wrong operator, a guard clause that lets through exactly the case it was written to block. Classic version: a permission check written with || where it needed &&, so access gets granted if any one condition is met instead of requiring all of them.

Reference correctness bugs — stale closures, the wrong variable captured, the wrong object mutated once two calls overlap. Classic version: a loop that captures its loop variable by reference in a callback, so every callback ends up pointing at the last value instead of the one that was current when it was created.

Boundary and indexing bugs — the everyday off-by-one: loop bounds, first/last-element handling, pagination math. Classic version: a "load more" offset computed as page * pageSize instead of (page - 1) * pageSize.

Normalization-symmetry bugs — a value gets normalized on write but not on read (case, whitespace, encoding), so a lookup silently misses. Classic version: emails lowercased at signup but not at login.

Nullability bugs — a new code path where a value can legitimately be absent, and nothing downstream accounts for it.

Shared-state concurrency bugs — races between concurrent writes, a rollback to a stale captured value, a cache write that clobbers something fresher.

None of these are exotic. Every engineer has shipped at least one of each at some point. What's changed is the volume and the plausibility — code that reads as confidently correct, generated fast enough that nobody's tracing each new input by hand anymore.

Why static analysis can't really get at this

Tools like SonarQube, Semgrep, and CodeQL work by pattern matching — an AST shape, a taint path from untrusted input to a dangerous sink, something that matches a known CWE. Genuinely useful, and it's why these tools are worth running. But it only works if the bug matches a pattern someone already wrote a rule for.

Most behavioral bugs don't work that way. Gecko Security put this well in a piece on why static analysis struggles with business logic: a lot of these bugs are about something being missing — a missing auth check, a missing validation step — rather than something dangerous being present that a rule can flag. Taint analysis can tell you untrusted data reaches a sensitive spot. It can't tell you whether the authorization logic guarding that spot is actually correct. And a lot of the bugs that cause real incidents span multiple files — their example is a real Cal.com auth-bypass bug that needed three separate issues chained together across different files, each looking fine on its own.

So that's the real limitation: pattern matching can tell you something looks like a shape it's seen before. It can't tell you that a specific input, actually walked through the logic, produces a different result than it should. That requires tracing behavior against intent — and it happens to be exactly where the data above says AI-generated code is weakest.

It's also why I think "detect that AI wrote this, then review it harder" — which a few vendors have shipped, SonarQube's AI Code Assurance being one — is sorting on the wrong axis. It's routing on who wrote the code, when the thing that actually matters is what the code does. The question was never "who wrote this" — it's "does this do the right thing for a real input," and that needs tracing, not detection.

Where this leaves Bug Tracing

This is basically the problem we built Bug Tracing to solve inside Dromeas — trace real inputs through the actual changed code and check what comes out, instead of scanning for patterns. The six categories above are exactly what it scores every change against, and it only reports a finding if it can name the concrete input that triggers it — no reproducible trace, no report.

And because "review a diff" and "audit a whole system" are genuinely different jobs, it runs at whichever scope your team actually works at: on the pull request itself (changed lines plus their blast radius), on a branch or release after merge for teams doing trunk-based development, or as an on-demand sweep across a whole repository when you just want a second opinion on a system nobody's looked at closely in a while.

If this is a problem you're running into, happy to show you how it works — the feature page is at dromeas.ai/bug-tracing.

Shadow AI in Your Codebase: The Governance Gap Most CISOs Haven't Mapped Yet

Manos Saratsis — Sun, 13 Sep 2026 13:27:37 +0000

Your AI code policy covers approved tools. The harder question is whether every change faces the same evidence-backed review, regardless of what wrote it.

Shadow AI is no longer a vague compliance concern. It describes employees using AI systems outside an organization's approved controls. The result can be both data exposure and software entering production without a consistent review record. That second problem matters even when the code looks ordinary.

A note on sourcing: the figures below come from a mix of primary surveys and industry roundups, and each is attributed to the publication that states it. Shadow-AI measurement is still thin, so treat the percentages as directional signals rather than settled numbers.

The visibility gap is larger than most programs assume

Airia's 2026 overview collects findings from named third-party studies: source code represented 35% of sensitive-data events involving AI tools in Cyberhaven's 2024 data; 60% of security teams lacked visibility into which AI tools employees used, per Cisco's 2024 AI Readiness Index; and Gartner reported in 2025 that 43% could not audit or inventory the AI tools in use.

A separate JumpCloud summary reports widespread unsanctioned assistant use. Survey percentages are useful warning signals, but they don't establish which tool authored a given line in your repository. That distinction matters when choosing a control.

Source code creates two different shadow-AI risks

Input risk appears when proprietary code, secrets, customer data, or architecture details are sent to an unapproved service. That requires controls such as approved-tool policy, identity and endpoint management, DLP, vendor review, and data-retention rules.

Output risk appears when generated code is accepted because it looks plausible, or enters through a workflow that never receives equivalent quality, security, and compliance checks. This is the part a repository and release review layer can address directly.

Govern the output without pretending the tool is invisible

Banning unsanctioned tools doesn't guarantee compliance, but governing only the output doesn't solve data leakage either. A durable program needs both: discover and control the tools where possible, then require the same review bar for every software change regardless of authorship.

This avoids a fragile "detect AI code, then review it differently" path. Pull requests, direct commits to the default branch, and pre-PR local diffs can all enter through different routes. The control should follow the change.

What an AI-BOM can, and cannot, tell you

Dromeas generates an AI Bill of Materials when a product actually invokes AI or machine-learning systems: a machine-readable CycloneDX 1.6 ML-BOM plus a human-readable report covering detected AI/ML components, data flows, risk classification, EU AI Act obligations, and source-backed provenance. For multi-repository products, the documentation process assembles evidence across the whole product rather than treating each repository as an isolated system.

That's an inventory of AI/ML components used by the software. It is not a forensic attribution system for which coding assistant wrote each line, and it doesn't calculate a trustworthy percentage of AI-authored code. It complements workforce AI-tool inventory, DLP, endpoint controls, and an AI-use policy; it doesn't replace them.

A practical first step

Inventory the services: use identity, network, endpoint, procurement, and expense data to find unapproved AI tools.
Protect the inputs: define what code and data may be sent to each approved service, and enforce it with technical controls.
Standardize the output gate: review PRs, trunk commits, and local agent diffs against one policy.
Record what shipped: keep review and release evidence, and generate an AI-BOM for software that contains or invokes AI/ML components.

Shadow AI can't be solved by one inventory or one scanner. It becomes governable when tool controls and change-level evidence meet at the release boundary.

Full piece, with more on Dromeas's changed-code and blast-radius review pipeline (independent Security, Quality, Compliance, and Bug Tracing analysts) plus AI-BOM documentation, originally published at dromeas.ai: https://dromeas.ai/blog/shadow-ai-in-your-codebase

Which AI Model Writes the Most Secure Code? What the 2026 Data Actually Shows

Manos Saratsis — Sun, 13 Sep 2026 13:26:40 +0000

Ask five engineering leaders which AI coding model is "safe," and you'll get five confident, contradictory answers. Veracode's 2026 GenAI Code Security Report gives the question a measured answer: across its benchmark tasks, AI-generated code passed security tests 56% of the time and introduced a risky vulnerability in the other 44%. That's effectively flat from the previous report's 55% pass rate, while Veracode estimates AI now authors roughly half of committed code.

Flat security performance at higher volume isn't a wash. It's the same failure rate landing on more production code.

The plateau nobody's marketing slide mentions

A separate CodeRabbit study reported 2.74x more vulnerabilities in AI-co-authored pull requests than in human-only pull requests, from 470 open-source PRs (320 AI-co-authored, 150 human-only), not from Veracode. CodeRabbit notes an important limitation: authorship was inferred from signals rather than confirmed ground truth.

Different datasets point in the same direction: model capability and secure output don't rise on the same curve.

Vulnerability class matters more than the average

Veracode's aggregate result hides a much sharper spread:

SQL injection: 83% pass rate
Cryptographic implementation: 87% pass rate
Cross-site scripting: 15% pass rate
Log injection: 12% pass rate

The hard cases require context: where untrusted data entered, how it moved through calls, where it reached a sink. That's a dataflow problem, not a syntax problem.

Model selection is a security decision, not a security control

GPT-5.5 led Veracode's benchmark at 68%. More than half of tested models clustered at 50-53%. Coding-specialized models averaged 51%, general-purpose models 52%, and reasoning models 56% vs. 51% for non-reasoning variants. Model size showed little correlation with security outcomes.

There's no universal "most secure" model. Even the benchmark leader failed nearly one test in three.

What to do with this data this quarter

Ask for weakness-level evidence, not just an aggregate score.
Review at the change boundary: local diffs, PRs, trunk commits, while context is fresh.
Prioritize reachable risk over raw finding counts.
Record the policy: which models, which checks, who signs off.

The 2026 data doesn't identify a shortcut past review. It makes the case for a review layer that stays useful when the model roster changes.

Full piece, with more on Dromeas's multi-model review pipeline (independent Security, Quality, Compliance, and Bug Tracing analysts), originally published at dromeas.ai: https://dromeas.ai/blog/which-ai-model-writes-most-secure-code

MCP for Code Review: What It Is, and How to Add a Review Layer to Claude Code or Cursor

Manos Saratsis — Wed, 09 Sep 2026 13:24:23 +0000

Originally published on the Dromeas blog.

Your coding agent writes code. MCP is how you give it a reviewer. Here's what the protocol actually does — and a working setup you can copy in minutes.

MCP, in one paragraph

The Model Context Protocol is an open standard that lets an AI client — Claude Code, Cursor, Windsurf, Zed — call external tools through a uniform interface. Instead of pasting output between your terminal and a review dashboard, the agent invokes a tool like review_pull_request directly and receives the result as structured data it can reason about. Tool support, not copy-paste, is what makes an agentic loop possible: the agent can act, observe the verdict, and repair — the loop we described in loop engineering.

Why a review layer belongs in the loop

A coding agent with no review layer grades its own homework. It writes a diff, checks that it compiles, and declares victory. A review layer changes the economics: the same agent submits its diff, gets an independent multi-model verdict — security, quality, compliance — and fixes what it finds before a human spends a minute on it. Self-review before the PR is the single highest-leverage place to insert checking, because the cost of a fix there is one tool call, not a review round-trip.

The setup, step by step

Connect your repositories. Sign up at dromeas.ai and connect GitHub, GitLab or Bitbucket. Dromeas builds a typed code map of your repos so review verdicts come with real context.
Get your MCP endpoint. Open Settings > MCP in the Dromeas app and copy your workspace's MCP server URL and API key. One endpoint covers Claude Code, Cursor, Windsurf, Zed and any other MCP-capable client.
Add the server to your client. In Claude Code run claude mcp add with the URL; in Cursor, add the server under Settings > MCP. The review tools appear in your agent's tool list immediately.
Ask your agent to self-review. Before opening a PR, ask your coding agent to submit the diff for review. It calls review_pull_request or review_local_diff, gets a multi-model verdict, and can fix what it finds before a human ever looks.

What your agent can actually do once connected

The Dromeas MCP server exposes the full review surface as tools: review_pull_request and review_local_diff for verdicts, code_finder_search and the code-map tools for cheap context before edits, get_findings and the fix tools for acting on results, and release tools like describe_release_state for go/no-go decisions. The point is that review isn't a dashboard your agent can't see — it's a function it can call.

Because every tool call is scoped to your workspace and logged, you keep the audit trail that matters when agents start merging on their own. That's the same provenance property the CISO checklist depends on.

Connect a repo, copy your MCP endpoint, and your coding agent gets a six-agent review council it can call from the terminal. Read about loop engineering for the fuller picture of what the loop looks like end to end.

The CISO's Guide to AI-Generated Code at Scale

Manos Saratsis — Wed, 09 Sep 2026 13:23:14 +0000

Originally published on the Dromeas blog.

AI-generated code has 2.74x more vulnerabilities than human-written code. Copilot adoption is near-universal in the Fortune 100. And the EU AI Act's high-risk obligations now land on 2 December 2027. Here is the checklist that actually matters.

The security conversation about AI-generated code has moved past "should we allow it" — your engineers already use it, and most of them use it daily. The question now is operational: how do you govern a codebase whose authorship is increasingly non-human, at a pace no review board can match?

Three numbers frame the problem. AI-generated code carries roughly 2.74x more vulnerabilities than human-written code (Veracode 2025). GitHub Copilot is used by around 90% of the Fortune 100 (GitHub), before you count Claude Code, Cursor, and the rest. And the EU AI Act's obligations for high-risk AI systems now apply from 2 December 2027 — pushed back from August 2026 by the AI Omnibus, which entered into force on 27 July 2026 (systems embedded in regulated products get until 2 August 2028). The extra runway does not change the expectation: documented provenance, an AI Bill of Materials, and evidence of how AI-assisted code was checked. If your governance plan is still "we'll review the PRs carefully," it is already behind the reality on your main branch.

Where the risk actually concentrates

Not all generated code carries the same risk. In practice the exposure clusters in three places, and each one has a different mitigation shape:

Dependency and secret drift. Agents reach for packages and patterns from training data — outdated versions, deprecated libraries, and occasionally hardcoded credentials in example-shaped code. Static dependency scanning catches the known-CVE slice; it misses the "correct-looking but wrong" slice, like an auth helper that works and is subtly unsafe.

The review blind spot. Human reviewers read generated code more charitably than human-written code — it looks confident and idiomatic, so it gets skimmed. That is precisely the code the 2.74x number is describing. The blind spot isn't negligence; it's a predictable cognitive effect, which means it needs a systemic fix, not a reminder.

The provenance gap. When an auditor (or your own incident review) asks "what wrote this line, under which policy, with which model," most teams today have no answer. That gap is what the AI Act's AI-BOM expectation is aimed at: not knowing the answer is becoming a compliance finding, not just an inconvenience.

What a workable governance layer looks like

The teams that get ahead of this do three things, and none of them involve slowing developers down:

One bar, no detection step. Apply the same security and quality checks to every change regardless of authorship. Architectures that first "detect AI code" and then route it somewhere stricter add a failure mode (the detection) and a governance seam (the routing). Sonar is already retiring the auto-detection half of its own feature — we wrote up why that's the wrong default. A single uniform gate can't be skipped by mislabeling.
Post-merge coverage, not just PR gates. Agents increasingly commit directly to trunk. If your security review only exists on the PR, a growing share of your production code passes no gate at all. Every commit — PR or trunk — should get the same automated pass.
Provenance as a byproduct, not a project. Every review run should record what was checked, by which models, against which standard, with which verdict. Do that and the AI-BOM, the SOC 2 evidence, and the EU AI Act documentation all fall out of normal operation instead of becoming a quarterly scramble.

The questions to put in front of your team this quarter

If you do nothing else, get concrete answers to these:

Which agents and assistants are committing code today, to which repos?
What percentage of merges in the last 90 days had no human review?
If an auditor asked for a bill of materials of the AI systems that touched production last month, could you produce one?
Which checks run on trunk commits after merge — and who reads the results?
When a generated-code incident happens, what is the provenance trail you would walk?

Most organizations can answer one or two of these today. December 2027 sounds far away; the codebase you will be audited on is being written this quarter.

PR Review vs. Trunk Review: A Practical Guide to Choosing (or Combining) Both

Manos Saratsis — Wed, 09 Sep 2026 13:21:50 +0000

Originally published on the Dromeas blog.

PR review and trunk-based review solve different problems, and most teams already run a hybrid without naming it. This guide is backed by data from 100,000+ real pull requests and 24,000 trunk commits across 500+ open-source repos.

When we looked at that data, one finding kept surfacing in different forms: the PR-versus-trunk question isn't binary. Teams that think they've picked one are usually already running a hybrid, they just haven't named it. Here's what the data actually supports about when each one earns its keep.

What PR review is for

PR review is built for the moments that benefit from a checkpoint: large or risky changes, anything that needs discussion before it merges. That matters because PR size in the wild is bimodal — plenty of small, quick changes, but a heavy tail of 1,000+ line PRs that are exactly where a pre-merge gate is worth the friction it adds. The PR is also the only place where a change is still cheap to reject: once it merges, every fix is a new change instead of a revision.

What trunk review is for

Trunk review is built for everything else. Direct-to-trunk commits in our sample averaged 63x smaller than PRs — fast, low-friction, and increasingly the shape of how coding agents actually commit. Waiting for a full PR gate on every micro-change doesn't match agent-speed workflows, and it doesn't need to. The mistake is assuming "no PR" means "no review" — trunk commits can be reviewed after the fact against the same bar, without blocking the commit path.

The tail is where the time goes

The part that costs teams the most time isn't the average case in either lane — it's the tail. Rejected PRs took 6x longer to resolve than approved ones in our data. That's where review capacity actually gets consumed: not on the easy approvals, but on the changes that go back and forth. Any review strategy that doesn't have an answer for the tail — smaller initial diffs, automated first-pass review, faster feedback — will feel slow no matter which lane you picked.

A decision framework that matches reality

Instead of "PRs for everything" or "trunk for everything," score each change on four axes and let the lane follow:

Signal	Lean PR gate	Lean trunk + post-merge review
Change size	Hundreds of lines and up; the heavy tail	Tens of lines; single-purpose commits
Blast radius	Touches shared contracts, auth, billing, migrations	Local, reversible, behind a flag
Contributor type	New contributor, unfamiliar area, cross-team change	Owner of the area, or an agent doing a scoped fix
Discussion value	Design decisions others need to weigh in on	Mechanical or already-agreed work

Most teams discover their real policy is already this table, applied informally. Making it explicit does two things: it stops the arguments about whether a given change "deserved" a PR, and it makes the post-merge lane a first-class citizen instead of an unreviewed loophole.

Why most teams will end up running both

The forces pushing the two lanes apart are getting stronger, not weaker. Risky changes are getting larger (more generated code per PR), and routine changes are getting smaller and more frequent (agents committing at agent speed). A single gate tuned for one of those shapes fails the other: too much friction on the small stuff, too little scrutiny on the big stuff.

The workable shape is both lanes with the same rigor on each: a real gate on the PR for the changes that benefit from one, and automatic, same-standard review on every trunk commit for the ones that don't. That's the model Dromeas implements — the same six-agent pipeline and multi-model council runs on PRs and on trunk commits alike, so the lane choice is a workflow decision, not a quality decision.

The data behind this guide

104,968 PRs and 23,964 trunk commits measured across 503 open-source repos — size distributions, review latency, and the slow-motion rejection problem in full.

Read the State of AI Coding 2026 · See the charts