Cards and Bolt.new — a comparison

Cards' honest claim is on guiding and checking: a persistent, human-readable work object pairing intent with actual work, fitting the technical developer re-entering a job or reviewing it without reconstructing context from chat logs. Bolt.new's honest claim is on starting and fitting in: a browser build environment with managed infrastructure that deploys on the spot, fitting the product-oriented builder turning an idea into a running application. The two sit on opposite ends of the pipeline, match different constraints, and can be used together rather than compete.

A companion piece lays out a way of looking at person-and-AI work as a pipeline with five steps: starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate. The slowest step sets the ceiling on output, and three other forces shape the result — how many attempts become accepted work, how much accepted work holds up later, and how much cleanup the workflow creates. This page walks Cards and Bolt.new through those steps side by side, without ranking them. In the marketplace ontology, Bolt.new spans the Execution Mode layer (browser-based interactive development through StackBlitz's WebContainer), the Delivery and Integration layer (Bolt Cloud hosting, databases, authentication, edge functions, and domains), and the Verification layer (autonomous debugging and the Security Audit). Cards sits primarily on the Control Artifact and Memory and Continuity layers. Those layer differences explain the pipe differences below.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized around a description, plans, comments, attachments, sessions, transcripts, commits, changed files, and attribution. Actions launch the configured agent from that job context; the harness and model provider run the agent. The operator is a technical developer who reads diffs, plans, and commits and judges them. The unit of work is one coding-agent job — a bug fix, feature, cleanup, or investigation — held as a durable work object on disk.

Bolt.new is a browser environment where you describe an application in natural language and an agent writes it, runs it, debugs it, and publishes it. Hosting, databases, authentication, edge functions, secrets, user management, file storage, and custom domains are provided by Bolt Cloud with no separate accounts or configuration. As of May 2026 the operator chooses between two agent tiers, Standard and Max, rather than a raw model. The operator is a product-oriented builder — a founder, product manager, marketer, solo developer, or student. The unit of work is one Bolt project: an application built from a prompt, iterated through chat turns, and either published or abandoned.

The plainest way to hold the difference: Cards is organized around keeping one job intelligible from plan to commit. Bolt.new is organized around getting an application running and deployed. Cards asks what this piece of work was for and what happened during it. Bolt.new asks what you want the application to do and whether it is live yet.

Bolt.new widens starting for speed; Cards narrows it to raise seriousness — starting is the act of getting a new attempt off the ground at all.

Bolt.new's most direct effect lands here. Describing an application in a sentence and watching a running version appear has near-zero setup cost — no local environment, no dependency install, no provider to configure. Plan Mode adds a structured path: the agent lays out its approach and the operator approves the plan before code is written, turning starting from type-and-hope into agree-then-build. The ontology layer is Execution Mode: browser-based interactive development that collapses the distance between an idea and a first running state. Bolt.new does not scale starting across many projects at once — each project is its own serial conversation, with no batch-start mechanism.

Cards moves starting in the other direction, on purpose. The default `interview` action runs a structured intake conversation before any code is written: what the work is for, why, what success looks like, what constraints matter. A vague idea is either sharpened into a concrete description and plan on the card or dropped. The ontology layer is Control Artifact: intent captured as a durable plan artifact before execution. The raw speed of starting does not go up; if the bottleneck is spinning up agent sessions faster, Cards has no answer.

Bolt.new widens the starting pipe for speed and removes infrastructure friction from the first move. Cards narrows it to raise the seriousness of each attempt. Which one helps depends on whether the team's problem is that starting takes too long or that too many started attempts were never well-formed enough to finish.

Cards lowers the cost of returning to existing work; Bolt.new lowers the cost of directing new work in real time. Guiding is the human work of pointing the agent at the right thing and keeping it pointed there across the life of an attempt.

Cards' guiding claim is its strongest, and it centers on re-entry. When a developer comes back to a job after a meeting, a weekend, or a handoff, the card already holds the description, the plan sequence, the comments and attachments, and the running map of what changed. The context is read, not reconstructed from a chat transcript. The per-attempt guiding cost falls: every return skips the minutes or hours otherwise spent paging through history. The ontology layer is Memory and Continuity — durable local state that outlives any single agent session. A smaller secondary effect: because cards are ordinary files on disk, a developer can glance at one in a terminal or on a second monitor without opening the heavy editor. That gain is limited to the same machine — there is no phone app or shared dashboard — and should not be claimed as more.

Bolt.new's guiding effect centers on the live interaction loop. Changes appear in the browser preview as the agent makes them. Plan Mode catches misalignment before code is written. The visual selection model — click an element in the preview, then describe the change — removes the need to know which file or CSS class maps to what is on screen. Connectors pull live context from external tools, and a Prompt Library and system prompts persist working patterns. The ontology layer is Execution Mode: direct visual access to the running application is the difference between a non-developer being able to steer the work and being locked out of it.

Both products carry the same backfire pattern: a flood of in-flight work turning cheap-per-attempt guidance into expensive aggregate context-switching. Cards warns that notification overload inverts its own attention gain; Bolt offers no dashboard for several projects in parallel. The difference in what each widens: Cards lowers the cost of returning to existing work; Bolt.new lowers the cost of directing new work in real time. Cards fits the developer with too many sessions to keep straight; Bolt fits the builder with no terminal workflow to fall back on.

Cards makes human checking cheaper without automating it; Bolt.new automates self-verification without an independent check behind it — for a non-developer operator, that gap is the more dangerous one. Checking is the step where the work is verified before it counts — did it do what was asked, and is it actually correct.

Cards supplies context for checking but does not perform the check. A reviewer reads the description and plan, written before and during the work rather than retrofitted, and compares them against the running change map. The ontology layer is Control Artifact: the card surfaces what the work was supposed to be and what it actually changed, so a human reviewer works with less context-reconstruction overhead. Cards' workflow markers — plan approved, ready to merge — are advisory; they say someone said this is okay but enforce no verification. Cards is explicit that real checking requires an independent human, test, or evaluation system behind those markers. The named failure mode is rubber-stamping: clicking approved without checking the substance, so the marker records review that did not happen. The documentation calls this the most dangerous trap in Cards.

Bolt.new checks its own work. Autonomous debugging detects and repairs error loops, a Security Audit scans backend configurations for issues such as missing row-level-security policies and disabled password protection with a one-click fix, and the agent runs the code, catches errors, fixes them, and reports the result. This is self-verification: the same model that wrote the code is checking it, sharing its blind spots. The ontology layer is Verification, but the subtype is automated self-verification, not human or independent verification. Bolt has no built-in independent review pipeline and no enforced quality gate between the agent finishing and the operator publishing.

Both carry a rubber-stamping risk with the same structural shape: a signal that says checked when checking did not happen. The difference is framing. Cards' markers are documented as something real checks must sit behind, and the pattern is named as the tool's worst trap. Bolt's self-verification is presented as a product capability, without the same explicit warning about what an agent checking its own work cannot catch. For a non-developer operator who cannot read the code, Bolt's checking story is the more dangerous one, because there is no independent way to judge whether the agent's self-check was enough.

Bolt.new removes large parts of fitting in through its own hosted infrastructure; Cards lowers the cost of fitting in without adding any integration capacity of its own. Fitting in is the work of connecting a finished piece to everything around it without breaking what already exists.

Bolt.new removes large parts of this through Bolt Cloud. Hosting, databases, authentication, edge functions, secrets, user management, file storage, and custom domains are provisioned from the same surface where the operator prompts the agent, so an accepted candidate goes live immediately rather than waiting in a deployment queue. Design System Agents add a second mechanism: by ingesting a team's component library, npm packages, Storybook, design tokens, and brand assets, Bolt generates code from approved components rather than invented ones, which the vendor frames as removing the rebuild step engineers otherwise pay on prototypes. The ontology layer is Delivery and Integration — repo-native paths within Bolt's own ecosystem, with a GitHub export when work must leave it.

Cards lowers the per-candidate cost of fitting in without adding integration capacity. The running change map makes collisions visible before merge time, and the default per-job worktree isolation keeps concurrent jobs from stomping on each other. But Cards does not host, deploy, manage databases, or provide infrastructure; it works inside whatever integration pipeline the team already runs.

The limitations mirror each other. Bolt Cloud is strongest for standalone applications living inside its ecosystem; once work must merge into a larger codebase with its own build system and CI pipeline, the all-in-one infrastructure stops helping and the cost shifts to the team's existing pipeline. Cards works for any codebase but never removes the integration step — it makes it cheaper per piece. Both carry a high-concurrency warning: Bolt treats each project as standalone, so many projects mean per-project overhead that scales linearly, and Cards warns that dozens of parallel jobs can break coordination faster than the change map can track.

Neither product has a real claim here. Approving is a recurring authority gate where a separate party must formally sign off on each piece of work. Cards' workflow markers are advisory, not enforced authority gates, with one narrow exception for the final merge marker that the system treats as a real rule; there is no approval queue, no audit trail for outside reviewers, and no role-based authority system, and the card lives on the developer's machine where no compliance officer logs in. Bolt.new offers organization-level GitHub controls and Teams-tier admin provisioning, plus SSO and audit logs at the Enterprise tier, but these are one-time governance and access settings, not recurring per-deployment sign-off gates; nothing requires a separate person to approve each individual deployment before it goes live.

This is a deliberate consequence of what each product is for, not a missing feature. Cards is a work surface for building with agents, not a control system for who may do the work. Bolt.new is a build-and-deploy platform for individual builders and small teams, not a per-work governance tool. For a team whose binding constraint is formal approval on every piece of work, neither product widens that pipe.

Both products lift accepted yield, through different mechanisms and with different offsets.

Cards lifts it in two ways. The intake interview keeps vague ideas out of the pool of started attempts, and the attached description and plan mean reviewers reject for substantive reasons rather than because context was lost between sessions. The offset is that Cards does not increase how many attempts get started, so the gain comes from a smaller, better-formed denominator and is conditional on context loss being the current source of rejection rather than code quality or changing requirements.

Bolt.new lifts it through Plan Mode catching misaligned intent before code is written and through incremental building, where the operator accepts each step rather than waiting on one large build that may never converge. Its offset is structural: low starting friction pulls the denominator of started projects up faster than the numerator of finished ones, so a speculative starter sees a lower acceptance fraction than one who starts only what they intend to finish. Cards' yield gain is mechanism-driven; Bolt's is conditional on operator discipline.

Cards helps accepted work hold up by keeping the reason for each change attached to it and by projecting the cumulative change map against the current state of the project. A later reader can see whether a piece of work is still in place and why it exists without forensic git archaeology, which stops the common failure where code is deleted because nobody remembers why it was added. The ontology layer is Memory and Continuity. The residual risk is a once-correct plan outliving its assumptions; the card surfaces signals that a plan needs re-confirming but cannot force the team to honor them.

Bolt.new's durability is split. Operationally — does the application keep running — Bolt Cloud handles uptime, hosting, and database management, and for prototypes, MVPs, and internal tools that is solid. At the code level — can it be maintained and extended — durability is weaker, because Bolt-optimized code prioritizes reaching a working state over long-term structure, test suites, and architecture documentation. Design System Agents narrow this gap for teams with a well-defined design system, but a Bolt project handed to a traditional team months later is still more likely to be rebuilt than extended. Cards preserves the rationale of accepted work; Bolt.new preserves its runtime. Neither preserves the other's kind of durability on its own.

Each product removes some cleanup and creates some.

Cards reduces cleanup through default agents that look for failure modes in plans and implementations before they cause downstream work, and through a recoverable on-disk record that makes rescuing stuck work faster. It increases cleanup through the rubber-stamping pattern: advisory markers create false confidence, half-checked work merges, and someone fixes it later. In practice that increase is usually the dominant effect unless the team wires real, independent checks behind the markers.

Bolt.new drives infrastructure and setup cleanup to near zero — no environment configuration, no deployment scripting, no orphaned cloud resources, since an abandoned project simply stops being worked on — and the autonomous debugging loop reduces in-development cleanup. It increases cleanup through the self-verification gap: code that passed the agent's own checks but carries subtle bugs produces post-deployment incidents that, for a non-developer operator, may require bringing in a professional developer after the fact. Vague starting prompts also generate cleanup in the form of guesses that must later be untangled. Cards' cleanup risk comes from false confidence in its own signals and can be managed by wiring real checks behind the markers; Bolt's comes from the gap between what the agent says works and what holds up in production, and is structural to the self-verification model rather than a configuration choice.

Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and runs against your existing local Git repository — no browser account, no Bolt Cloud project to set up. Trying it costs the time to install the extension and point it at a coding-agent CLI you may already run, such as Claude Code or Codex; Cards does not import anything from Bolt.new, so an existing Bolt project is untouched either way. Reversing the trial is just as cheap: a card is a plain folder in a local git repository under `~/.cards/cards-repos/`, so removing the extension and deleting that directory returns the project to exactly where it was. The two don't compete for the same work: a technical developer can prototype and deploy in Bolt.new while using Cards, in a codebase that has left the browser, to shape and review agent work there — trying one does not require giving up the other.

Cards' honest claim is on guiding and checking, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. Its mechanism — a persistent, human-readable work object pairing intent with actual work — fits the technical developer re-entering a job and the reviewer evaluating a result without reconstructing context from chat logs. Bolt.new's honest claim is on starting and fitting in, with a genuine secondary effect on guiding for non-developer operators; its mechanism — a browser build environment with managed infrastructure that deploys on the spot — fits the product-oriented builder turning an idea into a running, deployed application. A developer whose narrow pipe is guiding or checking should look at Cards; a builder whose narrow pipe is starting fast or deploying without infrastructure should look at Bolt.new. They can be used together: a technical developer can prototype and deploy in Bolt while using Cards to shape, record, and review the work, since the two occupy different ontology layers and do not contend for the same pipe.