What is it like to build in Cursor when every change is a diff?

It is the tightest of the agent loops, because you never leave the editor and you see every change
in place before you accept it. The tradeoff is that the tight loop encourages small steps, which is
excellent for editing a feature and less suited to building a whole one in a pass. The setup that
makes it work is the same as everywhere else: a codebase worth reading, and something to run.

## What changes when the agent is in the editor

Two things, and they pull in opposite directions.

**The feedback is immediate.** You see the change against the code around it, in the file you already
have open, with your own eyes on the surrounding context. This catches a whole class of "technically
correct, wrong for this file" problems that are invisible in a terminal diff.

**The unit of work gets smaller.** Because accepting is one keystroke, the loop pulls toward many
small edits rather than one complete change. That is great for refining and genuinely worse for
"build me this feature end to end", where you want the model, the policy, the controller, the screens,
and the tests to arrive as one coherent set.

The practical answer is to use the wider, multi-file mode for the first pass of a feature and the
inline loop for everything after.

## Have these before you start

**A guide file.** Cursor will read the files you have open and the files it decides are relevant. A
short document stating the non-negotiable rules is the thing that keeps a small edit from quietly
breaking a convention that is enforced three directories away.

**A worked example.** The single most useful thing you can do is open the existing example of the
thing you are building in another tab. Context that is already on screen is context it does not have
to go looking for.

**One command that verifies.** In this codebase that is `bin/check`. Small edits accumulate, and the
risk of the tight loop is that twelve individually reasonable changes add up to something that does
not pass.

## Building a feature

The first pass, in the multi-file mode:

```
Add a Bookmarks resource following the same shape as the example slice:
model, policy, controller, views, routes, and specs.
```

Naming the shape matters more than describing it. "Following the same shape as the example slice"
points at a file that already exists, which is far more precise than any description you could type.

What comes back should touch the model, the migration, the permission policy, the controller, the
screens, the route, and the tests. Read the migration and the policy properly. Skim the rest.

Then the tight loop takes over: adjust the empty state, fix the copy, tighten a validation, add the
one test you actually care about. This is where being in the editor pays.

## The two review habits worth building

**Look at what the diff touched, not just what it says.** The change summary is a description of
intent. The file list is a description of blast radius. When those disagree, believe the file list.

**Run the checks before you accept a run of edits, not after ten of them.** The tight loop makes it
easy to get twelve edits deep before running anything, and then the failure could be from any of
them. Verifying often makes each failure cheap to locate.

## Where it goes wrong

**Context you did not intend.** Having the wrong file open can steer a change. If a suggestion is
oddly shaped, check what is in your tabs before blaming the model.

**Accepting is frictionless, which is the point and the problem.** One keystroke to accept means it
is genuinely easy to accept something you did not read. The files where this matters are the
migration and the permission policy, always. Slow down for those two and move fast everywhere else.

**Small steps hide structural drift.** Twelve good local edits can arrive at a structure nobody would
have chosen deliberately. Every so often, step back and read the whole feature as one thing.

## What it does not change

The [four categories where generated code is plausibly wrong](/blog/what-your-agent-should-not-build)
are no more visible in an editor diff than in a terminal one. Sign-in, payments, email
deliverability, and customer data separation are best solved by already having them, tested, before
the first prompt.

The same loop with other agents: [Claude Code](/blog/building-with-claude-code),
[Codex](/blog/building-with-codex), [Hermes](/blog/building-with-hermes), and
[OpenClaw](/blog/building-with-openclaw).