I find myself saying this to people more and more often: if you have a math problem, don't ask AI to solve it. It's the wrong tool, and it will get it wrong. But ask AI to build you a calculator, and you'll have something reliable that solves that problem correctly every single time.
It's a simple distinction, but it's one that I think a lot of teams — and a lot of founders — are getting backwards right now.
The Tool Builder, Not the Problem Solver
AI is remarkably good at creating tools. It can scaffold applications, generate well-structured code, build interfaces, and wire together systems with impressive speed and accuracy. What it's less good at is being the tool itself for repetitive, deterministic tasks. Every time you ask an LLM to solve the same type of problem, you're rolling the dice again. The output is probabilistic by nature. It might get it right nine times out of ten, but that tenth time will cost you — and in production, at scale, those misses compound fast.
The better pattern is to use AI to build the thing that solves the problem, then let that thing — deterministic, testable, reliable software — do the heavy lifting. You get the speed benefits of AI-assisted development without the variability of AI-driven execution.
Not Everything Needs AI
I was recently advising a founder who had been working on a solid product idea for about six months. Good concept, clear market, real traction. Then she started getting pressure from investors and advisors telling her she needed to incorporate AI into the product.
Here's the thing: it didn't need AI. The product worked. The value proposition was clear. Introducing an LLM into the core workflow would have done two things, neither of them good. First, it would have introduced variability into a process that needed to be consistent and predictable. Second, it would have created potentially explosive operational costs — every user action burning AI tokens adds up fast, especially when those actions are repetitive and high-volume.
Not every product needs an LLM shoehorned into it just because the market expects an "AI story." Sometimes the smartest AI strategy is knowing where AI doesn't belong.
The 3D Printer and the Injection Mold
The analogy I keep coming back to is 3D printing versus injection molding. Both are legitimate manufacturing approaches. Both have an important role in the product lifecycle. But they serve very different purposes.
3D printing is incredible for prototyping. You can go from concept to physical object in hours. You can iterate rapidly, test ideas cheaply, and produce small batches of things that would be prohibitively expensive to mold. But if you're manufacturing at scale, you don't 3D print a million units. You invest in an injection mold — higher upfront cost, but dramatically lower per-unit cost, better consistency, and far greater throughput.
LLMs in software products work the same way. You can get some really impressive features out of an LLM very quickly. Magic-feeling functionality that would take a traditional development team weeks or months to build properly. That's genuinely valuable, especially early in a product's life when you're validating ideas and moving fast.
But over time, you should be looking at how to take those LLM-powered features and build them into the core of your product as traditional software. Replace the probabilistic with the deterministic. Swap the per-request token cost for a fixed infrastructure cost. Trade the magic for something that delivers consistent results every single time, at a fraction of the long-term operational expense.
The Irony Isn't Lost on Me
Here's the part that makes me smile every time I think about it. So many of the features where AI is being integrated into products today are cases where relatively straightforward software development is being replaced by magic LLM calls. Companies are using AI as a crutch to avoid building the actual functionality into their codebase.
And the irony? Those same LLMs are simultaneously making that "traditional" software development dramatically more accessible. The tool that's being used as a shortcut around proper engineering is also the tool that's making proper engineering faster and easier than it's ever been.
AI is amazing for making software — I'm finding new and incredible ways to use it every single day. But there's a meaningful difference between using AI to build your product and using AI as your product. The teams that understand that distinction are the ones that will build things that last.