At a glance

AI builders get you something that looks finished astonishingly quickly. That is not an illusion. The code is real and it does work.

The problem is that the eighty per cent it does brilliantly is the easy eighty per cent. Everything expensive, tedious and genuinely difficult lives in what is left, and that is precisely where it stops being able to help you.

The eighty per cent that demos beautifully

Screens. Forms. A database with sensible-looking tables. Login. Basic create, read, update, delete. A page that lists things and a page that shows one thing. Some pleasant styling on top.

This is the part everybody sees, and AI is genuinely excellent at it. A weekend gets you something you can put in front of people without embarrassment. Ten years ago that was a month of work and a meaningful amount of money.

Take the win. It is a real one.

What actually lives in the last twenty per cent

Then you try to put it in front of actual customers, and the list arrives.

  • Error handling. What happens when the payment provider is down, the upload fails halfway, or someone closes the tab mid-save.
  • Edge cases. The refund on a partially shipped order. The customer with two accounts. The name with an apostrophe in it.
  • Concurrency. Two people doing the same thing at the same moment without corrupting anything.
  • Permissions. Not just who can log in, but who can see which record, and enforcing that everywhere rather than mostly.
  • Performance at real volume. The query that was instant with fifty rows and unusable with fifty thousand.
  • Data migration. Getting the existing data in, correctly, including the messy historical stuff.
  • Monitoring and logging. Knowing something broke before a customer tells you.
  • Backups and recovery. Tested ones, not assumed ones.
  • Deployment. Shipping changes without downtime and undoing them when they go wrong.

None of it demos. All of it is the difference between a prototype and a product.

Why AI is bad at exactly this part

It is not a gap that a better model closes, which is the bit people find hard to accept.

The first eighty per cent is pattern work. Millions of applications have a login screen and a list page, so the model has seen the shape of the answer thousands of times. It reproduces it well because reproduction is what it does.

The last twenty per cent is not pattern work. It depends on facts about your specific situation that exist nowhere in the training data and usually nowhere in writing at all. How much traffic you get and when. Which failures you can tolerate and which you cannot. What your data actually looks like, including the ten years of inconsistency in it. What the regulator expects of your industry.

You cannot prompt your way to that. Somebody has to know it, decide what to do about it, and take responsibility for the answer.

Why it always costs more than you budgeted

Because the budget got set while looking at the demo.

Everything visible was done in a fortnight, so the remaining work feels like it should be another fortnight. In practice the invisible twenty per cent regularly takes longer than everything that came before it, and it arrives as a nasty surprise rather than a planned phase.

Worse, it usually arrives at the worst possible moment. You have customers now. You have told people it is nearly ready. The pressure to ship is highest exactly when the remaining work is least forgiving.

This is the rebuild nobody budgeted for, and it is why the upfront price of AI-built software is so rarely the real price.

The good news

Most of these apps are fixable.

The instinct when you discover the last twenty per cent is to assume the whole thing is rubbish and start again. That is almost always wrong and almost always more expensive. The screens are fine. The general shape is usually fine. What is missing is the unglamorous engineering underneath, and that can be added to what you already have.

Finding out where you stand is a days-long job, not a months-long one. Knowing costs very little. Not knowing is what gets expensive.

So should you build with AI at all?

Often, yes. For prototypes, internal tools and testing an idea before spending real money, it is an obviously good call.

Just budget honestly. If the thing is going to hold customer data or carry real traffic, plan for the last twenty per cent from the start rather than discovering it at launch. We have set out the decision properly in should you build your software with AI? if you want the longer answer.

As ever, it comes back to the same distinction: AI is a brilliant typist and a terrible architect. The first eighty per cent is typing. The last twenty is architecture.

Got something that is eighty per cent finished and unsure what is left? Our AI Code Audit is a fixed-price £495 review that tells you plainly what you are dealing with, or get in touch for a no-pressure conversation.