Understand one turn of the Cursor loop

The Agent sidebar (Cursor’s chat panel, opened with Cmd/Ctrl+I) is where the real work happens, and every task you’ll ever hand it - from a one-line fix to a multi-file refactor - runs through the same small loop: it reads for context, proposes a diff, you review it, and you commit at green. This page watches one complete turn of that loop, end to end, on a small real bug from the course’s illustrative repo, budgetcli - a self-hosted budgeting API that imports transactions from bank CSV exports and, on some statements, records a date on the wrong day. The transcripts below are illustrative, written to show the shape of each beat; the next lesson has you run the same loop yourself. The Codex and Copilot courses on this site drill the same four beats; what’s particular to Cursor is how each one shows up in the sidebar - and the beat that’s genuinely different from a terminal agent is the review.

Read: you describe the bug, it goes looking

You describe the outcome in plain English, the way you’d brief a teammate. You don’t name the file, because you’re not sure which one it is - you inherited this repo:

> the CSV importer is putting some statement dates on the wrong day -
  it looks like it only understands one date format. Make it handle the
  common bank date formats, and add a test that pins the broken case.

Watch where it goes first. You never said src/importers/csv.ts, yet that’s what it opens:

  Searched codebase "statement date" csv          (local index, 7 matches)
  Grepped  Date.parse|new Date                    (2 matches)
  Read     src/importers/csv.ts, tests/csv-import.test.ts  (2 files)

Two things about that first line are worth slowing down on. First, the index it searched is local: Cursor’s codebase search - Instant Grep, as of September 2026 - builds and queries its index on your machine, and Cursor does not upload file paths or code to build a search index, and does not store embeddings of your codebase for search (search docs). The index that just helped the agent find your importer is an artifact on your own disk, not a copy of your repo in the cloud. Second, notice what the search keys on: the concrete nouns in your prompt - statement, date, csv - not a file path you were supposed to remember. You don’t pick the search tool; the agent does. Broad asks like yours start with a codebase search, exact symbols get grepped, and a real task chains both - search to find candidates, reads to confirm them, grep to trace references. The reason this matters on day one: on a repo you didn’t write, you don’t know where the date parsing lives either - and the agent going to look is exactly the help you’re here for. It read the existing test too, so anything it adds matches the house style instead of inventing its own.

Propose: a diff, staged in the sidebar

Having read enough, it proposes. On Cursor that proposal isn’t a sentence in a terminal - it’s a set of inline diffs rendered right in the files, red for removed lines and green for added, gathered into a review bar in the Agent sidebar. One task, two files touched:

  src/importers/csv.ts
    - const parsed = new Date(Date.parse(`${day}/${month}/${year}`));
    + const parsed = parseStatementDate(dateStr);
    + // parseStatementDate tries the common bank formats in order,
    + // throwing if a row matches none.

  tests/csv-import.test.ts
    + it("parses dmy statement date to correct day", () => {
    +     // the format that was previously silently mis-parsed
    +     ...

Two beats are done - read, then propose - and the diff is sitting in your tree as a proposal you can read line by line before any of it is yours. That’s the same “treat every change as a proposal, not a result” discipline the rest of the course leans on; Cursor just gives you the diff to look at instead of a summary to trust.

Review: you drive it with Keep and Undo

Here is the beat that’s distinct from a terminal agent, and the one worth getting right. Cursor’s agent writes its edits to the files as it works, then hands you a review surface to accept or reject them - not a yes/no gate before each write, but a diff you adjudicate after. The review bar gives you Keep and Undo per change (and a Keep All / Undo All for the whole batch; exact labels as of September 2026 - the checkpoint mechanism under them is documented on the Agent overview page), with next-file / previous-file navigation to step through every hunk. So you read the diff before you keep it - and on inherited code holding your own money, that read is the whole point:

> walk the importer diff - does anything touch how amounts get parsed?

You’re reading for two things: does the change do what I asked, and did it do anything I didn’t ask. For a date fix it’s a thirty-second read, but the time isn’t the point - never skipping it is. Look for the failures this domain breeds: a test that passes because it asserts the wrong day, or a date “fix” that quietly drifts into how an amount gets parsed while it’s in there. (Money in budgetcli is stored as integer cents, and the original author wasn’t consistent about it - so any edit near the money path is the thing to catch.) Satisfied with the importer hunk, you Keep it; the test hunk you read and Keep too. Anything off, you Undo that hunk and re-ask rather than patching a fix on top of the agent’s mistake.

One Cursor-specific habit goes with this: because edits land on disk as the agent works, don’t let a large unreviewed batch pile up. Review in small bites and the red/green diff stays something you can actually hold in your head; let twelve files of changes accumulate and “review” quietly degrades into rubber-stamping. Small turns, reviewed as they land, is how you keep the leash short.

Commit: lock in the green

Reviewing only tells you the change is good. It doesn’t make it safe - until you commit, everything you just kept is sitting in your working tree, one bad next prompt away from being tangled or lost. So before you move on, confirm it’s actually green and commit. You can have the agent do both:

> run the importer tests, and if they pass commit with a sensible message

  Ran  npx vitest run tests/csv-import.test.ts                       (2 passed)
  Ran  git commit -am "Parse multiple bank date formats in CSV importer"

Commit at every green checkpoint - git is the floor that doesn’t vanish (you’ll build this habit in your first change).

The engine under the beats, once in slow motion

Before the beats become muscle memory, it’s worth seeing the machinery under them once in generic form. This stepper traces a different small fix through the loop: gather is your read beat, each act is an edit that in Cursor would land in the review bar as a red/green hunk waiting for your Keep, and the failed verify in the middle is precisely why the commit waits for green:

Step 1 / 8You hand over a task

Reset← BackNext →

you→gather context→act→verify↺→done

> The login test is failing on main. Fix it.

(prompt enters the window)

Your message lands in the context window. In this illustrative run, the model starts by reproducing the failure so it has evidence to investigate.

One loose end from the stepper’s closing note: everything the agent read, ran, and edited in that turn stays in its context window for the rest of the chat - later lessons cover managing what accumulates there and what it costs. The next lesson keeps the focus on the loop itself: you’ll run this same date-bug fix yourself, start to finish, with your hands on the review and the commit - the same four beats, this time with you driving.