The build cycle compressed. Most organizations have not redesigned what happens after the build.
InRhythm founder and Chairman Gunjan Doshi recently examined AWS’s AI-Driven Development Lifecycle and the industry’s new vocabulary for it, the “Bolt,” a unit of work measured in hours rather than weeks. His argument was direct: the unit of work genuinely needed to shrink, but renaming the sprint does not, by itself, fix what is actually broken in most organizations’ delivery pipelines. It is a distinction we see play out inside nearly every AI-native engineering engagement InRhythm is currently running, and it deserves a fuller treatment from an operational standpoint.
The core finding is not complicated, and it is not unique to AWS’s framework. Teams that adopt AI-native delivery patterns generate code dramatically faster. Very few of them have redesigned the validation infrastructure sitting downstream of that generation. The result is a faster input into a review process that has not gotten faster, and leadership teams reporting build velocity as evidence of progress while the actual release cycle barely moves.
The Data Behind the Pattern
The numbers Gunjan cited are worth restating plainly, because they are not soft. LinearB’s 2026 benchmarks, drawn from 8.1 million pull requests across 4,800 teams, found that AI-assisted pull requests now wait roughly five times longer for a reviewer to pick them up than human-written code, and only 32.7 percent merge within 30 days, against 84.5 percent for human-written work. Faros AI’s telemetry across 22,000 developers tells the same story from the output side: code churn up 861 percent, production incidents per pull request up 242.7 percent.
This is the same dynamic InRhythm observes across the enterprise engineering organizations we work inside, particularly in regulated industries. When generation speed triples and validation capacity does not move, the bottleneck does not disappear. It relocates to the review, security, and compliance functions that were never resourced or restructured for the new volume, and it becomes significantly harder to see on a standard engineering dashboard, because the dashboard is still measuring commit velocity rather than release velocity.
Why the Unit of Work Is Not the Hard Part
InRhythm has been building AI-native engineering practices inside enterprise organizations for the better part of three years, and the pattern separating the organizations making durable progress from the ones running what Gunjan calls acceleration theater comes down to a single operational question: does your validation model scale at the same rate as your generation model, or was it sized for a pace of work that no longer exists.
That question is harder to answer than it sounds, because it requires structural changes most engineering organizations have not yet made. It means redesigning who reviews what, at what threshold work escalates to a senior engineer, what gets logged automatically at the moment code merges, and how security and compliance functions are staffed and structured for a review queue that is now both larger and faster-arriving than the one their processes were built around. GitLab and TCS reached the same conclusion under a different name this year, with Intelligent Orchestration built around policy-as-code governance and auditable agent actions. Different vendor, same diagnosis, same shape of fix. That convergence is the signal worth paying attention to industry-wide.
What This Means for Engineering Leaders Right Now
The organizations we see genuinely benefiting from AI-native delivery are not the ones with the smallest unit of work. They are the ones treating validation capacity as a first-class engineering investment, scaled deliberately alongside generation speed, rather than an afterthought discovered once the review queue backs up. This is where InRhythm focuses its advisory work: not at the generation layer, where every organization now has access to broadly similar tooling, but at the operating model layer, where the durable advantage actually gets built.
The unit of work will keep shrinking. Whether that translates into real velocity, or simply a faster way to accumulate review debt, depends entirely on whether the validation layer was redesigned on purpose or inherited by default.