AI · 18 March 2026
Connect the model to a real system

A model earns its place when it is attached to something real. A chatbot over your own knowledge, search across your documents, extraction from a messy export, or an agent on an API the team already trusts. Someone asks, gets an answer grounded in that system, and the work actually moves.
The versions I'd build again are all attached to something real. Search over a team's own documents. Pulling fields out of a messy export. A small agent that calls an internal API the team already trusts, then shows what it changed. In each case the model is one step inside a task people were already doing.
Being connected brings its own rules. If the model can write, someone needs to see what it wrote and when. I spend more time on that trail than on the prompt, and I'd rather ship one narrow action with a visible result than a general assistant nobody can check.
Some briefs don't need a model at all. A missing field, a filter, or a better default can remove the work outright. When that's the case I say so early, because wrapping a model around a form problem is how these projects get expensive and stay vague.
When a model does belong, I make its edges plain in the interface: what it read, what it suggested, and what a person approved.
More insights
- Design the failed login path firstEngineering
- Agree what a finding is before building the dashboardInfrastructure
- Use motion for state, then stopInterface
- Write the empty state before the full oneEngineering
- Leave a handoff the next developer can useEngineering
- Give an agent a boundary people can seeAI
- Build a company site for the next page, not the firstInterface
- Show the feed that stopped reportingInfrastructure
- Design for the return visit firstInterface