Bottlenecks and AI

Responding to the code is not the bottleneck

There have been several pieces with the premise that writing code was never the bottleneck for how quickly product and engineering work gets done, and that even if AI tools speed up the coding part, the actual bottlenecks will still remain. This take is missing enough to be wrong, and skips over where there is fundamental improvement available to product and engineering orgs.

First up, the actual act of writing code may not be the bottleneck, but that doesn’t mean that it isn’t a bottleneck. Bottlenecks are simply places in your production process where work to be done piles up, so hands up if you have an empty backlog. Bueller? Bueller?

Now I think there is a fair take that the act of implementing for an individual engineer isn’t uniformly faster yet. Thats a combination of tooling, reskilling and cultural issues at play, so sure, we aren’t transformationally faster (yet) at this phase; but there definitely are teams that are racing up this curve.

What we also have to remember is that even if the phase doesn’t get way faster, the AI native development can also change the nature of how change is offered. Spinning up alternative implementations at the same time carries close to the same engineering time as one implementation when using agentic tools. Instead of big alignment discussions based on opinions or theories up front, we can just try things and then select winners.

If your team can’t decide and align between two similarly scoped libraries for your project? Implement a proof of concept with them both to decide using AI tools. The tests and selections will be reusable across both, so additional cost is small, but comes with much more information for selection, and in all likelihood faster in time.

Which brings us to the implicit core of the point the pieces are making. Generally speaking we have implementation and coordination activities as engineers, so what we’re really saying is it doesn’t matter if implementation speeds up, as coordination is the larger factor in determining speed, which has certainly been true. The miss here is that as the costs of implementation shift, and especially shift the optional costs, the coordination points will both move and reduce as a cost factor in the process of shipping change.

We’re seeing this in organizations where the product team vibe code as a discovery and learning step, and even if engineering is no faster afterwards, the overall value stream gets much faster as we get better information input in the first pass, so fewer total passes before something is shipped as done.

These shifting costs also have effects within a dev team, so many more things move under the bar of ‘I can just knock that out with little effort right now’. There is also this wonderful realization that instead of assembling 4 people for an hour meeting to dig into design choices for a refactoring, you can just spin up your agents, and offer 2 or 3 pull requests as options. Generally its harder to shout down working code, and so even large shifts are much much faster to get through.

These organizational rebuilds are sure to be messy during the transition to AI native engineering, but these are things that we’ve seen before, and of course bottlenecks will appear in different places as processes reform. I’ve certainly seen enough to be very bullish on the impact this will let me, my team and my org deliver.

This is a very similar set of forces I think to Kent Beck’s ideas in an article about how slow deploys cause meetings. Lets phrase it at the positive end; AI native development reduces meetings, less time doing coordination means more time on implementation activities, and really I would have thought engineers at large would have been all about that shift in our day to day experience.