What Is an AI Coding Agent?

The working pattern for AI coding agent basics is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running AI coding agent basics as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

Cursor's docs describe an agent as three components. Instructions, meaning the system prompt plus your rules. Tools, meaning file editing, codebase search, terminal execution and the rest. And the model you pick for the task. Two of those three are largely the vendor's problem, since Cursor tunes instructions and tools for each model it supports.

Which leaves instructions as the part you own, and it is the part buyers spend the least time on. Model choice gets the argument because it is the visible variable. The rules file is what decides whether a given model produces something your team recognises as its own code, and unlike the model, it does not change under you on a Tuesday.

Tools are the third lever and they are more of a permission question than a capability one. What an agent is allowed to reach matters, I suspect, considerably more than the list of what it could reach in principle.

It means one prompt is not one action. Cursor's docs are blunt about the scale: there is no limit on the number of tool calls an agent can make during a task. Inside a single turn it can search your indexed codebase by meaning, read files including images, edit them, run shell commands, drive a browser and ask you a clarifying question, and while it waits for your answer it carries on reading, editing and running.

So the thing you review is a trail rather than a reply. That is the real difference from chat, or at least the one that changes what you have to do about it, and it is why the diff carries more weight than the summary. A summary is the agent's account of a hundred small decisions. The diff is the dozen that survived into your repository.

Checkpoints exist for the same reason. Cursor snapshots your modified files automatically before it makes significant changes, so you can preview any point in the chat timeline and restore back to it when a run goes sideways.

They are stored locally and kept separate from Git, though, and Cursor's own guidance is to use them only for undoing agent changes and to keep Git for permanent version control. Read that as a limit rather than a footnote. It is an undo button, not a history.

Modes are how much autonomy you hand over for one particular task, which makes "is it an agent" a slider rather than a yes. Plan Mode researches the codebase, asks clarifying questions and produces a plan you can edit before anything is built. ⇧+⇥ rotates to it, and Cursor suggests it by itself when your wording looks like a complex task.

Debug Mode is the one I would point at if someone wanted the whole idea in a single example. It generates hypotheses, adds log statements that report to a local debug server running in a Cursor extension, then stops and asks you to reproduce the bug using steps it gives you. A step that requires a human, deliberately, in the middle of an autonomous loop. Afterwards it reads the real logs, makes a targeted fix and removes its own instrumentation.

Underneath all of them sits Run Mode, which decides when a shell command runs on its own, when Cursor stops to ask you, and when the command enters a sandbox that blocks unauthorized file access and network activity. That setting is the honest autonomy dial, and it is worth deciding before the first task rather than during one.