Designing a New Models Wizard for Bring Your Own AI
Helping enterprise admins configure, test, and manage AI models using their own provider accounts.
- Bring Your Own AI
- Wizard UX
- Enterprise Admin
- AI Configuration
Tabnine originally provided and maintained the AI models available to enterprise customers. Admins could approve, enable, or disable Tabnine-managed models, but the model stack itself was mostly curated by Tabnine.
As enterprise customers needed more control over providers, licenses, token costs, and governance, Tabnine introduced Bring Your Own AI: a self-managed path where organizations could connect their own provider accounts and configure their own models alongside Tabnine-managed models.
I designed the New Models Wizard to turn that technical capability into a guided, self-service admin workflow — helping admins configure, validate, and control model availability without leaving the enterprise governance model behind.
Supporting a new mental model — customers bringing their own AI.
This was not just a matter of adding more settings to an existing page. The product needed to support a new mental model — customers bringing their own AI provider setup into Tabnine.
The setup involved several technical decisions:
- Choosing a provider
- Entering the right credentials
- Defining the provider-facing model name
- Choosing the display name developers would see
- Setting availability
- Testing that the configuration actually worked
Each decision carried risk: an incorrect provider identifier, missing credential, or untested configuration could create a model that looked available in the admin console but failed later for developers.
A single long form would have exposed too much complexity at once. The setup had to feel reliable and controlled — not like the admin was leaving Tabnine’s managed environment behind.
What we set out to do.
The wizard needed to make a technical setup feel guided, safe, and predictable for enterprise admins.
- 01
Make Bring Your Own AI understandable as a self-service admin flow
- 02
Reduce cognitive load by splitting provider-specific setup into clear steps
- 03
Support multiple providers without redesigning the flow for each one
- 04
Help admins validate configuration before making a model available
- 05
Preserve enterprise control around availability, governance, and cost ownership
How the work moved.
I used an AI-assisted design-to-code workflow to move from Figma exploration to an interactive front-end mock quickly. The goal was not to replace engineering, but to give the team a concrete wizard flow to review before backend wiring.
The mock was handed off through a branch and PR with a written summary. Engineering connected the backend, completed testing, and released the feature. After the core structure was in place, I continued refining smaller friction points such as required vs. optional fields, unnecessary clicks, and protecting in-progress configuration.
Figma
Defined the flow, wireframes, and UI direction. Mapped the wizard’s structure and step-by-step logic before validating it interactively.
Figma Make
Explored the interaction model through an exploratory prototype — step transitions and decision points. Used as process evidence, not as the shipped product UI.
Claude Code
Translated the direction into a working front-end mock of the full wizard flow — an interactive artifact engineering could review and react to, without backend wiring.
Branch + PR
Opened a branch and PR — the working front-end mock plus a written summary of the flow. The engineer connected the backend, completed testing, and the feature was released as part of the product.
The calls that shaped the work.
A few calls shaped how the wizard reads and behaves.
A wizard instead of one long form.
We noticed
The setup is branching and provider-dependent. Showing everything at once would create too much cognitive load.
We decided
Split the flow into focused steps — Provider, Credentials, Model Details, and Availability. Each step asks one main question and adapts to the admin’s previous choices.
Why it worked
The admin’s first choice — provider or model type — determines what comes next; each provider needs different credentials and configuration. A wizard lets the flow reveal only what’s relevant at each moment, while the structure itself stays consistent across providers.
Provider cards, with auto-advance as a refinement.
We noticed
Provider choice is the foundation of the setup, but requiring a separate Next click after selecting a single provider added unnecessary friction.
We decided
Use visual provider cards as the main pattern. Auto-advance was designed as a refinement to make the single-choice interaction feel more natural.
Why it worked
Cards make the choice visible and scannable, while auto-advance removes a redundant click when the interaction is clearly a single decisive choice.
Designing Model Details around a critical path.
We noticed
The Model Details step contains both critical setup fields and optional advanced configuration. Showing everything at once increases cognitive load.
We decided
Design the step around a clear critical path, with optional pricing and additional configuration grouped into Advanced Settings.
Why it worked
This keeps the main path focused while preserving flexibility for advanced users.
Designed to reduce model-name errors.
We noticed
Exact provider model identifiers are technical and easy to mistype.
We decided
I designed a combobox pattern that could show provider model suggestions when available, while still allowing free text as a fallback.
Why it worked
This reduces avoidable errors without blocking custom model configuration. It also supports both experienced admins, who may know the exact identifier, and newer admins, who benefit from provider suggestions.
Required testing before save.
We noticed
If credentials, endpoints, regions, or model details are incorrect, the model will fail later. Because credentials and provider settings live outside Tabnine, a configuration can also break if keys are rotated, replaced, or revoked.
We decided
Make testing a required validation moment before saving.
Why it worked
The test verifies that the integration works against the provider right now — proving credentials are valid before the model becomes usable. Validating at setup prevents quiet downstream failures in usage and cost tracking, and gives admins confidence before they make the model available.
Handling credentials as sensitive UI.
We noticed
Because the flow handles provider credentials, sensitive fields could be exposed in plaintext — a real risk during demos, screen sharing, or collaborative admin work.
We decided
Credential fields needed to be treated as sensitive UI across the flow.
Why it worked
Consistent handling reduces the risk of exposing secrets and prevents surprises where a value is hidden in one place but visible in another.
Protecting in-progress configuration.
We noticed
Closing the modal could reset all state without warning. An admin who entered credentials, picked a model, or ran a test could lose progress with one accidental click.
We decided
Design a discard-confirmation pattern for in-progress configuration.
Why it worked
The confirmation should appear only when there is something to lose, protecting admin work without adding friction at the start of the flow.
What we shipped.
The final experience guides admins through a structured setup flow. Each step focuses on one part of the setup; provider-specific complexity is revealed only when relevant. Validation happens where it matters most — through the required test against the provider — and the structure supports moving between steps as the admin works through the setup.
The wizard turned Bring Your Own AI from a complex technical capability into a guided admin workflow.
How it fits together.
The flow starts with provider selection. The credentials step is designed so its fields adapt to that choice. Admins then define model details, validate the setup, and decide where the model should be available.
The flow is intentionally linear until validation: provider choice determines credentials, credentials and model details determine whether testing can succeed, and only a validated setup should become available.
The same surface, then and now.
Before, admins mainly managed Tabnine-provided models — enabling, disabling, approving, and setting availability.
After Bring Your Own AI, admins could configure customer-owned models, connect their own provider accounts, validate the setup, and control availability alongside the Tabnine-managed set.
BeforeAfterBefore: admins mainly managed Tabnine-provided models — enabling, disabling, approving, and setting availability.
After: admins can configure their own models using their own provider accounts, control where each model is available, and validate the integration before saving.
What changed.
The project was developed and released as part of the product.
Outcomes
- Turned model configuration into a self-service admin flow — admins could configure customer-owned models through a guided setup instead of relying on a one-off internal process.
- Supported the Bring Your Own AI direction — customers could connect their own providers and models alongside the Tabnine-managed set.
- Reduced setup risk — required validation helped catch configuration issues before a model became available.
- Preserved enterprise control — availability, governance, and cost ownership remained part of the admin workflow.
- Improved confidence around sensitive setup — credential handling and validation made the flow feel safer and more controlled.
- Supported a more scalable model-management approach — customer-configured models could be added without Tabnine needing to maintain every provider setup internally.
Related governance work
The wizard also connected to adjacent governance work around cost control, including follow-up exploration for per-model quotas and separate Agent and Chat cost caps. This sits outside the wizard flow itself, but belongs to the broader governance system around customer-owned AI models.