TL;DR: Apply five questions to each step of a job, not to the product as a whole. A step fits a model when its input is varied and messy, its errors can be tolerated or caught, it requires recognising patterns rather than applying written policy, there is data to evaluate it, and the value of each use exceeds its cost. Steps that fail belong to rules, ordinary software, or people.
Why a fit test
"Add AI" is a common instruction and a poor specification. It skips the question that decides whether the feature will work: does this job actually need a model? Models are excellent at some things (understanding messy language, reading documents in any format, summarising, drafting) and poor substitutes for others (applying exact rules, moving money, being consistent every time). Teams that skip the question build features that are slower, more expensive and less reliable than a rule would have been.
The test works best applied step by step. Few products are entirely suited or unsuited to AI; most jobs contain one or two steps where a model helps and several where it should not be involved.
The five questions
1. Is the input varied? Receipts in every format, support messages in any phrasing, documents in many languages: varied input that rules cannot anticipate is where models shine. A dropdown, a form field with a fixed format, or a structured record is not varied, and parsing it with a model adds cost and error for nothing.
2. Are errors tolerable or catchable? Every model makes mistakes. A step fits if an error is cheap (a slightly off product suggestion) or can be caught before it matters (the user confirms an extracted amount; a test suite checks generated code). A step where an uncaught error is expensive and irreversible needs either a very high bar or no model. See cost of a wrong answer.
3. Is it pattern or policy? Recognising that a photo shows a damaged parcel is pattern recognition. "Refunds over ₹5,000 need manager approval" is policy. Policy should be written as rules, because rules are exact, auditable and do not drift. Asking a model to interpret and apply a written policy invites inconsistency and makes decisions hard to explain.
4. Is there data to evaluate it? If you cannot assemble a few hundred real examples with known correct outcomes, you cannot measure whether the model works, which means you cannot responsibly launch it. Note that this is data for evaluation, not training; most AI features use pre-trained models and still need evaluation data.
5. Does value per use exceed cost per use? Models cost money per call. A feature used millions of times for marginal benefit can cost more than it creates. A feature used rarely but saving an hour each time easily pays.
Applying it
An expense approval flow, step by step:
| Step | Varied input | Errors catchable | Pattern or policy | Eval data | Verdict |
|---|---|---|---|---|---|
| Read the receipt | Yes | Yes, employee confirms | Pattern | Past receipts | Model |
| Check policy limits | No | Must be exact | Policy | Not needed | Rules |
| Flag unusual claims | Somewhat | Yes, reviewed | Pattern | Past flagged claims | Statistics, model to explain |
| Approve | Not applicable | Not applicable | Judgment | Not applicable | Person, with a summary |
| Reimburse | No | Must be exact | Policy | Not needed | Rules |
The result is a precise design: a model where input is messy and errors can be confirmed, rules where policy and money apply, and a person where judgment is required.
When rules win
Rules beat models more often than people admit:
- When the logic can be written down completely.
- When decisions must be identical for identical inputs.
- When an auditor or regulator will ask why.
- When the input is already structured.
- When volume is high and value per use is low.
A common pattern in good AI products is a deterministic backbone with models at the edges where messy input enters or language leaves. See deterministic plus probabilistic.
When the answer changes
The test is a snapshot. Models get cheaper and better; a step that failed on cost or accuracy last year may pass now. Keep the evaluation examples and re-run them when a significantly better or cheaper model becomes available. Conversely, a step that passes today can fail tomorrow if the input distribution shifts, which is why evaluation continues after launch.
In the interview
Almost every AI product sense question benefits from a fit test early in the answer: "Before designing, I'd check which steps actually need a model." Interviewers listen for whether candidates can say "this part should be a rule" with conviction. A Strong Hire answer applies the test step by step, keeps policy and money in rules, designs human confirmation where model errors can be caught, and names the data needed to evaluate the model steps.
Next: cost of a wrong answer · deterministic plus probabilistic