The first AI-enabled feature I shipped at Uptempo suggested values as a user filled out a form. They open a wizard to create a marketing activity, the system reads the surrounding context, and it proposes a value for each dropdown. That helps when the suggestion is right, and a model that guesses at values is going to be wrong a fair amount of the time. A confident wrong answer costs the user the time to notice and undo it, and a little of their trust in every suggestion that comes after.
I built the working prototype myself with an AI-assisted workflow and walked through it with the design and engineering teams. Almost every UX decision worth talking about came down to the same question: what does the feature do when the model is wrong?
Render on confidence, not on availability
The model returned a suggestion and a confidence tier for each field, and the interface keyed off the tier rather than off the existence of a suggestion. High and medium confidence rendered a button with a short hover explanation of why the value had been proposed. Low confidence rendered nothing, so when the model was unsure the field was indistinguishable from an ordinary form field.
A suggestion that never appears costs the user nothing; they fill the field in themselves, exactly as they would have without the feature. A wrong suggestion that appears with confidence costs them the correction and some of their willingness to trust the next one. So the low tier shows nothing, and the feature deliberately covers fewer fields than it technically could.
Degrade to the product you already had
The AI layer was additive. When the suggestion service was slow or down, the wizard behaved exactly as it had before the feature existed, with the same fields and the same flow and no error surfaced to anyone, because the creation path never routed through the model in the first place.
It’s an unglamorous property, but it’s the one that made the feature safe to release. A feature that takes the underlying workflow down whenever the model has a bad day is one you keep boxed into a small pilot; a feature that falls back to the plain form is one you can gate behind a flag and widen at whatever pace you’re comfortable with.
Measure quality from the first commit
The product’s analytics before this were click-level: what people clicked, in what order. None of that tells you whether a particular suggestion was any use. So the first version of the feature logged structured accept and reject events against each suggestion session - whether the user took the value, edited it, or left it alone. From those you can build an acceptance rate and slice it by confidence tier and by field, which is the number you actually need to know whether the model is earning its place. Because the logging shipped in the first commit, that signal started accumulating immediately, instead of being bolted on months later once someone realized the feature had never been measurable.
Hand off the code you meant to hand off
Raising the prototype as a pull request isn’t a normal move for a product manager, so I set the terms with engineering before I opened it: the outcome was entirely theirs, anywhere on the range from shipping it as written to deleting all of it and starting fresh. I left the code short of production quality on purpose. I wanted engineering to own something they understood and could maintain, not to receive a polished-looking draft that would feel awkward to rewrite.
They rebuilt most of the implementation in their own architecture. The parts I had designed to survive (the API contract and the accept/reject telemetry model) came through nearly unchanged, which was more or less the point: the prototype existed to settle the feature and the defensive patterns, and the devs rewrote the code so that ownership genuinely moved to the people who would keep it running. It launched with some of the product’s largest customers on it.
What carries over
None of these patterns are specific to my feature; they’ll serve any nondeterministic layer you put on top of an existing product. Render on confidence and weak output never reaches the user. Keep the AI layer additive and the product still works when the model is down. And instrument accept and reject from the first commit, which is the step teams most often defer and the hardest to add convincingly later, because you can’t backfill the months of signal you never collected.