Cards and Kiro — a comparison

Cards' honest claim is guiding and checking — a VS Code work surface that keeps one coding-agent job intelligible from plan to commit. Kiro's honest claim is guiding — a spec-driven environment that pre-configures what the agent should do before it does it. Both assume a professional developer and a scoped feature or bugfix, and they can be used together: Kiro pre-configures and executes the spec, Cards keeps the job intelligible across the interruptions and handoffs Kiro's specs don't, by themselves, preserve.

The companion piece to this page lays out person-and-agent work as a five-step pipeline: 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 useful output; three other things — how many attempts become accepted work, how much holds up later, and how much cleanup the workflow creates — shape the rest. This page compares Cards and Kiro pipe by pipe, without ranking them. In the marketplace ontology, Kiro is an interactive agent workbench with a spec-driven control-artifact system across IDE, CLI, and web surfaces; Cards is a control-artifact and memory-and-continuity system layered on top of whatever harness the developer already runs.

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, one or more plans, comments, attachments, sessions, commits, changed files, and attribution; actions launch configured agents from that job context. The operator is a professional developer in VS Code who already runs a coding agent — Claude Code, Codex, or similar — on multi-step work. The unit of work is a card: one bug fix, feature, cleanup, or investigation, named after the job rather than the chat session. Cards does not run the agent itself; the harness and model provider do that. But it is not a passive notebook either: its default configuration ships actions and skills that direct how the plan forms, how it gets stress-tested, how the change is checked, and how it merges. The boundary is execution, not direction.

Kiro is a spec-driven development environment from AWS, available as an IDE, a terminal CLI, and a web interface, powered by Claude through Amazon Bedrock. The operator is the same kind of person — a developer who reads and writes code daily. The unit of work is a spec: one structured feature or bugfix that flows through requirements, technical design, and a sequenced task list before any code is written. Steering files encode project knowledge once and load into every interaction; agent hooks fire on IDE events; autopilot runs approved tasks without per-step approval; the web agent clones repositories into isolated sandboxes and returns pull requests. Cards is organized around keeping one job intelligible from plan to commit. Kiro is organized around defining the work precisely enough up front that the agent can execute it with less ongoing direction.

Starting is turning a vague idea into a launched attempt the agent can act on. The question is not how fast you can launch, but what reaches the agent when you do.

Cards approaches starting through an intake interview. The default `interview` action walks the developer through a short question sequence — what are you trying to do, why, what does success look like, what constraints matter — and writes the answers into the card as a description and an initial plan. Plans are first-class content; a card can carry more than one, and when it does they form an ordered, evolving sequence rather than a single frozen document. The effect is on seriousness, not speed: fewer vague ideas become attempts, and the ones that do are scoped before the agent starts. The ontology layer is Control Artifact: the card becomes a durable plan-and-intent object before execution.

Kiro approaches starting through its spec system. The developer describes a feature or bug in natural language, and Kiro runs a three-phase flow — requirements captured in EARS notation, a technical design with architecture and sequence diagrams written to `design.md`, and discrete trackable tasks written to `tasks.md`. Quick Plan mode generates all three in one pass without approval gates for well-understood work; a lighter vibe mode skips the structured phases entirely. The ontology layer is also Control Artifact, but the artifact is heavier: three documents with distinct schemas and a task list Kiro's own engine can run, grouping independent tasks into concurrent waves by dependency analysis.

The structural difference is the shape of the starting artifact. Cards writes down intent and an evolving plan sequence the developer's own agent reads. Kiro produces a fixed three-document specification, then executes against it. Neither increases raw starting speed; if the constraint is how many attempts the developer can launch per week, the structured front end adds ceremony, not velocity. Both share the same backfire: on a one-line fix or trivial refactor the upfront process costs more than it saves, and the judgment to skip it falls on the developer each time.

Guiding is the human work of pointing the agent at the right thing and keeping it pointed there across sessions. This is the pipe both products are most honest about, and the mechanism difference is sharpest here.

Cards' guiding effect comes from persistence. The card survives the session, the harness, and the UI because it is a local git repository on disk. When the developer returns after a meeting, a weekend, or a handoff, the description, plan sequence, comments, attachments, and change map are already there. The developer does not reconstruct context; they read it. The next session's agent loads the same files instead of being re-explained. Per-attempt guiding cost drops because the card absorbs the re-entry tax. The ontology layer is Memory and Continuity: durable local state that persists independently of any agent session.

Kiro's guiding effect comes from pre-configuration and delegation. Steering files are markdown documents in `.kiro/steering/` describing product purpose, tech stack, and project structure; they load into every interaction, with four inclusion modes — always, conditional by file-path pattern, manual via `#name`, and auto when the request matches the file's description. The developer writes them once and the agent knows the project without being told again. Specs set scope before execution. Agent hooks fire on IDE events — a save, a file creation — to run conventions automatically. Autopilot removes per-step approval for an approved task entirely. The ontology layers are Control Artifact and Harness: Kiro shapes agent behavior before and during execution rather than recording it after.

The two mechanisms aim at different costs. Cards is strongest when the developer steps away and comes back — it makes re-entry cheap. Kiro is strongest when the developer wants to reduce the need to step in at all. Cards helps you remember where you were; Kiro helps you not have to be there. Both share the same outer limit: neither expands the developer's calendar hours. Cards runs on the developer's machine with no phone app or shared dashboard; Kiro adds a browser surface but still has no org-wide queue where someone else picks up steering work. Both share an information-overload failure mode: a poorly configured card becomes a notification flood, and too many steering files bury the agent in noisy context or misdirect it from a stale file. Both depend on the developer treating their artifacts as maintained documentation, not set-and-forget configuration.

Checking is verifying that what the agent produced is correct and is what was asked, before it counts as output.

Cards makes checking cheaper by giving the reviewer the same artifact that guided the work. The reviewer opens the card, reads the description and plan written before and during the work rather than retrofitted afterward, and judges the result against intent. The attribution tree projects the card's cumulative changes against the current codebase, showing at a glance which other code may be affected. The guiding artifact and the checking artifact are the same object. The ontology layer is Verification and Adjudication, human-verification subtype: Cards supports a person doing the checking but does not perform verification itself.

Kiro makes checking cheaper through separate outputs of execution: code diffs shown as changes happen with per-change approve or reject, error diagnostics for syntax and semantic issues, auto-generated tests for first-pass verification, and acceptance criteria drawn from the spec as a baseline. Here guiding and checking artifacts are distinct: the spec that set scope becomes a reference document, and the diffs, diagnostics, and tests are byproducts of the run. The ontology layer is the same human-verification subtype — Kiro scaffolds the reviewer but does not check independently of the agent that produced the work.

Both share the same fundamental vulnerability and the same most dangerous failure mode. Neither provides independent verification: in Cards, the agents that wrote the code and the advisory markers on the card share the same blind spots; in Kiro, the tests are generated by the same model family that wrote the code and the diffs go to the same developer who instructed the agent. The shared failure mode is rubber-stamping. Cards risks a reviewer clicking an advisory marker — "plan approved," "merge ready" — without checking substance; Kiro risks a developer accepting a diff because tests pass and acceptance criteria look met. In both cases the tooling can manufacture an illusion of checking worse than no tooling, because false confidence displaces whatever real checking would otherwise have happened. Kiro's own engineering posts acknowledge related problems under titles such as why AI agents keep breaking working code.

Fitting in is getting a finished piece into the larger project without breaking what is already there.

Cards' integration effect comes from two mechanisms. The attribution tree makes collisions visible — it answers whether this work is still in place against the current project state without git archaeology, and shows which parts of the project the job has touched against other in-flight work. The default isolated working copies keep two pieces of work in flight from stepping on each other at the file level. The ontology layer is Delivery and Integration, at most PR-centric: Cards reduces the friction of seeing what a change touches, not of merging or releasing it.

Kiro's integration effect comes from in-tool git commits, a spec dependency graph that sequences independent tasks into concurrent waves to cut wall time, and a web agent that clones repositories into isolated sandboxes, coordinates edits across multiple repositories in a single run, and opens pull requests directly to GitHub — assignable via a `kiro`-labeled issue or `/kiro` comment, with `/kiro all` and `/kiro fix` for reviewer feedback. The ontology layer is also Delivery and Integration, reaching further toward PR creation than Cards, but still stopping at the developer's own output.

Neither product manages CI/CD pipelines, resolves merge conflicts between different developers' work, coordinates releases, or handles deployment. The attribution tree is something Cards has that Kiro does not: Kiro's spec records why work was done but cannot answer whether that work is still present in the codebase later without manual investigation. Both share the same concurrency warning. Cards' creators advise that running many pieces of work in parallel raises integration cost faster than throughput; Kiro's parallel task waves and multi-repo sandbox runs carry the same risk, since independent work touching the same codebase creates merge conflicts and coordination overhead neither product resolves.

Approving is a real authority gate: a separate party who must formally sign off on each piece of work because of policy, regulation, customer trust, or data-access rules.

Neither product has anything to claim here. Cards carries advisory markers that can look like approval steps — "plan approved," "merge ready" — but they do not block at the system level, with one narrow exception for the final merge marker. The card lives on the developer's computer; there is no place for a compliance officer to log in. Kiro has no equivalent markers at all. Its diff approval is an individual in-IDE action, not a policy-enforced gate. There are no approval queues, role-based work gates, compliance dashboards, or audit infrastructure in either product. For a team whose binding constraint is a real authority gate that runs per piece of work, neither is built for that problem; both assume individual developers and technical teams making their own decisions about their own code.

Both products raise the fraction of attempts that survive to acceptance, but from opposite ends of the pipeline.

Cards raises the accepted fraction by preserving intent so the reviewer can see what was supposed to happen. The intake interview filters vague ideas before they become started attempts. Because the description and plan travel with the work, rejections shift from "I have no idea why this was built this way" to "this approach is wrong" — the context-loss rejection quietly disappears. Kiro raises it by defining intent in enough detail up front that the agent is less likely to produce the wrong thing: the spec process and the Analyze Requirements feature catch ambiguous or contradictory requirements before design, and steering files keep the agent on convention so fewer attempts are rejected for structural or style reasons.

Both share the risk that their artifacts become liabilities when wrong. A card whose plan was sound at creation but is now outdated can mislead; a well-structured spec built on incorrect assumptions produces output that is confidently wrong, and the acceptance criteria become a trap because the code meets a spec that was itself incorrect.

Cards has a distinctive durability mechanism: the attribution tree projects a card's cumulative changes against the current state of the project, answering whether the work is still in place a month later without digging through history. The card also keeps the rationale on disk, so a future reader does not delete code because nobody remembers why it exists. Kiro preserves rationale through the spec — requirements, design, and task descriptions stay on disk — but has no equivalent to the attribution tree and cannot tell whether the work survived against the current codebase without manual investigation.

Both face the stale-artifact risk. A plan in Cards or a spec in Kiro that was correct at creation and is no longer current becomes a liability for future readers and agents. Kiro has no built-in mechanism for detecting stale specs. Cards has signals that a plan needs re-confirmation, but those signals can be ignored, and ignoring them is a process problem the tool cannot fix.

Cards reduces cleanup through default failure-mode agents that critique plans and implementations before they cause downstream work, and through an intact on-disk record that speeds a senior person's rescue of a stuck piece of work. Kiro reduces cleanup by catching requirement bugs before they become code, auto-generating tests that catch some regressions, and preserving spec history for faster recovery.

Both create cleanup through the same rubber-stamping pattern. In Cards, advisory markers clicked without real review produce half-checked work that merges, fails, and requires rework — in practice usually the dominant effect on cleanup, not a reduction. In Kiro, plausible diffs and passing auto-generated tests create the same false confidence, and the tests compound it by passing when the code is wrong. For both, the net effect depends entirely on whether the developer uses the artifacts for real thinking rather than as procedural checkboxes; without real independent checks wired behind the markers and reviews, both pay more cleanup than they save. Neither reduces cleanup from the agent's own behavior — retrying the wrong thing, compounding mistakes within a task wave or session, producing output correct in isolation but wrong in the larger system. That cost sits outside what either tool addresses.

Cards' honest claim is guiding and checking: it makes re-entry cheap and gives the reviewer the same durable artifact that guided the work, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. Kiro's honest claim is guiding: steering files, specs, and hooks cut the per-attempt direction tax, with secondary effects on starting and checking and nothing on approving. Cards matches the team whose binding cost is re-entry — stepping away, reconstructing context, reviewing agent output without knowing what it was for. Kiro matches the team whose binding cost is ongoing direction — explaining the same project facts session after session and supervising work that could run on its own. The two can be used together: Kiro pre-configures and executes the spec inside its environment, while a card keeps the description, plan history, sessions, commits, and attribution intelligible across the interruptions and handoffs that Kiro's steering and specs do not, by themselves, preserve as a readable work object.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Kiro or migrate anything out of it. Cards runs on your existing local Git repository with no daemon, no account, and no code uploaded to a new service; card data lives locally at `~/.cards/cards-repos/<card-id>/`, alongside your repository rather than inside it, so there is nothing to import from Kiro and nothing Kiro produced that has to be rebuilt to use Cards. Uninstalling Cards removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program — the honest version is that trying Cards costs an install and undoing it costs an uninstall, and Kiro keeps doing whatever it already does in the meantime.