What Cursor is genuinely excellent at
Cursor is one of the best pieces of developer tooling built in the last several years. If you disagree with that, this page isn't for you.
It lives in your editor. It reads your full codebase. Its Tab autocomplete predicts your next edit or cross-file refactor — not just the next character. Composer and Agent mode execute multi-step changes across an entire codebase without your hands on the keyboard. Bugbot reviews PRs automatically. Claude Code and Windsurf operate in the same register. These are real tools doing real work.
The buyer Cursor is optimized for is a competent engineer who wants leverage on their own work. It gives them that. Cleanly.
The layer it leaves to you
Cursor writes the code. That's not a criticism — writing the code is most of the work. But when the PR opens, every item on this list is still on your plate.
Version pinning. Cursor generates code that imports whatever library version it was trained on or that you already have. Whether that version has a CVE, whether it matches your other dependencies, whether it's the version you'll be running in production six months from now — that's yours to check.
Source citation. When Cursor calls cookies() from Next.js, it doesn't record which version of the Next.js docs it matched against or whether the API matches the version you're actually running. You trust its training data or you go verify it yourself. Cursor's audit logs capture admin actions, not AI activity — not which docs the model consulted, not which files it read, not which MCP tools it invoked. That provenance trail doesn't exist by default.
Tests. Cursor will write tests if you ask. Some developers build workflows around this consistently. But tests are not generated by default, and the test suite is not run as a merge gate unless you configure that yourself.
Vulnerability and license checks. SPDX license compatibility, CVE scans against the GH advisory database, transitive dependency exposure — Cursor does not run these by default. Cursor shipped a Security Review feature (beta, April 2026) that includes a scheduled vulnerability scanner, but it is opt-in, admin-enabled, and available only on Teams and Enterprise plans. On Free and Pro, and for any engineer whose admin hasn't turned it on, the verification is still yours to configure. Your CI does it, if you've configured it.
Infrastructure. Cursor generates code that runs somewhere. That somewhere is entirely on you: the cluster, the CI/CD pipeline, the Postgres configuration, the TLS, the observability stack, the staging environment, the production isolation. Cursor's Background Agents and Cloud Agents run on Cursor's own AWS infrastructure — Cursor itself flags these as higher-risk. None of your production infrastructure comes with the tool.
The signed merge. When the agent finishes a task and the diff looks good, who checked it? You did, if you did. There's no mechanism that says "a named person with context reviewed this and is accountable for it shipping." That's the engineer, and the engineer is you.
By default, the verification, production infrastructure, and accountability layer is left to the engineer. Cursor has added automated guardrails — Bugbot PR review, cloud Background Agents, and an opt-in Security Review (beta, Teams/Enterprise) — but it does not provide, as a default managed service: deployment to your own production infrastructure, a human sign-off gate, or a re-runnable source-cited provenance trail. None of this is Cursor's fault. It's a tool. Tools don't sign work. People sign work.
Verification: yours to run
Here is what a launch.ist developer-agent commit trail looks like when it surfaces for human review. Path: auth / session.ts · +14 / −9. Commit: a2c91 · 02:14 UTC · signed: engineer reviewed. The diff replaces a synchronous sign() writing directly to document.cookie with an awaited sign() and a server-side cookies().set("sid", token, …) call carrying httpOnly, secure, sameSite: "lax", and a one-week maxAge.
The annotations attached to that diff: cited at L18 — nextjs.org · cookies() · 14.2 docs; verified at L20–22 — owasp cookies cheatsheet · 2024-09; tested at L18–22 — session.spec.ts · 4/4 pass; pinned at the package level — next@14.2.5 · iron-session@8.0.3. Trail archived at /launches/2026-05-14/2a91. Re-run any check months later.
A Cursor diff contains the code. This contains the code plus the record of how every claim in it was checked. The difference is not capability — Cursor can produce perfectly correct httpOnly cookie handling. The difference is whether there's a checkable trail attached to the fact that it was verified.
When an investor asks "how do you know this works," or when a security questionnaire arrives, that trail is the answer. The Cursor diff is not.
Infrastructure: yours to build
Cursor and Claude Code have no infrastructure opinion. That's by design — they're editor tools, and editor tools shouldn't make infrastructure decisions for you.
The practical consequence is that a project built entirely in Cursor ends up on whatever you provisioned yourself: probably a Fly.io app, a Vercel deploy, a Digital Ocean droplet, or a bare EC2 instance. That's fine for a prototype. As the project grows, "fine" is the ceiling you hit.
Every launch.ist project runs on isolated Kubernetes from the first deploy — your own namespace or dedicated cluster, not a shared multi-tenant environment. GitOps, CI/CD pipelines, Postgres with backups, Valkey, MinIO, Grafana observability, TLS, and staged environments. From $59/month.
The DevOps agent provisions all of this. You bring your domain. We handle the rest. This isn't a comparison about coding quality. It's a comparison about what's included when you ship.
Provenance: yours to construct
Cursor doesn't generate a provenance trail. It generates a diff. The diff is in your git history alongside every other diff. If something breaks six months later and you need to know whether the change that introduced the bug was checked against current docs, whether that version of the library had a known CVE, which tests were passing at the time of the merge — that record doesn't exist.
You could reconstruct some of it. You could annotate commits, run your own CVE tooling, keep your own citation notes. Some engineers do. That's significant work, and it's work Cursor expects you to do yourself.
Our provenance trail is generated automatically during the run. Sources cited, versions pinned, verifiers that passed or failed, the human who reviewed and signed. Stored at /launches/<date>/<sha> and designed to outlive the run — re-run any check months later to detect drift.
The trail isn't bureaucracy. It's the answer to "how do you know this works" that exists before anyone asks the question.
The accountability gap
Here is the practical difference between what Cursor produces and what we produce, stated plainly.
When a launch.ist engineer signs a merge, they are putting their name on a record that says: the agent ran these verifiers, the sources checked out, the tests passed, the versions are pinned, and I reviewed it and I am accountable for it shipping. You can find them at the trail URL. You can ask them a question.
When Cursor produces a diff and you merge it, you are the accountable party. That's appropriate if you're an engineer who wants full ownership of the work. It's the correct tool for that situation.
The question is whether you want to own that work, or whether you want to hand it to a team that will own it with you.
Additive, not either/or
This is where we should be honest about something: launch.ist agents are themselves MCP-native. You can run them inside Cursor. The developer agent, the lawyer agent, the DevOps agent — install the MCP server and they appear in your editor alongside whatever model you're already paying for.
This means the framing isn't "Cursor or launch.ist." It's closer to: Cursor provides the in-editor agentic coding environment; launch.ist agents add the verification layer, the provenance trail, and the human signature inside that environment.
If you're already using Cursor and want to add the accountability layer without changing your workflow, that's the integration path. The agents run in your editor. The trail, the pinned versions, the signed merge — those come with the agents, not the editor.
Install the MCP server. Run the developer agent on your next change. The trail surfaces in the same terminal you're already watching.
What it's for and what it isn't
Use Cursor when: you're a strong engineer who wants to own all of the verification work yourself; you're prototyping or exploring and the production trail doesn't matter yet; you want maximum flexibility with no opinions from your tooling; you want fast, in-editor leverage without any additional layer. Cursor is the right tool for this. We mean that.
Use launch.ist when: you've shipped something — possibly with Cursor — and you need a verified, signed, production-grade record of how it holds up; you need production infrastructure from day one, not "I'll provision that later"; a security questionnaire or investor asks "how do you know this works" and "I used Cursor and it looked right" isn't the answer you want to give; you want a named human accountable for the output, not just the tool that produced it.
The honest summary: if you can pass the 2am test — your project breaks at 2am and you have a record of what shipped and a person to call — Cursor is sufficient. If you can't, that's the gap we close.
How the layers compare, on publicly documented behavior as of June 2026 (we re-check quarterly): launch.ist cites sources for every claim; Cursor does not, Claude Code is partial, Windsurf does not. launch.ist pins library versions on output; Cursor, Claude Code, and Windsurf leave that manual. launch.ist runs the test suite before merging; the editors make it optional. launch.ist runs vulnerability and license checks; Cursor does so not by default (Security Review beta, Teams/Enterprise only), Claude Code and Windsurf not at all. A human engineer signs the work at launch.ist; none of the editors do. launch.ist gives you isolated Kubernetes from day one, CI/CD plus GitOps, production infrastructure from $59/month, a re-runnable provenance trail, branches plus a PR workflow by default, and an immutable audit trail; the editors provide none of these (Claude Code keeps a partial audit trail). All four live inside your editor over MCP.
Note on editor AI behavior: Cursor, Claude Code, and Windsurf are in-editor coding tools. They are not infrastructure providers, verification pipelines, or agency services. The "no" entries above are structural — the category doesn't cover them — not capability failures. And the vulnerability-check caveat in full: Cursor shipped Security Review (beta, April 2026) including a scheduled vulnerability scanner; it is opt-in, admin-enabled, and available on Teams and Enterprise plans only — not enabled by default, and unavailable on Free and Pro.
I already use Cursor every day. How does this interact with my workflow? Install the MCP server and the launch.ist agents appear inside Cursor. You can keep your existing Cursor workflow and add the verification layer — provenance trails, pinned versions, CVE checks, human review — on top of it. Nothing about your editor changes.
Cursor can write tests too. Why is this different? Cursor writes tests when you ask. Our developer agent ships tests with every function by default, runs your existing test suite as a merge gate, and surfaces the results in the provenance trail. The difference is default behavior and the audit record. An investor or security reviewer can check our trail; they can't check what Cursor might have generated in a prior session.
I want to own all of my infrastructure. Can I still use launch.ist? Yes. If you have an existing Kubernetes setup or specific cloud commitments, we can work within them. The agents run against your infrastructure; you're not required to use ours. The provenance trail, version pinning, and human review work regardless of where the code runs.
What does "human signs it" mean when a Cursor user reviews their own diffs? When you review your own Cursor-generated diff and merge it, you are the signer. That's legitimate — you're an engineer and you own the work. The difference is that our trail records what was verified before the signature: which verifiers ran, which sources were cited, which versions were pinned. Your self-review is not externally checkable. Ours is.
Do you also support Claude Code or Windsurf specifically? Same answer as Cursor: both are MCP-capable editors, and launch.ist agents can run inside them. The verification layer we add is editor-agnostic.