Cards and Codegen — a comparison

Codegen's honest claim is starting and guiding: it converts well-scoped tickets into pull requests in parallel and makes the task description carry almost all the steering, removing operator attention during the run. Cards' honest claim is guiding and checking: it makes each attempt cheaper to re-enter and each review cheaper to perform. A team whose narrowest pipe is a backlog of well-defined tickets and too few engineering hours matches Codegen; a team whose narrowest pipe is attempts dying from context loss on re-entry matches Cards — and they can run side by side.

A companion piece lays out 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 useful output; three more things shape the result — how many attempts become accepted work, how much holds up later, and how much cleanup the workflow creates. This page compares Cards and Codegen along that pipeline without ranking them. In the marketplace ontology, Codegen is a background delegation engine (primary layers Execution Mode and Delivery/Integration; secondary Verification/Adjudication and, through the task system, Memory/Continuity). Cards is a control artifact and memory/continuity system (primary layers Control Artifact and Memory/Continuity; an incidental touch on Isolation). One fact frames everything below: the standalone Codegen product was discontinued in January 2026, and its agent orchestration, sandboxed execution, and PR review now run as the coding-agent layer inside ClickUp, where a ClickUp task is the unit that becomes a pull request.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized inside the editor: a description of what the work is for, one or more plans, comments and attachments added as the work sharpens, the sessions and transcripts the agent produced, the commits that landed, the changed files, and an attribution view of what those changes still amount to against the current codebase. Actions on the card launch the configured coding agent from that job context; the default setup also directs how the work proceeds — how a plan is drafted, stress-tested, implemented, and merged — through configurable actions and skills. The operator is a professional developer who reads diffs, plans, and commits, and the unit of work is one coding-agent job held intelligible from plan to commit. Cards does not run the agent: the harness the developer already uses and the model behind it edit files and run commands.

Codegen is a background engine that turns a well-scoped ticket into a pull request without human attention during the run. An engineering team member assigns a task — in ClickUp, or through Slack, Linear, Jira, or Monday — and a Codegen agent reads the full task context, writes the code in an isolated sandbox, runs tests, opens a pull request, and reports progress back into the task. Multiple agents run in parallel, each in its own sandbox from the same baseline commit. The acquiring company frames the design around context: "the bottleneck to agents transforming how work is done is no longer AI capabilities — it's context." The operator is an engineering team member who can write clear scope and acceptance criteria, though any teammate can assign a task. The unit of work is one task-to-pull-request cycle.

The shortest way to hold the difference: Cards keeps one job intelligible from plan to commit — what it was for, what happened, what it now amounts to. Codegen is organized around executing the work — convert this ticket into a pull request without human attention. Cards asks how to make each attempt cheaper to guide and check. Codegen asks how to get more well-scoped tickets turned into pull requests in parallel.

Codegen raises the generation rate; Cards raises the seriousness of each attempt without touching the rate at all. Starting is launching a serious attempt — getting real work in motion rather than sitting on an idea.

Codegen's most direct effect is here. Assigning a ticket launches an attempt in the time it takes to tag a task, and agents run in parallel sandboxes, so a batch can be in flight at once. The ontology layer is Execution Mode with background managed execution: the operator's time is removed from the implementation loop, so the generation rate rises directly, and vendor case studies cite teams shipping dozens of features in a day. What it does not change is raw model capacity — if the constraint is API rate limits or compute budget, this does not move it — and it cannot start an attempt from a vague ticket; the vendor's phrasing is "clear scope is king."

Cards does not try to raise the generation rate. Its effect on starting is seriousness, not speed. The default intake interview draws a vague intent into a written description and a plan before any agent runs, so what reaches the agent is a formed attempt rather than a loose idea. Fewer vague attempts get started, and the ones that do are likelier to survive. Cards has no parallel or background runner; each attempt begins when the developer launches a session from the card. The ontology layer is Control Artifact: the description and plan become the durable object that makes the started attempt inspectable.

The split is clean. A team that cannot turn well-scoped tickets into pull requests fast enough has a Codegen-shaped problem at the front of the pipeline. A team whose attempts are too vague to finish, or die on re-entry because nobody can reconstruct what they were for, has a Cards-shaped problem in the middle.

Codegen pays guiding cost once, up front in the ticket; Cards pays it down on every return, through re-entry. Guiding is the human effort of pointing the agent at the right thing and keeping it pointed there as the work moves.

Codegen front-loads guidance. The operator writes a ticket with a success criterion, scope boundaries, and context references; the agent then works the implementation without demanding mid-task attention. Steering is paid once, as a single task description, rather than continuously across the run — the vendor describes the agent as starting with what an experienced engineer would have after ten minutes reading the ticket. A second, distinct effect: because the run is in the background, the operator's attention is free during execution, so one agent's output can be reviewed while another codes the next task. The ontology layer is Memory/Continuity anchored on the task system: the description, linked docs, and sprint context are the continuity the agent carries into the sandbox.

Cards lowers the per-attempt guiding cost from the opposite direction — by making re-entry cheap. When the developer returns after a meeting, a weekend, or a handoff, the card already holds the description, the plan sequence, the comments, the transcripts, and the map of what changed; context is read, not reconstructed. The card is also legible outside the heavy editor — a terminal, a second monitor — though the limit is same-machine, not a phone or shared dashboard. The ontology layer is Memory/Continuity anchored on the on-disk card: it survives session loss, compaction, and crashes regardless of which agent produced the work.

Neither model helps when the work cannot be described before it starts. Codegen's upfront guidance has nothing to encode for exploratory work where the approach emerges during implementation; the vendor concedes vague tickets produce weak results. Cards is built for that case — the card accumulates context as the work moves — but requires the developer to initiate each session, where Codegen removes the operator from the loop entirely for batchable work. Each side has a backfire: easy starting plus low steering cost can push a team to launch many under-scoped tickets that all need rework; a flood of card notifications can invert the re-entry saving and cost more attention than it returns.

Codegen automates a review pass; Cards makes human review cheaper without automating it — both share the same completion-signal risk. Checking is whether the produced work is actually verified before it counts — not whether it looks done.

Codegen runs an AI code review pass against each pull request before a human sees it, flagging security, consistency, and architectural departures, plus a check-suite auto-fixer that analyzes CI failures and pushes corrections. In the ClickUp-embedded form the reviewer carries the same task context the writer had — description, linked docs, acceptance criteria — so the review judges against intent, not only the diff. The ontology layer is Verification/Adjudication with automated and reviewer-agent verification. The structural limit: the review is produced by the same system that wrote the code, so blind spots are shared, and the vendor does not document calibration against separate human review — which makes the pass a triage layer, not trusted checking. The auto-fixer can make a failing test pass while leaving the defect intact.

Cards' effect is different in kind. It ships no automated review pass; it makes human review cheaper by handing the reviewer the card: the description and plans written before and during the work, the running map of what changed across the project, and the transcripts of what the agent did. The reviewer judges whether the work met the intent without rebuilding context from chat logs. The ontology layer is Control Artifact feeding Memory/Continuity: the artifact that lowers review cost is the same one that recorded the intent.

Both share a verification failure mode in different shapes, and it must be named plainly. Cards carries a rubber-stamping risk: advisory markers ("plan approved," "ready to merge") can be clicked without the substance being examined, so the system records that checking happened when none did. Codegen carries a self-verification risk: the AI review pass creates the impression of a check when the same entity generated and verified the work. The mechanism differs — an advisory marker versus an AI review report — but the structural risk is identical: a completion signal without independent verification. Neither product supplies that independent check; it has to be a careful human, an independent test, or an outside system sitting behind the signal.

Both isolate work in progress to prevent collisions during development, and neither manages the merge itself. Fitting in is merging a finished piece into the larger project without breaking what is already there.

Codegen runs each agent in its own sandboxed copy from the same baseline commit, so two agents on different tickets do not collide during development, and the vendor recommends stacked pull requests to keep individual diffs small. It does not manage merges, resolve conflicts, coordinate dependencies, or handle releases. The ontology layer is Delivery/Integration with PR-centric integration — producing pull requests from tickets is central to the design.

Cards gives each card its own isolated working copy by default and a running map of cumulative changes that makes collisions visible before merge rather than at merge. It does not manage merges, resolve conflicts, or handle releases either. The ontology layer is Isolation feeding Control Artifact; fitting in is incidental to Cards, not its purpose.

Both carry the same high-concurrency warning: the integration cost is per-pull-request, not per-agent. A team that cannot process pull requests as fast as its agents produce them will find fitting in becomes the new bottleneck regardless of which tool produced the work, and neither product changes the fact that each output must be merged by a human process.

Neither product claims this pipe. Approving means a recurring authority gate — a per-work permission decision enforced at the system level for policy, regulation, or organizational rule. Codegen's pull requests pass through standard GitHub or GitLab checks and human review, which are valuable but not an enforced recurring authority gate; the on-prem deployment's access controls govern who can operate Codegen, not whether a specific change may ship. Cards' workflow markers are advisory and live on the developer's machine — no approval queue, no compliance dashboard, no role-based authority system, with one narrow exception where the final merge marker is treated as a real rule. For a team whose binding constraint is a recurring authority gate — policy sign-off per change, data-access approval, regulated release authorization — neither product addresses that step, and the choice should be a different product.

Both can raise accepted yield through different mechanisms, and both effects are conditional on input quality.

Codegen raises yield through context assembly at the start: the agent begins with the full task description, linked docs, comments, and sprint context, so the output matches intent more closely and needs fewer revisions. The codemod approach helps a narrower class — dead-code removal, API migration, dependency upgrades — where transformations backed by a dependency graph guarantee the change is comprehensive and unlikely to be rejected for missing or breaking something.

Cards raises yield through the intake interview, which keeps vague ideas out of the started pool, and through context retention, which removes the class of rejections caused by a reviewer who cannot reconstruct what the work was supposed to be — common where context vanishes between sessions.

Neither product fixes a rejection rate driven by requirements instability, business decisions that change during implementation, or code-quality gaps the model cannot address. Codegen needs agent-ready tickets; Cards needs the team to actually use the intake mechanism and keep the card current.

Cards has the stronger structural claim on durability. The attribution view — a cumulative projection of the card's changes against the current state of the project — makes "is this work still in place a month later?" a glance rather than forensic history-digging, and keeping the rationale attached reduces the chance a future developer reverts or rewrites it because its purpose is no longer clear. The standing risk is a stale plan: one that was correct can outlive its assumptions, and the card does not stop an agent from following it unless the team heeds the re-confirm signals.

Codegen's durability mechanisms are narrower but real: the codemod approach guarantees completeness for a class of systematic changes through static analysis, and the task system preserves the rationale so a later reader can see why a change was made. Neither product eliminates the durability risk of autonomously generated code that is hard for humans to read; Cards reduces it by keeping the why attached, and independent measurement would be needed to say which direction dominates for Codegen.

Both reduce some cleanup and create some, in the same dominant pattern — false confidence in a completion signal — with different secondary reductions.

Codegen reduces cleanup through the codemod approach (systematic changes that need no follow-up), dependency-graph analysis (guaranteed completeness for deletion and refactoring), and the AI review pass catching issues before production; sandbox traces also make after-the-fact failure diagnosis cheaper. It creates cleanup through the check-suite auto-fixer, which can silence a test without fixing the defect, and through the volume of plausible pull requests that pass an AI review and a quick human glance, merge, and fail later.

Cards reduces cleanup through dedicated failure-mode-analysis agents in the default setup that examine plans and implementations before problems propagate, and through cheaper post-failure diagnosis because the full record is on disk. It creates cleanup through the rubber-stamping pattern: advisory markers that produce false confidence and let half-checked work merge — usually the dominant effect on cleanup unless the team wires real, independent checks behind the markers.

The shared lesson is structural. Both promise cleanup reduction that holds under ideal conditions, and both create a risk rooted in the same human tendency: treating the tool's completion signal — an advisory marker in Cards, an AI review report in Codegen — as sufficient rather than as an invitation to actually check. The cost shows up later, when the unchecked work fails in production.

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 ClickUp workspace or ticket system to connect. Trying it costs the time to install the extension and point it at a coding-agent CLI you may already run; Cards does not import anything from Codegen or ClickUp tasks, so nothing there needs converting. 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 the two sit at different points in the pipeline — background ticket-to-PR execution versus per-job re-entry and review — a team already running Codegen for well-scoped tickets can add Cards for the jobs that need shaping and human review without touching the Codegen flow.

Codegen's honest claim is starting and guiding: it converts well-scoped tickets into pull requests in parallel and makes the task description carry almost all the steering, removing operator attention during the run. Cards' honest claim is guiding and checking: it makes each attempt cheaper to re-enter and each review cheaper to perform, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. A team whose narrowest pipe is a backlog of well-defined tickets and too few engineering hours matches Codegen; a team whose narrowest pipe is attempts dying from context loss on re-entry, or reviews made expensive because intent cannot be reconstructed, matches Cards. They are not in conflict and can run side by side — Codegen turning tickets into pull requests, Cards keeping the jobs that need shaping, re-entry, and review-against-intent intelligible from plan to commit — but a team that widens the pipe that is not currently narrowest will see no rise in useful output.