When AI is the wrong tool

One of the things we find ourselves saying often, mostly to each other, is that the right answer to a problem is sometimes a switch statement and a careful schema.

This is not a criticism of AI. We use machine learning in our tools. It is in the products we are most proud of. We are not making the tired argument that AI is overhyped, or that classical methods are underrated, or that it is all going to come crashing down. We do not think any of those things.

What we are arguing with is the reflex. The instinct, now widely shared, that any new problem should be approached by asking how to apply a model to it. This reflex is a symptom of taste failure, not technical sophistication.

We have tried to be honest about the cases where we have caught ourselves indulging the reflex. Three classes of problem keep coming up. In each one, AI was the wrong tool, and the right tool was something simpler.

The first class is problems with hard correctness requirements that the tool itself cannot verify. Calculations whose answers must be exact. Decisions with legal or safety consequences. Lookups whose source of truth is a known table. For these, you do not want a system that produces a confident-sounding answer derived from patterns. You want a system that produces a correct answer derived from a definition. The model is the wrong abstraction. The schema is the right one.

The second class is problems where the value to the user is in doing the work themselves. Learning is the obvious example. If a student is trying to internalize how to think about a graph problem, a tool that hands them the solution has not helped them. It has helped them not learn. The structure of the help (when, how much, in what form) is the entire product. If you optimize for the user's immediate convenience, you destroy the long-term thing they came to you for.

The third class is problems that already have deterministic solutions. A search. A sort. A lookup. A diff. There is a strong temptation, in this moment, to wrap a deterministic operation in a model and call it intelligent. The result is slower, less reliable, more expensive, and harder to reason about than the original. The intelligence was already there, in the algorithm. Adding a model on top of it does not increase the intelligence. It increases the surface area of failure.

We made one of these mistakes early in our work on Glossem. The early version had a feature that suggested rewrites for strings it thought were unclear. We were proud of it. It seemed like the obvious thing to add.

We removed it after a few weeks of using the tool ourselves. The feature was producing suggestions that ranged from fine to actively harmful. More importantly, it was undermining the entire reason the tool existed. Glossem is supposed to surface the words in your product so the right person can edit them: the writer, the designer, the founder who cares about how the product sounds. The feature was bypassing the right person and replacing them with a model. That was the opposite of the goal.

Glossem now does no AI generation at all. It is a static analysis tool. It scans, finds, and surfaces. The intelligence is in the schema and the parser. The suggestions are made by humans. We think this is the right design, and we think we would not have arrived at it if we had been less willing to remove the feature we were proud of.

The honest position about AI is that it is a tool, in the same sense that a database is a tool, and a sorting algorithm is a tool, and a regular expression is a tool. The job of the person designing the system is to use the right tool for each part of the problem. AI is unusually good at some parts. It is unusually bad at others. Treating it as the default is not a sign of being modern. It is a sign of having stopped thinking about the problem.

The reflex is the failure. The taste is the answer.