DEV Community

MVPBuilder_io
MVPBuilder_io

Posted on

AI Didn't Remove Your Bottleneck. It Moved It.

AI lifted the building bottleneck. Theory of Constraints says the bottleneck doesn't disappear when you do that — it moves. Here's where it went, and why no tool will fix it.

I have a folder. You probably have one too.

Mine is full of repos that got to about 80%. Auth works. The core loop works. There's a deploy somewhere with a real URL. And then — nothing. No launch, no users, no Stripe key in prod. Just a project that was almost a thing, sitting next to four others that were also almost things.

For years I told myself the reason was time, or skill, or that the stack was fighting me. Then AI showed up and quietly removed all three excuses at once. And the folder kept growing.

That's the part nobody talks about. So let me reframe the question most developers are circling right now.

The wrong question

The anxious version going around is "Is AI making me obsolete?" It's the wrong question, and it's wrong in a way that hides something more useful.

The real question — the one that actually stings if you sit with it — is:

Why am I not finishing anything, now that building got easy?

If building were still the hard part, an unfinished project would be a capacity problem. You'd just need more hours, more talent, a better framework. But building isn't the hard part anymore. You can scaffold a working app in an afternoon. And the unfinished folder is still there. So the bottleneck was never really the building. We just couldn't see past it.

Goldratt saw this in a factory in 1984

Eliyahu Goldratt's Theory of Constraints makes one stubborn claim: any system has exactly one bottleneck that limits its throughput. Not five. One. Everything upstream and downstream of it is, in a sense, noise. You can optimize the non-bottlenecks all day and your output won't move.

The non-obvious second half: when you finally lift that constraint, it doesn't vanish — it relocates. Throughput rises until something else becomes the new ceiling. There is always a constraint. The work is figuring out where it just moved to.

For most of us building software, "writing the code" was the constraint for a long time. It was slow, it was where we got stuck, it was the part that needed skill and patience. AI lifted that ceiling. Generously. And exactly as Goldratt would predict, throughput on building shot up — while the constraint quietly slid one station down the line.

It landed on follow-through.

The thing limiting whether you have a shipped product is no longer your ability to produce code. It's your ability to keep showing up to the same project on day 9, day 14, day 22 — past the dopamine of the first working demo, through the unglamorous middle where you wire up error states and write the boring copy and actually put it in front of someone.

That constraint is not technical. It's behavioral. And here's the uncomfortable consequence: no tool can lift it the way AI lifted the last one. A better model, a slicker agent, a sharper IDE — they all operate on the station that's no longer the bottleneck. They make you faster at the thing that was never the problem.

Better build tools make the gap wider

This is the part that catches people off guard.

The instinct is: agentic coding, AI pair-programmers, one-shot app generators — surely these help with finishing? They don't. They widen the distance between "built" and "done."

Think about it through the constraint lens. If you 10x the output of a non-bottleneck station, you don't increase the throughput of the system — you increase the pile of work-in-progress stacking up in front of the actual bottleneck. More half-built things. More 80%-done repos. A faster builder, pointed at an unmoved finishing constraint, just generates a larger graveyard, faster.

So every leap in build tooling doesn't shrink the finishing problem. It makes it more visible and more urgent. The gap between people who have something and people who have nothing isn't a building gap anymore. Building is table stakes. The gap is finishing.

Which means finishing isn't a chore you do after the differentiation. Finishing IS the differentiation. It's the one part of the pipeline that didn't get commoditized this cycle.

AI makes you a builder. The work makes you a finisher.

I've started thinking about it as two identities.

AI is extraordinary at turning you into a builder. It compresses the distance from idea to running code into almost nothing. That's real and I'm grateful for it.

But it has no opinion about whether you ever cross the line. It will happily help you start your sixth project while five sit unfinished. It tracks nothing, notices nothing, cares about nothing. AI tracks; a human reads. The shift from builder to finisher happens somewhere it can't reach — in the boring, repeated, slightly-uncomfortable act of returning to the same unfinished thing until it's actually out.

I saw this framed on a stage in Berlin recently — same idea, scaled up to a whole engineering org:

Conference slide: the question shifts from
The org-scale version asks where the human checkpoints go. The solo-dev version is the same question, smaller: the checkpoint that decides whether you finish isn't a code review — it's whether anyone notices you stopped.

Naval has a line: work like a lion, not like a cow. Lions sprint, rest, and complete the hunt. Cows graze continuously and finish nothing in particular. Most of us, with AI, have become extremely productive cows. Always grazing on new builds. Rarely completing the hunt.

The honest ending

I don't have a clean fix to sell you here. I'm a solo dev with a full-time job, building in public, and I'm writing this partly to myself — because the folder is real and the pattern is mine before it's anyone else's.

But the reframe changed how I work, and it might change how you read your own unfinished folder. Stop asking whether AI makes you obsolete. Ask where your bottleneck moved. For almost everyone reading this, it moved to the same place: the finish.

Optimize the right station. Everything else is just a faster way to not be done.

(If the "structured finishing" problem is one you're actively wrestling with, I'm building toward it in the open at mvpbuilder.io — but the idea above stands on its own whether or not you ever click it.)

Top comments (0)