Not every problem needs a language model

These days a language model is the default answer to almost everything. Someone describes a problem in a meeting, and before they finish the sentence someone else says "we could use AI for that." Sometimes that's exactly right. I've shipped AI features I'm proud of, and I use these tools every day in my own work.

But in the products I've built myself, I used a model a lot less often than you'd think. That wasn't about budget or about being skeptical of the technology. It was a design decision, the same kind you'd make about a navigation pattern or a form. Every tool has a shape, and some problems just don't fit that shape.

Over time I ended up with three questions I ask before putting a model anywhere near a feature. None of them is clever. They mostly slow me down enough to actually think about the person on the other side of the screen, instead of the demo.

Does it actually need language?

One of my side projects is a small app that reads payment receipts. The first idea was the obvious one: take a photo, send it to a model, ask it what the receipt says. It would have worked, and it would have looked great in a video.

But when I looked closely at the problem, reading a receipt doesn't really need something that understands language. A receipt isn't a conversation. It's a short, predictable document with a total, a date and a reference number, usually in roughly the same places. That's a problem people solved well long before AI was in every pitch.

So I went the traditional way. The app reads the receipt right there, on the person's own phone, with no model involved. It costs nothing per use, so I never had to think about limits or pricing tiers. It keeps working on a bad connection. And nobody's bills, with their names, amounts and account numbers, get sent to someone else to be read. For a finance app, that last part matters more than any feature on the list.

A model would have made a nicer demo. The plain version made a better product. That's a trade I've learned to notice, because the demo is what gets applause in the meeting, and the product is what people live with afterwards.

What happens when it's wrong?

Every model is wrong some of the time. That's not a flaw you fix later, it's part of how they work. So the real design question isn't whether it'll make mistakes. It's what a mistake looks like for the person using the product, and whether they'll ever find out.

In another product I worked on, built for people buying used cars, the system flags listings that are probably posted by dealers rather than private sellers. Buyers care about that difference, so it's a genuinely useful signal. The tempting version simply hides those listings. Cleaner feed, fewer clicks, everyone's happy.

Until it guesses wrong. The system is making an educated guess, not stating a fact. When it's wrong in that version, a good car silently disappears from the feed. The buyer never knows it existed, so they can't complain, so nobody ever learns the model made a mistake. That's the worst kind of error, the kind nobody can see.

So we flag the listing, explain why it was flagged, and let the buyer decide what to do with it. It's a little less magical. It's also honest about what the system actually knows.

The AI informs. A person decides.

When I'm unsure how much to automate something, I picture the mistake happening to one specific person on a normal Tuesday. Would they notice? Could they undo it? If the answer to either one is no, the model gets to make a suggestion, not to press the button.

Who has the last word?

In the day-to-day work of a development team, sprint estimation is one of those rituals that eats more time than it should. Everyone has sat through a refinement where the same ticket gets debated for twenty minutes. On an internal tool I built for a team, I tried letting a model help with that.

The idea was simple. The AI looked at each ticket on its own, without knowing what the team thought, and proposed an estimate based on how the team had sized similar work before. When it wasn't sure, it said so and stayed quiet, and the ticket went straight to the people.

Its guess was very close to the team's final estimate about 80% of the time. Honestly, that was better than I expected. On paper, that's good enough to let it decide.

But something else showed up in the data. The people still agreed with each other more than they agreed with the model. And when I looked at why, the answer was kind of obvious in hindsight. An estimate isn't only a number. It's also the conversation where the team discovers what a ticket really means, what's hidden inside it, and who knows the risky part. If you replace the number, you quietly lose the conversation too.

So the model's guess became the opening estimate, the thing the team argues with, and never the final one. Refinements got shorter because people started from something instead of from zero, and the discussion went to the tickets that actually needed it.

Three questions, every time

Does this need language? What happens when it's wrong? Who gets the last word? I ask them in that order, every time, and the answers decide whether AI goes into a feature and how much rope it gets.

Sometimes the honest answer is a model with a clear human checkpoint. Sometimes it's a model that only suggests. And sometimes it's the old fashioned way: a few clear rules, a good empty state and a well written error message. None of those is the boring option. They're all just design.