Two numbers, both measured against our 2022 pre-platform baseline. Build speed rose roughly 30-fold. Delivered output rose about four-fold.

The ratio between them, roughly seven, is the number I keep coming back to, because nothing in our tooling explains it. This post is an attempt to read it, and a forecast of what closing it will take.

The record first

Duration figures come from our delivery metrics; work volume comes from resolved engineering tickets.

Concept to production compressed about 27-fold. The median went from about 20 days to 18 hours.

Time to first executable compressed about 36-fold over the same period: the time from an idea entering the system to the first working code, backlog time included.

Delivered output rose about four-fold, roughly 4.6× per engineer, from a team 16 percent smaller. Resolved engineering work went from 142 issues in a 2022 quarter to 551 in a 2026 quarter, while the team went from 19 people to 16.

The share of active delivery spent before any code existed fell from about 90 percent to near zero, zero in four of the last six months. In November I reported that building to discover removed roughly 80 percent of our discovery phase’s elapsed time. This is that change carried to its end: discovery stopped being a phase that ran ahead of the work and became part of the loop.

Two cautions. The numbers reflect the shift to agent-driven work broadly, not any one practice within it. And the medians trail; they include work started under the old system, so they understate where the current work runs.

What absorbed the difference

If building got 30 times faster and output rose four times, something ate the other seven. My best read is the thing I named in January: the velocity wall. Engineering gets fast, the processes around it don’t, and the gains pile up at the boundary. In January that was half diagnosis, half forecast. We live against it now.

We feel two of the coping patterns that post named constantly: the pull toward phasing work, and the pull toward adding scope. Both pre-existed AI. The tempting read is that someone is dropping the ball; nobody is. The processes were built for the old cadence, sensibly. The speed made both pulls stronger: when building costs this little, one more parallel phase or a bigger release always looks affordable.

Last quarter we tried widening who builds. I wrote about disruptive engineering: PMs and designers shipping production code themselves, because engineers had moved off the product and onto the tooling that lets others build safely. That experiment worked, and it did not touch the ratio. Building was never going to be the ceiling. The work is fast, and what the loop produces waits on the organization around it.

Which means the next gains aren’t technical, and working the loop harder won’t produce them. Once speed stops being the constraint, more speed just deepens the queue it feeds.

What closes it

Christensen’s disruptive innovations open a technology to people who couldn’t engage with it before. Spreading engineering to PMs was that move for code. Apply the same lens to the whole product development lifecycle and the disruption runs in a direction I didn’t expect. The work doesn’t spread out to more people. It moves off people entirely, onto agents, and the people concentrate onto the one thing agents can’t supply: judgment.

The day-to-day of product development is loop work: drafting the spec, writing the code and the tests, wiring the instrumentation, producing the release notes, summarizing what the data said. It can run continuously, and agents can run it. The humans sit on the loop, not in it. They set direction, judge quality, ratify what ships, and notice what the loop can’t: that the thing is correct but wrong, that a customer would wince, that a bet should die even though its numbers cleared the bar.

Back in December I argued that what PMs and designers bring was never the artifacts; it was knowledge, empathy, and common sense. Those three things are what make the judgment seat possible, and they concentrate into it: deciding what enters the loop, and what leaves it. Taste becomes the scarce input. Everything else got cheap already.

I want to be plain about what’s real and what isn’t. The pieces exist: agents carry most of our build work, and PMs ship production code. But nobody here sits purely on the loop yet. The day-to-day still runs through people for most of the lifecycle, and the seven-fold gap is where that shows. This is the direction, not our current state.

Two fences, because the old vocabulary will reach for this idea and miss. A judgment seat is not a stage gate; it rules on work as it comes, not on a calendar. And a loop is not a phase run faster; it has no use for phases at all.

The ask lands on the organization, not the technology. Every function that consumes what product development produces faces the choice engineering already faced, and the answer isn’t to run the old process faster. No meeting cadence keeps pace with a loop. It’s to make the same move: hand the day-to-day to agents, and put people on the loop as the judgment layer over it. Enablement, marketing, support, compliance: each becomes a loop with a human seat, not a queue with a calendar. Every function that makes the shift stops absorbing the speed and starts carrying it. That is what the seven becomes: a ramp.

The January post took about six months to stop being a forecast. I’m writing this one down for the same reason.