How Deckwright differs
The AI-builder category converged twice in eighteen months. First on execution: staged pipelines, testing gates, agent teams. Then, in 2026, on input: the leading tools now accept pointing, drawing, and voice, not just text. Deckwright competes in a category where the surface-level feature lists increasingly sound alike. The real differences are structural, and each one can be verified. We apply four questions to every tool, including ours:
- What is actually captured? One signal, or the full set of channels a moment of creation happens on?
- Is intent recorded or inferred? Instrumented at the source, or reverse-engineered from a screenshot after the fact?
- Does the capture persist? Is it a prompt that fires once and vanishes, or a durable, replayable artifact?
- Who decides? Does a human develop and govern the work, or supervise and approve what agents already did?
- What remains when the work ships? An empty belt and a transcript, or the project's accumulated understanding, attached where it happened?
Cursor Design Mode
What it is, stated fairly: Cursor 3.0 (April 2026) added Design Mode - a visual overlay on the integrated browser where you click elements, multi-select, draw on the page, and narrate changes by voice while an agent edits the code. Cursor 3.7 (June 2026) added a persistent mic and multi-element selection. It is the closest interaction cousin to the Bench, and it is genuinely good at what it does.
What it captures: per selection, the element's identity - xpath, component, attributes, computed styles, props from the React fiber tree - plus a screenshot for spatial context. Cursor's own documentation describes no capture of gesture timing, motion dynamics, hesitation, or runtime console data.
What happens to the capture: it is an immediate prompt. The agent edits, the app hot-reloads, and the capture is gone. There is no replay, no audit trail, no artifact.
The structural difference: Design Mode operates downstream, on a UI that already exists, and treats the capture as disposable throughput toward a code edit - because in a code editor, code is the asset. Deckwright's capture is multi-stream and time-aligned (voice, motion, dwell, canvas state, console activity on one clock), it operates upstream where the thing being described may not exist yet, and the capture itself is the durable asset: replayable, editable, attachable into governed production. Cursor proved the modality. It discards the artifact.
v0 and Figma Make
Stated fairly: v0 generates working full-stack UI from text, screenshots, and Figma files, has a visual design mode, and deploys to production. Figma Make generates data-connected applications inside Figma, with visual editing, publishing, and code export.
The screenshot problem: both accept images of designs as input. A screenshot is a single flattened raster with no time axis - no motion, no order of operations, no voice, no hesitation. Everything a model reads from it is inference, and inference is lossy: the image shows what the work looked like, never what the maker meant. Deckwright is signal-native, not pixel-derived: each channel of intent is recorded at the source as its own discrete timestamped stream, and there is no vision model in the capture loop at all - no screenshots taken, no screen recording parsed. Nothing is inferred that can be recorded.
The artifact problem: in both tools, the input - text, image, or visual edit - is consumed by generation. What persists is the generated artifact. In Deckwright, what persists is the intent record; generated output is its current executable form, regenerable from the record.
Lovable and the chat-first builders
Stated fairly: Lovable generates full-stack applications from chat and now supports direct preview editing with select-and-draw interaction. Bolt.new builds full-stack in the browser from text.
The chat transcript is the whole context, and it rots the way all long transcripts do: buried decisions, drifted scope, no way to prune a wrong turn without losing history. Deckwright's polyphonic structure is the architectural answer to exactly that failure - separate role-scoped context streams, deliberate context injection, pruning that removes bad material from future context while preserving the record. See how the Bridge works, and the demonstration on video: Bridge walkthrough, timestamped. On the preview-editing and console-inspection features this cluster now ships, see the next section: inspection is not capture.
Inspection is not capture
Several tools in this category can open a dev console, inspect network calls, or click elements in a running preview. Those are debugging affordances, and they are twenty years old: every browser has them. An inspection session evaporates the moment it ends - nothing it surfaced exists afterward except what a human retyped into a ticket.
The Bench is not an inspector. It loads live HTML as a captured surface: every DOM hover, input, scroll, and mutation, every console error, every network fetch is recorded as its own timestamped stream, time-aligned with the maker's voice and cursor on the same clock - and any slice of that record attaches as durable context to governed work. A bug is not described from memory; the captured moment of the bug, with the runtime state underneath it, is the ticket.
The same instrument works upstream of bugs. Demonstrate the behavior you want - "it eases in like this, hangs for a beat, then snaps" - with your voice and cursor over the live page. In a debugger there is nothing to keep. In a design tool there is nowhere to put it. On the Bench that demonstration becomes a replayable, attachable artifact, and a card gets built against it. Animations, HTML widgets, easing curves, interaction feel: the Bench is a development surface for exactly the class of intent that has never had a home in either a debugger or a design file.
Agent managers and control planes
A newer cluster - agent command centers, control planes, and parallel-agent worktree managers - ships boards of agents: launch several coding agents, watch their status, approve their pull requests. The largest of them, Paperclip, is open source, seriously well built, and reached tens of thousands of stars within months of launching: an org chart for agents, board-based approvals and policies, per-agent budgets with hard stops, audit tabs, cross-provider runtimes, multi-company isolation. Judged as a management console for agent labor, it is more complete than ours, and it is free. We would rather say that plainly than have you discover it.
Judged as a place where software gets meant, it is empty. Work arrives as a typed goal in a form field. There is no canvas, no capture, no surface where a person expresses intent in anything but text - and that is not an oversight. It follows from a decision Paperclip states openly in its own design notes: it is "not trying to become a single opinionated memory engine," but a control plane sitting above pluggable memory providers, whose job ends at "context assembly: turn raw memories into a prompt-ready bundle for the agent." If context is something you fetch at execution time, you never need a place to develop it. That is the fork in the road, and both directions are coherent. Only one of them treats the thinking as the asset.
The board those systems show is a roster of workers sorted by execution state. Deckwright's Board is a different object: a board of work - cards carrying context, specification, and a verification contract through explicit stages, where consequential transitions are held by the human Captain. Managing agents is supervision. Governing work is authority. The distinction sounds small and changes everything downstream: what can be audited, what can be inherited, and what survives the session.
Spec-driven development frameworks
The SDD wave - team-of-agents frameworks, executable-spec pipelines, context-isolation runners, TDD-enforcement methodologies - optimizes executing against a spec that already exists as text a human typed. These are harnesses: scaffolding around a model's execution, and increasingly good ones. Deckwright contains a harness with the same discipline (fixed passing tests before code, independent review, verification gates) - but the harness is the bottom half of the platform. The difference is everything upstream of the spec: none of the harnesses address how the spec gets developed, or how intent that cannot be typed - spatial, temporal, gestural - gets captured at all. Deckwright's first three pipeline stages and its capture layer exist precisely there.
What is left when the project ships
Software is never finished; it is between changes. So the right test for any AI builder is not what it does during the build - it is the state it leaves you in when the build ends. Run that test across the category. When a project "finishes" in a chat-first builder or an agent IDE, what remains is code plus a transcript nobody will read again. The intent, the constraints, the rejected alternatives, the reasons: evaporated. The next change begins with archaeology - re-explaining your own project to a fresh context window.
The strongest counterexample deserves a fair hearing, because the best control planes do leave something behind. Paperclip leaves a real audit trail - which agent did what, when, at what cost, attributable by company, project, goal, and model - a searchable archive of every issue thread, and, with a plugin enabled, a distilled wiki: linked pages with citations, entity and concept pages, and flagged contradictions, generated automatically from the issues, comments, and documents the team produced. That is meaningfully more than code plus a transcript, and it is better than most of this category manages.
It is still not the thing. That wiki is built from what people typed at each other; it sits beside the repository rather than bound to it; and by its own stated design it exists to be retrieved, assembled into a prompt when an agent asks. Nothing maps a file to the decision that produced it - there is no code graph in that system at all. So you can ask the wiki what was discussed, and you can ask git what changed, and nobody can tell you why this file is the way it is. What you are handed at the end is a repository and a receipt.
A Deckwright project ends differently, because the pipeline does not just process - it deposits. Every card that crosses it leaves its specification, its decisions, its officer handoffs, its verification contract and evidence, and its signed completion record, attached where they happened: at the board, at the stage, at the card. On one currently operating board, a single foundations card carries a versioned rules contract, an aligned Bench Proof, a completion record with named custody, and 110 officer handoffs. When the next change arrives it does not start from zero; it inherits. The board is not a record of the project. It is the project - the code is its current build. Photographs of that deposit, from the operating board: what compounds.
This is the system-of-record distinction. Tools that leave behind only code compete on whether their next generation is better than someone else's. A platform that holds the accumulated why of your software compounds with every card that crosses it.
The pattern
Across every cluster, the same three absences repeat. First: the capture, where it exists at all, is ephemeral and single-stream - a prompt, not an asset. Second: the human is positioned as a supervisor of finished work - approving PRs, accepting diffs - rather than as the decider developing the work. Third, and deepest: context is treated as something to retrieve at execution time rather than something to develop and keep - a lookup, not an asset. That third one is rarely admitted, but the strongest platform in the category writes it down as a design principle, and every feature it ships is consistent with it. Deckwright is built on the opposite three: intent captured as a durable multi-stream record, a human Captain whose authority is architectural rather than ceremonial, and context that accumulates as the project's system of record. Those choices are the platform. Everything else on the feature list follows from them.