The most expensive mistake in AI adoption is not using it correctly. It is using it on the wrong problem.

I spent 100 minutes and nearly 19,000 tokens asking Claude Code to clean up my Windows PC — old .NET runtimes, NVIDIA CUDA versions, Visual Studio build tools — figuring out what to keep, what to drop, what to upgrade.

It worked. Mostly. With a lot of permission dialogs, a few course corrections, and some very patient clicking on my part.

Then I realised: Bulk Crap Uninstaller and Winget, two free Windows tools, would have done the same job in under ten minutes.

That is not a complaint about the AI. Claude Code did something genuinely impressive. It reasoned through a messy, undocumented environment and wrote shell scripts without me spelling out every step. That kind of judgment in ambiguity is a real capability.

But I had handed a magic hammer to a problem that had always had a perfectly good screwdriver.

The mistake is not reaching for AI when things get complex. It is reaching for it when things are complex but well-mapped. Those are very different situations, and most adoption decisions right now are not making that distinction.

LLMs are extraordinary when the environment is unpredictable, requirements are shifting, and no existing tool can handle the ambiguity. They are expensive, slow, and overkill when the problem is well-understood and reliable tooling already exists.

This shows up everywhere. For founders, it is deploying AI agents for sales outreach before figuring out why your best customers actually buy. For operators, it is building an AI layer on top of a workflow that a better-designed spreadsheet would have solved.

The pattern holds at scale, too. For global logistics teams, it is asking a model to interpret shipment delay patterns every morning, when a dashboard threshold alert would have caught the same issues faster and more cheaply. For large enterprises, it is routine to route quarterly demand forecasts through a model when the data is structured, the variability is low, and a well-tuned statistical model has always been the right tool.

This is where the technology stands today. The boundary between what needs a model and what does not is shifting, and anyone who tells you it is fixed is not paying attention. The right answer next year may not be the right answer now. Stay curious, stay sceptical, and keep re-evaluating.

Not every hard problem is ambiguous. And not every ambiguous problem needs a model.

Use the magic deliberately.