When AI should, and should not, be part of a product
The most valuable thing an engineering partner can tell you about AI is where not to use it. A large language model is a probabilistic text engine with running costs and multi-second latency. Point it at a problem a database query solves, and you have made a reliable feature slower, more expensive, and occasionally wrong.
The dividing line is simple to state and easy to get wrong under hype pressure: use deterministic
code for anything expressible as a rule, a lookup, or a calculation; reserve AI for tasks that are
genuinely fuzzy, natural language, unstructured extraction, summarization, classification of messy
input, or judgment that would otherwise consume human hours. The failure mode we see most often is a
team reaching for an agent to do what a WHERE clause does perfectly and for free.
Expand the full engineering breakdown
Why common implementations fail
Teams adopt AI as a mandate rather than a fit. The result is features where the model adds variance without adding value: a support router that a keyword map handled at 99% accuracy, now at 92% and $0.01 per message; a "smart" form validator that a regex did deterministically. Worse, the probabilistic layer becomes load-bearing, so removing it later means rebuilding the workflow.
The decision framework we apply
We score a candidate use case on four axes: ambiguity (is the input unstructured language or judgment?), tolerance (can the workflow absorb an occasional wrong answer, or does one error cause real harm?), economics (does automating this save more than it costs at expected volume?), and defensibility (is there a deterministic fallback when the model is unavailable?). A use case that scores low on ambiguity belongs in code. One that scores low on tolerance needs a human in the loop, not full automation.
Trade-offs we make explicit
Even good AI use cases trade determinism for flexibility, and latency and cost for capability. We make those trade-offs visible up front: a summarization feature might be worth 3 seconds and a fraction of a cent; a real-time input validator almost never is. Where a hybrid works, a cheap deterministic pass that only escalates ambiguous cases to a model, we design for it, because it is usually the cheapest and most reliable answer.
The takeaway
The engineering maturity here is restraint. We will happily talk you out of a model when a plain function is the better product decision, and push hard toward one when the return is genuinely there.