Skip to content
Mariano Rodrigo

Mariano Rodrigo

AI Solutions Engineer building production systems with artificial intelligence, automation, and full-stack architecture. This is my public engineering lab: architecture decisions, implementation reports, experiments, and lessons from real systems.

When not to use an LLM

· ai-systems, architecture, decisions

The most useful thing I do on many AI projects is talk a team out of using a model where a deterministic rule, a query, or a small classifier would be cheaper, faster, and far easier to operate.

Questions before the model

  1. Is the task actually ambiguous? If the rules can be written down, write them down. Regex and SQL do not hallucinate.
  2. What is the cost of a wrong answer? High-stakes, low-tolerance tasks need verification layers that often cost more than the model itself.
  3. Can you evaluate it? If you cannot define “good” with examples, you cannot improve it or detect when it breaks.
  4. What is the steady-state cost? A demo runs a few times. A pipeline runs millions. Token cost and latency compound.

A reasonable default

Use the smallest mechanism that solves the problem. Reach for an LLM when the input is genuinely unstructured language and the output tolerates review. Everything else is usually a system-design problem wearing an AI costume.

Saying no to AI in the right place is what makes the yes credible everywhere else.