If code is cheap now, why aren't things moving faster?

We're so early in the AI adoption cycle that few organisations have worked out how to actually benefit from it. The focus right now is on individual productivity, but that rarely translates directly into team velocity. Instead, we need to redesign the product development process around AI.

A common claim is that code used to be expensive, and AI has made it cheap. That's true, but outside of green field projects, code was never so expensive that removing the need to write it entirely would double the rate at which teams ship products or features. It was expensive enough that teams had to be selective about where they invested their engineering time - which is why most projects go through many planning steps before a single line of code is written.

The slow part is everything that surrounds the act of building. Teams and stakeholders deciding what problems to solve, what the solution is, and how we're going to build that solution - or what everyone now describes as "alignment".

Getting everyone aligned is a lossy process. In a traditional team of product owners, designers, and engineers, no single person holds all the information needed to complete the project. Discussions, debates, and iteration cycles exist because there's always room for interpretation or incorrect assumptions.

That's why AI is so powerful for solo builders. The alignment bottleneck disappears when you're a product manager, designer, and engineer rolled into one, so the rate of output is directly linked to how quickly you can produce code. Orgs will try to emulate the solo-builder model, but it only works in narrow cases: small enough projects, genuine autonomy, and people capable of the founder-like polyglot role.

So the question is not how to remove the need for alignment, but how to reduce its overhead.

I've always viewed writing as a superpower that separates high-performing teams from average ones. Spending time up front clearly articulating the problem being solved and why, and building a shared understanding before describing the solution is a worthwhile investment. Too often teams rush to start building in the name of moving fast, but this lack of shared understanding costs more time later than was saved.

Writing isn't the only way of solving the alignment problem. It was simply cheaper than polished designs or working prototypes, and that's what's changed.

If you narrowly view AI as speeding up existing processes, you may ask how we can use AI to speed up the creation of PRDs or similar docs, but that's the wrong question. Even if it does accelerate things without sacrificing quality, it's still only going to be an incremental improvement to overall team velocity. 'Accelerate things without reducing quality' is also not a given - too often, thinking is delegated to the LLM which produces plausible-looking but poor-quality documentation that actively hurts understanding.

The better question is how to redesign the process now that AI exists. Rather than looking to speed up existing processes, we should ask what replaces them. Why spend time writing a PRD when you can now build a working prototype that communicates more in the same amount of time? Even if you're sceptical about AI's value in generating production-ready code, it is remarkably effective at producing throwaway prototypes.

A prototype moves alignment from something abstract to something concrete. Everyone is looking at the same artefact, not their interpretation of words, and it uncovers questions or edge cases that previously wouldn't surface until building starts, reducing iteration cycles later. There's something tangible to review much earlier, creating an opportunity to question whether the team is heading in the right direction at all.

Alignment is the most obvious bottleneck, but it's not the only one. Code reviews, testing, deployment, user research - all were shaped by assumptions about how expensive it was to produce features, and those assumptions no longer hold. The teams that thrive will be the ones willing to redesign their ways of working, rather than try to use AI to do the same things faster.