Why the most expensive mistake in AI isn’t that it won’t work — it’s assuming it can do more than it actually can.
There’s a number doing the rounds in boardrooms and LinkedIn posts right now: AI can automate 90% of the work. It’s a great line. It’s also the start of a very expensive misunderstanding.
The figure isn’t wrong. For certain types of work, 90% is entirely believable. The problem is the missing half of the sentence. Ninety per cent of what? Strip that qualifier away and a true statement about one narrow kind of project quietly becomes a blanket promise about every project, including the complex, analytical, high-stakes builds that construction and manufacturing businesses actually need.
That gap between the headline and the reality is where budgets blow out, timelines slip, and trust in AI gets quietly burned. So let’s close it.
“Ninety per cent of what?”
Recently our team had a healthy internal debate about exactly this claim. One view: 90% of work can be automated by AI. The pushback was simple and correct, 90% of what kind of work?
Here’s the honest answer. If you’re building a low-risk workflow or application build, the kind where the work is forgiving of error, and an AI tool can generate large portions of the solution from a high-level brief, then yes, AI might genuinely handle around 90% of it. Low risk, low complexity, low cost of getting it wrong. Perfect territory for automation.
But that is not the work that runs a construction estimating team or a manufacturing production line. The moment a project becomes analytical, mathematical, or carries real risk, money on the line, safety implications, decisions people will actually act on, the picture changes completely. In our experience, the realistic AI contribution on that kind of complex build sits closer to 20–40%. The remaining 60–80% is development, design, integration, and human judgement.
Same technology. Wildly different percentage. The only thing that changed was the type of project, and that’s the qualifier the hype conveniently drops.
Faster is not the same as cheaper
The second assumption worth dismantling is that AI automatically makes a project cheaper. We hear it constantly, clients arrive expecting a build to be both faster and cheaper, as if the two always travel together. They don’t.
AI is not free to run. There are token costs every time a model does work. More importantly, there’s a human cost: on a serious project, a developer has to control the AI, check what it produces, and correct it when it’s confidently wrong. That supervision is real, skilled labour. Add the running costs and the correction effort together, and your cost per hour can actually go up — even on a project that finishes sooner.
So where does the genuine value show up? Usually in time, not money. Picture a complex build that would normally take six months. If roughly a third of it suits AI-assisted delivery, you might compress that to four months. That’s a meaningful win, faster to market, faster to value but it’s a speed benefit on the right slice of the work, not a blanket discount on the whole invoice.
The organisations getting the best results understand this distinction before they start. They’re buying speed where speed is available, not expecting magic across the board.
The plug-and-play myth
Underneath both misunderstandings sits a bigger one: that AI is just prompting. Type a clever instruction, get a finished result, done.
Prompting is the visible 5%. It’s the part people see in a demo, and it looks effortless. What stays hidden is everything that makes the output trustworthy: the prompt engineering that actually holds up under real conditions, the testing, the correction of wrong answers, the integration into systems that already exist, and a human who knows the business well enough to tell good output from plausible nonsense. AI doesn’t run itself. It needs an operator.
“Plug-and-play” is the most dangerous phrase in the AI conversation, because it sells the part that’s easy and hides the part that’s hard. The question for any business isn’t whether AI can help. It’s where AI helps most and what still has to be built by people around it.
What this looks like on the ground
Two illustrative scenarios — representative of the kind of work we see, rather than any single client — show how the 20–40% reality plays out.
Construction: automating the tender pile
Imagine automating estimating. A builder receives drawings, specs, and a stack of subcontractor quotes for every tender, and someone has to read through all of it. AI is genuinely good at the first pass: extracting figures, classifying documents, pulling line items out of the noise. That’s the suitable slice, and on a clean set of documents it looks brilliant in the demo.
Then reality arrives. The real documents are marked-up PDFs, inconsistent spec formats, and drawings with handwritten annotations across them. The quantity logic, the exception handling, the validation that catches the AI’s confident mistakes, all of that has to be built by people. And it’s precisely that edge-case handling, not the tidy extraction, that consumes most of the build. The AI got you started faster. It did not do the project.
Manufacturing: forecasting you can actually trust
Now picture a demand-forecasting or production-risk tool. AI accelerates the early scaffolding, boilerplate code, exploratory data work and gets a working shape on the screen impressively quickly. Useful, real, time-saving.
But the modelling itself, the validation of assumptions against what actually happens on the shop floor, and the testing required before anyone trusts the numbers against real purchasing or scheduling decisions, that’s human-led. Here’s the twist that surprises people: because AI produces plausible-looking forecasts fast, it can increase the testing burden, not reduce it. Output that’s plausible but wrong is far more dangerous than output that’s obviously broken, especially when it’s about to drive a purchasing decision or a predictive-maintenance schedule. Plausible-but-wrong is the most expensive failure mode in the building.
Before you commit to an AI project
The biggest risk in AI isn’t that it won’t work. It’s assuming it can do more than it actually can and discovering the gap after you’ve committed the budget. And the only reliable way to know that is to assess the work itself, task by task, before a single line of production code is written.
For anyone signing off the investment, that gap is a financial risk, not just a technical one. Funding a project on the assumption it’s a 90% AI solution when it’s really 30% doesn’t just blow the timeline, it commits capital against a return that was never on the table. The cost of backing the wrong AI initiative isn’t only the money spent; it’s the budget that didn’t go to the initiative that would have paid off. Knowing the real percentage before you commit is how you protect the return.
Before investing in a build, a business needs clarity on a few unglamorous questions:
- What AI can realistically automate
- What still requires human expertise
- Where the integrations get genuinely complex
- What the real implementation effort — and cost — looks like
That’s the entire reason we built Discovery & Design.
Most businesses start an AI project by asking what they want to build. We start by understanding what actually needs to be done.
During Discovery & Design, our consultants and developers break the proposed solution into individual tasks, workflows, integrations and functional requirements. Each component is then assessed against several criteria:
- AI coding suitability
- Integration complexity
- Business criticality
- Human oversight requirements
- Development effort
Some tasks are highly suited to AI-assisted development. Others require traditional engineering, testing, validation and business expertise.
By analysing the project at a task level rather than a project level, we can calculate a realistic AI impact score before development begins.
That’s how we determine whether a project is realistically a 20%, 50% or 90% AI-assisted opportunity. Not through assumptions. Through structured analysis backed by both consulting and developer input.
For organisations still mapping where AI and automation fit across the business rather than scoping one specific project, our SmartStart program helps identify and prioritise the opportunities worth pursuing first.
And where that work proves genuinely suited to AI-assisted delivery, we can implement it through our AI-First Development approach.
Clarity before commitment
AI is powerful. AI is not magic. Most complex projects still demand real human design, process thinking, integration, and business knowledge and the 90% headline conveniently forgets to mention it.
CROFTI exists to separate AI possibility from AI reality before you commit time, money, and resources to a build. If you’re weighing up an AI project and want a straight answer on what it can actually deliver, that’s exactly the conversation we’re built for.
Start with clarity, not assumptions
Discover whether your idea is a 20%, 50%, or 90% AI opportunity before committing budget, time, or resources. Start with Discovery & Design.