When not to use AI (and use plain software)

The strongest move an AI architect can make is sometimes to not use AI. A large language model is a probabilistic engine for language and reasoning under uncertainty. When a problem is deterministic, has a known correct answer, or must be exact every time, plain software is cheaper, faster, and more reliable.

Signs that AI is the wrong tool: the rules are stable and writable, such as flag any invoice whose total exceeds the limit; the output must be identical for identical input; a mistake is expensive and hard to catch; or a simple lookup, regular expression, or database query already solves it. Reaching for a model here adds cost, latency, and a new failure mode in exchange for nothing.

Signs that AI earns its place: the input is messy natural language, images, or unstructured documents; the space of valid answers is too large to enumerate; some ambiguity is acceptable; or the task is summarizing, drafting, classifying, or extracting from human-generated content. Even then, AI is often one component beside deterministic code, not the whole system.

A pattern worth keeping: use deterministic software for the parts that must be exact, and AI for the parts that must be flexible. A tax calculation stays in code; the explanation of the result can come from a model. This split gives you the reliability of software where it matters and the flexibility of AI where it helps.

The reliability angle: every AI component you add is a component that can be confidently wrong. Adding one where plain code would do is a permanent tax on both your latency budget and your trust budget.