There are two versions of the AI conversation right now.
In the first one, everyone with “Software” in their job title will be unemployed by next Tuesday. AI is coming for all of us. Learn prompt engineering or learn to enjoy standing in line for bread.
In the second one, AI is just autocomplete with better marketing. A glorified parlor trick. Anyone who thinks it’s useful has clearly never encountered a real problem.
Both are loud. Both are confident. Both are wrong.
I’ve been working with AI tools daily for a couple of years now. Building with them, testing their limits, watching them fail in spectacular and boring ways, seeing things built in minutes that would have taken me weeks. And I keep landing in the same place — somewhere that neither camp seems interested in occupying.
AI is amazing. It offers a lot. It doesn’t solve everything. And the interesting part isn’t picking a side — it’s figuring out which is which.
When AI is the wrong answer
A colleague of mine — a proper AI engineer, not someone tinkering on the side — once used an LLM to parse JSON. Not malformed JSON. Not ambiguous, semi-structured data scraped from somewhere messy. Just regular, valid JSON.
The kind of JSON that JSON.parse() handles in one deterministic, free, instant line of code.
The LLM approach cost tokens, introduced latency, and added a failure mode that didn’t need to exist. It sometimes returned the data slightly restructured. Occasionally it would “helpfully” correct values it thought were wrong. For a task with exactly one correct output, they’d introduced a tool that’s fundamentally probabilistic.
It’s an easy mistake to make when you’re deep in the AI world. When you have a very impressive hammer, things that were never nails start looking like they could be.
I’ve seen a similar pattern with someone building an AI agent to monitor server usage and dynamically scale compute resources. The agent would observe CPU and memory metrics, “reason” about traffic patterns, and decide when to spin up or shut down instances.
The thing is — autoscaling has been a solved problem for years. Cloud providers offer rule-based autoscaling that triggers on thresholds: if CPU exceeds 80% for 5 minutes, add an instance. No reasoning needed. No tokens burned. No wondering if the model hallucinated a traffic spike that didn’t happen.
Could an AI-powered system eventually be smarter about predictive scaling? Maybe. But the baseline problem — react to load and adjust capacity — has a deterministic solution that works, costs almost nothing to run, and has years of production reliability behind it.
Both examples share the same pattern: reaching for intelligence when what you actually need is reliability. If the rule is clear, the outcome is deterministic, and the variability is low, you don’t need a model. You need a function.
When you have a very impressive hammer, things that were never nails start looking like they could be.
When AI is the right answer
This isn’t an anti-AI argument. I use AI every day, and for the right problems, nothing else comes close.
Getting information from images. This is where AI is currently unmatched. Extracting text from messy documents, reading handwritten notes, identifying objects, pulling structured data from photos of receipts or invoices — try doing any of that with a rule-based system and you’ll be writing regex for the rest of your life. AI genuinely excels here because the problem is inherently fuzzy. There’s no deterministic answer to “what does this handwriting say.” Pattern recognition is exactly what these models are built for.
Coding. Software development has never moved this fast. The feedback loop between having an idea and seeing it work has compressed dramatically. Things that used to take an afternoon of documentation reading and Stack Overflow browsing now take a conversation. I can scaffold a project, debug an unfamiliar library, or explore an approach I’ve never tried before — all in a fraction of the time. It hasn’t replaced the thinking, but it’s massively reduced the friction between thinking and doing.
Prototyping and MVPs. This is where the impact is most visible. Going from concept to working proof of concept used to take weeks. Now I can have a conversation about a product idea, build the first version in a day, and put it in front of someone to test. The speed at which you can validate (or kill) an idea has fundamentally changed. For a founder, that compression of the build-test-learn cycle is worth more than any single feature AI can offer.
The pattern here is the opposite of the wrong-answer cases: these are problems where ambiguity is the point. There’s no single correct output. You need flexibility, pattern recognition, or creative generation — and that’s where AI earns its keep.
The “WHAT ARE YOU DOING” reality
For anyone who thinks I’m painting an overly rosy picture of AI in coding — let me balance it out.
I have lost count of the number of times I’ve watched an AI assistant confidently refactor code that didn’t need refactoring. Not broken code. Not messy code. Just code that the model decided could be “improved,” unprompted, while it was supposed to be fixing a minor bug somewhere else.
I once asked it to fix a typo in a config file. It fixed the typo. It also created four new files, introduced an abstraction layer that didn’t exist before, and reorganised the folder structure. For a typo.
Or the time I needed a small utility function — genuinely four or five lines of code — and got back a solution that pulled in seven external libraries, each with their own dependency tree, because the model optimised for looking comprehensive rather than being practical.
These aren’t horror stories. The code usually works. But it works the way a contractor works when they’re billing by the hour and nobody’s reviewing the invoice. AI is a brilliant colleague with no concept of restraint, no sense of project scope, and absolutely no awareness that sometimes the best solution is the boring one.
This is why “AI will replace developers” misses the point so completely. The tool is powerful. The judgment of when to use it, when to override it, and when to throw away its output entirely — that’s the actual job now.
AI is a brilliant colleague with no concept of restraint, no sense of project scope, and absolutely no awareness that sometimes the best solution is the boring one.
How I think about it
I don’t have a perfect framework for when AI is the right call, but I have a few questions I’ve started asking:
Is the problem deterministic? If there’s one correct answer and a known way to get it, AI is probably overhead. Use the known way.
Is the input messy or ambiguous? If you’re dealing with natural language, images, unstructured data, or anything where the “right answer” requires interpretation — that’s AI territory.
What’s the cost of being wrong? AI is probabilistic. It will occasionally get things wrong. For a prototype, that’s fine. For a production system processing financial data, that’s a conversation you need to have before writing the first line of code.
Am I reaching for AI because it’s the best tool, or because it’s the most interesting one? This is the honest question. It’s more fun to build an AI agent than to write a cron job. But the cron job might be the right answer.
None of this is groundbreaking. It’s common sense dressed up in a technical context. But common sense is surprisingly uncommon in a landscape where the incentives push everyone toward the extremes.
The middle holds
Social media doesn’t reward nuance. The algorithm wants heat, not light. “AI is amazing AND limited AND requires judgment” doesn’t generate the same engagement as “AI WILL DESTROY US ALL” or “AI IS A SCAM.”
But the middle is where the actual work happens. It’s where decisions get made, products get built, and real problems get solved.
The radical middle is underrated.