Codebase · since v1.6.0
Visual editor for your real codebase
Build mode is a visual editor for the code you ship: pick an element in your running app, edit it visually, and the change lands in the component's own idiom — verified by a real re-render before it's yours.
Document · Devin · e2e · gate PASS
RFC-0142 — A two-page engineering RFC for offline-first sync — status headers, summary table, and numbered design decisions.
▸ the prompt that made it▾ the prompt that made it
“Write a document: a 2-page engineering RFC for adding offline sync to a notes app.”
Why it matters
Visual editors that generate code make you the merge tool; ones that edit your repo usually write alien markup. Build mode's contract is different: the edit lands the way your code is written — Tailwind classes, CSS-module rules, styled-components templates, StyleSheet entries — never as a bolted-on inline style. And it verifies: your dev server re-renders, the check runs, a failed edit rolls back.
How it works
- 1Adopt the repoPoint the studio at a checkout. Worktree mode (the default) registers an app-owned worktree on a 1design/<slug> branch — your checkout is never written to.
- 2It runs your real appThe harness daemon serves your project; screenshots and picks come from your actual UI, not a sandbox recreation.
- 3Edit visually, land idiomaticallyPick → comment → Apply & verify. The edit is written in the element's own style idiom and verified by re-render — a leak into other usages rolls back and says so.
- 4Stay in your conventionsAn edit no codemod can make in your idiom stops with 'Ask the agent' — it goes to the project's coding agent as a verified turn instead of a hack.
Capabilities
- Edits land in your code's idiom: Tailwind, CSS modules, styled-components, emotion, StyleSheet — never bolt-on inline styles
- Worktree isolation by default: your checkout is read-only to the app
- Verified edits: re-render and lint on the diff, rollback on failure
- Shared-component awareness: 'all N instances' asked before spreading, verified per usage
- Compare re-renders edits at a second device or theme
- Lint surface merges kit findings and harness findings with stable rule ids
Without it
Mock it in a design tool, hand it to engineering, watch the two drift apart — or push pixels in devtools and lose the diff.
With 1DesignTool
The design tool is the repo: edits land as your code, on a branch, verified — merge it when it earns it.
FAQ
Does it write to my checkout directly?
No — worktree mode (the default) works in an app-owned worktree on a 1design/<slug> branch. Your checkout is the read-only origin; you merge when you're happy. A direct mode exists for cases that need it.
What stacks does Build mode support?
Web stacks the harness can render — React and friends with Tailwind, CSS modules, styled-components or emotion; React Native's StyleSheet maps for mobile. The idiom rules are per-file: the edit follows what the file already does.
What happens when an edit can't be made idiomatically?
It stops honestly — 'Ask the agent' hands the change to the project's coding agent as a verified turn, rather than silently writing alien markup.
Does it run my whole test suite?
Verification is diff-scoped: the changed files get re-rendered and linted, plus Compare variants when on. It won't gate on tests unrelated to the edit.
In the docs
Related features
Design with the agent you already have.
Free to try, buy once — the studio and your own coding CLIs do the rest.
Download