DISCUSSION

pipelinesLinkhoneycomb.io ↗

30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems

Honeycomb's peak merges went from ~30 to ~74 a day and incidents from 18.5 to 53 a quarter. The CI, flags, and ownership that kept the extra change volume off the pager.

Illustration of a developer at a laptop beside a code document, a Honeycomb hexagon logo, and a rising bar chart

Why we picked it · the editor's summary

The change volume came in three steps as models and tooling improved, with the Opus 4.6 release in February 2026 the visible inflection, and the codebase went from 0.97M to 2.1M lines in sixteen and a half months while human-authored merges fell. What kept the pager quiet was already built: continuous delivery, CI fast enough to be legible, observability that maps a change to production behaviour, and blameless incident review. Incidents tracked change linearly; nothing AI-authored caused a catastrophic outage. Fong-Jones states the caveats herself: peak weekday figures, attribution as a floor, other org changes in the same window. The order she recommends is substrate first, then throughput. If your CI is slow and your ownership map is fiction, doubling merges doubles the wrong thing.

Read on honeycomb.io ↗23m read

Comments

Loading comments…

Back to all articles