Shipping MVPs with AI coding tools
When building gets cheap, the expensive thing is deciding what not to keep
Thesis
The constraint has moved, and almost nobody has adjusted their behaviour to where it went.
For most of software's history, building was the expensive step. Product method grew up around that fact. Specify carefully, because implementation is costly. Prioritise ruthlessly, because engineering capacity is scarce. Validate before you build, because building the wrong thing wastes months.
Coding assistants broke that. A working prototype of a small product is now a weekend, sometimes an evening. Whatever your estimate for the build step was in 2022, it is wrong now.
The reasonable inference is that you should build more things. The correct inference is that you should discard more things, because the cost of building fell and the cost of finding out whether anyone wants it did not fall at all.
What accumulates when you miss that is what I would call validation debt: a growing collection of things that exist and have never been tested against a person. It is not a productivity problem. It looks exactly like productivity, which is why it goes unnoticed.
Context
Two of my own numbers frame the situation, and they are checkable on GitHub. Seventeen repositories appeared on my account between February and June 2026. Two of them were packaged into anything a stranger could evaluate.
The seventeen are real. Every one is dated, most are TypeScript, and they cluster into recognisable problem spaces. The gap between seventeen and two is the whole subject here, and I do not think it is unusual. I think it is the standard output of a solo builder with modern tools and no forcing function on the downstream steps.
That gap did not exist in 2019 because it could not. Seventeen builds took a year and a half, and by the time you finished the third you had been forced to think about the second. Compressing the build step removed the natural pause where thinking used to happen.
Research
Brooks, 1986, "No Silver Bullet". The most important thing written on this topic, forty years before the tools existed. Brooks separated accidental complexity, which comes from our tools and representations, from essential complexity, which is inherent in the problem being solved. His argument was that most historical productivity gains attacked accidental complexity, that this category was already largely exhausted, and that no single tool would produce order-of-magnitude gains because the remaining difficulty is essential: understanding the problem, specifying behaviour, and designing conceptual structures.
Coding assistants are an enormous win against accidental complexity. Syntax, boilerplate, API surface recall, configuration, the shape of a CRUD layer. Brooks predicted the ceiling on that category of win, and the ceiling is where a lot of teams are now sitting, surprised.
Amdahl's law, applied as an analogy. Amdahl's original formulation concerns parallel computing: total speedup from improving one component is bounded by that component's share of the whole. Used as an analogy rather than a calculation, it is clarifying. If implementation was thirty percent of the work of getting a product to someone who values it, then making implementation ten times faster produces an upper bound of about 1.4 times overall improvement. Not four times. Not ten.
I am flagging this as an analogy, not a measurement, because the shares are not measured. The structural point stands regardless: the return on speeding up one step is capped by how much of the total that step was, and for most products implementation was never the majority.
Peng, Kalliamvakou, Cihon and Demirer, 2023, on GitHub Copilot. A randomised controlled trial in which developers using Copilot completed a task around fifty-six percent faster. Worth reading the fine print: the task was implementing an HTTP server in JavaScript, which is well-specified, greenfield, heavily represented in training data, and requires no understanding of an existing system. That is close to the best case, and the result is real within it.
METR, 2025, on experienced open-source developers. A randomised trial with sixteen experienced developers across 246 tasks in their own large repositories found they took roughly nineteen percent longer with early-2025 AI tools, while both they and outside observers had expected a substantial speedup. The sample is small and the authors are careful about generalisation, but the direction is the point. Perceived productivity and measured productivity came apart, and they came apart on real work in unfamiliar-to-the-model codebases.
Hold those two studies together and the picture is coherent rather than contradictory. Large gains on greenfield, well-specified, conventional work. Neutral or negative on large existing systems requiring context the model does not have. Which is exactly what Brooks would predict: the accidental complexity is where the win is, and greenfield prototypes are almost entirely accidental complexity.
GitClear's code quality analysis, 2024. Industry research rather than peer-reviewed work, and worth knowing: their examination of many millions of changed lines reported rising code duplication and a declining share of refactoring activity as assistant use grew. Treat the magnitude cautiously and the direction seriously. Generated code trends toward addition over consolidation, because generating a new function is easier than finding and adapting the existing one.
Argument
The build step was probably not your constraint, and now it definitely is not.
Write out the actual sequence from idea to a person who values the thing. Understanding the problem. Deciding what to build. Building. Making it comprehensible to a stranger. Getting it in front of anyone. Learning whether it helped. Deciding to continue or stop.
One of those seven got ten times cheaper. Six did not. If you have doubled or tripled your build throughput and your rate of learning has not changed, you have not become more productive; you have changed the composition of your output toward the part of the pipeline that was never binding.
Validation debt compounds quietly, and it looks like a portfolio.
Each built and untested thing carries an unpaid obligation: at some point someone has to find out whether it matters. Unlike technical debt, it produces no friction. Nothing gets slower. There is no failing test. The only symptom is a list of repositories that grows faster than the list of things you understand.
The reason it is dangerous is that it degrades the value of the whole set. Seventeen dated, described, checkable artifacts constitute evidence of judgement and range. Seventeen artifacts of which six have no description constitute a list of names, and a reader cannot distinguish the good ones from the abandoned ones, so they discount all of them.
The strategic consequence: run more probes and keep fewer of them.
Here is where cheap building genuinely changes strategy, and it is not "ship more".
The cost of a deliberately disposable build fell further than the cost of a keeper. A throwaway prototype used to be an expensive luxury, which is why teams built things they intended to keep and then defended them. Now you can build a probe in an evening whose entire purpose is to be shown to five people and deleted.
That makes a genuinely different method available. Build the ugly version to learn one thing. Show it. Delete it. The saved time goes into the six steps that did not get cheaper, and the discipline that makes it work is a kill rule, not a shipping rule.
Which means the scarce skill is now discarding. It always was rare, and it used to be protected by cost: you could not build twelve things, so you did not have to kill eleven. That protection is gone.
Specification is now the leverage point, which is Brooks's essential complexity arriving on schedule.
If a model will write whatever you can describe precisely, then the ability to describe precisely is the whole job. This is not a new skill and it is not a prompting skill. It is knowing what the objects are, what the states are, what happens at the boundaries, and what the thing must refuse to do.
The observable difference between people getting large gains from these tools and people getting small ones is mostly not tool fluency. It is whether they knew what they wanted before they started. Vague instructions produce plausible code that solves an adjacent problem, and the cost of discovering that is higher than the cost of the specification would have been.
Every shipped thing is a liability, and the ledger is usually one-sided.
A live product has a domain, a dependency tree, a security surface, and users who will eventually email you. Ten live products is ten of those. Nobody counts this when celebrating throughput, and it is the reason a builder with thirty deployed prototypes is often less capable of shipping the thirty-first than they were at ten.
The version of this I would actually recommend: keep the artifacts, retire the deployments. A dated repository with a good README costs nothing to maintain and carries most of the signal. A running deployment with no users costs attention every month.
Reviewing generated code is a different skill from writing it, and the risk moves.
The failure mode of generated code is not that it does not work. It is that it works on the path you tested and is wrong somewhere you did not look, and it is uniformly confident in appearance, so nothing draws the eye. Handwritten code has a texture: the parts the author was unsure about look unsure.
Practically, this means the review effort has to be spent where correctness matters rather than spread evenly. Auth boundaries, money, data deletion, anything writing to a store. Generated code in those places gets read line by line. Generated code rendering a settings page does not.
Examples
A weekend prototype to test a mechanism. The right use, and the tools are genuinely transformative here. Build the thing badly, show it to five people who have the problem, learn one fact, then decide. The mistake is deploying it, adding auth and a landing page, and thereby converting a probe into an obligation.
A greenfield internal tool with a clear spec. Close to the Peng et al. condition, and the reported gains are real. Well-specified, conventional, no legacy context. If you have work like this, do it with assistance and expect a large win.
A change deep in an existing production system. The METR condition. The model lacks the context that lives in your head, and the time you spend explaining it plus the time you spend checking the result can exceed the time you would have spent typing. Notice that the perception in that study ran the other way, which is a warning about trusting your own sense of speed.
A landing page plus waitlist for something unbuilt. Now trivially cheap, and it tests demand rather than implementation, which is the step that did not get cheaper. If you have build capacity to spare, this is a better use of it than another prototype, and almost nobody chooses it because it feels less like building.
Counterargument
"Volume is how you learn. Your seventeen repositories are an asset, and telling a builder to discard more is advice from someone who has already got their reps."
The strong version of this is more persuasive than my argument admits. Skill comes from repetition, and a person who has built seventeen things in five months has pattern recognition that a person who has built two carefully validated things does not. Range across problem spaces is genuinely valuable, and it is not available any other way. The archive also has option value: any one of those repositories can be picked up later, and the marginal cost of having built it was a few days.
There is a sharper version aimed at the specification argument: you discover the specification by building. The idea that you can know what the objects and states should be before writing code is a waterfall assumption in new clothes, and for a novel product it is frequently false. Building is a form of thinking, and the model that writes code cheaply makes thinking cheaper, not just typing.
Where this is right. Building as thinking is real, and I would not give it up. The seventeen taught me things no amount of validation planning would have. And for someone early in their craft, throughput is the correct objective, because the constraint really is skill and repetition really does address it. My argument is aimed at someone trying to produce commercial outcomes, and it should not be applied to someone trying to become competent.
Where I think it is wrong. The learning claim is doing more work in that objection than it can support. You learn implementation from repetition. You do not learn product judgement from repetition, because product judgement requires feedback from people, and building without showing produces no such feedback. Seventeen builds with no user contact teaches you seventeen times about building and zero times about what to build, and it feels like general learning because effort was expended.
On specification: I would concede that the object model emerges from building, and hold the line on boundaries. What the system must refuse to do, where the money is, what happens on failure. Those you should know first, and they are the parts generated code gets wrong most silently.
Practical implications
Decide before you start whether a build is a probe or a product, and write it down. Probes get a deletion date. Products get a README, a description and a distribution plan.
Set a kill rule and honour it. No user contact in two weeks, it becomes an archived probe. Without a rule, everything lives forever at low value.
Write four lines per repository, minimum. What it does, who it is for, what state it is in, what is missing. This is the cheapest possible fix for validation debt and it converts a name into an artifact.
Spend the saved build time downstream. Distribution, positioning, one conversation with someone who has the problem. If build time savings are being reinvested entirely in more builds, the pipeline has not changed shape.
Specify boundaries before generating. Auth, money, deletion, refusal. The rest can emerge.
Review generated code unevenly. Line by line where consequences are real, lightly where they are not. Uniform review is either too slow or too shallow, and usually both.
Retire deployments, keep repositories. Signal without maintenance.
Distrust your sense of speed. The one trial that measured it found perception and reality pointing in opposite directions on real codebases.
My perspective
Opinion, from my own record.
I used the current generation of tools heavily: Claude Code, Cursor, Lovable, n8n, and Figma with Google Stitch and 21st.dev on the design side. They worked. Seventeen repositories in five months is not achievable otherwise for one person with other commitments, and I would use them again tomorrow.
What I got wrong was assuming the acceleration was general. It was specific to one step, and I responded to a cheaper build step by building more, which is the intuitive move and the wrong one. Six of the seventeen have no description at all, which means real work is sitting in public communicating nothing about my judgement. The fix is four lines of markdown per repository and it has been available the entire time.
The more uncomfortable observation is about what the tools did to my selection of work. When building is cheap, the marginal idea gets built, and the marginal idea is by definition the one you had least reason to build. There is no natural filter left. The filter used to be effort, which was a bad filter but a real one, and nothing replaced it. I did not replace it either.
If I were starting the five months again, I would keep the volume and add one rule: nothing gets built until I can name the person I am going to show it to. Not a segment. A person. That rule costs nothing, it removes maybe half of what I built, and I think it would have converted two packaged projects into six.
Conclusion
Coding assistants delivered a large, real gain against Brooks's accidental complexity, and left essential complexity where it was. Total improvement is bounded by how much of the work implementation ever represented, which for most products was a minority.
So the useful response to cheap building is not more building. It is a higher discard rate, an explicit distinction between probes and products, four lines of documentation per artifact, and the reinvestment of saved time into the steps that did not get cheaper. Building has stopped being the thing that limits you. Deciding what to keep has taken its place, and it is a harder skill with worse tooling.
Sources
- F. P. Brooks Jr., "No Silver Bullet: Essence and Accidents of Software Engineering", IEEE Computer, 1987 (first presented 1986).
- S. Peng, E. Kalliamvakou, P. Cihon and M. Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot", 2023. https://arxiv.org/abs/2302.06590
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- GitClear, "Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality", 2024: industry research, not peer reviewed. https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
- G. M. Amdahl, "Validity of the single processor approach to achieving large scale computing capabilities", AFIPS 1967: used here as an analogy, not a calculation.
- github.com/TheDevChopra, nineteen public repositories, seventeen authored between February and June 2026. Recorded as A2 in
SOURCE_INVENTORY.md. https://github.com/TheDevChopra
Related reading in this archive
- The Build Archive: the seventeen repositories, with dates
- Why I build many small products instead of one large one
- What seventeen products in five months actually taught me
- Designing under uncertainty
- Productivity claims in AI-assisted software development: the four studies behind the speed claims, read against each other