The credibility problem with the opposite advice
Everyone selling AI has an incentive to find a use for it. The useful version of that expertise is knowing where it loses to something simpler, because a badly-placed model is the fastest way to make a team distrust the whole category.
1. When the rule is actually a rule
If the logic can be written as conditions — thresholds, eligibility, routing by explicit criteria — write it as conditions. A model asked to apply a deterministic rule will apply it correctly almost every time, and almost is a downgrade from a rule that is right always.
If you can write it as an if-statement, a model is a slower, more expensive if-statement that occasionally disagrees.
2. When you can’t tolerate variance
Anything where the same input must produce the same output — financial calculation, compliance determinations, anything audited — wants deterministic code. Consistency is not something to prompt for; it is something to choose an architecture for.
3. When the volume doesn’t justify the maintenance
An AI feature carries permanent costs: evaluation, prompt upkeep, monitoring, review. A task performed twice a month cannot repay that, however well it demos, and the total running cost is mostly staff time.
4. When nobody can verify the answer
If no one on the team can tell a correct output from a plausible one, you cannot evaluate it, cannot catch drift, and will not notice when it degrades. That is not a model problem — it is a missing evaluation and the feature should wait.
5. When the real problem is upstream
Teams frequently reach for AI to cope with data that is contradictory, a process that is unclear, or documentation that doesn’t exist. A model does not fix any of those; it inherits them, and contradictions in the corpus produce effectively random answers.
Fix the upstream problem and quite often the AI feature is no longer needed. That is a good outcome, not a failed project.