What is it like to build an app in Cursor?

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 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, Codex, Hermes, and OpenClaw.