What Is Agentic Coding? How the Loop Works in Cursor

Cursor's own definition is short: building software by directing AI agents instead of writing every line yourself. You give an agent a goal, and it plans the work, edits code, runs commands, and verifies the result while you guide and review.

The word that carries the weight there is "verifies". An autocomplete suggests and stops. An agent runs the thing it just wrote, reads what came back, and keeps going. That is the difference the definition points at, and it moves your reviewing onto a finished diff instead of onto each suggestion as it appears.

The definition also sets a precondition that is easy to miss. For the agent to verify anything, something in the repo has to be verifiable: a command that passes or fails, a page that loads or does not. Where nothing runs from a clean checkout the loop degrades into generate-and-hope, and you are back to reading every line by hand. Getting the broken test command working again is unglamorous and probably where the time is best spent.

The loop starts with a prompt that describes the goal and any constraints. From there the agent uses tools to search code, edit files and run the terminal, and it reads each result before deciding its next step. That read-then-decide step is what makes it a loop rather than a single generation.

Cursor is explicit about the input that most changes the output: grounding the prompt in real files and patterns produces better results than describing the change in the abstract. Point at the code you mean. If you want to review the approach before any code is written, run it through Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. first.

The retry row describes the failure people actually hit. An agent that has tried the same fix four times is reading its own four failures as context, so the fifth attempt tends to be worse than the first. Kill the thread and open a new one carrying only what you learned. Letting it run on costs tokens, and it also leaves you a diff shaped by four dead ends, which is the part that takes longest to unpick.

Approvals get half a cell in that table and carry most of the risk in the loop. The setting behind them is Run Mode, which decides whether a shell command runs on its own, stops to ask you, or drops into the sandbox. You are trading interruptions against blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. and no setting avoids both. I would start strict on any repo with deploy scripts in it, then loosen once you have watched which commands it reaches for.

Cursor frames the arrival in three steps. Read them as one scope widening rather than three separate products: each step holds more context and runs longer than the one before it.

1. 1Tab autocomplete handled repetitive edits one suggestion at a time.
2. 2Synchronous agents could hold more context and run longer, so developers directed them through prompt-and-response loops.
3. 3Autonomous agents now take on larger tasks over hours with less direction.

Each step widened the scope of a single instruction, and the scope of a single mistake with it. Step three is the one to read slowly. Less direction going in means fewer moments where you could have said no, not like that.

None of the three replaced the one before it, which the numbering rather hides. Tab is still the quickest way to make an edit you can already picture in full, and a prompt-and-response loop still beats an autonomous run on anything you want to steer every few minutes. All three run in the same working day, and which one fits is a per-task call.

The demand curve is public: Cursor reports agent usage has grown more than 15x in the past year, and tracks the shift across millions of developer sessions in its Developer Habits Report. Cursor's own read of what comes next is agents that run for hours and coordinate with each other, up to codebases that keep improving with little intervention.

That 15x figure measures demand rather than outcome. Usage growing that fast tells you developers keep reaching for agents; on its own it says nothing about whether the code held up or whether review kept pace. Anyone making an internal case with the number should expect the second question, and I would rather walk in with a before-and-after from our own repo.

Cursor uses a second term for the organisational half of this: agentic engineering, which it describes as the industry working out what software engineering looks like when most code is written by coding agents and systems need to be redesigned to take advantage of AI.

It is framed as an evolution of existing practice rather than a replacement, aimed at cutting drudge work and moving engineer time toward higher-value tasks. The example Cursor gives is on-call: speeding up debugging and incident triage so engineers find the root cause faster.

The size of the org changes what that sentence is asking for. On a small team it is mostly the on-call example: one person triages faster, and the practice spreads because other people watch it work. The redesign half only bites once you have systems built around a human writing rate, and those are what bind first: a review queue sized for what people could read, a staging environment one team books at a time. No tool rollout fixes those. That work needs an owner and a quarter.

The starting move is smaller than the term suggests. Open Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. and describe a task in plain language; the agent overview is the reference for what it can reach. Two escalations exist from there, and task size is what decides between them.

Task size is the rough version of that rule, and it is the one I used a paragraph ago. What you are choosing between is how long you can go without a chance to steer. A small change with a vague spec wants Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. more than a big mechanical one does.

Each escalation costs something the table leaves out. Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. on a two-line change means reviewing a plan for a change you could have read faster than the plan itself. Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. on work you have not scoped yet means the run finishes before you learn it went sideways, with no minute-three correction available.

Handing work to a Cloud Agent also has a setup bill, and it comes due before the first run rather than during it. The agent works from a VM, so anything your repo currently borrows from your laptop has to be handed over. That means the secrets it will read, the URLs it may reach if egress controls are on, a checkout that runs without services the VM cannot see, and enough written context in skills or an agents.md for it to test its own changes. Cursor's own framing is blunt about the checkout. If a human cannot test the repo locally, an agent will struggle with it too. The best-practices page lists the checks.