Zalando Auto-Approves a Third of PRs. Agents Made Them Bigger.

Zalando published 2.5 years of agentic engineering data across 250+ teams. The 20-40% pull request lead-time win came from a bot that auto-approves 33% of PRs without a human — while PR sizes climbed into the 1k-2k line buckets and per-commit cyclomatic complexity showed inflection points exactly where coding agents entered.

By Rajesh Beri·August 17, 2026·13 min read
Share:
A printed pull request diff on continuous fanfold paper spilling off a developer's desk onto the floor of an empty office, with a rubber approval stamp resting on top of the untouched top page. No text or logos legible.

Illustration generated using AI

The number your board will hear is a 20-40% cut in pull request lead time. The number that matters is 33% — the share of Zalando's pull requests that a bot now approves with no human reading them at all. Those two figures come from the same snapshot of 2.5 years of agentic engineering that Bartosz Ocytko, an Executive Principal Engineer there, published on 14 August 2026. It is the clearest published account of what happens when coding agents meet a real engineering org: throughput rose because a review gate came out, and the code arriving at that gate got bigger at the same time.

This is the rare dataset that is neither a vendor survey nor a lab benchmark. It covers more than 250 engineering teams, an internal LLM proxy serving 2,000 monthly active users, and per-commit complexity traces across four real codebases. Almost no other enterprise can produce it, and that — not the lead-time figure — is the finding you should act on.


Where the 20-40% Actually Came From

The lead-time reduction is not the coding agents. It is a separate piece of automation that removes the reviewer. Zalando "built a risk-based PR approval tool, triggered at PR creation stage," which grades every pull request low, medium or high risk. In the post's own words: "33% of our PRs are low-risk and are auto-approved by the bot," and "the author of the PR can thus choose to merge the PR, which in our case reduced PR lead time by 20-40% (when compared with all PRs)." Read that parenthetical closely, because it is doing real work: the 20-40% is how much faster the auto-approved third moves than the all-PR average, not a 20-40% cut in the organisation's lead time. And low-risk changes — documentation edits, backwards-compatible tweaks — would clear review faster than average even if the bot had never shipped, so an unknown share of that gap is selection rather than automation.

The rule set is genuinely well-built. It is "built based on analysis of our production incidents and the typical drivers for outages" — documentation-only changes are low risk, breaking backwards compatibility is medium and "requires judgement from another human," and configuration typos are high risk because a config typo caused a real outage they name in the post. That is incident-derived engineering, not vibes.

But notice what the published rule set is keyed on: blast radius and change category. Diff size is not among the risk drivers described. A backwards-compatible, non-config change is low risk whether it is nine lines or nine hundred. Meanwhile, the same post shows the diffs getting much larger.

The PRs Got Bigger as Review Got Thinner

Zalando's own PR size distribution moved up and to the right, and they date the move precisely. "In addition to a consistent increase in PR sizes of [100,500) we also see growth in the higher buckets since Sonnet 4 release in Q2/2025, esp. [500,1k) and [1k,2k)." Anthropic shipped Claude Sonnet 4 on 22 May 2025. That is a suggestive coincidence rather than a natural experiment. Zalando's own word is "since," there is no agent-free control on the PR-size chart the way there is on the complexity chart, and the same post describes engineers restructuring pull requests to court the approval bot — a second force acting on diff size over the same period, in the opposite direction.

Those buckets are exactly where human code review stops working. SmartBear's peer review research — drawn from a study of a single Cisco Systems team in 2005-2006, and published by a company that sells a code review product — is blunt about it — "developers should review no more than 200 to 400 lines of code (LOC) at a time," a review of 200-400 LOC over 60 to 90 minutes "should yield 70-90% defect discovery," and there is "a significant drop in defect density at rates faster than 500 LOC per hour." A 1,500-line pull request is not a slightly harder review. It is a review that, past the first hour, is mostly theatre.

GitHub's own guidance for agent-authored PRs, published in May 2026, lands in the same place: "The larger and less scoped the pull request, the more likely you're going to sink review time into something that goes nowhere," and it tells reviewers to send a PR back when "the diff touches more than five unrelated files." It also states flatly that "agent-generated code introduces more redundancy and more technical debt per change than human-written code."

Zalando saw this coming and handled it socially rather than mechanically: "teams who found large PRs to be a problem, have reached internal agreements that they will limit PR sizes to a fixed size." That is a per-team convention, not a platform control. The post is candid that hard enforcement through pre-commit hooks proved less popular than team agreements.


Complexity Has an Inflection Point With a Timestamp

This is the part almost nobody else can show. Zalando tracked total cyclomatic complexity per commit across four codebases — go-agentic-only (Go, new, agents from the first commit), go-reference (Go, 10+ years old, agents from commit 3000 on), java-with-agents (Java, 4 years old, agents from commit 1600 on), and java-reference (Java, 12+ years, no agent usage as a control).

Cyclomatic complexity is a count of the independent paths through a function — every branch, loop and conditional adds one. It is a proxy for how many cases a reader, a test suite, and the next engineer have to hold in their head.

The result, verbatim: "Looking at the total cyclomatic complexity evolution on a per commit level, we can pinpoint inflection points in code complexity at a time when coding agents come into the picture." And where agents were there from day one: "for codebases that started with full use of agentic coding, we see complexity to build up very quickly with growth fading out."

The honesty here is worth copying. The post does not declare this a defect. It offers the optimistic reading — "if code complexity is expected to plateau for a well-scoped microservice, one would hope this means that the time to build has been drastically reduced" — and then says plainly that time will show whether that is the case. A plateau reached in three months instead of two years is a win. A plateau reached because the service is already as tangled as a human can hold is not. Zalando does not yet know which one it has, and neither do you.

Nobody Else Can Run These Numbers

The reason this post exists at all is instrumentation that predates the agents. Zalando has run a LiteLLM-based API proxy since January 2024, fronting OpenAI, AWS Bedrock and Google Vertex, and it now serves "2k MAU with just six small (2k CPU, 4 GB) pods." Every agent call goes through one place, which is what makes attribution possible at all — the same argument for self-hosting the gateway before you need it, and the same gap that opens the moment a model runs outside any logging path.

Even with the proxy, attribution is hard. The post's complaint is one every platform team will recognise: "too often, tools use a generic User-Agent header, making it difficult to identify the tools used as clients of the proxy." On the git side, "some codebases carry markers (Co-authored-by) that confirm these inflection points; others (esp. OSS) have less consistency in these as not all authors disclose usage of coding agents."

The payoff is operational, not just analytical. Session data surfaced "a user with very low cache hit ratio for opencode (<30% vs. 80%+ expected)" — a pure cost finding you cannot get from a seat count. They inspect sessions with agentsview and usage across projects with codeburn.

Compare that to the field. When Cursor and Benchmark Partners surveyed the Fortune 500, 64% had deployed AI coding agents and 33% could measure the ROI. Harness put the number even lower, finding 94% of engineering orgs could not produce a defensible AI coding ROI figure. Airbnb's Q2 disclosure had the same shape — a headline velocity claim, with exactly one number an outsider could audit. Zalando is not smarter than these organisations. It wired the gateway first.

Engineers Are Already Optimizing for the Bot

Give an engineering org a classifier that decides which pull requests skip review, and the org will learn its edges. Zalando says so out loud: "anecdotal evidence shows that the bot affects behavior of engineers to increase the probability of a low-risk PR," with "PRs start to be broken down into those that can be shipped quickly (low risk) with backwards compatible-changes and less important medium-risk PRs dropping unused fields that require another approval."

Steel-man that, because the steel-man is strong. Splitting work into a backwards-compatible increment and a separate cleanup is exactly what a good engineer does anyway. The bot is teaching a genuinely healthy habit and paying people in merge speed to adopt it.

The risk is the second-order version. A metric that gates human attention becomes a target, and the same restructuring that produces small safe increments can produce a large change chopped into three "low-risk" pieces that nobody reviews as a whole. Zalando's rule set is derived from historical outage patterns, which means it is calibrated on the failure modes of human-written code. Agent-written code has a different distribution — more duplication, more plausible-looking wrong branches — and the classifier has not been retrained on it. This is the automation-bias problem in a new costume: a confident-looking assessment reduces the scrutiny applied to the thing being assessed.


What the Outside Data Says About Big Agent PRs

Three independent datasets say Zalando's complexity inflection is not a local anomaly.

Review is quietly vanishing on agent PRs. A study of 33,596 agent-generated pull requests in open-source GitHub repositories with 100 or more stars, published in May 2026 by researchers at Nicolaus Copernicus University, found that 61.38% carried no recorded review activity. The authors are careful that this is not proof nobody looked — "the absence of review comments does not imply that the code was not reviewed (e.g., it may have received a silent approval)" — which is precisely the ambiguity that makes the metric useless as an oversight signal. The sharper figure is who reviews when a review is recorded: human-only review accounts for 25.21% of reviewed human-authored PRs but just 8.08% of reviewed agent-authored ones, the remainder being bots or humans steering an agent. Their warning is the one to write down: "conventional review metrics should be interpreted with care when used as indicators of human oversight." An approval rate is no longer evidence that a person looked.

Maintainability signals are moving the wrong way industry-wide. GitClear's Maintainability Gap report, published January 2026 across 623 million analyzed changes from 2023-2026, is correlational and comes from a company selling the code-quality analytics it is reporting, with a proprietary methodology — trust the direction, not the decimals. It found duplicated code blocks rose from 40.3 to 73.0 per million changed lines — an 81% increase. Moved (refactored) code fell from 21% of changed lines in 2022 to 3.8% year-to-date in 2026. Cross-file function calls dropped 35%, from 343 to 223 per thousand changed lines. Long-term maintenance of older code fell 74%. That is a portrait of code being added rather than integrated.

And the delivery research already predicted the tension. DORA's 2025 State of AI-assisted Software Development report surveyed nearly 5,000 technology professionals and published on 23 September 2025. It found 90% of respondents using AI at work and over 80% believing it raised their productivity — alongside 30% reporting little or no trust in the code it generates. DORA's own analysis of the tension puts it in one sentence: "higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability." Zalando's charts are the in-house version of that sentence.

What to Instrument Before Your Next Rollout

The lesson is about sequencing. Zalando can argue about whether agents helped because it can attribute commits and trace complexity. If you cannot, your lead-time improvement is unfalsifiable and your complexity cost is invisible — and you will present the first to your board without knowing the second.

This Week:

  1. Pull your PR size distribution for the last 24 months, bucketed the way Zalando did it — under 100, 100-500, 500-1k, 1k-2k, 2k+. Overlay the date each coding agent went live per team. If the higher buckets moved, you have the same shift and no chart of it.
  2. Check what your LLM gateway sees. If your agent traffic carries a generic User-Agent, you cannot tell Copilot from Cursor from OpenCode in your own logs. Set a client-identifying header and reject calls without one.
  3. Turn on Co-authored-by trailers for every agent, in every repo, and make it a merge requirement. Retrofitting attribution is impossible; the commits are already written.

This Month:

  1. Pick one legacy service and one greenfield service and start tracking total cyclomatic complexity per commit. Two lines on one chart beats a quarterly quality score nobody reads. Keep one codebase agent-free as a control, the way Zalando kept java-reference.
  2. Audit whatever automation approves changes without a human. If you have a risk classifier, confirm diff size is one of its inputs — Zalando's published rule set is keyed on change category, not volume, and a 1,500-line backwards-compatible change is a very different object from a 15-line one.
  3. Cap review scope, not just PR size. The 200-400 line guidance predates agents by two decades, and nothing about agents raised the number of lines a human can hold at once.

Before Your Next Renewal:

  1. Tie the seat or token spend to something auditable. A 20-40% lead-time number attributed to the wrong cause is worse than no number, because it survives scrutiny long enough to justify the next purchase. This is the same discipline that separates a real agent trace from a vendor benchmark, and the same question worth asking before you standardise a coding assistant across hundreds of engineers.

The Bottom Line

Zalando did the hard thing and published the awkward half. The 20-40% is real for the third of pull requests that skip review, and it came from deleting a human step; the bigger PRs are real and arrived with a model upgrade; the complexity inflections are real and nobody yet knows whether they are efficiency or debt. That combination — a measured win, a measured cost, and an honest "time will show" — is what a mature agentic engineering program looks like in 2026. It is not a story about coding agents being good or bad.

The organisations that will regret this cycle are not the ones whose complexity went up. They are the ones who removed the reviewer, shipped faster, and built no way to find out what it cost.

Instrument first. You only get one chance to have a before.

Continue Reading

Share:

Frequently Asked Questions

What did Zalando's agentic engineering snapshot actually measure?

It covers 2.5 years across more than 250 engineering teams, an internal LiteLLM-based proxy serving 2,000 monthly active users since January 2024, PR size distributions, and total cyclomatic complexity per commit across four codebases — two Go, two Java, with one 12-year-old Java repo kept agent-free as a control.

Did coding agents cause Zalando's 20-40% PR lead time reduction?

No. Zalando attributes that figure to a separate risk-based PR approval bot that classifies each pull request low, medium or high risk at creation. 33% are graded low-risk and auto-approved without a human reviewer, letting the author merge immediately. Note the denominator: Zalando measures the 20-40% for that auto-approved third against the average across all PRs, so it is not a 20-40% cut in organisation-wide lead time. The coding agents are a parallel change, not the cause of that number.

Why does PR size matter more once coding agents are in use?

Zalando saw growth in the 500-1k and 1k-2k line buckets after Claude Sonnet 4 shipped in May 2025. SmartBear's peer review research finds defect discovery of 70-90% at 200-400 lines reviewed over 60-90 minutes, with a sharp drop in defect density above roughly 500 lines per hour — so larger diffs get materially weaker review.

What is cyclomatic complexity and why track it per commit?

Cyclomatic complexity counts the independent paths through a function — every branch, loop and conditional adds one. Tracking the total per commit rather than per release lets you line the curve up against the exact commit where coding agents entered a codebase, which is how Zalando identified its inflection points.

What should an engineering leader instrument before rolling out coding agents?

Three things, and all of them are hard to retrofit: Co-authored-by trailers on every agent commit for attribution, a non-generic User-Agent header on agent traffic through your LLM gateway so you can tell tools apart in your own logs, and a per-commit complexity baseline with at least one agent-free codebase as a control.

Newsletter

Stay Ahead of the Curve

Weekly enterprise AI insights for technology leaders. No spam, no vendor pitches—unsubscribe anytime.

Subscribe

Latest Articles

View All →