Subtraction · part 3 of 3

AI Made Us Worse at Finishing

4 min read

Gus walking away from a vine-covered half-built tower toward a floodlit new construction site, toolbox in hand, saying "I'll come back and finish it properly."

I went back to the AI psychosis post this week. The first time I quoted it for the sprawl and skipped the diagnosis, which is sitting right there in a definition: AI psychosis is "dream it, vibe it, ship it." Three steps, and once you see it written down, the mindset has a shape.

What the PM is measured on

Think about what a product manager is measured on in front of stakeholders. Not "is the product good." How many things shipped this quarter, the new pricing, the answer to whatever the competitor announced last week. Those are the numbers in the update, so those are the numbers that get chased.

Nobody in that room is being stupid. The world really is that fast, and I've been the one opening the meeting with the market. The incentive just doesn't have a slot for finishing anything. Shipping counts. Finishing doesn't show up anywhere.

Gus beaming at a tiny glowing golem on his palm while three engineers work by candlelight inside the cracked-open chest of a full-size one, saying "See? It already works."

"If I can vibe code it, why can't you?"

Then vibe coding made it worse. A PM or a CEO can build a working version in an afternoon. It runs, it demos, and the obvious question is why the real one takes three weeks when they did it before dinner.

The afternoon version is the tip of the iceberg. Everything under the water is what makes it a feature: how it behaves next to the thing somebody built last quarter that touches the same data, what happens when it fails at 2am and whether anyone gets paged, the migration for the people already on the old version, the error message when someone types the wrong thing into it.

None of that demos. All of it is the actual product.

Nobody goes back

A proof of concept that ships is permanent, which is why it belongs in a series about subtraction. It joins the product, never gets removed, and was never finished. You pay full price, forever, for something built to survive one demo.

Nobody goes back to finish it because there's always a next thing. And it isn't laziness. Iteration takes real time, real thought and real room in someone's head, and that capacity is spent before anyone asks.

Speed doesn't buy trust

Speed of this kind doesn't buy trust. It buys a reputation for shipping things that don't quite work, and a product broken in a hundred small ways nobody owns. A broken product doesn't grow. People try it, it fails them once, and they don't come back to check whether you fixed it.

So my position is plain. I'd rather ship a high-quality product slower. A smaller thing that's been battle-tested beats a feature list where half of it is a POC that never got its second half. Better for the company, not just the engineers.

Engineering's part

Nobody pushes back, and it isn't because engineers don't know. The new thing is genuinely fun to build. And an engineer who tires of the mess can leave and be the person building the exciting first version somewhere else. The mess stays with the product and the people who didn't leave.

Nobody is trapped, so nobody stops it. That's what makes it a cycle instead of a mistake.

Dream it, vibe it, ship it. There's no step for going back, and that's the diagnosis I skipped the first time.