Engineer A is the subject of the Cambrian explosion. Then we found two more Camunda engineers who got there on their own. Nobody taught them this approach: we found them when we started looking at how to expand it across the organisation, and each had taken a different path.
Engineer B works on the SaaS console and its operations tooling, and went agentic independently of Engineer A. Before agents, B already shipped in small, fast steps: about 34 pull requests a month, a median of 33 changed lines, nearly all approved by a colleague.
From late 2025 the rate tripled, to about 100 a month, and the pull requests grew to a median of 76 lines. Colleagues still approved 94% of them.
Then B ran an experiment: build a whole product from a written plan, in one go, in a private sandbox repository. One of the first pull requests added the CI gates. After that, every pull request carries a task ID from the plan, and each one merged through those gates.
The fence mattered. No person reviewed the sandbox, but in the same months B’s work in shared repositories was still 75% approved by a colleague. Zero eyes where the blast radius is contained; human review where it is not.
Engineer C maintains a deployment repository that many teams depend on, and went agentic independently too. Every change there is reviewed by another maintainer, and nobody wanted to change that.
From April 2026 C went agentic. C’s pull requests in that repository went from 10 a month to 47, and they got bigger. The review rule held: colleagues approved 98% of them.
The median time from open to merge went from 11 hours to six days. That looks like a slowdown. It isn’t: merged pull requests went from 9 a month to 34. Time to merge measures how long one change waits. Throughput measures how much gets done.
The reviewers scaled too. Human reviews of C’s pull requests went from 14 a month to 69, five times as many. The queue of open pull requests grew from a handful to between 10 and 30, and it drains: it does not grow month on month. That is a longer queue, not a backlog.
The wait has three parts. A first review now comes after about a day instead of a few hours, because reviewers batch their work. Most changes now get a round of comments. And after approval, a change waits about 19 hours instead of 2 for CI and the merge queue. More pull requests were also closed without merging, as approaches were tried and dropped.
The risk is concentration: two reviewers do most of the reviews. C’s answer was to work on the gate, not around it. C reviews as much as C writes, and built tools for the queue: a multi-agent PR reviewer with domain checks, a test bed for merge-queue races, and a CLI for running agents across many repositories.
None of them copied the others. Each went agentic on their own, with their own tools, in a different setting, and the setting decided where the speed went. Even so, all three ended up putting agent reviewers in front of the merge, each with their own setup.
| A · Derive | B · Fence | C · Gate | |
|---|---|---|---|
| Setting | SDKs and tools: one owner before, a pod of three after | Product team; a private sandbox | A repository many teams depend on |
| PRs a month, before → after | 11 → 95 | 34 → 100, and 1,900 in five weeks in the sandbox | 18 → 75 |
| Median PR size | 114 → 285 lines | 33 → 317 lines | 57 → 126 lines |
| Approved by a colleague | Rarely, before and after. Before: one owner. After: the tests and the agent loop are the gate | Mostly in shared repos; never in the sandbox | Always, before and after |
| Median time to merge | Under an hour | Under an hour; up to 2 hours in shared repos | 11 hours → 3–6 days, while merged PRs a month went up almost 4× |
| Where the speed went | Into new repositories, languages and people | Into a whole product, fenced off | Into throughput, paid for with a longer wait per change, and into tools for the review queue |
Source for this section: pull requests in Camunda’s GitHub organisation by each engineer. “Before” is May 2024 – April 2025 for A and B, and May 2025 – March 2026 for C, who went agentic later. “After” is May – October 2026 for A and B (B without the sandbox), and April – September 2026 for C. Line counts here include generated files. AI reviewers and bots do not count as a colleague. Direct commits without a pull request, and work outside the organisation, are not included. Snapshot taken November 2026.
All three engineers use agent reviewers. What differs is who decides that a change is finished. That explains the different times to merge.
None of these is wrong. Where a change can break other teams, C’s gate buys safety with time. Where the loop is trusted, a human signature costs little, and it adds little. The choice should be deliberate, per repository.
Source: merged pull requests in Camunda’s GitHub organisation, May – October 2026 (C from April). An agent round is a review by an AI reviewer, or a comment that an agent posted: a verdict, a review report or an “addressed in <commit>” reply. Loops that ran before the PR was opened are not visible, so these numbers undercount them. A comment-free approval can still follow a careful read; the short gap after the last agent round is the stronger signal.
Engineer A derived everything from a hardened spec and let the loop decide. Engineer B put the gates in first and fenced the experiment off, so it could run with zero eyes. Engineer C kept the human gate on shared code. Each change waited longer, but the reviewers scaled with the volume, so the queue grew without becoming a backlog, and C started building tools for the gate.