Ask why you need AI before asking where to put it

In the last entry, I wrote that “coding tool” no longer describes how I use AI. It now appears in much more of the work around a product: while I am thinking through decisions, architecture, implementation, testing, debugging and delivery. At first, that seems to point toward an obvious conclusion. If AI is useful in so many parts of creating a product, perhaps it should also appear in more of the product itself.

I have found the distinction itself more useful than that conclusion. Using AI to build a product and building AI into the product are two separate decisions. I can use AI heavily throughout the work and still end up with something whose users have no reason to care whether AI was involved.

HoursKZ is probably the clearest example I have. The original problem in my coffee shop was manual employee time tracking, and the useful solution began as a straightforward Telegram workflow. Working with Codex made that software much cheaper and faster for me to build and iterate, but the employee did not need an AI feature for the product to become useful. From their point of view, the important change was simply that a piece of manual work became easier.

That separation now affects how I think about adding AI elsewhere. Questions such as “where could we put a chatbot?” or “which process could use an agent?” are not necessarily bad questions. The problem is that they begin with a capability that already exists and then go looking for somewhere to apply it. I find it more useful to begin with what is actually happening. Sometimes a frustrating process is frustrating because two systems do not talk to each other. No amount of intelligence changes the fact that the useful fix may be an integration. Sometimes people are repeating the same predictable action and ordinary automation is enough. Sometimes the underlying rule is already known and stable, so implementing it directly gives exactly the behaviour the product needs.

And sometimes the difficulty is somewhere else entirely. The information exists but people cannot get to it easily. The inputs arrive as inconsistent language rather than clean fields. Each case depends on context. The useful answer has to be assembled from material that does not fit neatly into a fixed sequence. That is where the reasons for using AI start becoming much more concrete.

Real products rarely divide this neatly. A single workflow may contain a deterministic rule, an integration, a search problem and a genuinely ambiguous part that benefits from AI. The point is not to classify the whole product. It is to understand what each difficult part actually requires.

This is also why I do not find “if normal software can do it, don't use AI” particularly useful. A conventional implementation may already exist and AI can still make it substantially easier to use. A search problem may be technically solved by filters and keywords while remaining frustrating for the people doing the searching. A process may be expressible through rules while still becoming much more adaptable when a user can work with it through natural language. AI can also change the economics of work that was previously too expensive to perform manually at useful scale.

The fact that a deterministic solution exists does not make AI unnecessary. The fact that an AI solution exists does not make it better either. What I want to understand is the improvement. Sometimes that means making the task materially faster or easier to access. Sometimes it means handling variation that would otherwise require a large amount of manual work. In other cases, AI may make a capability feasible that was simply too expensive or impractical before. If I cannot identify an improvement like that, “we can add AI here” does not give me much to work with.

That matters because adding AI is not neutral from an engineering point of view. It can bring more variability into behaviour, additional latency and operating cost, new dependencies, and more work around monitoring and support. Those may be completely reasonable trade-offs. A capability that changes the outcome enough can justify all of them, but they are still trade-offs.

AI is not a free architectural adjective. Putting it into a product changes the product, just as choosing any other consequential technical approach does. “We can” is therefore not enough information for me.

What makes this slightly strange is that my development work keeps moving in the other direction. I use AI more frequently than I did before. It helps me investigate a problem, explore implementation choices, produce code, test, debug, document and review what I have built. The more normal that becomes, the less I feel any need for the finished product to prove that AI was involved.

The opposite shape is possible too. In another product, AI may be the capability that makes the useful outcome possible at all. Remove it and much of the product’s value disappears with it. That can be just as sensible a product.

So I still ask where AI could help. I expect I will ask that question more often as the technology becomes capable of more things. I just try not to ask it first.

The question I want ahead of it is what actually needs to improve, and then: what would become materially better because AI is here?