Cards and JetBrains Junie — a comparison

Junie's honest claim is guiding — plan mode, live prompting, persistent guidelines, and deep JetBrains-IDE integration lower the per-attempt cost of steering an agent. Cards' honest claim is also guiding, plus checking, through durable cross-session continuity. The two run on different editor surfaces — Junie inside a JetBrains IDE, Cards inside VS Code — so the overlap for one developer is small, and the real question is which bottleneck binds: steering inside a JetBrains IDE, or returning to and reviewing work across sessions.

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 of it holds up later, and how much cleanup the workflow creates. This page compares Cards and JetBrains Junie one pipe at a time, without ranking them. Using the marketplace ontology, Junie is primarily an interactive agent workbench and harness with secondary roles in verification and delivery integration; Cards is primarily a control-artifact and memory/continuity system. That layer split is the structural fact underneath everything below: Junie runs the work, and Cards keeps one job readable from plan to commit.

Junie is an LLM-agnostic coding agent by JetBrains. It runs as a plugin inside a JetBrains IDE — IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest of the family — as a command-line tool in the terminal, and inside CI/CD through a GitHub Action and a GitLab integration. The developer describes a task in natural language; Junie explores the codebase, can produce an implementation plan in plan mode, writes code, runs tests, and presents the result. It is model-agnostic: a developer can bring an API key from Anthropic, OpenAI, Google, xAI, or OpenRouter, or use a JetBrains subscription. The operator is a developer working in a JetBrains IDE or its terminal; the unit of work is one task prompt handed to the agent.

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, transcripts, commits, changed files, and attribution. Actions on the card launch the developer's configured agent from that job's context, and the default configuration ships instructions and helper agents that direct how a plan forms, how it is stress-tested, how the change is checked, and how it merges. Cards does not execute the agent: the harness the developer already runs and the model behind it call the model, edit files, and run commands. The operator is a professional developer in VS Code or a VS Code-based editor; the unit of work is one card. The simplest way to hold the difference: Junie is organized around running the work — the session, the edit-test loop, the pull request. Cards is organized around keeping the job intelligible from plan to commit — what it was for, how it was going to be done, what happened, and whether it still holds.

Starting is the act of getting a serious attempt launched at all. Junie makes this nearly instant from several surfaces: type a prompt in the terminal, open a session inside the JetBrains IDE, or tag the agent on a GitHub issue or GitLab merge request. Plan mode adds optional structure — toggled with Shift+Tab or invoked as `/plan`, Junie analyzes the codebase with read-only operations, produces an implementation plan, and waits for approval or redirection before any file changes. The ontology layer is execution mode: Junie spans interactive local, terminal, and CI-triggered starts.

Cards' effect on starting is about seriousness rather than speed. The default `interview` action draws a vague intent into a written description and a plan before the agent touches code, so what reaches the agent is a defined attempt rather than a loose instruction. The ontology layer is the control artifact: the description and plan exist as durable content on the card before execution begins. Cards does not raise the raw rate of launching attempts, and it lives on one surface — the editor — not the terminal or CI.

For a team whose narrow pipe is launching work from many entry points, Junie's three execution surfaces address that. For a team whose narrow pipe is too many poorly-defined attempts entering and going nowhere, Cards' intake barrier addresses that, independent of which agent runs the work. Neither tool provides a control room for launching dozens of attempts at once.

Guiding is the human cost of pointing the agent at the right thing and keeping it pointed there. Both products make a strong claim here, on different costs. Junie reduces the per-attempt cost of steering through several harness mechanisms: plan mode front-loads alignment so the developer confirms an approach instead of writing step-by-step instructions; live prompting lets the developer redirect while the agent is still running; a `.junie/AGENTS.md` guidelines file is applied with every prompt; Agent Skills — folders in the open Agent Skills format — load on demand only when they match the task; and the IDE connection lets the agent start from the developer's working state and the project's semantic index rather than scanning from scratch. The ontology layer is the harness: the agent manages its own context, accepts in-session redirection, and reads persistent project instructions.

Cards reduces a different guiding cost through one mechanism with wide reach: the persisted work object. When a developer returns to a job after a meeting, a weekend, or a handoff, the card already holds the description, the plan sequence, the comments, and the running change map. The developer reads the card instead of paging through a transcript, and the card is not tied to any one agent. The ontology layers are control artifact and memory/continuity: the record survives the session and is readable by anyone who opens the card, including the next agent and a reviewer.

Junie's guiding help is largest for a developer working in continuous sessions with the same agent who wants cheaper real-time direction and persistent in-IDE context. Cards' is largest for someone who juggles several jobs, steps away often, switches agents, or hands work to reviewers who need the why without asking. Junie carries a configuration surface Cards does not: Agent Skills, guidelines, MCP servers, and an action allowlist all reward setup and punish skipping it, and in the default mode every sensitive action triggers an approval prompt unless the allowlist or brave mode is set. Cards' equivalent burden is the intake interview and keeping the card current; its risk is the inverse — a flood of card notifications can invert the gain and cost more attention than it saves.

Checking is whether the work is actually verified before it counts. Junie has two built-in mechanisms. The test runner runs the project's tests after changes and iterates until they pass or it cannot. The code review agent is a built-in subagent that reads the diff, explores the surrounding codebase, and returns a structured review using a focused system prompt and a review-specific subset of tools, without changing code; it can be run locally with a `--review` flag and triggered in the GitHub Action on opened or updated pull requests. The ontology layer is verification, through automated and reviewer-agent checking. The limitation is self-verification: the same model family that wrote the code runs the tests and produces the review, so a review agent that shares the coding agent's assumptions misses the same categories of mistakes. The JetBrains IDE's static inspections add a model-independent layer, but only at what static analysis can catch.

Cards makes human-led checking cheaper rather than automating it. A reviewer opens the card, reads the description and the plans written before and during the work, looks at the running change map across the project, and judges whether the work meets intent without reconstructing what it was supposed to be. The ontology layer is the control artifact: durable review context makes a human verifier faster and better-informed. Cards does not run tests or produce automated reviews.

Both products share a failure mode. Junie's automated checks can create false confidence — all tests green and a clean same-model review can buy acceptance without scrutiny. Cards has a more direct version: its advisory markers ("plan approved," "ready to merge") enforce nothing, and the most dangerous trap is rubber-stamping — a reviewer clicking approved without checking the substance, so the record says reviewing happened when no reviewing did. In both cases the mitigation is identical: independent verification must sit behind the tool's signals, not replace them.

Fitting in is the work of merging a finished piece into the larger project without breaking what is there. Junie has the more direct effect. The GitHub Action and GitLab integration create pull requests from completed tasks, create branches, push commits, resolve merge conflicts, and post inline review comments and CI failure analysis on merge requests. The IDE connection means changes are aware of project structure and build configuration. The ontology layer is delivery integration: Junie does the git operations and opens the PR.

Cards has the more modest, visibility-oriented effect. Its running change map makes collisions visible before merge time, and the default setup gives each job an isolated working copy so two in-flight pieces do not collide. The ontology layer is the control artifact — it shows where work will collide but does not create PRs, resolve conflicts, or touch CI/CD. Both products warn about parallel work for the same reason: more simultaneous attempts mean more integration surface, and neither adds integration capacity. Junie's GitLab documentation states it can work on multiple tasks simultaneously, excluding parallel runs on the same MR branch; Cards' broader formula warns against extrapolating gains from a few simultaneous pieces to many.

Approving here means a real authority gate that must clear on each piece of work. Neither product widens it. Junie asks for approval before sensitive actions — shell commands, edits outside the project directory, MCP tool calls — and brave mode bypasses those prompts. These are safety controls on agent behavior, not work-approval gates: no audit trail for external reviewers, no compliance dashboard, no organizational role-based control. Cards' advisory markers can look like approval but enforce nothing, with one narrow exception for the final merge marker treated as a system rule; there is no place for a compliance officer to log in. For a team whose binding constraint is a policy, security, or data-access gate that must run per change, neither is the tool. The ontology layer — authority, identity, and trust — is one both products deliberately leave to other systems.

Both products lift accepted yield through different mechanisms. Junie's plan mode catches misaligned attempts before they become expensive code, and its recommended spec-driven workflow — requirements, then plan, then task list, then phased execution — creates explicit acceptance criteria that reduce drift; both gains require the developer to stay engaged during planning, and skipping plan mode forfeits the filter. Cards' intake interview keeps vague ideas out of the pool before they are started, and the description and plan on the card mean reviewers reject for substantive reasons rather than for lost context. The yield risks differ in direction: Junie's ease of starting can encourage speculative tasks that get abandoned, while Cards' intake barrier makes speculation harder. Both effects are conditional — neither moves rejections driven by code quality, requirements changes, or business decisions.

Cards has the stronger claim on durability. The attribution tree projects each card's cumulative changes against the current state of the project, so "is this work still in place a month later?" is a glance rather than forensic history-digging, and keeping the why on the card means a later reader is less likely to undo the work for the wrong reason. The residual risk is a stale plan that outlives its assumptions; the card signals when a plan needs re-confirming but cannot force the team to heed it. Junie's effect is smaller: the test runner reduces the chance a change is reverted for breaking something, and IDE inspections catch some violations early, but Junie has no mechanism tracking whether accepted work stays valid over time, and its spec-driven plan artifacts help only as a side effect of record-keeping. Neither tool independently re-verifies that work correct last week is still correct this week.

Both products reduce and create cleanup. Junie reduces it when plan mode kills wrong approaches before they become code and the test-and-fix loop catches failures before a human; it creates it when self-verified code that looks correct is not, when parallel branches collide, and through a configuration tax paid later by whoever skipped setup. Cards reduces cleanup through dedicated failure-mode helper agents and an intact on-disk record that makes rescues faster; it creates cleanup primarily through rubber-stamping, where half-checked work merges on the strength of a marker and someone fixes it later. The summary is structurally the same for both: each reduces cleanup only when the team maintains independent verification behind the tool's signals. Without that, the false-confidence effect tends to dominate — and for Cards, in practice, that increase is usually the larger effect.

Junie's honest claim is the guiding pipe: through plan mode, live prompting, persistent guidelines, Agent Skills, and deep JetBrains-IDE integration it lowers the per-attempt cost of steering an agent and keeping it on track, with real but conditional effects on checking through its test runner and code review agent. Cards' honest claim is also guiding, plus checking — through a different mechanism: durable cross-session continuity and review context that make returning to and judging one job cheaper, with a stronger secondary claim on durability. The constraints differ: Junie fits a developer whose bottleneck is specifying and steering agent work inside a JetBrains IDE; Cards fits a developer whose bottleneck is returning to work after a gap or reviewing it without context. They fit together only with one caveat that is a fact, not a ranking: Junie is a JetBrains-IDE agent and Cards is a VS Code-family extension, so one developer running both would be working across two editor surfaces. Where a team runs a VS Code-based editor and some other configured harness, Cards organizes the job around it; where the team lives in a JetBrains IDE, Junie is the agent doing the work, and the overlap with Cards is small enough that the question is which scarcity binds, not which product wins.

Cards and Junie do not compete for the same install slot, so there is no true switch to price: Junie runs inside a JetBrains IDE, and Cards is a VS Code-family extension, so adopting one does not require leaving the other. A developer already split across both editors can add Cards without disturbing a Junie workflow; a developer fully committed to a JetBrains IDE gets no benefit from installing Cards, since Cards does not run there. Where Cards does apply, it costs one extension install on your existing local Git repository — no daemon, no account, no code uploaded to a new service. Card data lives locally at `~/.cards/cards-repos/<card-id>/`, alongside your repository, not inside it. Uninstalling removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program.