Cards and Amazon Q Developer — a comparison

Cards' honest claim is guiding and checking: plan formation and low-cost re-entry through a durable job object that survives across sessions. Amazon Q Developer's honest claim is starting and the per-attempt cost of guiding: turning a natural-language request into a planned, autonomously implemented change. They sit at different layers and are not substitutes — a team whose narrow pipe is re-entry and review fits Cards; a team whose narrow pipe is raw coding throughput fits Amazon Q Developer; some teams have both pipes narrow and can run them together.

The companion piece ([introduction.md](../../formula/introduction.md)) frames person-and-AI work as a pipeline with five steps — starting, guiding, checking, fitting in, and sometimes approving — plus accepted yield, durability, and cleanup. This page compares Cards and Amazon Q Developer pipe by pipe, without ranking them. In the marketplace ontology, Amazon Q Developer is classified primarily as a hosted harness and background delegation engine with an automated verification regime; Cards is classified primarily as a control-artifact and memory-and-continuity system. They occupy different layers, so most of the contrast is structural.

Cards is a VS Code extension for building with coding agents from plan to commit. For each coding-agent job it keeps one durable work object in the editor: a description, one or more plans, comments and attachments, the sessions and transcripts an agent produced, the commits that landed, and an attribution map projecting those changes against the current codebase. Actions launch a configured coding agent from the job's context. Cards does not run the agent — the harness the developer already uses and its model provider do that — but its default configuration directs the work: how the plan forms, how it is stress-tested, how the implementation is checked, how the change merges. The operator is a professional developer working in VS Code on multi-step agent work; the unit of work is one coding-agent job that survives across sessions.

Amazon Q Developer is an AI coding assistant built and hosted by AWS, reachable from VS Code, JetBrains, Visual Studio, Eclipse, the terminal, the AWS Management Console, and from Microsoft Teams and Slack. The developer describes work in natural language, the agent analyzes the workspace, maps "a step-by-step implementation plan spanning multiple files," and on approval autonomously reads and writes files, generates diffs, runs shell commands, and writes tests until a change is ready. The operator is also a professional developer who reviews pull requests; the unit of work is one natural-language request that produces a change. In one line: Cards is organized around keeping one job intelligible from plan to commit; Amazon Q Developer is organized around running the implementation once a plan is approved.

Cards trades starting speed for starting quality; Amazon Q Developer trades quality for speed — starting is getting a serious attempt off the ground rather than leaving an idea unstarted.

Cards changes starting through seriousness, not speed. The default intake interview asks what the work is, why it matters, what success looks like, and what constraints apply, so the description and plan exist before any agent runs and vague ideas are sharpened or dropped at the front door. The ontology layer is Control Artifact: work is delegated through a structured plan artifact from a guided process, not a bare prompt.

Amazon Q Developer changes starting through activation cost. Describing the work in natural language and receiving a multi-file plan in seconds drops the cost of beginning to nearly nothing — no branch, no scaffolding, no design document drafted by hand. The ontology layer is Harness and Runtime Mediation: the hosted harness turns a request directly into a planned candidate. Grounding comes from workspace analysis, but the harness cannot supply intent the prompt left out, so a vague request yields a plausible plan that misses constraints.

Neither product raises raw generation throughput — the shared gap. Cards trades starting speed for starting quality; Amazon Q Developer trades quality for speed. Both carry the front-of-pipe backfire: a cheaper or more rigorous start only helps if starting is the narrow pipe, and on small or obvious work the upfront step costs more than it returns.

Cards makes the developer more efficient per unit of attention across a job's life; Amazon Q Developer removes the need for attention during one request's implementation phase — guiding is the human cost of pointing an agent at the right thing and keeping it there: prompts, answered questions, course correction, and rebuilding context after stepping away.

Cards lowers this cost through persistence. After a meeting or a week, the description, plans, comments, and change map are already on disk; re-entry is reading the job rather than reconstructing it from chat logs, and the next agent session loads the same context. The ontology layer is Memory and Continuity: durable local state that survives the session, the harness, and the UI, so the per-attempt cost of re-entering work falls.

Amazon Q Developer lowers this cost through autonomy. The developer writes one prompt, approves the plan, and the agent implements without continuous attention. The ontology layer is Harness and Runtime Mediation: the harness absorbs the steering that would otherwise be hands-on time during active coding, so a task that needed hours of back-and-forth can drop to a plan review plus a wait.

Same pipe, different effects. Cards makes the developer more efficient per unit of attention across a job's life; Amazon Q Developer removes the need for attention during one request's implementation phase. Neither adds calendar hours or an async surface for someone else to take over steering. Both share a failure mode — when the controlling artifact is wrong, the mechanism that lowers guiding cost magnifies the damage. A stale plan in Cards drives re-entry on false assumptions; a plan approved without understanding in Amazon Q Developer is executed faithfully against a flawed specification.

Cards makes human checking cheaper; Amazon Q Developer automates part of the check itself — but neither provides independent verification. Checking is the verification a result must survive before it counts — did it do what was asked, is it correct, what is hiding in the middle.

Cards makes checking cheaper by handing the reviewer a complete object for intent. The description and plans were written before and during the work, not retrofitted, and the attribution map shows at a glance which parts of the project this job touched, so review shifts from reconstructing the transcript to reading the job and the map. The ontology layer is Verification and Adjudication, human-verification subtype: the job supports a person doing the checking.

Amazon Q Developer makes checking cheaper through automation. It runs generated tests alongside the code, scans for "hard-to-detect vulnerabilities, such as exposed credentials and log injection," and performs automated code review that detects "logical errors, anti-patterns, code duplication, and security vulnerabilities" — real signals that catch a class of obvious defects a manual pass can miss. The ontology layer is the same Verification and Adjudication layer, automated-verification subtype: the tool checks the code and presents findings for a human in the loop.

Both share the same ceiling: neither provides independent verification. Cards' advisory markers are set by the same people who guided the work; Amazon Q Developer's tests and review run on the same model and workspace context that produced the code, so a planning misunderstanding produces tests that confirm the wrong behavior. The security scan is the most differentiated piece, since it looks for patterns the generator was not optimizing for. The shared, most dangerous failure mode is rubber-stamping: a Cards reviewer clicks an advisory marker without reading the substance; an Amazon Q Developer user sees passing tests and a clean scan and approves without reading the diff. In both, false confidence replaces real checking. Cards does not automate verification at all — it only makes human checking cheaper — a smaller claim and a smaller correlated risk.

Cards surfaces collisions before merge; Amazon Q Developer avoids some of them at generation time — but both stop at the boundary of merge itself. Fitting in is connecting a finished piece to everything around it without breaking what already exists.

Cards' effect is modest. The attribution map makes collisions visible before merge — which parts of the project this job has touched against the current state, a question that otherwise means digging through git history. The default isolated worktrees keep two in-flight jobs from stepping on each other at the file level. The ontology layer is Delivery and Integration, at most a PR-centric surface that lowers per-piece integration cost.

Amazon Q Developer fits changes in at generation time. It analyzes workspace structure before writing code, so it knows which files exist, how they relate, and where new code belongs, making its diffs more likely to fit the existing codebase than output from an agent with no workspace context. That awareness operates while code is generated and is not persisted as a readable artifact; the produced change is the durable output.

Both stop at the boundary of merge. Neither resolves conflicts between developers' branches, coordinates releases, runs build pipelines, or manages deployment, and both carry the same concurrency warning: many overlapping pieces in parallel raise integration cost faster than throughput, and a first change can invalidate a correctly planned second one. Coordination boundaries remain the team's job under either product.

Neither product widens this pipe, for parallel reasons — approving means a real authority gate that runs on every piece of work, a separate party who must formally sign off because of policy, regulation, or organizational rule. Amazon Q Developer's plan-approval step looks like a gate but is not a formal one: the same developer approves the plan and reviews the output, with no separation of duties, no tool-enforced audit trail per candidate, and no escalation path for work that exceeds authority. Enterprise access controls describe who may use the tool, not a per-change approval. On the Authority and Identity layer this is an operator approval model — the individual developer decides. Cards carries advisory markers — "plan approved," "merge ready" — that look similar but enforce nothing (with one narrow exception treated as a real rule at final merge); the job lives on the developer's machine, with no place for a compliance officer to log in, so it sits at the same operator approval model. For a team whose binding constraint is a recurring formal sign-off, neither product is built for that.

Cards raises the accepted fraction by reducing context-loss rejections: the intake interview filters vague ideas, and because the description and plan travel with the job, rejections become "this approach is wrong" rather than "I cannot tell why this was built this way." The lift is conditional — if rejections are driven by code quality, requirements changes, or business decisions, none of those are context loss.

Amazon Q Developer raises the accepted fraction through the plan-first screen: the developer approves the approach before any code is written, so a wrong direction is rejected in seconds rather than discovered in the diff. The risk is symmetric — a plan that looks correct but is not passes the screen and produces code that needs rework. Cards' mechanism works on the review side, Amazon Q Developer's on the development side; both degrade when the controlling artifact is stale or wrong.

Cards has a distinctive durability mechanism: the attribution map projects a job's cumulative changes against the project's current state, so "is this work still in place a month later?" is a glance rather than forensic history work, and the preserved description keeps the rationale attached so future readers do not delete code for the wrong reason. The risk is the stale plan that outlives its assumptions; Cards has signals to re-confirm a plan but cannot force a team to heed them.

Amazon Q Developer does not persist its reasoning. The plan exists during the workflow and is not attached to the change; the code is the artifact. Whether it holds up depends on the rigor of human review and whether the agent-written tests catch regressions — and because those tests share the code's blind spots, the durability they imply is weaker than it appears. Review slippage from clean automation signals is the most direct threat here.

Cards reduces cleanup through default failure-mode agents that critique plans and implementations before they cause downstream work, and because the on-disk record makes rescuing a stuck job faster. It creates cleanup through rubber-stamping: advisory markers clicked without real review merge half-checked work that fails later, an increase that often dominates unless real, independent checks sit behind the markers.

Amazon Q Developer reduces cleanup by leaving fewer half-finished changes — the agent either completes a change or reports a problem, so there are fewer abandoned branches and partial refactors from mid-task context switches. It creates cleanup through code that looks right but does the wrong thing because a plan was approved without understanding, through wrong or irrelevant review findings that need triage, and through accumulated branches someone must close. Both share the honest summary: the net effect depends on whether the developer treats the tool's artifacts as inputs to real thinking rather than checkboxes, and neither reduces cleanup from the agent's own behavior — retrying the wrong thing, compounding mistakes, producing output correct in isolation but wrong in context.

One concrete 2026 fact bears on which surface the claim lives on. AWS has announced that "Amazon Q Developer IDE plugins and paid Subscriptions will reach end of support on April 30, 2027," and that "new signups will no longer available starting May 15, 2026," with the IDE and CLI experience transitioning to a successor spec-driven environment; the Console and first-party AWS experiences continue. For a team weighing the starting-and-guiding claim of the IDE-and-CLI workflow, the horizon is now finite. This does not change the pipe analysis — it changes the surface on which that pipe is available.

Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and runs entirely against your existing local Git repository — no daemon, no database to configure, nothing uploaded to a hosted service. Trying it costs the time it takes 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 or migrate anything from Amazon Q Developer, so there's nothing to convert and no Q Developer history is affected 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. Because Cards organizes the job rather than running the agent, a developer already using Amazon Q Developer for implementation can run both side by side without conflict — this isn't a switch, it's an additional layer to try.

Cards' honest claim is on guiding and checking: plan formation, low-cost re-entry, and returning to intent and actual work together through a durable job object — with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. Amazon Q Developer's honest claim is on starting and the per-attempt cost of guiding: turning a natural-language request into a planned, approved, autonomously implemented change, with conditional effects on checking and fitting in and nothing on formal approval. The matching constraint differs: Cards fits a team whose narrow pipe is re-entry and review against intent; Amazon Q Developer fits a team whose narrow pipe is raw coding throughput on well-scoped work. Because they occupy different ontology layers — a durable control-artifact and continuity surface versus a hosted harness with automated verification — they are not substitutes and can, in principle, be used together: shape and preserve the job on one, run the implementation on the other.