Most of the AI work we do isn't greenfield. It's a system that's already running, already load-bearing, and already has an on-call rotation that pages someone at 3am when it breaks. The client's ask is never "rebuild this with AI" — it's "make this smarter without making it worse."
That constraint shapes everything.
Start with the workflow, not the model
The instinct when someone says "add AI" is to reach for a model first: which one, how big, hosted where. Wrong starting point. We start with a single, narrow workflow inside the existing system — one that's manual, repetitive, and low-risk if it's occasionally wrong — and we retrofit that, end to end, before touching anything else.
This does two things. It gives us a real production feedback loop with actual users and actual data, and it keeps the blast radius small if something's off.
Shadow mode before it's load-bearing
Before the new path is allowed to affect a real outcome, it runs in shadow: same inputs as the existing system, output logged but discarded. We compare against the current behavior for days or weeks, not hours, before anything user-facing changes.
It's slower than shipping straight to production. It's also the only way we've found to retrofit AI into something that can't go down without eventually causing an incident that erodes trust in the whole effort.
The rewrite that never happens
The system stays the system. No framework migration, no "while we're in here" refactor. The AI-native piece is a new, isolated dependency the existing code calls into — swappable, monitorable, and removable on its own if it ever needs to be rolled back.
That's the whole approach: small workflow, shadow mode, isolated dependency, repeat.