[!WARNING] What follows happened under specific conditions. A small, senior team, twenty years of accumulated context, and infrastructure stable enough to absorb rapid change. This isn’t a universal playbook. It’s what happened when execution stopped being the bottleneck.

For decades, software organizations were shaped by one dominant constraint: development was slow and expensive. Every process, every ritual, every layer of validation existed because shipping code took time, and mistakes were costly to fix.

Roadmaps batched work into quarters and sprints batched it into weeks. Backlogs accumulated because there was always more to build than capacity to build it. Feasibility acted as a natural filter: if something was hard to implement, it often didn’t happen.

That constraint is now collapsing.

The shift

In six months, I went from writing code to planning and validating AI-generated output. What used to require multiple reviewers and days of back-and-forth now resolves in a single pass. Claude became our top GitHub committer. We went from one or two PRs per week to several per day.

When code takes minutes instead of hours, postponed work suddenly moves. Refactors happen. The backlog stops being a stockpile and becomes a flow.

But this isn’t just about speed. It’s about what speed reveals.

The questions that remain

When execution was expensive, feasibility answered most prioritization questions for us. We didn’t build things because we couldn’t, and that felt like strategy.

Now feasibility answers almost nothing. The hard questions moved upstream: should we build this? and what does it displace? and, perhaps most importantly, what do we choose to ignore?

These aren’t engineering questions. They’re judgment questions. And they don’t compress the way code does.

The new bottleneck

The scarce resource is no longer developer time. It’s human attention and decision quality.

For example, one weekend, our CMO built and shipped an entire website alone. Under our previous process, that would have taken weeks of coordination. Our CTPO’s first reaction wasn’t celebration. It was confusion: “What do I do with this?”

The question mattered more than it sounded. Our system was built to authorize work before it existed, not to absorb work already done. The organization couldn’t metabolize output at the rate it was being produced.

This is the new problem. Not how do we go faster? but how do we decide faster, and better, without burning out the people who decide?

Why “going faster” isn’t a strategy

On the startup world, speed used to be a competitive advantage because it was rare. When everyone can ship fast, speed becomes table stakes. The differentiation moves elsewhere: to taste, to focus, to the quality of the problems you choose to solve.

Organizations optimized for throughput will keep optimizing for throughput, and they’ll wonder why it doesn’t help. The bottleneck moved upstream, but the dashboards still measure velocity.

The companies that adapt won’t be the ones that ship the most. They’ll be the ones that learn to say no faster, with more conviction, and with clearer reasons.

Execution was the constraint that justified our structures.

That constraint is disappearing. And with it, the excuse for not asking harder questions.