All the other bottlenecks
Writing code is fast now.
Most teams are no longer blocked by the speed of turning specs into PRs.
What I've noticed is that a lot of people, usually non-code-writing people, assumed that the speed of shipping the code was the only thing determining the speed they could grow.
It wasn't. That's nothing to do with AI except that teams can now write lines of code fast enough not to be the bottleneck.
But that's the funny thing about bottlenecks; you always have one. Remove the slowest part of the process and you're now limited by your previous second slowest process.
Making code fast has started to reveal all the other things that stand in between your business and delivering value to your customers.
Here's a few I've seen recently when talking to teams. There are plenty more and some are unique but these are a few I’ve seen enough to call them common:
Working out what's worth building
This one is the most common. Folks can build fast which often means they do. Churning out features that land flat with customers.
The sugar rush of shipping fast catches hold of previously slow teams and they ship any idea they come up with. ProdEng teams don't want to be seen to be idle so there's a pressure to constantly fill the time with shipping.
If we were building physical goods this would be the equivalent of filling warehouses with stock. The units produced per day are high but the number representing 'value the customer is getting' isn't shifting.
The other blockers in this post can contribute to this one but choosing what's worth building has become more important than ever.
There’s no one size solve to this blocker. Diagnosis will take time and effort and likely some shifts in status quo.
Getting comfortable with new features
It's pretty rare for features to just appear and be used by customers. It takes effort across documentation, sales, customer success, marketing and many other departments to ensure a feature is used (and can be charged for).
The pipeline of ProdEng to the wider business is one area that's not as 'agentic' as other single function processes. This means there's usually a lot of time needed to shift a feature from 'in production' to 'in our sales deck'.
Letting customers know about changes
Just because you can ship 10 updates a day, doesn't mean your customers want 10 update emails. Some products can get away with changing a lot because they've positioned themselves as 'new' and 'on the cutting edge'. Customers of other products, B2B SaaS especially, may be less excited by yet another addition to their workflow.
In this case the choices tend to either be to just release things as they come out and deal with the disparity or hold features back and align releases with a sales or marketing cadence.
There's not really a correct answer here other than not violating your customers expectations of you. If you did half yearly releases for a decade you can't just switch to daily feature drops without a reset in expectations.
Coordination overhead
A lot of processes and rituals in ProdEng teams were designed around certain expectations on the time to ship a project.
When projects ship significantly faster all of that process starts to become a bigger percentage of the time to deliver. Having time between development cycles used to allow a certain cadence for sales, marketing, product, design and others to synchronize with engineering to move things along. If each of those teams needed an hour to meet and discuss and features ship three times faster that's many more hours each week on staying in sync.
This overhead adds up pretty quickly and many teams find they need to revisit how they keep in sync to account for the change.
Importantly, its not as if the scale of the features has decreased. Without efforts there's no magic reason that a standard sized feature can be discussed any faster just because it takes less time to build.
Getting usage data
Sometimes you need a certain volume of feature usage before you can make a confident call. When you had longer development cycles you had a longer window to gather data between cycles.
When features move faster, coupled with the desire to always be moving, this can lead to teams moving onto other things while waiting for signal from end customers.
This isn't a bad thing on its own but if your larger feature cycle requires data between each step this can lead to coordination issues bringing projects back in and out of 'ready to work on' as data is collected.
I could go on here, and certainly go into more detail but what I think folks are starting to agree on is that faster 'code in production' doesn't mean faster 'value to customers'.
Shipping code faster without changing any other systems is not going to build a better business. A company is a set of interconnected systems all working together. Improving that requires system level thinking and organization.