Building in the UI

The creator UI in 2.0 is not the old editor rearranged. The thing that changed most is what it shows you: structure, dependencies, and history that used to be implicit or invisible are now on screen. If you build in code, see building in code instead. Most teams end up doing both, on the same lab.

Watch the walkthrough

What you notice first

• The interface exposes what used to be hidden. Structure and relationships between parts of a lab are visible rather than something you hold in your head
• A command center, opened from the search bar or with cmd+k, finds anything in a lab and jumps you to it
• Tooltips surface the relevant documentation where you are working, with a link through to the full page
• Dark and light mode

A lab’s structure is visible

• Chapters and pages. Pages replace challenges. Chapters group pages by theme, so a long lab reads as a set of topics rather than one sequence
• Assets, files, and scripts in one tab. A dedicated tab shows the full structure of a lab, including the parts that used to sit outside the editor
• Used in labels. Any resource shows every other place it is used in the lab, and you can click through to each one. Before you change something, you can see what depends on it

Building a page

A page is far more flexible than a challenge. It can hold instructions, several activities, and components together, in whatever order fits the content.

• Activities. Tasks and quizzes are together called activities. A task validates work in the sandbox and holds multiple conditions, each with its own fail message. A quiz checks understanding. Both sit inline on the page, and you can mix them freely
• Quizzes no longer need a page of their own. Put a quiz where it is relevant, put several on one page, and use the new question types including text and number input
• Layouts per page. The screen changes as a learner moves through the lab. A reading page can show one tab, the next page a terminal and an editor
• Tabs that persist. A tab is created once and assigned to a layout, carrying the learner’s real state forward across every page it appears on, instead of being rebuilt per page
• Notes anywhere. Notes are a tab type now, so you can place as many as you need, only where they help
• A cloud credentials tab exposes the credentials for a given cloud account natively, so you do not write them into instructions
• Completion component. The end of a lab is a component like any other, with a message, button label, and link you control
• Feedback component. Place feedback directly in the content, as many times as you want, with your own question text. Available at general availability
• Embedded PDFs and Google Slides render inline

The sandbox in the UI

The sandbox is a set of typed resources you declare and connect, not a block of configuration plus scripts.

• Resources reference each other, so the platform works out what has to exist first
• Any field takes either a literal value or an expression, chosen with a toggle. This includes the value of a variable
• Secrets carry team managed values and variables carry values a lab declares itself, so values no longer travel through scripts
• Terraform runs through a Terraform registry, replacing custom resources
• Far less needs a script at all. Where something is genuinely imperative, it becomes an exec resource

Editing safely

This is the biggest change for teams with more than one builder.

• Version control is always on. Every lab is versioned from the moment it is created, with nothing to set up. Every change carries who made it and when, and changes can be reverted
• Edit mode separates viewing a lab from actively editing it, so it is always clear which one you are doing
• Branches let you build a complete working version of a lab, play it, and share it before it goes anywhere near the version other people are using
• Version tags mark a known good version, so you can pin, compare, and roll back as the subject a lab teaches moves on
• Inline comments and notes on resources let the team explain why something exists, in the place it exists

Reuse without leaving the UI

• Lab templates. Save a finished lab as a template and use it as a scaffold for the next one, built to be copied safely
• Modules. A versioned package containing any part of a lab, sandbox resources, instructions, or tabs, pulled from a registry so one change updates everywhere it is used. Modules and the registry arrive at general availability, not in Early Access

Starting from a description instead of a blank page

The AI Lab Builder works inside the product. Describe what a lab should achieve and who it is for, and it plans the structure and then builds it with you. A knowledge base does the research first, covering the company, the products, and the users. It also works the other way around: someone new to a library can interrogate what already exists and keep building without the original author to explain it.

When something goes wrong

• Rebuilt logs give you more information, with real controls to filter and slice it
• Used in labels tell you what a change will affect before you make it
• Lab ids are predictable, derived from the resource type and name rather than being a random string

Mapping from V1

In V1	In 2.0
Track	Lab
Challenge	Page, grouped into chapters
Check, a button that validates	Task, a component with multiple conditions
Quiz on its own page	Quiz inline, anywhere on a page. Tasks and quizzes together are called activities
Fixed final page	Completion component
Fixed feedback in a lab	Feedback components you place
Notes used as a loading page	Notes as a tab type, placed anywhere
One layout for the whole track	A layout per page
Tabs rebuilt per challenge	Tabs assigned to layouts, state carried forward
Sandbox presets	Modules, versioned in a registry
Scripts holding setup logic	Declared resources, with exec for what is genuinely imperative
No version history in the editor	Version control always on, with branches and tags