Cards and Claude Code — a comparison

Claude Code's honest claim is the guiding pipe: it executes the agent and reduces the per-attempt cost of steering it conversationally within a session. Cards' honest claim is guiding and checking across sessions: it keeps one job intelligible from plan to commit and directs how it proceeds, then launches Claude Code to do the work. They aren't alternatives — Cards is a layer on top of the harness a developer already runs, and Claude Code is one of the harnesses it launches by default.

A companion piece lays out person-and-agent work as a five-step pipeline: starting, guiding, checking, fitting in, and sometimes approving through a real authority gate. The slowest step caps useful output; three other factors shape the result — how many attempts become accepted work, how much holds up later, how much cleanup the workflow creates. This page compares the two pipe by pipe without ranking. The relationship is unusual: Claude Code is one of the harnesses Cards launches from. Cards directs and organizes the job; Claude Code executes the agent. They compose more than they compete. In the marketplace ontology, Claude Code is an interactive agent workbench (Harness/Runtime Mediation, Execution Mode); Cards is a control artifact and memory/continuity system (Control Artifact, Memory/Continuity). The layers do not overlap, which is why the two stack cleanly.

Claude Code is an agent that runs in a terminal, code editor, desktop app, or browser. The operator is an individual developer; the unit of work is one task or feature request — describable in a sentence or two, possibly touching several files, tests, and a commit. The developer states a goal in plain language; the agent reads the code, plans across files, edits, runs tests, reads failures, fixes, and re-runs. The marketing line: "If you can describe it, you can build it." Interaction is conversational — interrupt, redirect, approve as it proceeds — and permissions default to cautious, asking before edits or commands.

Cards is a VS Code extension for building with coding agents from plan to commit. The operator is a professional developer inside a codebase; the unit of work is one coding-agent job — bug fix, feature, cleanup, or investigation — kept organized around a description, plans, comments and attachments, the sessions and transcripts that ran, the commits that landed, the changed files, and attribution against the current codebase. A card is a local git repository that survives the harness, session, and UI. Actions launch a configured agent from the job's context. Cards does not run the agent: the harness and model provider do, and in a default setup that harness is often Claude Code itself.

The difference: Claude Code is organized around running the agent — session, conversation, edit-test loop. Cards is organized around keeping one job intelligible from plan to commit and directing how it proceeds. Claude Code asks "what should I do next?" Cards asks "what is this work for, how should it proceed, and what happened?" — then hands the doing to Claude Code.

Both lower the cost of beginning but remove different friction. Claude Code lowers the effort barrier to a serious attempt: instead of choosing files and writing code by hand, the developer describes a goal and the agent does the exploration and first pass. It starts from terminal, editor, desktop app, or browser, so a thought becomes a started attempt without waiting to be at a desk. The layer is Execution Mode. The default permission model prompts for each significant action, so parallelism still runs into one developer's attention.

Cards raises the seriousness of a started attempt, not its speed. The default `interview` action runs a short intake that pulls vague intent into a written description and initial plan before any code is touched. The ontology layer is Control Artifact: the card carries description and plan as durable objects from the first moment. Cards does not increase start throughput; it makes poorly-defined starts harder.

These compose directly. A developer runs the intake, lands a description and plan, then triggers a launch action opening a Claude Code session from that context. Claude Code's low-friction execution moves the started card; Cards' intake keeps a thin idea from becoming a Claude Code session that goes nowhere. Where the constraint is launching agent work fast from many surfaces, Claude Code addresses it and Cards does not. Where it is too many vague starts, Cards addresses it and Claude Code, by making starting cheap, can make it worse.

Both make their strongest claims here, about different kinds of guiding cost. Claude Code reduces the per-attempt cost of steering inside a session. The developer describes intent in natural language; the agent explores and implements without step-by-step instruction. On drift, "that is not right" and it adjusts. Plan mode lets a developer review an approach before code is written; for agent teams, a teammate can be required to plan in read-only mode until the lead approves. Re-entry within a session is cheap because the conversation holds context. The mechanism is conversational; the layer is the Harness. The known limit is the context window — as a session fills, automatic compaction can drop details the developer assumed would persist, so guiding cost rises late in long sessions unless the developer clears or summarizes.

Cards reduces the cost of re-entering work across sessions and directs how it proceeds. Returning after a day or a week, the developer reads the card's description, plan sequence, comments, and change map instead of reconstructing the story from a transcript. The layers are Control Artifact and Memory/Continuity: the card outlives any session and is readable by anyone. Cards does not merely store context and wait — its default configuration ships actions and skills that direct the work: how a plan is drafted, stress-tested before coding, checked, and merged. The distinction is execution versus direction: Cards directs and organizes the job; the harness and model run it. When Claude Code is that harness, Cards' actions shape what each session is asked to do, and Claude Code's conversational steering handles moment-to-moment correction inside it.

The mechanisms are not rivals; they sit at different time scales. Claude Code is strongest within a session, in real time. Cards is strongest across sessions, on re-entry, and at the direction layer that decides what the next session is for. A developer in one long continuous session gets most guiding value from Claude Code; one who juggles several jobs, steps away, or hands work to reviewers gets Cards' value on top of it. Neither removes the underlying judgment load.

The two help at different points. Claude Code runs tests, lint, and type checks automatically after edits; on failure it reads the error, fixes, and re-runs. It monitors CI on GitHub and GitLab and can commit fixes. `claude ultrareview` / `/ultrareview` provide a non-interactive review pass, and a Writer/Reviewer pattern uses a second independent session to review the first. The layer is Verification and Adjudication. The structural limit is self-verification: the same model writes the code and interprets the tests, and if the suite has gaps the model does not know to look. The documentation's own framing: the agent does dramatically better when it can verify against developer-supplied tests, screenshots, or expected outputs — without those, the self-check is only as deep as the existing suite.

Cards makes human-led checking cheaper by putting review context on the card. A reviewer reads the description and plan written before the work began rather than retrofitted, looks at the attribution tree projecting cumulative changes against the current codebase, and judges whether the work met its intent without rebuilding what it was supposed to be. The layer is Control Artifact. Cards does not perform trusted verification itself.

Both share a failure mode. Claude Code's "all tests passed" can create false confidence — passing is not correctness. Cards' advisory markers ("plan approved", "ready to merge") are suggestions, not enforcement; a reviewer can click "approved" without checking substance. This is structural, not a discipline problem. **Plausible, fast output is the exact condition under which careful, senior reviewers stop cross-checking** — and multi-job load makes it worse. That rubber-stamping is the most dangerous trap in Cards: the marker says reviewing happened when none did. The mitigation is identical for both — an independent check, a careful human, an independent test, or an outside system must sit behind the signal. Used together, Claude Code's test-and-fix loop reduces failures that reach a human and Cards' context lets the human review the rest faster; the false-confidence risk is additive, not cancelled, and the team's independent verification standard determines whether the pair nets positive.

Claude Code has the more direct effects here; Cards a narrower, visibility-oriented one. Claude Code creates branches, commits, opens PRs, resolves simple merge conflicts, and monitors CI. It works across the full codebase and accounts for how a change interacts with the rest. It supports several forms of concurrency — git worktrees for parallel branches, background agents, and experimental agent teams that coordinate multiple sessions through a shared task list with file-locked task claiming. The layer is Delivery and Integration.

Cards' effect is more modest. Its change map makes collisions visible before merge time, so overlapping in-flight work is spotted earlier; its default setup gives each card its own isolated working copy. The layer is Control Artifact and Isolation: visibility and per-job isolation, not merge execution. Cards does not run merges, manage releases, or open PRs.

Both warn about parallel work for the same reason. Claude Code's agent-teams docs advise starting with three to five teammates, sizing tasks so coordination overhead does not exceed the benefit, and avoiding two teammates editing the same file. Cards warns that running many jobs in parallel can make fitting-in costs rise faster than throughput. The mechanism is identical: more parallel attempts mean more integration surface, and neither tool changes that. In combination, Claude Code does the git work for a card's job while Cards' change map shows, across all in-flight cards, where those jobs collide — visibility one level above execution.

Neither product has a meaningful claim here, for both a deliberate scope choice rather than a gap. Approving is a recurring authority gate: a separate party formally signs off on each piece of work because of policy, regulation, or organizational rule. Claude Code has a technical permission model — ask before every action, auto-approve named commands, or a classifier sorting safe from risky; agent-team teammates inherit the lead's mode. This is tool-safety enforcement on the developer's machine, not work-product approval. It does not route work to a compliance officer, produce audit trails for outside reviewers, or enforce organizational policy. Cards has advisory markers signaling a plan was reviewed or a change is ready to merge — suggestions the workflow can honor or ignore, not system-level blocks, with one narrow exception for the final merge marker. There is no approval queue, no compliance dashboard, no role-based routing, and nowhere for a compliance officer to log in.

For a team whose binding constraint is a real authority gate — a security review on every change, a policy approval blocking each deployment — products on the Authority, Identity, and Trust layer address that. Neither Claude Code nor Cards, alone or together, is one of them.

Cards raises accepted yield through upstream filtering and context preservation: the intake interview keeps vague ideas out of the started pool, and the description and plan on the card mean reviewers reject for substance rather than lost context. Claude Code raises it through conversational course correction and plan mode — the developer redirects mid-task and reviews an approach before code is written.

Both effects are conditional and, paired, complementary. Cards' intake is wasted on a team that already scopes work well upstream. Claude Code's correction depends on the developer staying engaged — describe a task and walk away and the benefit is forfeited. Claude Code carries a yield risk Cards does not: cheap starting invites speculative attempts that get abandoned, while Cards' intake barrier pushes the other way. Run together, Cards filters which jobs become Claude Code sessions at all, and Claude Code's in-session correction catches the ones that survive but still drift — two filters at different stages of one pipeline.

Cards has the stronger durability claim. The attribution tree projects a card's cumulative changes against the current codebase, answering "is this work still in place a month later?" with a glance instead of forensics. The "why" on each card makes a later reader less likely to undo work for the wrong reason. Claude Code's effects are smaller and passive: auto-memory carries learnings across sessions, the project instructions file records conventions the agent reads each session, and checkpoints preserve the reasoning behind changes.

Neither independently verifies that work correct last week is still correct this week. A plan that was right can hang around after its assumptions go stale; Cards has signals for "this plan needs re-confirming" but cannot force the team to heed them. Claude Code does not test for durability at all. Together they reduce accidental contradiction — Claude Code within the agent's memory, Cards across the human-readable record — but durability still rests on test coverage, requirements stability, and review discipline.

Each product both reduces and creates cleanup. Claude Code's test-and-fix loop catches failures before a human sees them, and checkpoints — every prompt creates one, and `/rewind` restores code, conversation, or both — let a developer undo edits cleanly. But its self-verified work that looks correct and is not creates the dominant cleanup risk; checkpointing also does not track files changed by bash commands or concurrent sessions, and experimental agent teams can leave orphaned tmux sessions and lagging task state. Cards' dedicated failure-mode agents look for problems before they cause downstream cleanup, and the on-disk record makes rescuing stuck work faster. But its advisory markers create the rubber-stamping pattern: half-checked work merges, fails later, and someone fixes it — usually the dominant cleanup effect for Cards users.

The honest summary is the same for both and for the pair: cleanup goes down only when the team also maintains independent verification standards. Without them, both false-confidence effects compound — Claude Code's "tests passed" feeding a reviewer's unchecked "approved" marker — and cleanup rises.

There's no switch to make here. Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and, in a default setup, launches Claude Code itself as the harness — if a developer already runs `claude`, adopting Cards costs installing the extension and pointing it at that existing CLI, not replacing anything. Cards runs against the existing local Git repository and imports nothing from prior Claude Code sessions; 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, and Claude Code keeps working exactly as before, with or without Cards launching it.

Claude Code's honest claim is the guiding pipe: it executes the agent and reduces the per-attempt cost of steering it conversationally within a session, with secondary effects on starting and checking. It matches the constraint of specifying and re-explaining work to an agent inside a session. Cards' honest claim is guiding and checking across sessions: it keeps one job intelligible from plan to commit and directs how it proceeds, with smaller effects on starting, fitting in, accepted yield, and durability, and no claim on approving. It matches the constraint of returning to work after a gap and reviewing it without context. Used together by design: Cards directs and organizes the job, then launches Claude Code, which runs the agent. The boundary is execution versus direction, which is why they stack instead of collide.