AI-Techno Jinni: Just because AI can do it, doesn't mean it should.
Building with AI has made more things possible. HoursKZ, warehouse interfaces and an architectural detour taught me to ask which of them belong in the product.

One of the most tempting things about having an AI Jinni is how often the answer to "Can you build this?" is yes. Another feature? Certainly. Another interface? Why not? A different architecture? The Jinni probably has a few suggestions already.
It's wonderful to have so many possibilities. But I've noticed something about working this way: the easier it becomes to make things, the more important it becomes to decide which things should exist in the first place. I learned part of that lesson by saying yes.
HoursKZ started as a simple way to stop tracking employee hours manually in my coffee shop. As people began using it, we discovered related problems with schedules, shift coverage and approvals. I expanded the product because those needs were real. They weren't features I added to make the software look more impressive. That was a good reason to use the Jinni's abilities.
Other decisions have been less about adding something and more about choosing where to stop. In a warehouse-operations product I've been developing, Telegram was a natural interface for frontline tasks. But that didn't mean every interaction belonged in a chat. Some tasks worked better in a dedicated interface, while administration needed a different workspace altogether.
I could build more interfaces, put more actions into Telegram or try to make everything work in one place. None of those possibilities answered the important question: what would actually make the work easier for the person doing it? I've encountered the same temptation in software architecture.
During another AI-assisted development effort, a technical blocker appeared. Instead of concentrating on resolving it within the design we'd already agreed on, AI began proposing architectural changes. The alternatives were technically possible. Some might even have been interesting.
But I hadn't asked for a new architecture. I needed a specific problem solved without discarding decisions that were already made. That distinction matters. A technical obstacle doesn't automatically give the Jinni permission to redesign the system around it.
I don't want AI to stop suggesting ideas. Quite the opposite. One of the best things about these tools is that they make me consider possibilities I might otherwise overlook. But a suggestion is not a product decision. Neither is a technically feasible implementation.
What I've found interesting is that my role hasn't become less important as the Jinni has become more capable. The decisions have simply changed shape. Instead of spending all my attention on whether something can be built, I spend more of it deciding whether it belongs in the product at all. Sometimes the answer is yes. Sometimes it's not yet. And sometimes it's a perfectly reasonable idea that has no business being there.
My Jinni can help me make a remarkable number of things. That doesn't mean I need all of them.