Meet Studio: Your AI Employee Builds Real Web Apps While You Watch. Point at Anything to Change It.

Asking an AI employee to build you something on the web has worked for a while now. You describe what you want, it writes the files, it publishes, you get a link. The part that never worked was everything after the link: you open it, you see the headline is wrong, and now you are back in a chat box trying to describe in words which headline, on which page, and what it should say instead.

v4.0.19 removes that round trip. The Studio is a new panel in the chat sidebar that opens full width, like the Kanban, and shows what your employee is building as it is being built. Every file it writes appears at once. You can look at the draft as a desktop, a tablet or a phone, in portrait or landscape, and the whole panel becomes that device.

This is not a page builder

Worth saying early, because most tools that look like this one only produce pages. The Studio builds real applications. Everything the web-publish skill can do works here: server-side functions, a real database, file storage, and genuine WebSockets, with connections, messages and broadcast to every connected client. That last one is the line between a site and an app. It is what a live dashboard, a chat, a queue display or a collaborative screen needs, and it is the part most page builders do not have. Your employee writes the backend, not just the front of it.

So a showcase site with a contact form that actually sends is the small end of the range. The large end is a full-stack app with a protected admin area, a CRM whose records live in a gat-database, a dashboard pulling live figures, an installable mobile app. Your employee builds the visible page first with sample data so you have something to react to, then the database and the functions behind it.

That matters for what you can ask it to change, too. When you comment on something, you are not limited to what is painted on the screen.

Point at the thing instead of describing it

Click any element on the page and write what should change. Your employee receives the element itself: the page, the element, its text, its code, and a picture of exactly what you were looking at, including the tab you had open and the state the page was in. If you want to change a region rather than a single thing, draw a rectangle over it and every element inside comes along. Hold Ctrl or Cmd and click to pick several elements for one comment.

Each comment stays pinned on the page as a numbered dot until the employee marks it done, with a note of what it changed. The Comments panel is open by default and lists everything you asked in order, with where each one stands: to do, done, and what was done. Click a request and it shows you where it lives on the page. There is a field at the bottom for anything about the whole project when nothing is picked, and a microphone if you would rather talk than type.

Or just change it yourself

Press E and the Studio becomes an inspector, the kind you would expect in a design tool. Type directly into any title or paragraph. Bold, italic, underline. Pick the font from any Google font, the size, weight, line height, letter spacing, colour and alignment. Change a block's background, padding, margin, corners, border, shadow and opacity. Swap an image, change a link, select the parent, hide an element, or undo what you did to it.

This is written straight into the site's files. No employee, no tokens, no waiting. Your employee gets a short note afterwards saying what you changed, so it does not overwrite you on the next pass. V, C and E switch between looking, commenting and editing.

Three versions, side by side

There is a button that never leaves your sight: ask for 3 versions of a section, or of the whole page. They render side by side, live, and the one you pick replaces the page. It is the fastest way to settle a question that would otherwise take four rounds of "a bit warmer, a bit less rounded".

You can see it working

While your employee builds, a bar runs along the top of the preview and a pill shows its portrait, that it is working, its latest note and the elapsed time. The panel underneath says what it is doing in plain words, including the parts that do not show on a page: the database, the server, security. Steps already finished appear as small bubbles. Messages you sent while it was busy queue up visibly. When something changes, it lights up in the page for a few seconds with the employee's picture next to it.

While a brand new project is still empty, the Studio shows it under construction and reports progress at least once a minute until there is something to look at. That matters more on a full-stack build than on a landing page, because a lot of the early work is server-side and has nothing to show yet.

A check before anything goes live

Every publish runs a scan of the project's files that detects the common security holes by known patterns: a key or secret visible to visitors, database queries built from raw input, code run from text, data inserted as HTML, insecure links and forms. Worth being precise about what that is and is not. It catches the usual mistakes. It is not an audit, and it is not a penetration test of the running site.

Then the draft is actually opened in a browser, in desktop view and in phone view, and scored out of 100 on speed, search engines, accessibility and mobile, with a list of what to fix. Those numbers are measured, not read off the files. One click asks your employee to fix all of it, and the check runs again when it is done. A serious security hole turns the button into "Publish anyway", so you have to mean it.

Your employee runs the same check by itself before it tells you a project is finished.

Publishing, versions, and your own address

Publishing puts the draft online as a new version. The last 20 are kept, and any one of them goes back online in one click. The draft's own history is separate and keeps every change, not just the published ones, so any moment comes back and you can go forward again.

Once a project is published, "Connect my domain" in the More menu puts it at your own address. The window shows the single DNS entry you need to add, with a copy button on each field, worked examples for the domain itself, a subdomain, with and without www, and Cloudflare, and a Check button that tells you where the domain currently points if it is not right yet. HTTPS turns itself on.

The draft has its own test database, its own storage and its own environment, and publishing never touches the live site's data. One exception is worth knowing before you start clicking around: a project built on a gat-database, a CRM for example, reads and writes the same database whether it is the draft or the published site. Anything you try out in the draft there is writing real records. The draft itself runs only while its Studio is open and stops shortly after you close it.

Starting a project

The New project button takes a description, a template from 15 (blank, showcase site, landing page, full-stack app, CRM, dashboard, mobile app, slide deck, document, wireframe, HTML email, flyer, diagram, from a mockup, from your current site), each shown with a drawing and an example of what it produces. You pick a design system from fifteen ready-made styles, or your own colours, fonts, corners, mood and logo, which is then kept for every project. You can also import a DESIGN.md from a file or a link and your employee will follow it whole.

Add the files it should use (logo, images, brief) and any existing code to start from, as a .zip or a GitHub repository. Drop a screenshot or a Figma export and it builds that. Give it the address of your current site and it takes the content and brand and rebuilds it clean.

Each kind of project has its own recipe, and the recipe goes all the way down: a showcase site with a working contact form and map, a landing page with its sign-up list, a full-stack app with a protected admin, a CRM with its data in a gat-database, a dashboard with charts, an installable mobile app, a printable document, a clickable wireframe, an HTML email that survives every inbox. Slide decks made here are full screen animated presentations, and they stay editable for every comment you make.

And a few more things

A QR code opens the draft full screen on your phone, signed in, updating live while your employee works. The link lasts 12 hours.

Pick your languages and every page is translated with a switcher added.

Published sites come with their own stats: page views, visitors, visitors right now, bounce rate, pages per visit, where people came from, countries, devices, browsers, systems, languages, hours, entry and most viewed pages, and forms submitted, over whatever period you choose, exported as CSV. No cookies, nothing personal kept, no IP stored. You are told when a form message arrives.

You can also run an A/B test: two of your employee's versions online at once, half the visitors each, with the goal each one reached and the odds that B is actually better. Keep the winner.

Save a project as a template and it is offered to every one of your employees on their next project.

Everyone who can use the employee can see and work on its Studio projects: you, an admin, and anyone you shared it with.

Fixed

Chrome extension sign-in now returns the same clear message as the web sign-in when the verification code could not be emailed, instead of an opaque server error.

Studio panels that were open before a restart stayed counted, so their drafts never stopped. They are forgotten at each start now, and the drafts stop with them.

When a visitor requested a file on a published site that did not exist yet, the "not found" answer was cached by their browser for four hours, so the file stayed missing for them even after it was written. Missing files and error pages are no longer cached.

Clicking a link to a folder in the chat tried to read it as a file and showed "Failed to load file". It now opens the folder in the file tree.

Employees get the new studio skill with their next skills update.