Someone shows a customer a prototype. It was built in four days with an AI coding tool, with no guardrails, no architecture direction and no one from the wider team involved. It has a login screen, a dashboard, data that looks real and a workflow that runs end to end. The room leans in. Somebody asks when it can go live. Watch the engineers’ faces.
I’ve been on both sides of that moment. You can now build things in an afternoon that I’d have quoted a fortnight for two years ago, and I know how good it feels when the room leans in. I also know what the question that follows does to a team.
The wrong question
The question is always some version of “do we build on this or start again?” It sounds like a sensible engineering decision. It isn’t, because it assumes the code is the asset.
The code is the cheapest thing in the room. The expensive thing is the picture now sitting in everyone’s head of a finished product.
Why it looks finished
AI tools are very good at the surface. Screens, flows, plausible data, a demo that runs. What they don’t build unless you make them is everything a demo can’t show: input validation, authentication done properly (OAuth is hard, and hard for all the right reasons), one data model instead of four slightly different copies of it, tests, logging, a way to deploy it, the plumbing that turns a thing that works into a thing that keeps working.
An experienced engineer carries all of that without thinking about it. The coding structure, the testing habits, the guardrails, the awareness that it has to run somewhere other than their own laptop. It’s baked in from years of living with the alternative. An AI tool carries none of it unless someone puts it in, and the person building in four days usually doesn’t know it’s missing. So we get something that runs on localhost:8080 and nowhere else, and looks exactly like something that runs everywhere.
It doesn’t have to be that way. Everything the engineer carries can be written down and put where the tool can’t miss it, and an AI builds with it as readily as without. Most teams just haven’t done it yet.
None of the missing parts are visible from the front. That’s the point.
A film set shopfront looks like a shop from where the audience sits. Walk round the back and it’s a sheet of plywood held up by struts and sandbags. Nobody on the crew is fooled, because they built it and they know it comes down after the shoot. The audience was never told.
An AI prototype is that shopfront. The customer is the audience.
The real cost
Sales has a date now. The customer has a picture, and somewhere a contract is being written around it. The real system has to match a thing that was never built to be matched, and every week it falls short, the prototype looks better by comparison.
That’s the debt. Not technical debt, which you pay off in refactoring. Expectation debt, which you pay off in trust.
The rule
Treat a proof of concept like a set: build it to be struck.
- Bake the guardrails in before the first prompt. The things an experienced engineer carries in their head go into the project before the AI writes a line, as things the tool can’t ignore: a skill that sets out how you build and test, permissions that stop the agent touching what it must never touch, tests it has to pass, a pipeline that refuses to deploy what isn’t ready, and a second agent reviewing at the points where you’d want a senior to look. If nobody can write those down, that’s the finding, and it’s worth more than the demo.
- Time-box it. One, three or five days. Not a week that becomes a month.
- Sandbox it. Synthetic data, no integrations, nothing that can leak into production.
- Say what it is before you show it. “This is a flat front. Here’s what’s behind it, and here’s what isn’t.” Say it before the room leans in, not after.
- Hand forward the spec, not the code. Which flows mattered, which assumptions broke, what the real one needs. Write that down. Then strike the set.
The first build was never the hard part. The moment the customer says yes, the prototype stops being a demo and becomes a product, and a product has to go through everything the demo skipped. Threat modelling and a pen test. Authentication that holds up to someone trying to break it. Tests that run on every change. A pipeline that builds, checks and deploys it the same way every time. Logging and monitoring, so you know it’s broken before the customer does. Scaling, because the demo had one user and the contract has thousands. Backups, support, a way to roll back. None of that is optional, and none of it was in the four days.
That isn’t a flaw in the prototype. It’s what a prototype is for. The mistake is letting it make promises on the product’s behalf.
Keep the spec. Bin the prototype.