Practical AI: Tools, Not Magic

The useful question is never “can the model do this?” — it is “what happens the day it doesn’t?” Design for that day, and the demos take care of themselves.

Functions, not oracles

Strip the mystique and a model call is a function: input, output, latency, cost, error modes. Functions get types, tests, and budgets. The moment you write the type signature, the design improves:

// Not: "ask the AI about the document"
// But:
extractInvoiceFields(doc: Document): Result<InvoiceFields, ExtractionError>

The second version can be validated, cached, retried, evaluated, and — crucially — replaced. When a cheaper model or a regex covers 80% of cases, a typed boundary lets you swap it in without the product noticing. An “AI feature” cannot be replaced; a function can.

Where AI actually pays

The wins that survive contact with production are narrow and boring: classification that routes support tickets, extraction that fills forms, retrieval that finds the paragraph a human then reads. Each has a measurable success rate, a human fallback, and a scope small enough to evaluate.

The losses share a shape too: open-ended generation in the critical path, no ground truth to evaluate against, and a user who cannot tell whether the output is wrong. If you cannot say what a good answer looks like, the model cannot either.

Tools, not magic. It is less romantic and it ships.