Stop Building Rocket Ships for Groceries: Why Some Business Applications Should Never Use AI
See the video here: https://youtu.be/VxFYfbF1Hgs
Artificial intelligence has become the default answer to almost every technology question. Need better customer service? Add AI. Want to modernize operations? Add AI. Looking for a competitive edge? Surely AI belongs somewhere in the plan. But that reflex has created a serious problem inside many organizations: teams are using AI not because it is the best solution, but because it is the most fashionable one. The result is predictable—bloated budgets, unnecessary complexity, weaker systems, and disappointing returns. The core argument of The Hard Truth: Some Applications Should Never Use AI is simple: the real skill is not figuring out where AI can be used, but where it actually should be used.
That distinction matters more than most executives, architects, and product teams want to admit. AI is powerful, but it is not magical. It is not automatically better than traditional software, and in many cases it is dramatically worse from a cost, compliance, and maintainability perspective. According to the video, one of the biggest mistakes enterprises are making right now is force-fitting AI into problems that traditional software already solves well. In other words, some organizations are building rocket ships to deliver groceries: technically impressive, but wildly unnecessary.
The first and most important test is whether a problem is deterministic or probabilistic. Deterministic problems have clear rules and exact answers. If the same input goes in, the same output should come out every time. Billing engines, tax calculations, eligibility checks, policy enforcement, and approval workflows generally fall into this category. These are not areas where you want guesswork. You want precision, repeatability, and clear audit trails. Traditional software excels here because it is designed to follow rules exactly and consistently.
Probabilistic problems are different. They involve uncertainty, patterns, and changing conditions. Instead of producing one guaranteed correct answer, the system estimates, predicts, classifies, ranks, or interprets what is most likely true. That is where AI starts to make sense. The video highlights use cases such as fraud detection, demand forecasting, predictive maintenance, churn prediction, and interpreting unstructured inputs like emails, PDFs, contracts, images, audio, and free text. In these domains, the logic often cannot be cleanly captured in a rules engine because the patterns are too subtle, too messy, or too dynamic. AI adds value precisely because it can operate in ambiguity.
This is why structured versus unstructured data is such an important dividing line. Traditional systems work beautifully when data arrives in clean fields and fixed formats. They struggle when the input looks like the real world: inconsistent, incomplete, contextual, and messy. AI shines when software has to understand meaning rather than simply read a predefined field. If a company needs to extract intent from support tickets, analyze visual defects in manufacturing, or interpret the language of insurance claims, AI may provide a meaningful advantage. But if the application is mainly moving known values through known workflows, AI may only make the system harder to explain and more expensive to operate.
That cost issue is one of the strongest themes in the video, and it deserves more attention than it usually gets. Many organizations discuss AI as if it were merely a technical upgrade, like replacing one framework with another. It is not. AI is a business investment with significantly different economics. In the video, AI systems are described as often costing five to ten times more to build than traditional alternatives, and twenty to thirty times more to operate over time. Even if those numbers vary by organization, the broader point holds: AI is expensive, both upfront and continuously. It requires additional compute, monitoring, retraining, governance, testing, and human oversight. If the business problem is small, stable, and easy to automate with rules, paying that premium is difficult to justify.
Recommended by LinkedIn
That is where many AI projects quietly fail. They may technically function, but they do not produce enough value to justify their cost. A system that solves the right problem the wrong way is still a failed investment. The video argues that this mismatch is a major reason many AI initiatives are not delivering return on investment. Teams become captivated by the possibility of using AI and stop asking the tougher, more important question: is this the minimum viable technology needed to create business value?
Another useful insight is that AI becomes more compelling when the environment changes faster than rules can keep up. Fraud patterns evolve. Customer behavior shifts. Language changes. Equipment performance drifts. In these environments, hard-coded logic becomes brittle. Traditional software can still work, but it often requires constant updates to stay relevant. AI has an advantage because it is better suited to adapt to changing patterns over time. The key is not that AI is inherently smarter than rules; it is that rules are static and the world often is not.
Still, even in strong AI use cases, the video warns against treating AI as a total replacement for people. One of the smartest architectures is often a human-in-the-loop design, where AI drafts, prioritizes, extracts, flags risks, or recommends actions while humans review and make final decisions. This approach captures much of AI’s productivity value without fully surrendering control, explainability, or compliance. It also reflects a more realistic understanding of how most organizations operate. AI is usually better at augmenting human work than eliminating the need for human judgment altogether.
That leads to perhaps the most practical takeaway of all: many of the best systems are hybrid systems. The video description explicitly notes that rules should handle what is clear while AI handles what is uncertain. That is often the sweet spot. Use deterministic logic where certainty matters and probabilistic models where interpretation or pattern recognition is required. Instead of replacing conventional architecture, AI becomes one component in a broader design. This is a more mature and less ideological way to think about modern application development.
Ultimately, this is not an anti-AI argument. It is a pro-discipline argument. It calls for better architecture, clearer thinking, and more honest economics. AI absolutely belongs in some applications—especially those involving prediction, classification, unstructured data, changing environments, and hard-to-scale human judgment. But a large share of business software does not fit that profile. In those cases, traditional software remains faster, cheaper, safer, easier to explain, and often more reliable.
The organizations that win in the AI era will not be the ones that insert AI into every workflow. They will be the ones that know when not to. They will understand that good architecture is not about chasing trends but choosing the right tool for the job. When teams stop asking, “Can we use AI?” and start asking, “Should we?” they move from hype-driven engineering to value-driven design. And that is the difference between building something impressive and building something that actually works.
So very true. It's kind of like the days of "you need an app, I need an app, we ALL need an app." No, we don't all need apps. And as you state here, some business applications also don't need, and/or shouldn't use, AI. Good insights, DL
💯 The real decision for leadership is whether AI should not be used. Leadership must exercise courage and understanding to know when AI is not the right fit or does not improve a business process or workflow.
We mistake novelty for utility because forcing AI into every workflow feels like progress. Traditional, rules-based software handles structured data and predictable logic with a level of precision that probabilistic models simply cannot match. I watched an engineering team scrap a complex LLM pipeline for an invoice routing system and replace it with simple database queries. The simpler code cut processing costs by ninety percent and completely eliminated the random errors they were fighting every week. When a leadership team is determined to hit an AI adoption quota, how do you convince them to leave standard software alone?
Force-fitting anything often leads to long-term pain. I agree, David Linthicum, that we need to be careful about overusing AI-driven solutions. As architects, it’s tempting to follow trends or design flashy solutions, but our role is to stay trusted advisors who prioritize the business’s best interests. We’ve achieved so much through deterministic code, yet it feels like that progress is at risk as we eagerly embrace non-deterministic or autonomous systems and applications.
David, this is such an important reality check because too many organizations are treating AI like a status symbol instead of a strategic tool. The real competitive advantage is not blindly adding more technology, it’s having the discernment to know where complexity should be reduced instead of amplified. I learned this through experience myself. Some of the strongest operational improvements I’ve seen came not from layering on more systems, but from simplifying workflows, clarifying decision paths, and using technology intentionally where it genuinely strengthened human judgment instead of replacing it unnecessarily. What makes your message powerful is that you’re reframing AI adoption from hype into architectural discipline. The organizations that win long-term will not be the ones forcing AI into every process, they’ll be the ones mature enough to align the right tools with the right problems while protecting clarity, trust, and operational simplicity.