Notes on applied AI, written while learning it
I'm learning the forward-deployed engineering craft in public. This site is my notebook: how to audit a real workflow, decide which steps deserve a model, and prove the result is safe to ship.
Why I work this way
Frontier intelligence is sold on the same terms to every company. Prompting it a little better than the next team is not a lasting advantage.
The real process lives in people's heads, in spreadsheets built to get around the system, and in exceptions nobody documented. That context is what makes a model useful on one specific account.
Put intelligence only at the steps that need judgment. Keep everything around those steps deterministic, logged, and approved by a person before it commits.
The method
Map the workflow as it really runs, exceptions included, and measure real time.
Decide whether it needs changing at all, then which steps need a model.
Scripts first, then an API, then a front end. Prove one workflow before building shared parts.
Grade against real past cases. Escalating to a person counts as a pass.
Shadow mode before autonomy. Every run leaves a trace.
Watch edit rate and bypass rate. Whatever breaks next names the next workflow.
Each pass reveals the next workflow, because bottlenecks are connected.
From the notebook
Why two weeks of audit comes before any code, and what to collect: interviews, exception paths, the spreadsheets people built to get around the system, and where colleagues already use AI on their own.
There is one way work goes right and a thousand ways it goes wrong. How to list the failure modes, and why a disagreement between people is a policy question and not an exception.
Three gates decide where a model belongs: does the workflow need changing, can plain code do it, and which steps are truly fuzzy. Most steps land in code.