The Architecture Review Bottleneck
I argued elsewhere that AI made judgment the whole job. Someone reasonably asked what that actually changes on a Monday morning. It is a fair question, and the abstract version of the answer is worthless, so here is the concrete one from inside my own organization.
Architecture review became a bottleneck, and we stopped trying to fix it.
That sentence gets read as resignation. It is the opposite. We looked at where the constraint had moved, decided it had moved to the right place, and then spent deliberately to make that constraint good instead of fast.
Hire Me
The Instinct That Makes It Worse
This is the part people get wrong. When implementation goes from days to hours, the review queue backs up. That is not a failure of the review process, and it is not a sign that your reviewers got lazy. It is arithmetic. The upstream stage got several times faster and the downstream stage stayed exactly as fast as a human reading code. Any queue fed faster than it drains grows without bound, and it does not matter how good the people standing at the drain are.
The instinct is to speed up review. Approve faster, batch the diffs, split the reviewer pool thinner, trust the tests. Every one of those moves is locally rational and collectively catastrophic. That is how you generate technical debt at machine speed and call it velocity.
"Trust the tests" deserves its own warning. In a shop that generates implementation with an agent, the tests were very often generated by the same agent, from the same reading of the same requirement. If the model misunderstood the boundary, it will misunderstand it consistently, and the suite will go green on the wrong behavior with impressive coverage numbers attached. A passing test proves the code matches the author's intent. It has never proven the intent was right, and the author is now a machine.
So we went the other way.
"Review got slower and more expensive on purpose, because it is now the only place a human decision actually enters the system."
Read that literally. In a pipeline where requirements come in as tickets, implementation comes out of an agent, and tests come out of the same agent, review is not one checkpoint among several. It is the checkpoint. Everything else is machinery executing a decision that was already made. If you optimize the one human decision point for throughput, you have optimized away the only judgment in the system and kept all of the cost.
The Blast Radius Scaled, So the Decision Has To
A bad architectural call used to cost you a sprint of misdirected work, and you usually caught it partway through because a human writing the third file would notice the abstraction fighting back. That friction was free error correction, and nobody ever budgeted for it because nobody knew they were getting it.
Now a bad call costs you a sprint of misdirected work that has already been generated, tested, documented, and merged across forty files. Worse, it is internally consistent. An agent handed the wrong abstraction does not get tired of it or start complaining in standup. It propagates the mistake faithfully, with clean naming and full docstrings, into every corner of the change. There is no friction to notice, because the thing that used to create the friction was a person getting annoyed.
That is the shift nobody prices in. Generation speed multiplied the cost of being wrong and simultaneously removed the cheapest signal that you were wrong. Both halves of that sentence push in the same direction: spend more on the decision, earlier, before there is anything to review.
Three Things That Actually Changed
Gates Got Stricter, Not Looser
Static-analysis thresholds, coverage floors, and pull-request review that actually blocks the merge rather than leaving a comment somebody resolves at 5pm on Friday. When code volume climbs several times over, gates stop being bureaucracy and start being the load-bearing wall.
Loosening them under volume pressure is the single most expensive mistake available, and it is the one every organization reaches for first, because the gate is the thing that is visibly saying no.
The Expensive Conversation Moved Earlier
Not "review this pull request" but "should this exist, and where does it sit in the system." Ten minutes of that saves a week of generated code pointed at the wrong abstraction. Review after the fact is the most expensive place to discover you built the wrong thing well.
The conversation is cheap precisely because there is nothing to defend yet. Once code exists, sunk cost enters the room and the honest answer gets more expensive to say out loud.
QA Stopped Being Downstream
I taught the quality team to generate Playwright suites with an agent directly. They went from receiving work to producing coverage in parallel with development, which meant the test suite stopped being an artifact of the implementation and started being an independent statement of what the feature was supposed to do.
That is not a tooling change. That is an org chart change, and it is the one that actually moved the queue.
How Review Actually Runs Now
"Spend more on review" is a slogan until it has a shape. This is the shape it took, and none of it requires a tool purchase.
- The boundary decision happens before generation, in writing. Where does this live, what does it own, what is it allowed to depend on, and what is deliberately out of scope. A short paragraph, not a document. It becomes the context the agent gets and the standard the reviewer measures against.
- Review is scheduled work, not interstitial work. If reviewing is the highest-leverage thing a senior engineer does, it cannot be the thing they squeeze between the tasks that appear on the board. It gets calendar time and it gets counted as output.
- Reviewers are allowed to reject the direction, not just the diff. "This works and we should not do it" has to be a survivable sentence, and it is only survivable if leadership has said out loud that it is. Otherwise reviewers quietly downgrade themselves to typo-catchers.
- Large generated changes get split before they get read. A forty-file pull request does not get reviewed, it gets skimmed and approved. Whoever asked for the change owns breaking it into pieces a human can actually hold in their head.
- The author explains the why, and the agent does not get to answer for them. If nobody on the team can say why the code is shaped the way it is, the organization does not own that code. It is renting it from a model.
- Machines do the mechanical pass first. Formatting, lint, coverage, security scan, and performance budget are all enforced before a human opens the diff. Human attention is the scarce input, so none of it gets spent on anything a rule can decide.
"That Sounds Slow"
It is slow, at one stage, on purpose. The mistake is measuring a stage instead of the system. Time to merge is a stage metric and it is the one everybody instruments, because it is easy to instrument. Time to a correct thing running in production is the system metric, and it includes every hour spent unwinding something that merged cleanly and was wrong.
Rework does not show up in the velocity chart as rework. It shows up as new tickets, which look like productivity. That accounting error is what lets an organization accelerate into a wall and describe the acceleration as progress right up to the impact.
The other half of the answer is that we did not only add cost, we moved it. Pushing quality generation upstream to the QA team and pushing the boundary conversation earlier both took load off the review queue. Net, the queue got shorter even though each review got more expensive, because fewer changes arrived pointed in the wrong direction and fewer arrived without tests.
If you want the honest version of the trade: we gave up some raw merge throughput and bought back the ability to change our minds later. In a system that is going to be generated against for the next five years, optionality is worth more than a week.
Signals You Already Have This Problem
Most teams hit this before they name it. These are the symptoms I look for in the first two weeks anywhere I land.
- Pull requests are getting larger and approval times are getting shorter at the same time. Those two lines moving in opposite directions is not efficiency, it is a queue being cleared by lowering the bar.
- Review comments are overwhelmingly about naming, formatting, and style. That is what a reviewer defaults to when they do not have the time or the standing to question the design.
- Coverage is up and confidence is down. Somebody generated a lot of tests and nobody believes them, which is a precise description of tests written against the implementation instead of the requirement.
- A quality gate got a temporary exception that is now four months old. Exceptions do not expire on their own, and the fourth one is always easier to grant than the first.
- Nobody can explain a recently shipped module without opening it. Ownership has quietly transferred to the model, and the first production incident is where you will find that out.
What the Evidence Says
- Speed and instability arrive together. DORA's 2025 research found that "AI adoption now improves software delivery throughput, a key shift from last year," and in the same breath that "it still increases delivery instability." Ninety percent of respondents reported using AI at work, a 14.1% year-over-year increase, across nearly 5,000 technology professionals. DORA 2025 (source dated 2025-09; verified 2026-07)
- AI amplifies what is already there. DORA's headline finding is that "AI's primary role in software development is that of an amplifier" - it magnifies the strengths of high-performing organizations and the dysfunctions of everyone else. A weak review culture does not survive a five-fold increase in code volume; it gets exposed by it. DORA 2025 report (source dated 2025-09; verified 2026-07)
- Practitioners describe exactly this queue. A developer quoted in DORA's follow-up analysis put it plainly: "Reviewing [another's] code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed." DORA frames the pattern as time saved in generation being re-allocated to verification and prompting overhead. This is a practitioner observation, not a measured statistic. DORA on balancing AI tensions (source dated 2026-03; verified 2026-07)
- The volume is real and it is already landing in review queues. GitHub reported "1+ million pull requests that were created between May 2025 and September 2025" by its coding agent alone. Every one of those is a review someone owes. GitHub Octoverse 2025 (source dated 2025-10; verified 2026-07)
What I Do About It
The uncomfortable version: if your senior engineers still spend most of their time producing code, you are paying architect rates for something that got cheap. Their expensive skill is now review, boundaries, and saying no. That is not a demotion and it should not be sold as one, but it does mean the definition of a productive week has to change, and the person whose identity is built on volume of output will feel that first.
So I fund review as a first-class stage rather than treating it as overhead, hold the gates when volume makes them inconvenient, move the boundary conversation ahead of generation, and push quality upstream into the teams that used to sit at the end of the line. None of that is exotic. All of it is unpopular for about a quarter, because it trades a metric everyone watches for one nobody instruments.
That is a harder job than writing the code was. It is also the one that does not get automated next.
Hire Me →