How the studio works.

Real systems, not a sandbox

This isn't a no-code builder or a closed third-party "AI website" environment. The work you're watching runs an AI coding tool directly on real Linux servers — the same infrastructure the software actually runs on. Real code, real commands, real files, full control: the way a senior engineer works, not inside a vendor's packaged sandbox.

That directness is the point. What you see is the genuine build — the actual decisions and execution — governed and shown in the open, not a polished demo recreated after the fact.

What you're watching

Every action the studio takes during a build session emits an event: a file read, a code edit, a terminal command, a decision. These events flow through a sanitization layer (the redactor) and onto your screen as tiles.

You see the work. You don't see the operator's screen. You can't see anything the redactor refuses to pass through.

The security model

The redactor is the only thing between the raw event stream and this page. It has three layers, all fail-closed (on doubt, drop).

Director and studio

You're watching the studio — that's the AI. Behind the studio is the director — the human shaping the work. The conversation between them appears in the chat overlay at the top of the page. The director's commissioned intent flows in; the studio's work flows out as tiles. The director and studio see more than you do (prod context, business decisions, customer files); none of that flows through unsanitized to your screen.

A "Studio thinking" tile is the studio narrating its own work aloud. A tool-call tile is the work itself. A chat bubble is the director and studio talking directly.

Architecture

The director's terminal is on a private host. The redactor is the only path off it. Every line that reaches your screen has been through the path-whitelist, the value-blacklist, and the blob detector. None of those layers needs to be perfect — together they're fail-closed.

Privacy

What's on this page:

What's never on this page:

This stream is one-way. There is no input field on the studio page. The page reads from a static file (stream.ndjson) and renders the tiles. No backend, no auth, no session — for you, the visitor, the studio is fully read-only.

When the studio is offline

If the director isn't running a session, the stream file doesn't exist on the server and the page shows a "studio is quiet" state. No data, no events, nothing to see. The page is harmless when offline.

A live session ends with a "SESSION ENDED" sentinel tile, then the stream file is removed and the page returns to the offline state. Past sessions are archived locally on the director's host — replay is a future feature.

Why this exists

"Every Lakeville site is built in the open" is the brand promise. The Developer Studio is the operational proof of that promise. Watching the work is the same thing as auditing it.

It's also a candid look at how AI-assisted engineering actually feels — not a polished marketing reel, but the real cadence: small edits, terminal commands, course-corrections, the occasional redacted sentinel where the safety net catches something.