Every team I've worked with wanted to talk about the model first. The interface, they figured, was the easy part: drop a text box on the page and let the magic happen. It never works out that way.
The model gives you a capability. Turning that capability into something a person will rely on is a different job, and that job is where most AI features quietly fail.
01 The model isn't the product
When I designed internal tooling at Meta, the underlying model could do far more than anyone used it for. What people were short on was trust, not capability. Nobody hands a real decision to a system they can't read or correct.
So the first questions were never about prompts or parameters. They were about surface: how much to reveal, when to interrupt, what to do when the model is wrong but sounds completely sure of itself. Those are interface decisions, and they decide whether anyone ever uses the thing twice.
A model that's right 90% of the time is a demo. An interface that handles the other 10% gracefully is a product.
02 Show the work, not the magic
The instinct with AI is to hide the machinery and present a clean answer. That reads beautifully in a demo and erodes trust in production. The interfaces that actually got adopted did the opposite, they showed their work:
- Surface the sources, so a person can sanity-check the claim in two seconds.
- Admit uncertainty instead of delivering everything in one flat, confident tone.
- Make every AI action reversible, so trying it costs nothing.
The model didn't change in any of this. People could suddenly see where an answer came from and what it would cost to act on it, and that's what moved the tool from "neat" to "I use this every day."
# the pattern, roughly. "confidence" isn't free:
# estimate it (logprobs, a judge, agreement across
# samples), then calibrate it against real cases
if confidence < threshold:
show_reasoning() # let them audit it
offer_easy_undo() # make trying it free
else:
act() # but still leave a trail
03 Design for being wrong
A model doesn't have bugs so much as a distribution of outcomes, which means being wrong isn't an edge case, it's a Tuesday. The whole experience has to assume the model will miss and stay calm when it does.
Practically, that meant designing the failure states first, not last: the empty result, the low-confidence answer, the "I'm not sure, here's what I'd check." When those states feel considered, the occasional wrong answer reads as honesty rather than betrayal.
04 What I'd tell my past self
Start from the surface, not the model. Sketch the moment a person reads the output and decides whether to trust it, because that moment is what you're really shipping. Better models will keep arriving whether or not you do anything. The interface is the part nobody else is going to fix for you.
That's been the throughline across everything I've shipped in this space. The model was rarely the hard part, and I've never once shipped an AI feature where the interface wasn't.