{"slug": "embracing-the-code-review-bottleneck", "title": "Embracing the Code Review Bottleneck", "summary": "Fred Hebert's team at Honeycomb deliberately leaned into the code review bottleneck caused by AI-generated code, choosing to maintain thorough reviews rather than reduce them. The team found that velocity held up, knowledge sharing improved, and collective system ownership developed as a result of this counterintuitive approach.", "body_md": "# Embracing the Code Review Bottleneck\n\nFaced with an endless stream of AI-generated code reviews, our team made the counterintuitive choice to lean into the bottleneck rather than reduce it. Surprisingly, velocity held up, knowledge sharing improved, and we developed a collective system ownership that stuck.\n\nBy: [Fred Hebert](/author/fred-hebert)\n\n#### The Second Edition of Observability Engineering Is Here\n\nThe second edition of Observability Engineering is available for download on our website.\n\n[Download](/blog/the-second-edition-is-here)\n\n## A developing bottleneck\n\nRoughly a year ago, I left Honeycomb’s SRE team to join the newly formed Tenant team, which works on our [Private Cloud offering](/platform/private-cloud). This team held some significant challenges on its roadmap if it wanted to demonstrate that the offering was possible, would be worth the cost, and could be done without representing a heavy tax on the rest of the organization.\n\nIt required taking software that was written and maintained by teams dedicated to continuous delivery—and operated in a very hands-on manner—and repackaging it in point-in-time delivery to infrastructure that isn’t fully owned—nor scalably operable—in the same way. It both had significant greenfield and brownfield elements, and the uncertainty around the project meant we needed to keep our team as small as possible.\n\nThis, of course, meant that we were expected to do some prototyping, but mostly a lot of [falsework](https://ferd.ca/a-bridge-over-a-river-never-crossed.html)—a temporary structure used to hold a building in place until it can stand on its own, at which point the falsework is thrown away—and so using AI tools made sense.\n\nOne thing we did early on was reach team-level agreements on AI usage. We wanted to avoid a focus on individual experimentation and go for what would make the whole team productive, aligned, and coherent in our approaches—similar harnesses, editors, and models, with multiple early pairing sessions so everyone could get on a similar level as the team gelled and established the foundations we’d work on.\n\nAs our product’s (and our team’s) maturity grew, and while the technical landscape changed, we frequently revisited our choices and norms. At some point, like many teams out there, we felt that most of our work consisted of an endless stream of code reviews, as new code could be generated much faster than we could assimilate.\n\nSome more subtle patterns also surfaced. For example, people sharing time zones could end up reviewing each other’s work and moving faster than teammates who had less overlap. If someone had started slinging PRs while someone else was reviewing them, one person tended to remain in a reviewer role and the other to remain in a producer role, since reviewers wouldn’t produce and producers awaiting reviews could pick up more tasks. Our team has a very wide area (”awareness of all of Honeycomb’s features and infrastructure, plus the new places it all runs”), and knowledge concentration got amplified. We were each rapidly over-specializing in some portions of our stack.\n\n# Join us for a live event!\n\nNew Engineering Realities, New Questions:\n\nA live AMA with the authors of Observability Engineering\n\nJuly 29 | 10 a.m. PT / 1 p.m. ET\n\n## The experiment\n\nWhen we had the inevitable discussion about what it is we should do about code reviews, three options were available:\n\n- Change nothing\n- Reduce the reviewing bottleneck (this is what the industry keeps suggesting)\n- Lean into the reviewing bottleneck\n\nWe all agreed that changing nothing was suboptimal, and we weren’t willing to review nothing at this point of development. So, we decided to lean into the bottleneck. The flatly maximalist agreement we came up with was announced in February and looked a bit like this:\n\nOver in Tenant land, we’re trying to live the future of AI writing code. We clearly need to review the code before merging, but are thinking that, perhaps more importantly, we need to review the plan and prompt given to the AI that is writing the code. We came up with a few ways of doing this and are trying them out.\n\nFor each of the four major phases (plan, review, implement, finish), a Claude skill was created and put in our repositories to automate feedback phases and have a uniform set of steps.\n\nI am one of the most dissentious engineers at Honeycomb when it comes to AI. I’ve written about [the risks of bad AI integration into workflows](/blog/ai-where-in-the-loop-should-humans-go), [how dissatisfied I’ve been with the marketing around it](https://ferd.ca/the-gap-through-which-we-praise-the-machine.html), given a [keynote with Charity about all of this](https://www.usenix.org/conference/srecon25americas/presentation/majors), and further written about [the risks of mismanaging bottlenecks](https://ferd.ca/software-acceleration-and-desynchronization.html).\n\nHere we’d actually go nearly hands off on the code and fall into a far more passive (and risky) monitoring role. I was particularly reluctant about this aspect of it. But we were *also* going for the counterintuitive option: as [Donella Meadows mentions when discussing complex systems](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/), people tend to know what the leverage points are, but they also tend to try very hard to push in the *wrong* direction. Complex systems are counterintuitive, and pushing along the intuitive direction can often make things worse.\n\nWhat if the bottleneck exists because this stuff matters? What would happen if we were to decide our job isn’t producing and running code, but owning the system? After all, knowing what changes are happening, keeping up with the structure of our systems, discussing the changes we want to see happen, staying aligned on plans and asking for each other’s input are all critically important. If code takes almost no time to write anymore, what if we instead could use all the freed-up time to do more of everything else?\n\nDespite my disdain of a review-centric workflow, our experiment is one I was fairly enthusiastic about, *because* it embraced that counterintuitive sense and kept a heavy focus on *us* as a team rather than on individuals or automation specifically. There was a chance to emphasize different [qualitative aspects of software development](/blog/production-is-where-the-rigor-goes), where everything could be a sort of small-scale RFC, rather than obsessed with quantitatively-visible code production. And agent-driven programming where you keep steering coding assistants *already* felt like code reviews all the time anyway.\n\nThis is not to say the entire team liked it for these reasons. Some of us wanted to try it because it would let us spend time on things that should *also* be done but were usually ignored; some felt it was a good test of how hard you could drive LLMs. I can’t speak for the whole team and don’t know all of their reasoning, but we all found bits that individually made us agree to this approach.\n\nWe ran the experiment for a while, for all sizes of tickets and pull requests, with larger, more complex ones requiring everyone’s participation and some requiring only one peer.\n\n## The outcomes\n\nThe results were not bad. Despite people still owning tickets end to end in a solo manner, it started feeling like everyone was more aware of what was happening. Despite plans being wrong here and there, the surprises were more easily communicated (that’s *learning* and updating our shared mental models right there), and when similar tasks were reoccurring (e.g., supporting a new SaaS service into the HnyPC environment), the steps and plans could be borrowed again for inspiration and caveats. There were multiple discussions such as *What’s the right level of detail for a good plan?* since we all had to review it and commit to it (something glaringly missing from all the spec-oriented discussions out there).\n\nOur velocity did *not* seem to go down; it kept up, even as we exited greenfield and entered brownfield projects of correcting and shedding our old falsework. We created (or generated) tools that could deterministically provide output to support planning efforts, and we tried to surface some patterns that could be useful.\n\nIn practice, we ended up not sticking with the experiment in its strictest form for every piece of development we do, but still use it from time to time. The original form of the experiment is a heavy workflow. There are often tasks that are straightforward and for which the heavy planning is unnecessary. The plan may then be private and only the overall task reviewed. There are sometimes tasks where the plan is worth sharing, but steps of it may be done manually and left to be decided by the engineer—whether it is due to complexity going beyond what models do, personal desire to work on something “hands on” (either for fun or to see if we still like what the code looks like), or to experiment with alternative approaches.\n\nWe relaxed our norms and trust each other’s judgment as to when to bring up the heavy process. It may have become easier, through the new protocol, to properly break down a potential task and get everyone on the team aligned with a plan regardless of how much automation plays into it.\n\nMy own personal stance is that there are parts of our system, mainly some tests, that I think are now difficult to maintain without AI involvement, because it breaks some long-standing rules of thumb about DRY principles that AI can deal with well but people won’t. There are gotchas and brittle bits that I think people wouldn’t have put in place. But there’s also a greater shared awareness of what our roadmap is, what our team goals may be, and of what’s coming down the road. If we were [on a road toward AI generating everything](/blog/what-comes-after-observability), we might as well make it happen in a way that builds up the team rather than one that simply accumulates more code.\n\nOther groups at Honeycomb have experimented with similar practices as well, and some of them have told us that they are gradually making their way to similar conclusions and practices, whether it comes from trying our approach or meeting us there through a different path. Elsewhere within the organization, there are still other approaches being attempted.\n\nThe code review “bottleneck” is visible to everyone, but it hasn’t been embraced everywhere.", "url": "https://wpnews.pro/news/embracing-the-code-review-bottleneck", "canonical_source": "https://www.honeycomb.io/blog/embracing-code-review-bottleneck", "published_at": "2026-07-22 15:00:00+00:00", "updated_at": "2026-07-22 17:26:53.418798+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["Fred Hebert", "Honeycomb", "Tenant team", "Private Cloud"], "alternates": {"html": "https://wpnews.pro/news/embracing-the-code-review-bottleneck", "markdown": "https://wpnews.pro/news/embracing-the-code-review-bottleneck.md", "text": "https://wpnews.pro/news/embracing-the-code-review-bottleneck.txt", "jsonld": "https://wpnews.pro/news/embracing-the-code-review-bottleneck.jsonld"}}