Frontic Studio

Frontic Studio is your AI factory for shipping shopping experiences - idea to feature in one place. The Studio chat draws on your project’s Context Base (skills, rules, patterns your team has captured), reads from the live stack, and already knows the commerce model underneath. With a connected Shopware store, each session also starts aware of recent promotions and catalog changes. Open a job, describe the outcome, and Studio builds it against a live preview. You bring judgment; Studio brings execution. Studio’s focus is creating the experience - frontend code, visuals, the pages your customers see. It can edit files in a real Git repository, and when a code change needs a block, listing, or small tweak to the stack, Studio will make it - but that’s a side effect of making the code work, not the main event. Studio is the surface for building a whole frontend. When the work is a single page - a campaign landing page, a seasonal takeover - the Experience Designer is the shorter path: no repository, no branch, and it publishes into your existing storefront in place. Build in Frontic compares the two.

​

What you can do in Studio

Use Studio when you want to:

• describe a feature in natural language and have an agent build it
• work against a live preview of your frontend as it’s being changed
• review the resulting files and repository state before committing
• iterate fast on frontend work without leaving Frontic

Studio is especially useful when your work cuts across frontend code and the stack pieces that feed it - the agent can adjust blocks, listings, or pages to match a code change without forcing you to jump between tools.

​

Jobs and workspaces

Every task in Studio is a job - a named unit of work that lives on the Board. Each job has its own workspace: sandbox infrastructure running your code, plus a live preview, chat, and change review scoped to that one job. You create a job to start something; everything related to that something lives together in one workspace until you archive the job - at which point the sandbox is torn down but the chat is preserved for replay if you ever unarchive. Typical jobs:

• “Build a product detail page that uses the new variant picker”
• “Add a category filter to the existing product listing”
• “Migrate the homepage hero to the new design”
• “Fix the 404 handling on the category pages”
• “Rebuild the footer navigation with the new menu structure”

Each gets its own branch, its own preview, its own sandbox. Each results in one coherent set of changes you ship as one pull request.

​

One job per meaningful task

The default Studio workflow is one job per meaningful task - not one per line of code, but not one per month either. A good rule of thumb:

• Small tasks (a CSS tweak, fixing one label) can share a job if they’re related
• Medium tasks (a new feature, a refactor, a migration) each get their own job
• Large tasks that touch multiple unrelated areas get split into multiple jobs, one per area

Why not one giant job per project? Bigger jobs ship slower - work that’s ready ends up waiting for work that isn’t. Focus also degrades with session length (the chat agent is at its best when the conversation is about one thing), review costs scale non-linearly, rollback gets messier, and context stops carrying cleanly across topics. Smaller jobs keep the pipeline flowing - what’s done goes out, what isn’t keeps cooking. When in doubt, create a new job. They’re cheap.

​

Creating a job

Two ways to start one: Whichever route you pick, Studio provisions the same setup: a name (the agent picks one after your first prompt), a source - a GitHub repository and branch, or a starter template - and a fresh workspace with chat on the left and live preview on the right. The workspace sets up in the background while you stay where you are. The job’s card on the Board and the workspace’s loading screen name the step it’s on - Creating workspace, Cloning repository, Starting sandbox, Installing dependencies, Starting dev server - and a notification with Open Workspace tells you when it’s ready and running your prompt. If setup fails, a Workspace setup failed notification takes you to the job, where Retry starts it again.

​

The Board

Opening Studio takes you straight to the Board. By default its columns follow each job’s status: New, In Progress, In Review, Completed, and Archived. The Mine tab shows the jobs you own and All shows every job in the project; the Board opens on Mine until you pick the other tab, then remembers your choice. Click any job to reopen its workspace; chat history, current preview state, and branch state all come back. Each card shows, from top to bottom:

• the job’s preview, its branch or repository, and the avatars of teammates who have the job open right now, each with a green ring
• the job’s status and how long ago it last changed
• the job’s title
• one line on where the job stands: the agent’s open question if it’s waiting on you, your first prompt while the job is new, otherwise its latest progress
• the job’s owner

While a job sets up, its card shows the setup step instead of the preview; if setup fails, it says Workspace failed. Switch the Board’s view to List to see the same details as one row per job. This matters because work is rarely linear. You start a job, get interrupted, come back two days later, pick up where you left off. Studio keeps the context; you don’t have to rebuild it from memory or scroll through a 200-message chat to find where you were. You can also run multiple jobs in parallel. Each workspace has its own branch and its own sandbox, so two agents (or you and an agent) can work on unrelated tasks without stepping on each other. The only tricky case is coupled changes - if one job depends on another’s work, you need to finish the dependency first and rebase the other onto the updated base. Studio doesn’t resolve this for you; it’s Git.

​

Filter and arrange the Board

Above the Board, search finds jobs by their title or latest progress, and two menus shape what you see:

• Filter narrows the Board to the jobs you care about - by state, owner, repository, template, when a job was last updated, and more. Each option shows how many jobs match it, and you can stack filters and match all or any of them.
• Display switches between the board and a list, groups the jobs into columns and rows by a field such as state or owner, sets their order, and chooses what each card shows and how far back archived jobs reach. Reset to defaults brings back the status columns.

The Board remembers your filters and display settings in this browser. Filters and search are also part of the page address, so a link you copy opens the Board with the same filters for a teammate.

​

Job ownership

Every job has one owner. When you create a job, you own it. Only the owner can drive the agent: chat with it, answer its questions, approve its plans and tool calls, and upload assets to the workspace. Everyone else can open the job and follow along, but the chat is view-only for them. See who can act in a workspace. Ownership moves with the work. From the ⋯ menu on a job’s Board card:

• Claim job makes you the owner. It shows on jobs you don’t already own.
• Assign to opens a list of your team’s members, sorted by name, with a check mark next to the current owner. Pick someone to hand the job to them.

You don’t have to be the current owner to claim or reassign a job: anyone who can create jobs in the project can change the owner of any job, at any time. The same two actions are also available from the owner’s avatar inside the workspace.

​

Archiving a job

Once a job is done - or paused indefinitely - archive it from the ⋯ menu on its Board card. Archiving keeps the conversation transcript on the job but tears down the sandbox: the running dev server, the preview, and the workspace files all go away. The card moves to the Archived column and can no longer be opened directly. Unarchive from the same ⋯ menu when you want to pick the work back up. Studio rebuilds a fresh workspace at the same base branch and replays the saved chat history into it, so you land back in the job with the conversation intact.

​

Todo list

Work in Studio rarely fits in one round-trip. The agent breaks larger tasks into a checklist - search the codebase, edit a few files, verify in the preview, fix what broke - and the chat surface shows that checklist as a Todo List panel above the message input. While the agent works, you see the steps tick over: each step shows its status (pending, in progress, completed) and a counter at the top tracks overall progress (e.g. 2/5 Completed). The active step’s description sits right at the panel’s edge so you always know what the agent is doing right now. This isn’t a separate tool you invoke - it surfaces automatically whenever the agent organises its work into more than one step. The panel collapses out of the way once everything’s done.

​

Plan mode

Plan mode is a formal approval gate for the Studio chat. When it’s on, the agent writes a plan describing what it intends to do - the approach, the files it’ll touch, the stack tweaks if any - and waits for you to approve before making a single change. Useful when the cost of catching a misunderstanding after the fact is high. Studio starts every job in Build mode by default: the agent writes code directly and you review via Preview and Changes. Switch to Plan mode from the workspace toolbar when you want the agent to stop and check in before acting. The agent also enters Plan mode on its own for complex work - multi-file refactors, a feature cutting across frontend and stack, anything where scope should be clear up front.

​

Approval flow

After approval, Studio flips back to Build mode automatically. The agent executes the approved plan and keeps building from there. It won’t re-enter Plan mode for follow-up tweaks unless something substantially new comes up.

​

When to use it

• Multi-file changes or refactors where scope should be clear up front
• New features that cut across frontend code and stack config
• Work you’d normally write a ticket for anyway
• Anything where catching a misunderstanding in review would cost more than catching it in a plan

​

When to skip it

• Small tweaks - a CSS change, a copy fix, a variable rename
• Iterations on work the agent already has approved plan context for
• Quick prototypes where moving fast beats tight planning
• Questions and read-only investigation - the agent isn’t making changes, so there’s nothing for Plan mode to gate

​

You stay in control

Studio is agent-driven, but nothing reaches production until you deliberately ship it. Changes happen in a sandboxed workspace against a feature branch; the agent pauses for a tool approval before each step (with a Skip approvals toggle when you want it to run uninterrupted); the live preview lets you see the result before anything leaves Studio; pull requests run through your team’s normal review; and Release Control decides when the stack-side changes move from develop to public. You can drop out at any point and continue the work in your editor - the branch is a real Git branch, clone and keep going. Teammates can open your job and watch the agent work without taking it over - only the job’s owner drives it. You don’t need to watch the workspace while the agent works. When it stops for a question, an approval, or a plan review, or when a run finishes, Frontic tells you wherever you are in the admin app.

​

Related