Build with Cursor: from agent chat to verified change

The Cursor build section is 22 guides for developers and tech leads who turn an accepted plan into working code with Cursor’s agent. It covers editor features, agent chats, parallel agents, large and multi-repo codebases, and nine scenarios. Every guide ends with evidence (tests, type checks and lint output) that shows the change works without a line-by-line read.

You asked Cursor’s agent for a Stripe webhook handler. It changed six files, reported “all tests pass”, and you cannot tell whether it verifies signatures or edited the tests. This section is for whoever writes that prompt and whoever approves the pull request.

Which Cursor build guide do you need?

Your situation	Start with
You want the everyday editor features	Core features, Tab autocomplete, Inline edit
You hand feature-sized work to the agent	Agent chat workflows, then Agent modes
You need to undo an agent turn	Checkpoints and branching
The codebase is large or spans several repositories	Large codebase strategies, Multi-repo workflows
You want several agents working at once	The Agents Window
You keep retyping the same instructions	Prompt templates, Snippet management, Time savers
You are restructuring tested code	Refactoring strategies

Each scenario guide takes one kind of work from request to proven change:

Scenario	Guide
Untested, callback-heavy code	Refactoring legacy code
Third-party APIs with retries and webhooks	API integrations
Figma frames that become React components	Frontend UI from designs
Docs and diagrams checked in CI	Documentation
Service boundaries and contracts	Microservices
Thinking a design through with the agent	Pair programming
React Native and cross-platform apps	Mobile development
ETL jobs with reconciliation	Data pipelines
Framework or major-version upgrades	Framework migration

How does a build task run in Cursor?

The agent-driven guides follow this order, so you check the result instead of reading it. Set up context and project rules first; the plan comes from Plan with Cursor.

Start from an accepted plan. If you cannot yet state the acceptance criteria, produce the plan first in Plan Mode, which Cursor describes as creating “detailed implementation plans before writing any code”.
Write the failing tests first and approve them. Commit them before implementing, so any later test edit shows up in git diff.
Implement against named gates. The prompt lists the exact test, type-check and lint commands, and the agent runs them until they pass.
Commit each green turn. A commit is the undo point that survives the session; the checkpoints and branching guide covers the undo points between commits.
Report evidence and get an independent review. The agent reports the gate output. Bugbot reviews the pull request, and a fresh agent chat runs the evidence-report prompt below against the acceptance criteria.

Implement the Stripe webhook handler described in @docs/plans/stripe-webhooks.md.

Definition of done:
- The tests in tests/webhooks/ (committed, currently failing) pass.
- npm run typecheck and npm run lint pass with no new warnings.
- Do not edit, skip or delete any file under tests/. If a test looks wrong,
  stop and tell me why instead of changing it.

Follow the handler pattern in @src/routes/billing.ts. Verify the Stripe
signature before parsing the body. Run the three commands after each change.
When you finish, list every file you changed with one line on why.

Do not change any file. Prepare the evidence for this branch:
1. Run npm test, npm run typecheck and npm run lint. Paste the last 10 lines
   of each output.
2. Run git diff --stat main... and flag any changed file under tests/.
3. Map each acceptance criterion in @docs/plans/stripe-webhooks.md to the
   test that proves it. Mark any criterion with no test as UNPROVEN.
4. List anything you assumed that the plan does not state.

How do you trust agent-built code without reading every line?

Read code only where evidence is missing or surprising. A build pull request is ready for review when it carries:

Tests that failed first. Committed before the implementation, failing on the old code.
Untouched tests. git diff --stat for the implementation commits lists no test files. Protect the oracle shows how to enforce this.
Green gates in CI, not only in the agent’s report.
Every acceptance criterion mapped to a test, from the second prompt above. An UNPROVEN criterion is where a human reads code.

The developer who ran the agent owns the evidence; the reviewer approves when it is complete. See reading evidence instead of code and the team-wide evidence bundle.

What goes wrong when you build with Cursor’s agent?

Symptom	Likely cause	Recovery
The agent reports success but CI is red	It ran only some gates, or none	Name every command in the prompt and ask for pasted output
A failing test turned green after an edit to the test	The agent fitted the test to its code	Revert the test file, say “The test is correct; fix the implementation”, and recheck `git diff --stat`
The code works but ignores your conventions	No rule or example in context	Point at a reference file with `@`; add the pattern to project rules
Each correction makes the chat worse	The context is full of failed attempts	Reset to the last green commit; start a new chat with the plan and failing test (agent chat)
Parallel agents edit the same files	Tasks were not split by file ownership	Give each agent its own worktree and task; merge in order (Agents Window)

Where to go after building with Cursor

Agent chat workflows in Cursor The core loop: tests as the definition of done, gates in the prompt, restarts.

Test and debug with Cursor Tests that catch real bugs, and root causes before fixes.

Review and ship with Cursor Code review, Bugbot and CI gates before release.

The same stage for other tools: Claude Code and Codex. The tool-neutral practice lives in build workflows.