Designing a New Models Wizard for Bring Your Own AI
Turning a technical, provider-dependent setup into a guided self-service workflow for enterprise admins.
- Bring Your Own AI
- Wizard UX
- Enterprise Admin
- AI Configuration
Executive summary
- The problem
- Enterprise admins needed to configure customer-owned AI models across different providers, credentials, model identifiers, validation requirements, availability rules, and governance constraints.
- My contribution
- I translated that technical capability into a guided self-service workflow, designed the end-to-end setup and validation model, and carried the work from Figma into a working front-end artifact reviewed with Engineering.
- The outcome
- A shipped enterprise workflow that lets admins configure and validate customer-owned models while preserving control over availability and reducing setup risk.
Tabnine originally provided and maintained the AI models available to enterprise customers. Admins could manage those models, but the model stack itself was largely curated by Tabnine.
Bring Your Own AI introduced a different model: organizations could connect their own provider accounts and configure customer-owned models alongside the Tabnine-managed set.
My challenge was to turn that technical capability into a guided admin workflow that made provider-specific setup, validation, and availability feel controlled rather than fragile.
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 step carried setup risk. A wrong provider identifier, invalid credential, or untested configuration could create a model that appeared ready in the admin console but failed later for developers.
The challenge was therefore not simply to expose more settings. It was to create a setup flow that could reveal provider-specific complexity gradually while keeping validation and enterprise control explicit.
What we set out to do.
The wizard needed to make a technical setup feel guided, safe, and predictable for enterprise admins.
- 01
Turn Bring Your Own AI into a clear self-service admin workflow.
- 02
Reveal provider-specific complexity only when it becomes relevant.
- 03
Prevent configuration errors before a model becomes available.
- 04
Preserve enterprise control over credentials, availability, and governance.
How the work moved.
I used an AI-assisted design-to-code workflow to move quickly from product definition into an interactive artifact the team could review before backend integration.
Figma
Defined the end-to-end flow, step structure, wireframes, and UI direction.
Figma Make
Explored transitions and decision points in an interactive prototype before committing to the implementation model.
Claude Code
Translated the approved direction into a working front-end mock of the complete wizard flow, without backend wiring.
Branch + PR
Shared the working artifact through a branch and PR, giving Engineering a concrete interaction model for states, validation, and provider-specific behavior. Engineering connected the backend, completed testing, and released the feature.
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 every field and configuration option at once would expose too much complexity.
The decision
Split the setup into focused steps — Provider, Credentials, Model Details, and Availability — with required validation before the model can proceed to availability.
Why this mattered
The provider choice determines what credentials and configuration come next. A wizard lets the interface reveal only what is relevant at each moment without creating a completely different workflow for every provider.
Design Model Details around a critical path.
We noticed
Model Details contains both required setup information and optional advanced configuration.
The decision
Keep the core path focused on the information needed to configure a working model, while grouping pricing and additional configuration under Advanced Settings.
Why this mattered
This reduced cognitive load for the primary setup path without removing flexibility for admins who needed deeper configuration.
Reduce model-name errors without blocking custom configuration.
We noticed
Provider-facing model identifiers are technical, exact, and easy to mistype.
The decision
Use a combobox pattern that can surface provider model suggestions when available while still allowing free text.
Why this mattered
This helps prevent avoidable identifier errors while supporting both known provider models and custom configurations.
Require validation before a model can be saved.
We noticed
Invalid credentials, endpoints, regions, or model identifiers could create a configuration that looked complete but failed later.
The decision
Make testing a required validation step before saving.
Why this mattered
The test verifies that the provider configuration works at that moment, catching setup problems before the model becomes available to developers.
Protect sensitive and in-progress configuration.
We noticed
The workflow handles provider credentials and can contain meaningful setup progress before the admin saves.
The decision
Treat credentials as sensitive UI throughout the flow and protect in-progress work with discard confirmation when there is something to lose.
Why this mattered
Enterprise setup should not expose secrets or allow accidental dismissal to erase meaningful work. Both protections reduce avoidable risk without adding friction to an untouched flow.
What we shipped.
The shipped wizard guides admins through a controlled sequence from provider selection to validated model availability. The structure stays consistent while fields and requirements adapt to the selected provider.
Provider selection uses scannable provider cards; single-choice interactions can advance directly when the next step is unambiguous.
The result is a repeatable setup model that contains provider-specific complexity inside a predictable enterprise workflow.
How it fits together.
The flow is intentionally linear through validation: provider choice determines credentials, credentials and model details determine whether the integration can be tested, and only a validated setup can proceed to availability.
The same surface, then and now.
Before Bring Your Own AI, admins mainly managed Tabnine-provided models. Afterward, they could configure customer-owned models using their own provider accounts and validate those integrations before making them available.
BeforeAfterBefore: admins mainly managed Tabnine-provided models — enabling, disabling, approving, and setting availability.
After: admins can configure customer-owned models, validate the provider integration, and control where each model is available.
What changed.
The project shipped as part of the product. The working front-end artifact also shortened the distance between design intent and implementation by giving Engineering a concrete interaction model to review before backend integration.
Outcomes
- Turned customer-owned model configuration into a guided self-service admin workflow.
- Created a repeatable structure that supports provider-specific setup without requiring a different end-to-end flow for every provider.
- Reduced setup risk by requiring validation before a model becomes available.
- Preserved enterprise control around credentials, availability, and governance.
- Reduced implementation ambiguity by giving Engineering a working interaction model for states, validation, and provider-specific behavior.
Related governance work
Adjacent work extended the same governance questions into cost control, including exploration of per-model quotas and separate Agent and Chat cost caps. These concepts sit outside the New Models Wizard itself, but connect to the broader governance model around customer-owned AI.