Should You Still Build an MVP in the AI Era? 211M Lines of Code Say Rework Went From 3.3% to 7.1%

Throw an idea at an AI and eight times out of ten, the first thing it says back is “let’s start with a minimum viable version.”

That sounds like a judgement. It’s a memory. The Agile Manifesto is from 2001, The Lean Startup from 2011, and those two documents plus the several hundred thousand blog posts, courses and postmortems they spawned are all in the training data. It recommends iteration, not because it ran the numbers on its own costs.

It ran the numbers on ours. And the two bills are structured in opposite directions.

The four premises MVP rests on — three still hold

Iteration isn’t a law of nature. It’s the optimal answer under a specific set of constraints, and the set looks like this:

• Writing code is slow and expensive. A feature goes from understood to running in person-days.
• Changing code costs more than writing it. To change it you must first read it, and reading it means climbing back into someone else’s head — or your own from three months ago.
• Requirements get sharper along the way. Users only know what they want once they see something, so putting something in front of them early pays.
• The decisive one: there is a large cost gap between a crude implementation and a complete one.

That last one is the economic bedrock of MVP. Store it in localStorage for now, skip permissions for now, hard-code a few config values — the weeks you saved were real, and spending them on validating an assumption instead was genuinely the better trade.

Three of those four still hold today. The fourth is gone.

localStorage vs PostgreSQL: minutes apart in an AI’s hands

A thread on V2EX puts it most cleanly (t/1216691, titled “Has MVP thinking stopped working in the age of AI coding?”). The original poster’s words: describing “store the data in localStorage” to Cursor and describing “use PostgreSQL with a connection pool” differ by a few minutes of generation time.

If the cost is the same, why build the crude version?

That single line pulls out half the foundation. What you save is no longer weeks, it’s minutes — while everything you take on in exchange is unchanged: a storage layer that will be ripped out, a batch of calls written against it, a migration you’ll have to redo.

Crude isn’t cheap anymore. It’s just incomplete.

The AI’s bill: context is the main cost, not the task

The other half of the foundation collapses at the level of cost structure, and this layer is better hidden.

Run one agentic task and the bulk of the input tokens is never your task description. It’s the system prompt, the repo map, the conversation history, the files it read. The task description is a rounding error inside it.

What follows has all been measured:

• Every retry resends the entire context. Two retries can triple the cost of a session.
• Counting context overhead, real cost runs 3–5× the naive estimate — roughly $0.27 to $3.25 per PR, and north of $20 for a single task in a complex repo is unremarkable.
• The arXiv paper Cheap Code, Costly Judgment (2607.01087) measured agentic tasks consuming 1000× the tokens of ordinary code chat, with up to 30× variance in token spend across repeated runs of the same task.

Now put human iteration and AI iteration side by side.

A person splitting work into three phases pays roughly the same per phase, because a person remembers what happened in the last one. The context sits in their head and costs nothing to call.

The AI doesn’t remember. It has to buy the context again every phase.

Iteration is insurance for a human and a friction fee for an AI.

GitClear measured the rework: 3.3% → 7.1%

Everything above is inference. What follows is measurement.

GitClear analysed 211 million lines of changed code, tracking a metric called churn — the share of code substantially rewritten or deleted within days of being merged. It measures exactly one thing: not getting it right the first time.

More than double in two years. Other metrics in the same research point the same direction:

• Within-commit copy/paste +41%
• Duplicated code blocks +81%
• Error-masking constructs +47%
• Cross-file function calls, the proxy for reuse: −35%
• Refactoring line moves: −70%

GitClear sorts AI-amplified rework into three kinds, and every one of them is a direct consequence of shipping a half-finished thing first:

1. Wrong place — logic and syntax both correct, but sitting in the wrong architectural location; someone relocates it later
2. Built twice — reimplementing functionality that already existed instead of reusing it
3. Rewritten days later — merged, then substantially changed because of an edge case or a convention it violated

In the same body of research, AI-authored PRs carry 10.83 issues on average against 6.45 for human-authored ones. A factor of 1.7.

Developers’ own experience matches the numbers. From the Stack Overflow 2026 Developer Survey:

• 84% are using AI tools
• 45% say debugging AI-generated code takes longer than writing it themselves
• 66% say their biggest frustration is output that is “almost right, but not quite”
• And trust in AI output sits at 3%

A separate survey puts 43% of AI-generated code changes as needing debugging in production.

“Almost right” is the operative phrase. It means the problem doesn’t surface when you accept the work — it surfaces after the merge, which lands it squarely on the next iteration. The round you thought you saved gets billed later.

”Right once” is not “all at once”: delivery granularity vs execution granularity

This is where it’s easiest to slide into a slogan: stop iterating, do it all at once. That’s wrong, and dangerously so.

Two granularities have to be kept apart:

• Execution granularity: change one thing, verify, then the next. Still correct today, more so than before — an AI touching ten files at once is more than you can review.
• Delivery granularity: whether what you hand over this round is a finished thing.

“Right once” is about the second. It constrains completeness, not feature count.

Scope can be narrow — one page, one endpoint narrow. But the part you committed to this round has to be complete: real data structures, not placeholders; loading, empty, error and success states all present, not just the happy path; something that actually runs for a person to use, not a screenshot.

The deepest problem with the word MVP is that it sold “narrow scope” and “built crudely” as a bundle. They used to be genuinely bundled — saving money meant saving on both. Now they come apart: scope should still be narrow, but crude has stopped being cheap.

”MVP is about validating assumptions, it has nothing to do with AI” — which two of the four objections hold

The replies under that V2EX thread are more valuable than the original post. One at a time:

1. “The core of MVP is validating an assumption. It has nothing to do with code, and nothing to do with whether AI is involved.”

It holds — and it points straight at where the problem is. The word MVP has always bundled two things: validating an assumption, and shipping an incomplete implementation. They used to be inseparable, because the only cheap way to validate an assumption was to build something rough. They’ve come apart. Validate the assumption, by all means — you can now do it with something complete.

2. “You can never learn all of your potential users’ needs up front.”

It holds, and it doesn’t conflict with doing it right once. Nobody is asking you to build every feature in one pass. The ask is that the part you do build this pass isn’t left half-finished.

3. “For logically complex projects — especially systems with intricate business loops and state machines — doing it in one shot produces a mess.”

A real problem, but a problem of execution granularity. A complex state machine obviously gets built step by step with verification at each step. That is not an argument for shipping a version you already know you’ll rewrite.

4. “With AI, iteration is fast and costs almost nothing.”

This one doesn’t hold. The two sections above are its counterexample: what got fast is generation, not convergence. Churn climbing from 3.3% to 7.1% is a measurement of exactly that gap.

After writing “no phased development” into my global rules

I have one line hard-coded into my own global rules: no phased development, delivery means a finished product, no MVPs and no partial milestones.

In practice that comes down to:

• Real data structures and real content from the first pass — no Lorem ipsum, no fake data
• All four states delivered together: loading, empty, error, success
• Running it myself before it counts as delivered — open it in a browser, execute it on the command line, hit the endpoint with curl

The price is real: the first description has to be much longer. You have to think through boundaries, states and data structures before anything starts. That work didn’t get taken over by AI — it just moved from “forced to think it through during the third round of rework” to “thought through before the first round starts.”

The payoff is equally direct: you don’t explain the same thing a second and a third time. And explaining it again is the single most expensive item on that bill above.

How narrow to cut the scope — AI can’t help there

That question still has no answer.

Doing it right once presumes the scope was cut right. Cut too wide and “right once” becomes “a very long once.” Cut too narrow and what you built can’t validate anything. Where that line falls comes down to judgement about users and situations — and that paper’s title already said the whole thing: code got cheap, judgement didn’t.