When an AI-coded MVP needs an engineering partner

Hire an engineering partner when a paying user can be hurt by the next change and nobody who can ship that change can also explain it, test it, and undo it. Ugly code is not the signal, and neither is the fact that an AI coding tool wrote the first version. Four conditions are. You cannot name the blast radius of an ordinary change. Your sense that prompting is still faster is a feeling you have not measured. Someone who is not you now depends on the system — a second company on the same database, a charge that must not happen twice, a security question from a buyer. And the work left is the operate half: permissions, logs, evaluations, a way to roll back. Until two of those are true, keep prompting. Once they are, another month of prompts is how the gap gets more expensive.

The studies that seem to disagree are measuring different jobs, and the disagreement is the whole point. On a task nobody has done before, with the tests handed to you, an AI pair programmer makes unfamiliar work faster. On a codebase you already own, where the tests are whatever you bothered to write and the next change has to leave yesterday's behaviour intact, the same class of tool can make experienced people slower while leaving them sure they were faster. A first version and a system other people depend on are not two points on one curve. They are different pieces of work, and the tool that is right for one is the wrong instrument for the other.

The greenfield result is real, and it is narrower than the demos suggest. In a controlled experiment run before GitHub Copilot was generally available, 95 professional programmers recruited through Upwork were asked to implement an HTTP server in JavaScript as quickly as possible. The group given Copilot finished 55.8% faster than the control group, with a 95% confidence interval of 21% to 89% (Peng, Kalliamvakou, Cihon & Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv, 2023). The authors work at GitHub, Microsoft Research and MIT Sloan, and the product under test was GitHub's. The task was a fresh server, with a twelve-check test suite the participants could see and could not alter. That is a fair description of an MVP weekend. It is not a description of the month after a customer is live.

The owned-codebase result is the one founders skip, because it insults the feeling that got the product this far. METR ran a randomised trial with 16 developers who already had, on average, five years in the mature open-source projects they were changing. They completed 246 tasks. Each task was defined before it was randomised to allow or disallow early-2025 AI tools, mostly Cursor Pro with Claude. Before the tasks, the developers forecast that AI would cut completion time by 24%. Afterwards they estimated they had been 20% faster. The measurement went the other way: allowing the tools increased completion time by 19% (Becker, Rush, Barnes & Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv, July 2025). The trial is cited here for what it measured in early 2025, not as a permanent speed limit.

METR has since said the picture may have moved, and that its newer evidence cannot size the move. A follow-up paid at a lower rate, run while more developers refused to work without AI at all, was too biased to trust: 30% to 50% of participants declined to submit tasks they did not want to do without AI. METR's judgement is that developers are "likely" more sped up in early 2026 than the early-2025 estimate, and that the newer data is "only very weak evidence for the size of this increase" (Becker, Rush, Cunningham, Rein & Mahamud, We are Changing our Developer Productivity Experiment Design, METR, 24 February 2026). Do not quote 19% as this month's number. Do not treat that as permission to trust a feeling. The finding that survived is the gap between "I was faster" and a clock. If the only evidence the last two weeks were faster is that the tool felt helpful, you are standing where those participants stood after the trial.

The second signal is that you cannot name the blast radius, and generated code is unusually good at hiding it. GitClear analysed 211 million changed lines, authored between January 2020 and December 2024, across its own customers and large open-source repositories. Lines associated with refactoring — code moved into something reusable — fell from 25% of changed lines in 2021 to less than 10% in 2024, while lines classified as copy/pasted rose from 8.3% to 12.3%. 2024 was the first year in their series in which copy/paste exceeded moved code (GitClear, AI Copilot Code Quality: 2025). GitClear sells code-review tooling, and the study is observational: it does not prove a particular assistant caused a particular commit. What it measures is still the shape AI-coded repositories take. The same idea gets implemented again, nearby, instead of being moved into one place. A one-line fix then has to be found in every copy, and the copies do not know about each other.

You do not need their dataset to run the test on yours. Pick one change from the last month and list the files that should have changed and the files that must not have. If you cannot, or if the only record is a chat transcript, you do not have a blast radius. Duplication is why a small fix ships twice, or ships once and leaves the other copy wrong. More prompting at that point tends to add another copy.

The third signal is a stranger. While the only user is you, a wrong answer is an annoyance and a schema change is free. The day a second company shares the database, a card can be charged, or a buyer sends a security questionnaire, the cost of being wrong is no longer yours to absorb quietly. None of those events is a reason to throw the product away. Each is a reason the next change needs an owner who has done it before: tenant isolation that a developer cannot forget, a write that is safe to retry, a log that can reconstruct last Tuesday, an answer to the questionnaire that is true. What breaks when an AI-built prototype meets real users is the catalogue of those gaps. This article is only the decision that the catalogue now applies to you.

The fourth signal is the kind of work left, not the volume of it. The screens exist. The happy path has been described, which is why the happy path is what the tool built. What is missing is the operate half: an evaluation that says what a wrong answer is, a permission check that lives on the request rather than in the navigation, a spend ceiling, a rollback. People who use these tools most already sort their week this way — they hand over the draft and keep the deployment — but a founder with no second engineer has nobody to hand the second half to. Prompting harder does not create that person. It produces a longer draft of the half you already had.

Two of the four is the threshold, not all four, and none of them is "the code looks like a machine wrote it." Generated code is locally plausible and globally inconsistent; that is a reason it is tiring to read, not a reason to start over. Rewrite or repair an AI-built codebase is the decision you make after you have hired, or instead of hiring if the honest answer is a week of repair you can do yourself. Most of the time the shape of the product can stay. The data model survives. One or two modules get replaced. The operate half gets built for the first time. A rewrite is justified in three narrow cases — the centre of the system is the wrong shape, nobody can run it from a clean machine, or the floor underneath it has gone out of support — and distaste is not one of them.

There is a version of this where you should not hire anyone. Nobody but you uses the product, and you could delete the repository tonight without emailing a customer. The next change is one screen, and you can name every file it touches. You are still searching for whether the idea works, and a wrong answer costs you an afternoon. In that window the Copilot result is the relevant one: a fresh task, a visible test, a large speedup, and nothing to inherit. Spending a partner's week on it is how founders buy a process for a product that does not exist yet. The two-week AI readiness assessment is the wrong purchase there too. It assumes there is a system and a data set worth mapping.

When the threshold is met, the purchase is specific. You are not buying a new idea, and you are not buying a ranking of agencies — we do not publish one. You are buying the operate half on top of a version that already has users. That is the work a startup software development company is for: architecture, evaluations, a security posture you can hand to a buyer, and a defined end, rather than a retainer that replaces the prompting habit with a standing invoice. The verification layer inside that, if the product makes claims a model can get wrong, is AI evaluation and observability. If you want the failure modes named before you buy any of it, the free production-readiness diagnostic reads a description of what you shipped and returns the ones most likely to bite first, and says where it is inferring rather than being told.

What that work looks like, when the product is already a multi-tenant workspace rather than a demo, is ordinary and visible. A multi-tenant agency operating system we built had to put subscription billing, role-based access for agencies, admins and team members, and an admin-trained knowledge assistant in one place, because the permission model and the assistant constrain each other. The assistant was not the product. The isolation was. Nothing in that description is a headcount or a duration; those figures are not the point, and several of them on this site are still estimates. The point is the shape: the first version of a product can be a set of screens, and the version other companies share cannot.

Run the four questions on a Monday and write the answers down, because the feeling will try to revise them by Wednesday. One: name last month's most ordinary change and the files it must not have touched. Two: state how you know the last two weeks were faster, in a unit that is not a mood. Three: name a person who is not you whose record you could not export or delete this afternoon. Four: name the last question a buyer, a bank or a second company asked that you could not answer from the repository alone. Two yeses is the threshold. Zero is a reason to keep the tool and stop reading. Four is a reason to stop prompting new features until the operate half exists — whether you build it, or you hire someone who has built it before and will leave it in your repository when they go.