Almost every project conversation now includes the same question: should this have AI in it? Sometimes the answer is yes. Often it is "not yet". Occasionally it is "no, and here is what would work better".
We are not sceptical of AI. We build with it. But a language model is an unusual component. It is fluent, it is confident, and it is sometimes wrong in a way that looks exactly like being right. Adding one to a product without a clear reason doesn't add a feature. It adds a new kind of failure.
The test we apply first
Three questions. If we cannot answer all three clearly, the feature waits.
Is there a specific job? "Add an AI assistant" is not a job. "Explain why this answer to this exam question is correct, in the learner's language" is a job.
Is the answer checkable? Somewhere there must be a source of truth to compare the output against: a rulebook, a syllabus, a price list, a policy. If nobody can say whether an answer is right, nobody will notice when the system starts getting answers wrong.
What happens when it's wrong? Not if, but when. A clumsy product description is an annoyance. A wrong legal deadline or a wrong traffic rule is a different matter. The cost of an error decides how much control a person needs to keep.
If nobody can say whether an answer is right, nobody will notice when the system starts getting answers wrong.
Example: Instruktori AI
Instruktori AI started from a problem a driving school in Gostivar described plainly. Learners study for the theory exam alone, often in the evening, on their phones. They get stuck on a single question or one road sign, and there is no instructor around to ask.
That passes the first test immediately. The job is specific: explain this question, or this sign, now, in the learner's language.
The product is a conversational assistant that answers in Albanian and Macedonian. A learner can photograph an exam question or a road sign and get the answer with an explanation. For learners who don't know where to begin, guided topics such as right of way, police signals and speed limits give them a starting point.
It passes the second test too. The theory exam follows a defined syllabus and the official traffic rules. An explanation of right of way either agrees with those rules or it doesn't.
The third test shaped most of the design.
Constraining the assistant
A general-purpose model will happily talk about anything. That is a feature in a chat app and a liability in a study tool. A learner asking about a roundabout should not get a confident answer borrowed from another country's traffic code.
Before writing a prompt, we write the boundaries down in plain language. Simplified:
ROLE Driving-theory tutor for learners in North Macedonia
SCOPE Traffic rules, road signs and theory-exam questions only
LANGUAGE Reply in the learner's language: Albanian or Macedonian
SOURCE Explain from the official rules; never invent a rule
UNSURE Say so, and suggest confirming with an instructorScope of subject. It stays with traffic rules, road signs and the exam, and redirects anything else politely instead of improvising.
Scope of language. It answers in Albanian or Macedonian, matching the learner. Both are first-class; neither is an afterthought.
Scope of authority. It explains; it does not certify. The exam, the instructor and the official rules remain the authority, and the assistant says so.
Keeping a person in control
The assistant is a study aid, not an instructor, and the design makes that boundary visible instead of burying it in terms of service. The guided topics are chosen deliberately rather than generated, so the main entry points into the material are predictable. And "ask your instructor" is not a failure state: it is part of the product, and it keeps the learner connected to their teacher.
How we decide what an assistant should decline, and how we test that it does, is the subject of What an AI assistant should refuse to answer.
When we say no to AI
The same test tells us when not to use AI, and we say so when it does.
When the answer is a lookup. If the information is a list of prices, hours or services, a well-structured page is faster, cheaper and always correct. The sites we built for a heating installer, a tyre workshop and a café have no AI in them, and they don't need any. A quote form and a WhatsApp button do the job.
When the rules are fixed. Scoring a mock exam on Test-Start is deterministic: an answer is right or wrong under the exam's rules. Ordinary code does that perfectly. A model would only do it nearly perfectly, and "nearly" is the wrong standard for an exam result.
When nobody will review the mistakes. If a client can't name who will look at the failures, the system will drift and nobody will notice.
Saying no is not anti-AI. It keeps AI where it is strong: understanding loosely phrased questions and explaining the rules in plain language.
A smaller, better feature
The pattern repeats across projects. The useful AI feature is usually narrower than the one first imagined. It has one job, one source of truth, one clear boundary, and a person who stays in charge of the outcome.
What this means for your project
Before we add AI to your product, we name the job, the source of truth it is checked against, and what happens when it is wrong. If those answers are weak, we recommend the simpler solution. If they are strong, you get an assistant that knows its limits.
