Development experience
They can read a pull request, judge an approach, tell a sound change from a plausible one and, when it is quicker, write the code themselves. A coding agent's work is reviewed by someone who understands it.
Specify the work. Let agents build it. Decide what ships.
A Product Engineer has development experience and owns the product. They write the intent, the brief and the work packages, set the Definition of Ready and Done, send each package to a coding agent and review what comes back before it merges. The Studio is built for this person.
It is the step on from vibe coding. Prompting an assistant and hoping can produce a demo in an afternoon. A business needs to know what was asked for, what was built, who checked it and why it shipped: specified, gated and reviewed delivery, with the record to show for it.
Two kinds of experience in one role. The role is not a project manager handing tickets to agents, and not a developer who only writes code.
They can read a pull request, judge an approach, tell a sound change from a plausible one and, when it is quicker, write the code themselves. A coding agent's work is reviewed by someone who understands it.
They decide what is worth building and why, say what done means before the work starts, and answer for what is released. The agents build to their specification, not to a prompt.
Every check, decision and exception is recorded as it happens. What an auditor, a customer or a manager asks about a change is answered from the record, not from memory.
Agents draft, plan, code and review. These stay the Product Engineer's.
What problem is being solved, for whom, and why it matters now: weighed against the studio's value model so the order of work is argued, not guessed.
What the intent asks for in words an agent and a reviewer can both hold it to: scope, constraints and what done looks like.
The intent broken into workstreams, and each into work packages: one change each, built and reviewed as a single pull request, in the order they should be built.
The checklists a package must pass before it goes to a coding agent and before it ships. You set them for the studio; the reviewer agents and a person check each package against them.
Whether a package is ready to build, whether what came back is done, and what is released. Agents advise; the decision is a person's.
One intent, from the vision to what it achieved after release. Each step is a page in the Studio, in the order of the AI Delivery Lifecycle.
| Step | Where | What you do | What the Studio does |
|---|---|---|---|
| Vision | Vision | Set the studio's north star and the outcomes it serves. | Drafts outcomes with you, and gives every later agent the vision as context. |
| Ideas | Ideas Board | Get the thinking down: notes, documents, shapes and connectors on a shared canvas. | Generate turns the board into context, and proposes intents you accept or not. |
| Intent | Intent Pad | Capture the idea, problem, opportunity, bug or spike, and weigh its value. | Classifies and scores it; the order between intents is advice, never a gate. |
| Plan | The intent's plan ladder | Climb it one step at a time: brief, workstreams, work packages, work items, then send the drafts to review. | Each step has its own agent action; only the next step offers buttons, so the page always says what is next. |
| Ready | Work package: Definition of Ready | Read what the reviewer agents found, then approve the package or send it back. | Checks the package against the Definition of Ready and records both sides of the gate. |
| Build | Work package: Coding | Dispatch it to a coding agent (GitHub Copilot, Claude, Codex or a Claude Code routine), or take a developer branch and code it yourself. | Briefs the agent with the package and its Plan, and follows the run to its pull request. |
| Iterate | Work package: Iterate | Go back and forth on the pull request: answer the agent's questions, send an instruction or send rework. | Shows what the agent is doing now and posts what you send to the pull request. |
| Done | Work package: Definition of Done | Decide whether the change is done, then approve and merge it, or send rework. | The reviewer agents read the pull request against the package, its Plan and the Definition of Done. |
| Release | Release plan and Release comms | Approve the release on its two keys and the notes for each audience. | Builds the release from the packages whose merges it holds, and drafts what to tell customers, teams and auditors. |
| Learn | Outcome Telemetry and the Outcome Feedback Loop | Judge whether the release moved what it said it would, and decide what to do next. | Collects the readings and assesses each release against its key results; it never creates an intent itself. |
The studio's operating mode, chosen by its owner in Trust Settings, sets how much the agents do without asking. It never changes who decides what merges.
| Mode | Who decides | What is handed to agents | Plans |
|---|---|---|---|
| Supervised | A person decides every step: agents suggest and draft, and nothing they write is applied until someone accepts it. | Nothing is applied without you. Agents draft the brief, the workstreams, the packages and the work items, and you accept or change each one. | Every plan |
| Semi-Autonomous | Agents apply their own work and accept their own suggestions; a person approves each work package and decides what ships. | Agents apply their own drafts and accept their own suggestions, and Auto Pilot can take an intent from its brief to draft work packages. You still approve each package and decide what ships. | Business and Enterprise |
| Fully Autonomous | Agents run the whole loop to a pull request; a person watches and steers, and still decides what merges. | Choosing it records your standing approval of the person's side of the Definition of Ready gate, the approval and the dispatch of each work package a Fully Autonomous Auto Pilot run made and takes forward, when every reviewer agent passed it and every required item is met. Never the Definition of Done, a merge, an exception or an override of the reviewer agents. The loop runs as far as a pull request; you watch and steer. | Business and Enterprise |
Approval needs the reviewer agents and a person. An agent's assessment is minted by the server from its own prompt; it cannot be posted by a client or an agent.
No agent merges. A pull request is merged by a person, or by GitHub under the repository's own rules.
Setting an item aside, or overriding the reviewer agents, is a recorded decision: who, under which authority, why and until when.
A release is approved on two keys and ships what was approved, built from the packages whose merges it holds.
A studio starts with one person, and nothing needs a second. You decide both sides of a gate yourself; the record says one person did, and nothing refuses it. The Free plan is one studio for one Product Engineer.
Any member of the studio can do the work of delivering a change: send a package to review, send rework to the coding agent, iterate on the pull request. Approvals stay with the owner and the reviewers, and separation of duties is a Trust Settings switch, off until the team turns it on.
On Enterprise, an organisation can set guardrail policies across its studios and keep one register of every exception. The studio's own controls still apply.
If you already build with AI and want work you can stand behind, start a studio on the Free plan with your own AI provider key. No card and no time limit.
Why demo-speed AI coding rarely ships is on The Vibe Coding Curse; the overseeing agent of an Enterprise studio is on The Studio Controller.