Everyone is talking about speed. Engineers shipping faster, more code per sprint, shorter cycles. That's real. But it's the surface of something more significant happening inside engineering teams — and in the companies that depend on them.
The more interesting change isn't about how fast engineers work. It's about what they can now attempt.
The tax that disappeared
For as long as product companies have existed, there has been a gap between what a team wanted to build and what it could build. Not because engineers weren't capable — but because certain kinds of work came with a tax. An unfamiliar API. A payment integration. A shipping provider. A design pattern outside the team's usual stack. A frontend written by a backend engineer, or vice versa.
It would usually boil down to: this will cost X or take Y days — and either of those was too much. These weren't insurmountable barriers. But they were real costs. Research time. Trial and error. The slow accumulation of understanding before anything useful could be produced. For a startup or a small product team, that tax could stretch a side project into months, or turn a promising feature into a deprioritised backlog item that never quite made it to the top.
Now we look at things and think: that's going to take me a week instead of a month. And that shift breaks blockers that used to kill entire initiatives.
That tax is largely gone.
Not because engineers got smarter or faster at learning. But because the barriers to attempting unfamiliar work have dissolved. You prompt, you review, you iterate — and you learn. The work that used to require days of research or weeks of trial and error now requires a focused session and good judgment about the output.
A concrete example
A friend of mine runs a small business. Years ago, I built him an ecommerce site — products, stock management, payments, email notifications, the works. Part ego, part pragmatism: I didn't want to add Shopify as an intermediary and a cost, and I didn't know how to build Shopify sites anyway — so I built the shop without them. It took around six months of side project work. Weekends, evenings, the slow grind of figuring out how to connect each piece.
That site is now overdue for a refresh. For more than a year, I'd been putting it off. Not because I didn't want to do it. But because I knew what it cost — the design discussions, the feature mapping, the integrations, the deployment. Weeks of work for a side project. Hard to justify.
A few weeks ago I picked it up again, this time with Claude Code. I wrote a brief: the kind of site I wanted to build, the stack I wanted to use — Rails, specific design patterns, Docker, a payment provider, an email service, the works. I described the features. I described the products. I described what the admin experience should feel like.
What followed were a couple of four-hour sessions spread across two weekends. From idea to deployment. From deployment to showing the thing to my friend and getting his approval.
Six months became two weekends. Not because the work was easier. Because the blockers stopped being blockers.
What changes
The implications go beyond speed.
The "that'll take a long time" conversation is disappearing. Engineers can say yes with genuine confidence — not because they know exactly how to do everything, but because the gap between knowing what needs to be done and being able to do it has narrowed dramatically. The scope of what a small, well-composed team can credibly promise has expanded — not just in volume, but in reach.
This changes how teams are composed. You don't need every specialisation represented if the gaps can be bridged contextually. You do need engineers who can engage with the product question — who understand why the thing they're building matters, what signal would tell them it's working.
The engineer who treats code as the output and the ticket as the input is more exposed than before. The engineer with broad judgment — who knows what good looks like across domains, who can direct and review and integrate — is more valuable than ever.
The constraint that was always there
If the execution barriers are dissolving, the binding constraint shifts to where it always lived — just hidden behind the noise of delivery.
Product thinking.
What are we building? For whom? What problem does it solve? What does success look like, and how will we know?
These were always the right questions. But when downstream execution consumed most of the oxygen — when "can we build it?" was genuinely hard — teams could defer them. That cover is gone. The downstream is no longer the bottleneck, and the upstream can no longer be skipped.
The wall moves
The focal point of the engineering pipeline has to shift. Not because someone decided it should. Because the downstream is no longer where the constraint lives.
If a team can build almost anything, the question of what to build becomes existential. The conversation that used to happen at the end — "can we build this?" — has moved to the beginning, where it belongs. And the conversation that matters most — "should we build this, and why?" — is now the only place where genuine competitive advantage lives.
Product and engineering collaboration at the earliest stages of the pipeline isn't a process improvement. It's now a survival condition. Teams that skip it aren't saving time — they're spending their newfound reach on the wrong things, faster than before.
The question that remains
Reach without direction is just getting lost across a wider territory.
The companies that will extract real value from this moment are the ones that have already built the conditions for it — shared ownership between product and engineering, clarity about what they're trying to achieve and for whom, the cultural conditions that make upstream collaboration possible and natural.
The ones that haven't will be very good at building the wrong things, very quickly, across a much wider surface area.
The gap AI closed was real. But it wasn't the execution gap. It was the last excuse for not investing in the thinking that should have come first.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.