Heuristic

A heuristic is a rule of thumb or approximation that produces good-enough answers with bounded effort, even if it is not provably optimal. In AI and software engineering, heuristics are everywhere: A* search uses a heuristic to estimate distance-to-goal; chess engines use material-plus-position heuristics to evaluate board states; recommender systems use heuristic tie-breakers when ranking scores; LLM agents use heuristics to decide when to stop iterating. The word sometimes carries a slightly pejorative tone ("just a heuristic") when contrasted with principled methods, but most production AI systems run on a carefully-engineered stack of heuristics, and that is usually correct — the alternative is slower, more expensive, and often no better in practice.

The design of a good heuristic follows recognisable patterns. **Admissibility** (in search) — never overestimating the true cost — preserves optimality guarantees. **Monotonicity** — the heuristic only gets better as you approach the goal — simplifies reasoning. **Calibration** — the heuristic's confidence tracks actual correctness — is the property that most industrial heuristics fail on in subtle ways. **Failure graceful** — when the heuristic is wrong, the error is bounded, not catastrophic — is what separates production-quality heuristics from brittle ones.

For APAC mid-market AI teams, the practical discipline is **naming your heuristics out loud** — treating them as first-class design decisions rather than hidden magic constants. A system that explicitly says "we rerank search results using a heuristic that weights recency at 0.3, relevance at 0.5, diversity at 0.2" is debuggable, tunable, and legible to product managers; a system where those weights live as undocumented constants in code is a maintenance trap. Every LLM-based system contains dozens of small heuristic choices — max tool-call iterations, confidence thresholds for when to ask clarifying questions, fallback order when primary models fail — that deserve explicit documentation.

The non-obvious principle: **heuristics usually beat learned components on the edges**. Teams replace a simple rule with a model, gain average-case quality, and then discover the rule handled edge cases the model now gets wrong. The right architecture is usually **learned components wrapped in heuristic guardrails**: the model handles the bulk of decisions, and explicit rules catch the failure modes that matter.