Cards and Sourcegraph Cody — a comparison

Cody is honestly a guiding tool, strongest at bringing automatic codebase context from Sourcegraph's cross-repository search index into the model's context. Cards is honestly a guiding-and-checking tool, strongest at keeping one coding-agent job intelligible from plan to commit. They address different scarcities — Cody the model needing to know the codebase, Cards the human needing to know the job's history — and can be run together since neither's mechanism overlaps the other's.

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, and three other factors 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 compares Cards and Sourcegraph Cody pipe by pipe without ranking them. In the marketplace ontology, Cody is an interactive agent workbench on the Execution Mode layer, with strong ties to the Interoperability and Protocol layer through its Sourcegraph search index and Model Context Protocol tools. Cards is a control artifact and memory/continuity system on the Control Artifact and Memory/Continuity layers. Those layer differences map directly to the pipe differences below.

Sourcegraph Cody is an AI coding assistant that lives inside a code editor — VS Code, JetBrains, Visual Studio — and also runs in the Sourcegraph web app and command line. It provides chat, autocomplete, an Auto-edit feature that suggests changes from cursor movement and typing, reusable prompts, and agentic context gathering that can call configured MCP tools. Its defining mechanism is the context behind those surfaces: Cody connects to Sourcegraph's Search API and SCIP-powered code index, a cross-repository database, so the model can pull in APIs, symbol definitions, and usage patterns from the indexed codebase before it answers. As of 2026, after the Free and Pro tiers were discontinued in mid-2025 and the Amp agentic product split into a separate company, Cody is supported on Sourcegraph Enterprise. The operator is an individual developer who already reads and judges code; the unit of work is one code change started through a chat message or inline edit. Each chat starts fresh — there is no persisted job object carrying what an earlier session discussed, decided, or tried.

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, 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 codebase now. Actions on the card launch the configured coding agent from that job context; the harness and model provider still run the agent. The operator is a professional developer; the unit of work is one coding-agent job — a bug fix, feature, cleanup, or investigation — that may span many sessions over days.

The difference, stated plainly: Cody is organized around making the model aware of the codebase so generation matches the project; Cards is organized around making the job intelligible from plan to commit so a person can shape, continue, and review it. Cody's honest strength — code intelligence and search across a large multi-repository codebase — is real and is not something Cards does or claims. Cards' honest strength is job-context organization, which is not something Cody does or claims.

Starting is the act of getting an attempt off the ground at all. Cody lowers the effort barrier: a developer types a request in chat — add pagination to this endpoint, write a test for this function — and code arrives in seconds, already informed by the indexed codebase. The gap between idea and code on screen is small. The relevant ontology layer is Execution Mode: Cody is an interactive workbench that turns a natural-language request into a code change in one turn. What Cody does not do is decide what to start. It does not scope, prioritize, or filter. A poorly defined request produces code anyway, and cheap generation makes it easy to begin work that should not have been started.

Cards' effect on starting is about seriousness, not speed. The default flow runs an intake interview that draws a vague intent into a written description and a plan before the agent touches code. The ontology layer is Control Artifact: the description and plan are durable artifacts that exist before any session runs. Fewer underspecified ideas reach the agent, and because the card holds the context, several well-formed attempts can be in flight at once without losing the thread. Cards does not raise raw starting throughput; if the constraint is how many agent sessions can be paid for or spun up, Cards has no answer.

The contrast is direct. On a team whose narrow pipe is starting more attempts from more places, Cody helps and Cards does not. On a team whose narrow pipe is too many started attempts going nowhere because they were never well-defined, Cards helps and Cody does not — and Cody's low starting cost can make that problem worse by multiplying speculative starts. Neither product screens for whether an attempt is a good use of time; Cards moves the screening earlier through the interview, while Cody leaves it entirely to the developer.

Guiding is the human work of pointing the agent at the right thing and keeping it there. Both products have a real claim through different mechanisms. Cody reduces the per-request cost of supplying codebase context: instead of pasting source files or explaining how a project is organized, the developer describes the change and Cody has already read the relevant controllers, middleware, types, and existing implementations from the Sourcegraph index — across as many as ten remote repositories, within context windows reaching a million tokens. An `@`-mention syntax pulls in specific files when automatic retrieval misses, and custom prompts let a team standardize recurring tasks. The ontology layers are Execution Mode and Interoperability: the tool connects the model to an external code index so each request carries broader context.

Cards reduces a different guiding cost: re-entry across sessions. When a developer returns to a job after an hour or a week, the card holds the description, the plan sequence, the comments, the attachments, and the running map of what changed. The developer reads the card instead of paging through transcripts; a reviewer does not have to ask why the work was built a certain way because the why is on the card. The ontology layer is Memory/Continuity: the card outlives any single session and is readable by anyone, not only the person who ran it. There is a smaller secondary lift — because the card is an on-disk file, a developer can glance at it outside the heavy editor — but that is limited to the same machine, not a phone or shared dashboard.

Each product fills a gap the other leaves. Cody does not preserve context across sessions; every chat is fresh, so for a job spanning multiple sessions the steering benefit resets each time. Cards does not feed the model project-wide codebase context automatically; the agent knows only what the developer or the card tells it, plus whatever the harness retrieves. Cody helps when the model needs to know the codebase but does not; Cards helps when the human needs to know the job's history but does not. These are distinct scarcities, and a team can have both. Cody's guiding benefit also has a failure mode: when the index is stale or the relevant code sits in an unindexed repository, answers look context-aware but rest on missing information, and the developer cannot tell from the answer alone — the verification cost the index was supposed to save reappears.

Checking is whether the work is actually reviewed before it counts. The two products approach it from nearly opposite structural positions. Cody can identify errors through its debugging path: when a runtime error occurs, the developer can ask Cody to analyze and propose a fix. This is error-finding, not verification. It does not check specification compliance, edge cases, or coding standards, and it carries the self-verification problem — when the same model both writes and checks the code, a blind spot in generation is a blind spot in the check. Sourcegraph has been transparent about this in its own benchmark work, concluding that agents exploit loopholes that pass their own checks and that independent auditing is needed for trust. The relevant ontology position is that Cody's checking mechanism is model-internal.

Cards makes human-led checking cheaper by putting the review context on the card. A reviewer opens the card, reads the description and plans written before and during the work, looks at the change map showing what the job touched across the project, and judges the result against the recorded intent. The cost of reconstructing what the work was supposed to be — usually the largest hidden cost in review — is paid by the card, not the reviewer. The ontology layer is Control Artifact: an independent record of intent that a human judges the output against. Cards does not generate code and does not perform the verification itself; it lowers the cost of a human doing it.

Both products share a false-confidence failure mode. Cody's debugging path can feel like a check when it is not. Cards has the same risk through its advisory markers: a reviewer who clicks the plan-approved or ready-to-merge marker without examining the substance. This is the most dangerous trap in Cards — the marker says checking happened when no checking did, the rubber-stamping risk named honestly. Real checking requires something independent of the agent that produced the work — a careful human, an independent test, an outside system — sitting behind the marker. Cards does not enforce that, so a team that treats the marker as the check makes work look reviewed while leaving it unreviewed. Neither product supplies independent verification; each can make work look more checked than it is.

Fitting in is the work of merging a finished piece into the larger project without breaking what is there. Cards has a modest claim. The running change map makes it visible, at a glance, which parts of the project a job touches, so collisions with other in-flight work surface earlier than merge time. The default setup gives each card its own isolated working copy, so two jobs in flight do not stomp on each other. The ontology touches the Isolation and Boundary layer through per-job working copies and the Control Artifact layer through the change map. Cards does not run merges, manage releases, coordinate dependencies, or open pull requests; that step's capacity is whatever it was before.

Cody has nothing to claim here. It does not create branches, resolve merge conflicts, monitor CI, or coordinate releases; generated code goes through the team's existing integration machinery unchanged. This is a scope boundary, not a deficiency. Both products share a parallel-work caution: Cards warns that running many jobs at once can make fitting-in costs rise faster than throughput, and a developer using Cody to generate code for many tasks in quick succession creates the same integration surface.

Approving is a real authority gate — a separate party who must formally sign off on each piece of work because of policy, regulation, or organizational rule. Neither product has a meaningful claim here. Cody does not provide approval queues, per-work policy enforcement, role-based routing of work products, or audit trails for outside reviewers. Sourcegraph Enterprise as a platform has administrative controls over repository access and user permissions, and recent changes enabled additional AI features on Enterprise plans without separate license keys, but those are one-time adoption and access gates — they govern who can use what, not whether a given change is approved for release.

Cards has advisory markers that can look like approval steps — plan approved, ready to merge — but they are suggestions the developer's own workflow may honor or ignore, not enforced authority, with one narrow exception for the final merge marker treated as a real rule by the system. There is no approval queue, no compliance dashboard, and no role-based routing. For a team whose binding constraint is a per-change authority gate, products built around the ontology's Authority, Identity, and Trust layer address that constraint. Neither Cards nor Cody is one of them, and both are explicit about it.

Cody's effect on accepted yield is modest and runs in both directions. Better codebase context means generated code more often matches the project's conventions and uses the right APIs, so fewer attempts are rejected for context-related reasons — code that does not compile, wrong types, ignored existing patterns. Against that, Cody does not screen requests, and cheap generation encourages speculative starts that get abandoned during review, testing, or after acceptance. The net effect depends on whether the developer is disciplined about what they ask for; well-scoped tasks raise yield, unclear ones lower it.

Cards lifts accepted yield through two mechanisms. The intake interview keeps underspecified ideas out of the pool of started attempts, so the work that does start is more likely to survive. The description and plan on the card mean reviewers reject for substantive reasons rather than for context loss — the common send-it-back-because-nobody-knows-why-this-exists rejection quietly disappears. Both effects are conditional: if a team already produces well-scoped tasks upstream, the interview adds overhead instead of yield, and rejections driven by code quality or changed requirements are not about context loss and will not move. Cody's yield risk is speculation from easy starts; Cards' yield benefit is filtration from harder starts. They are symmetric forces, and a team feeling both can run the intake filter and the context-aware generation together.

Cards has the stronger durability claim, and it is a direct mechanism rather than a side effect. The attribution view projects each job's cumulative changes against the current state of the project, so the question is this work still in place a month later becomes a glance rather than forensic history-digging. Keeping the why on the card also means a later reader is less likely to undo the work for the wrong reason. The ontology layer is Memory/Continuity. The honest limit: a plan that was once correct can outlive its assumptions, and the card does not on its own stop an agent from following a stale plan — Cards emits re-confirm signals, but a team that ignores them has a process problem the tool cannot fix.

Cody's durability effect is smaller and indirect. Code generated with awareness of the full codebase tends to use the right patterns and fit the existing architecture, so it is less likely to need rewriting when the next change touches the same area. There is no direct durability mechanism — Cody does not test whether accepted work still holds, does not detect when last month's change conflicts with newer work, and does not revisit prior sessions. The orientation difference is the cause: Cards is built around is this work still valid, so durability is a design goal; Cody is built around does this match the codebase, so durability is a byproduct of better initial context.

Both products reduce some cleanup and create some. Cody's reductions are real: better-contextualized first attempts need less rework, and the debugging path can catch obvious errors before review. Its created cleanup has two forms. Generated code that looks correct but is subtly wrong merges and surfaces months later during an unrelated change, when the fix is most expensive — the dominant and hardest-to-measure risk. And because context does not persist across chats, a developer revisiting a task may ask Cody to regenerate work already done, paying the generation cost twice.

Cards' reductions are also real: the default setup ships failure-mode agents that look for problems in plans and implementations before they cause downstream cleanup, and the on-disk record makes rescuing a stuck job faster because the history is intact. Its created cleanup is the rubber-stamping pattern from the checking section — clicking a marker without reviewing actively produces cleanup, because half-checked work merges and fails later. In real-world use this is usually the dominant cleanup effect for Cards, an increase from false confidence in advisory markers rather than a reduction. The honest summary is the same for both: each reduces cleanup only when the team maintains independent verification standards behind the tool. Without those standards, the false-confidence effect dominates and cleanup rises. Cards also does not reduce cleanup from the agent itself going in circles inside a session; that is the agent's own behavior.

Cody's honest claim is the guiding pipe: it lowers per-request steering effort by bringing Sourcegraph's cross-repository code index into the model's context automatically, so a developer explains less of the project. Its effect on starting is real but secondary, its debugging path is useful without being verification, and it has nothing on fitting in or approving. Cards' honest claim is guiding and checking together: it lowers the cost of re-entering a job and of reviewing it against recorded intent, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. A team whose binding constraint is the effort of supplying an AI with enough codebase context to generate correct code should look at Cody. A team whose binding constraint is losing the thread of agent work across sessions, or reviewing it without knowing what it was for, should look at Cards. The two can be used together: Cody supplies the model with codebase awareness inside a session, and Cards keeps the job intelligible from plan to commit across sessions. The mechanisms do not overlap, and each fills a scarcity the other leaves open.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Cody or migrate anything out of it — both can run in the same VS Code window at once. 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 Cody and nothing Cody 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.