In the AI Era, Humans Are the Bottleneck

Written by Michael Rood on 

For the last few months my team’s Kanban board has been heavy in the right-hand columns. Last week we had so many stories in Ready for Deployment that we had to organize and schedule the releases to ensure we could sanely impact the health of our systems. AI has sped up the execution pieces of the software lifecycle and clear bottlenecks are emerging.

What Changed

Smaller Teams, More Features

Since the release of Opus 4.5 and other frontier models at the end of 2025, combined with model harnesses such as Claude Code, I’ve seen considerable acceleration in my team’s ability to deliver features. We now have small tiger teams (1 - 3 person cross-functional teams) with deep expertise in a system/product delivering more features (3X the pull requests and story points) than ever before. These small groups are gaining a deep understanding of both the domain and the codebase which has further accelerated product and development speed. In other words, our ability to Get Shit Done rose and continues to rise considerably.

Where we’ve seen an extreme acceleration is where a single individual with the trust or knowledge to own several domain spaces can now build faster than ever. Given the ownership of the entire pipeline, a single person can ship products and features at a silly speed. Small trusted teams or single individuals with large amounts of ownership can now move at machine speeds.

The Cost: Lost Context

The downside to breakneck development speed and narrowing scope is that engineers begin to lose context of other parts of the system. The loss of context further amplifies as development speed increases. The key-man problem is not new. To mitigate, we:

  1. Trade some productivity for context by rotating or mixing the tiger teams on a regular cadence.
  2. Include team testing (bug bashes) as part of the development process, ensuring engineers use all our products and features.
  3. Ensure on-call responsibilities include maintenance across all systems and products, ensuring engineers touch systems not included in their daily toil.

Including these processes organically in the development cycle has been important to mitigating key-man problems.

Code Review Is Now a Clear Bottleneck

Our PRs now wait in review three to four times longer than it took to write them (measured as first commit to PR vs. PR to approval). It isn’t that time to perform code reviews has gone up, rather the time to get code into review has plummeted. Put more abstractly, the bottlenecks are now where one or more humans gate a process. Where I would like to take my team, and where they have been reluctant to go, is enabling an agent-led (and humanless) code review if a risk calculation is deemed low by an agent. For operational and ownership reasons I’m sympathetic to their hesitancy. As an industry I foresee this continually being a bottleneck until we gain trust in both a humanless process and each other’s instincts and intentions.

This might be an unpopular opinion, but I see a lot of value in pursuing a humanless process. A humanless review process would necessitate an agent to prove that changes work as intended and do not have unintended consequences. Proof points might include automated usability testing, end-to-end testing, observability and monitoring of test environments, etc. If an agent can provide proof that software works as intended, then I’m reluctant to wait around for a human to rubber stamp it.

There is a lot of disagreement in the industry on this topic and I’m excited to see how it unfolds. My recommendation to everyone is to not fear experimentation and learning.

Deployments Are Another Bottleneck

As more features go through the development pipeline it has become important to plan our deployments, especially for mobile applications. Minimizing system downtime is important to us and confidently (but sanely) releasing software requires some scheduling. Some days we’ll have five different systems to deploy and staggering the deployments so on-call has time to monitor for operational safety is generally advised. Nothing about deployments has necessarily changed, just we now have more of them and we don’t yet have the confidence to just let them fly.

What Hasn’t Changed

Planning

Feature and product planning are the same as pre-AI. Product/Engineering/Stakeholders lay out a business need and produce an artifact (usually a PRD), that need is weighted and prioritized against competing needs, designs may or may not be created, engineering produces some design artifact if the change warrants it, and finally engineering works on it. I think this has stayed the same because the organizational and communication structure is largely left unchanged. Humans still exist in organizational arrangements and because this structure exists we still communicate this way.

My personal opinion is that this process should not change for major products, features, and initiatives. For large or critical initiatives, critical thought is still required by domain experts. AI has, however, enabled freedom to do better cross-functional work. Product people can now produce smaller wireframes or designs quite quickly with AI where formal designs aren’t needed. Engineers can generate copy for approval by product. Design can create working prototypes. Where we used to have to pull information we can now self-serve and push information for approval by domain experts.

An Unwelcome Guest - The Slop Cannon

A natural early use of AI is to let it write documents. Over the past year I’ve seen a proliferation of dozen+ page manifestos masquerading as PRDs, engineering requests, or design documents. None of them are done out of complete laziness but all are equally ineffective, even counterproductive. Here are a few reasons this pattern is unwelcome:

  1. The biggest problem with this pattern is that the author or owner of the document has not really considered critically what they are suggesting. Writing forces us to think deeply. Proof-readers keep us honest about where we lack data or where our arguments are weak. More broadly, I feel like society is very quickly entering a post-literate phase due to LLMs and critical thought will be the first victim. But that’s a much broader topic for a much larger blog post.

  2. It is incredibly selfish to think that we should have to read your 12+ page document when you couldn’t be bothered to write it. Out of self-preservation of my sanity I outright refuse to read these documents.

  3. LLMs are very good at receiving a 2 - 5 sentence prompt and generating 2 pages of text that looks reasonable on the surface but actually says nothing at all. The impact of this is most obvious when you are on the receiving end of these documents from someone that isn’t a domain expert. To the non-technical person, the text generated by Claude seems reasonable, even smart, because it is able to use domain-relevant words. On the receiving end, however, these documents are often wordy and lack specificity despite there being no lack of words. Your ask is messy because your thoughts are messy and unclear. Clear them up.

Closing Thoughts

As the tools continue to get better, it is evident to me that the value of software engineering is not and will not be in execution, but rather evaluation and higher order problem solving. I’m here for it and am excited to see where we are in 2027.