Speed is not a virtue

The startup orthodoxy goes something like this: ship fast, break things, iterate, repeat. Speed is survival. The company that ships first wins. Move fast or die slow.

It was always an oversimplification. But in the age of AI-assisted development, it has become actively dangerous.

Here’s why. When building software was slow and expensive, speed served as a useful proxy for something else: decisiveness. A team that shipped fast was probably a team that could make decisions, cut scope, and focus on what mattered. Speed was the symptom. Clarity was the cause.

But AI broke that proxy. Now you can ship fast without being decisive. You can generate features without understanding them. You can produce at the speed of prompting without any of the underlying clarity that used to be required. Speed decoupled from thought.

The most dangerous thing AI enables isn’t bad code. It’s fast bad decisions.

I keep hearing variations of the same pitch: “We used to take eight weeks to build this. Now we do it in two.” And everyone nods approvingly, as if the six weeks saved were pure waste. But were they? What happened during those six weeks?

Some of it was genuinely unnecessary. Boilerplate. Repetitive tasks. Yak shaving. Good riddance. But some of those weeks were spent thinking. Talking to users. Arguing about scope in a room with a whiteboard. Sleeping on a design decision and realizing the next morning that it was wrong. That kind of slow work isn’t waste. It’s where the actual value gets created.

The best use of AI isn’t to ship in two weeks what used to take eight. It’s to spend those six extra weeks asking whether you should ship it at all.

This isn’t an argument against speed in general. There are contexts where speed matters enormously: validating a hypothesis, responding to a production incident, a market window that’s genuinely closing. In those moments, the ability to move fast is a real advantage, and AI makes you better at it.

But most software isn’t built in those moments. Most software is built in the long, quiet middle of a product’s life. And there, the biggest risk isn’t moving too slowly. It’s building the wrong thing efficiently.

I’ve seen a team rebuild their entire notification system in a week using AI-assisted development. Impressive velocity. The problem was that nobody had stopped to ask whether their users even wanted notifications. They didn’t. The team had moved so fast they’d lapped the question of whether they should have moved at all.

There’s a physics metaphor that’s useful here. Velocity is speed plus direction. You can have enormous speed and zero velocity if you’re moving in circles. The startup world measures speed and calls it velocity. But velocity without direction is just vibration.

The cultural pressure to ship fast is hard to resist because it feels productive. You can see the output. The PRs are merging. The deploys are going out. Metrics are moving. But activity is not progress. Shipping is not solving. The most productive thing a team can do is sometimes to stop shipping and start asking hard questions.

What problem are we actually solving? Do we have evidence it’s real? Is this the best way to solve it? What would happen if we built nothing?

These questions feel slow. They feel like overhead. In a culture that worships velocity, asking “should we build this?” sounds like obstruction. It’s the opposite. It’s the only question that gives your speed meaning.

AI should make you more thoughtful, not just more prolific. If you’re using it to do in two days what used to take two weeks, and spending the rest of that time starting the next thing instead of questioning the first thing, you’re using it wrong.

The companies that will win aren’t the ones that ship the fastest. They’re the ones that are right the most often. Speed helps you test whether you’re right. But only if you’re actually testing, not just shipping.

Slow down. Not because slowness is a virtue either. But because the speed only matters if you know where you’re going.