Analysis / Development and agents
How to take an AI prototype to production without rebuilding everything
The prototype works and looks convincing on screen. Before releasing it, establish which parts are dependable, which only serve the demo and what maintaining them will require.
What a prototype actually proves
A prototype shows whether an idea can work and helps uncover requirements. It does not yet establish that the system can handle real users, recover data after a failure or be updated safely.
Generative tools shorten the initial exploration. That saving is valuable when it lets the team test important decisions earlier; it disappears when the first output is treated as a finished application.
Start by writing down which part of the demo must survive. It might be the journey, an interaction or a task result. Everything else can change during construction. If the prototype uses Astra, also review what to check before adopting it.
The gap between what is felt and what is measured
One figure explains much of the enthusiasm. On 10 July 2025 METR published a randomised trial with 16 experienced developers across 246 real tasks in their own repositories. Before starting, they estimated AI would make them 24% faster. With the tools in hand, they took 19% longer. And afterwards, having taken longer, they still reckoned they had been 20% faster.
Between what was felt and what was measured there are nearly forty points. That gap is why a team can be convinced it is flying while the calendar says otherwise, and why a demo convinces the person showing it as much as the person watching.
What piles up when nobody goes back
GitClear analysed 623 million code changes between 2023 and 2026 and published the results in January 2026. Block duplication rose 81% since 2023 and sits at the highest level they have on record. Moved code, the signal that somebody goes back and reorganises, fell from 21% in 2022 to 3.8% so far in 2026, while copy and paste climbed to 15.7%. Calls to functions in other files dropped 35%.
Put briefly: far more gets written and far less gets reorganised. Each new piece is pasted beside the last one instead of replacing it.
Black Duck's OSSRA report, published on 25 February 2026 across 947 commercial codebases in 17 industries, shows where that road ends: 93% contain components with no development activity in the last two years. The mean number of open vulnerabilities per codebase rose 107%, to 581. And 68% carry licence conflicts, against 56% the year before. Choosing what you build on matters more every year, which is the subject of how to pick a stack with its maintenance in mind.
Where the bill turns up
CodeRabbit reviewed 470 public GitHub pull requests and published the result on 17 December 2025: 320 with AI involvement and 150 written by people only. The first group arrived with 10.83 issues per pull request against 6.45 for the second. For security vulnerabilities the difference rises to 2.74 times. The report itself notes that authorship is inferred from signals rather than confirmed one by one.
The bill is not always paid by whoever generated the work. Daniel Stenberg, who maintains curl, wrote on 14 July 2025 that around 20% of the security reports he was receiving that year were AI-generated noise, and that only 5% of the total turned out to be valid. The work of discarding what was worthless was eating the project, to the point of rethinking the bounty programme it had run since 2019.
It is the same pattern we saw with 3D models: something that looks right in the viewer and does not hold in production does not save work, it moves it somewhere else.
How to tell whether what you have holds
| Criterion | What to check |
|---|---|
| Owner | Who maintains it in six months, by name and with hours |
| Origin | Which parts were generated, with which tool and on what date |
| Dependencies | How many there are and when each was last updated |
| Licences | Whether what comes in really allows what you plan to do |
| Tests | What breaks when a line changes, and who finds out it broke |
| Data | Where it ends up and who can read it if the prototype ships |
| Rebuild | What building it properly would cost against maintaining this |
The final row avoids two extremes: preserving a fragile foundation through inertia or rebuilding without evidence. Compare both routes by time, risk and maintenance before deciding.
What to ask for before production
Three things in writing, before anything is touched. What the project has to do when it is done, one sentence per thing somebody will check. Which parts are generated and which have been reviewed by hand. And who answers when it breaks, by name and with time assigned. Writing that down before starting is exactly what spec-driven development measures.
With those three answers, a generated demo is a good starting point and can be quoted. Without them, what you have is a piece that works on the day it is shown, and the real cost turns up later, spread across whoever maintains it.
If you have a generated prototype and want to know what taking it to production would cost, tell us what it does and what holds it up.
Sources
Checked on September 20, 2026