Cards and Lovable — a comparison

Lovable is honest about starting — turning a plain-English description into a running application for someone who cannot write code. Cards is honest about guiding and checking — keeping one coding-agent job intelligible from plan to commit for a developer who reads diffs. They serve different operators on different units of work and don't compete; a team whose constraint shifts from "no engineers" to "unintelligible engineered work" could use both.

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 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 Lovable pipe by pipe, without ranking them.

In the marketplace ontology, Lovable is a hosted managed-execution system on the Execution Mode and Harness/Runtime Mediation layers, plus the Delivery and Integration layer through its own deployment and connector platform. Cards is a control-artifact and memory/continuity system on the Control Artifact and Memory/Continuity layers, with smaller effects on Delivery and Integration at the repository level. These placements are structural — they decide which pipes each product can plausibly widen.

Lovable is a hosted service that turns a plain-English description of a web application into running software. The operator types or speaks what they want; Lovable's agent explores, plans, builds the front end, back end, database, and authentication, runs browser tests against the result, and either hosts the application or syncs the code to GitHub or GitLab. The operator is a person who wants a web application but cannot write the code — a founder, product manager, marketer, designer, or operations lead. The unit of work is a whole application: one project is an entire piece of software, not a focused change.

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 launch the configured coding agent from that job context. Cards does not run the agent — the harness the developer already uses (Claude Code, Codex, or similar) and the model behind it call the model, edit files, and run commands. But Cards is not a passive notebook either: its default configuration ships actions and skills that direct how the plan forms, how it is stress-tested, how the change is checked, and how it merges. The boundary is execution, not direction. The operator is a professional developer who reads diffs, commits, and plans. The unit of work is one change inside an existing codebase.

Lovable produces running software for someone who cannot produce it themselves. Cards keeps one coding-agent job intelligible to someone who can.

Starting means launching an attempt at all: how many can you kick off, and can you kick off the ones you need?

Lovable's strongest claim lives here. Before Lovable, a non-developer who needed a web application had to learn to code, hire a developer, or accept a template builder's limits. Lovable removes that barrier: someone who can describe an application has a running version in minutes, in an agent mode that explores, plans, and acts without the operator writing code. The starting pipe goes from functionally closed to open for an operator who had no starting mechanism before. The ontology layer is Execution Mode: hosted generation from natural language creates a start where none existed. Two qualifiers matter. A Lovable start is large-grained — one project is a whole application, so starting five in a week means launching five significant software efforts. And starting is metered: the credit system caps each plan's monthly allowance (5 daily credits, 30 per month on Free, 100 on Pro), and an operator at the cap cannot start more until the cycle resets.

Cards' effect on starting is smaller and about seriousness, not speed. The default intake interview draws a vague idea into a written description and plan before the agent runs, so fewer started attempts get abandoned later as never-really-defined. The ontology layer is Control Artifact: the description and plan are durable objects that exist before any session. Cards does not make starting faster and does not let anyone start something they could not start before. A Cards start is small-grained — one change inside a project the operator already has.

A team blocked by lack of development talent is a Lovable team. A team whose started work goes nowhere because it was never well-defined is a Cards team. They do not compete on this pipe.

Guiding is the human work of pointing the agent at the right thing and keeping it pointed there across the life of an attempt.

For Lovable's operator, the guiding inside Lovable is the only guiding available. Steering happens through conversation — "make the header blue," "add a login page" — now also by voice. A prompt queue lets the operator stack up to fifty instructions for sequential execution, reorder them, or pause. Plan mode separates thinking from building: the agent produces a readable plan the operator can edit before code is written. The ontology layer is Harness/Runtime Mediation: the hosted agent accepts natural-language instruction and carries project context across turns. Steering is bound to Lovable's surfaces — chat, voice, a desktop app, a Telegram bot — and each generation costs credits, so an operator near the cap is pushed to accept an imperfect result or batch into fewer, larger prompts. Both degrade steering quality.

Cards lowers the per-attempt cost of re-entering work, the dominant guiding cost for its operator. When a developer returns after a meeting, a weekend, or a handoff, the card already holds the description, the plan sequence, the comments, and the map of what changed; the developer reads the card instead of paging through a transcript. The ontology layer is Memory/Continuity: the card's record survives any agent session, on disk, in git. A smaller effect: because cards are ordinary files, the developer can glance at one on a second monitor or in a terminal without opening the heavy editor — same-machine, different-window, since there is no phone app or shared dashboard.

Lovable enables steering that was impossible for its operator before. Cards makes existing steering cheaper for a developer who already steers agents fluidly and whose real cost is reconstructing context after an interruption.

Checking is whether someone or something independent of the agent that produced the work actually verifies it before it counts.

Lovable offers an automated security scanner — API-key detection, database-access-policy review, code-vulnerability analysis, dependency audits — and a plan-review step. It does not offer independent verification. The model that generates the code produces the plan, runs the scanner's analysis, and supplies the quality judgments the operator relies on; the operator cannot read the code to check it. The ontology layer is Verification and Adjudication, and the gap is structural: no separate reviewer, no independent test authority, no human who can read the source. Browser testing confirms the application runs, not that it is correct, maintainable, or sound.

Cards makes human-led checking cheaper by putting review context on the card. A reviewer opens it, reads the description and the plans written before and during the work, looks at the map of what changed, and forms a judgment without reconstructing intent. But Cards adds advisory markers — "plan approved," "ready to merge" — and the serious failure mode is rubber-stamping: a reviewer clicks the marker without checking the substance, so the workflow records a review that did not happen. Cards lowers the cost of a real check; it does not supply one, and teams must wire independent checks behind the markers or the markers make work look checked while it is not.

Both share a blind-spot problem at different severity. In Lovable the operator cannot perform an independent check at all — fixing it requires a capability the product lacks. In Cards the operator can perform the check but may choose not to. Neither belongs where independent verification is the binding constraint.

Fitting in is connecting a finished piece of work to everything around it without breaking what is already there. The products' different units of work produce the sharpest contrast here.

Cards is built to fit one change into an existing codebase. The running map shows which files a card has touched, so collisions with other in-flight work surface before merge; the default setup gives each card its own isolated working copy. The ontology layer is Delivery and Integration at the repo-native, PR-centric level: Cards reduces the fitting-in cost of not knowing what changed what. It does not run merges, manage releases, or coordinate dependencies.

Lovable generates standalone applications, so fitting in is service-level, not code-level. Its workspace connectors — over forty external services, data-warehouse connectors for BigQuery, Databricks, and Snowflake, Google Workspace and Microsoft 365 — and its GitHub and GitLab sync provide integration paths. The ontology layer is Delivery and Integration at the deployment-and-connector level: Lovable integrates a new service into the organization's portfolio. It does not fit generated code into an existing shared codebase, because it generates whole projects, not incremental changes.

A high-concurrency warning applies to both. Running many Lovable projects in parallel multiplies databases, credentials, connectors, and monitoring, none of which the platform consolidates. Running many cards in parallel multiplies merge surface and collisions faster than the map can track. Neither solves the nonlinear growth of integration cost at scale.

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.

Lovable has a bounded claim, on its enterprise tier. Workspace owners can restrict publishing by role, with editing, approving, and publishing as separate capabilities tracked by audit logs, and group-based access controlling who can act across projects, folders, and published apps. The ontology layer is Authority, Identity, and Trust: a genuine gate on every version published to Lovable's hosting. Its boundary is equally clear — it controls deployment on Lovable's platform, not architectural review, independent security review, or compliance approval the organization runs outside Lovable. Free and Pro tiers have nothing beyond viewer and editor roles.

Cards has nothing to claim here, by design. Its markers are advisory and enforce nothing (with one narrow exception, the final merge marker, treated as a real rule by the system). There is no approval queue, no compliance dashboard, no role-based routing, no place for a compliance officer to log in — the card lives on the developer's computer.

Both leave external authority gates unaddressed. For a team whose binding constraint is a cross-organizational approval gate running outside Lovable's hosting, neither widens that pipe.

Lovable's effect on yield depends on who accepts and for what. For internal tools and prototypes it is probably high — the operator sees it run and deploys it. For customer-facing production software that must meet an engineering team's standards for maintainability, test coverage, and security beyond the scanner's patterns, it may be substantially lower: it runs but is not production-ready by the receiving team's standard. The credit system adds pressure to accept results that would otherwise be refined.

Cards raises yield two ways: the intake interview filters vague attempts before they start, and persistent context removes context-loss rejections — the "I have no idea why this was built this way, send it back" pattern. It does not move rejections driven by code quality, requirements changes, or business decisions.

Both raise yield against different kinds of loss — Lovable by making running results reachable for an operator who had none, Cards by preventing poorly defined attempts and context-loss rejections. The mechanisms are compatible.

For Lovable applications that stay on its cloud and keep iterating through the platform, durability is reasonable: context persists, code is versioned, the operator can refine. For applications handed to an engineering team through GitHub sync, durability depends on whether the team can maintain a codebase they did not write — and on who maintains the dependencies, framework versions, and connector configurations over time. The platform does not answer that.

Cards improves durability by keeping the why attached to the work, so a later reader is less likely to undo it for the wrong reason, and by projecting the attribution tree against the current codebase, turning "is this work still in place a month later?" from forensic digging into a glance. It does not stop an agent from following a stale-but-once-correct plan if the team ignores the signals to re-confirm.

Lovable keeps project-level context in its hosted environment. Cards keeps per-change context on disk where the next developer encounters it. Both improve on workflows where context vanishes.

Lovable's cleanup risk is structural. It enables operators to generate code they cannot maintain independently; each application is real software with real dependencies and security surface. An engineering team receiving a Lovable application may need significant rework before they can support it — the vendor's own prototype-to-production material implicitly acknowledges this handoff. There is also a shadow-IT risk: non-engineering teams deploying applications the organization does not centrally track, creating unknown decommissioning and update obligations. The enterprise tier's publishing controls and audit logs reduce this within the platform but not for handed-off applications. Plan mode, the scanner, and the connectors reduce specific kinds of cleanup.

Cards' cleanup risk is behavioral. Rubber-stamping creates cleanup because half-checked work merges, fails later, and someone must fix it. Cards ships cleanup-reducing mechanisms — failure-mode-detection agents, cheaper rescue of stuck work — but in practice these are normally outweighed by rubber-stamping unless the team wires real independent checks behind the advisory markers. Cards does not reduce cleanup the agent creates by going in circles inside a session.

Lovable's cleanup risk is the operator's inability to maintain what they built. Cards' is the operator's choice to skip a check they could have run. Both demand discipline of different kinds: for Lovable, budget explicitly for the production handoff; for Cards, do not treat advisory markers as real checks.

Lovable's honest claim is starting, with a secondary claim on guiding for an operator who could not steer software at all before; on the enterprise tier it has a bounded claim on approving within its own deployment. Cards' honest claim is guiding and checking — yield and continuity, not raw volume — with smaller effects on starting, fitting in, and durability, and nothing on approving. Lovable matches the team whose constraint is "we have the ideas but not the engineers"; Cards matches the team whose constraint is "we cannot keep our agents' work intelligible, and reviewers cannot judge it without rebuilding the context." They serve different operators on different units of work and do not compete; a team whose constraint shifts from no engineers to unintelligible engineered work could use both, since their ontology layers do not overlap.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Lovable 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 Lovable and nothing Lovable produced that has to be rebuilt to use Cards — a team that syncs a Lovable project to GitHub can put a card around the next change to that codebase without touching how Lovable itself works. Uninstalling Cards removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program.