Short notes, infrequently.
On platform engineering and applied AI — written to be useful, not to be seen.
Why the AI pilot never becomes a product
Almost every enterprise has an AI pilot that impressed a room and then quietly stopped. Not because the model was wrong. Because nobody made it someone's job to be responsible for what happens when it's wrong.
A pilot gets built by whoever was curious enough to try. It gets evaluated on a demo — a handful of prompts, a clean dataset, a good day. Then it gets shown to leadership, gets a round of applause, and gets handed to a team that has neither the mandate nor the time to take it further. Nothing about that sequence produces a system that survives contact with production traffic, edge cases, or a bad actor.
The systems that do survive share three things the pilots didn't have.
An owner, not a sponsor. Someone whose job is the outcome of the system, not the launch of it — accountable for what it does in month six the same way they were for the demo in week one.
Evaluation built for the failure mode, not the happy path. A pilot is judged on whether it worked when you tried it. A product is judged on what it does the one time in five hundred that it's confidently wrong, and whether anything catches that before a customer does.
A place in the workflow, not next to it. The AI systems that actually change how work gets done are wired into the tool people already use, with the guardrails and human checkpoints that make the automation trustworthy enough to leave alone. The ones that don't are a tab someone opens twice and forgets.
None of this is a reason to slow down. It's a reason to stop treating the pilot and the product as the same project with a different budget. They aren't. The pilot answers whether the idea works. The product answers who owns it when it doesn't — and that question needs an answer before the rollout, not after the first incident.