Chat gives you code to paste. An agent — Claude Code, Cursor's agent mode, and the rest — reads your files, edits them, and runs commands. The leverage is much higher and so is the blast radius, and the habits that made you good at chat prompting will not automatically make you good at this.

Set up the safety net first

Non-negotiable, before your first agent session on a project: it must be under version control, and everything must be committed. An agent that edits eleven files is fine when git diff shows you exactly what changed and git restore . puts it all back. Without that, you are trusting a system you cannot inspect.

Commit between tasks, not between sessions. One task, one review, one commit.

Ask for a plan, then approve it

The single highest-value habit. An agent given a vague goal will start editing, and by the time you see the direction it has touched twenty files.

agent-plan-first.txt
Goal: <what you want to end up with>

Before changing anything, tell me:
1. Which files you'll read to understand this.
2. Which files you'll change, and what changes in each.
3. Anything you're unsure about — ask me now rather than guessing.

Wait for my go-ahead. Don't edit yet.

The plan is also where you catch the misunderstanding. Reading "I'll add a users table" and realising you already have one costs ten seconds; discovering it in a diff costs a rollback.

Scope every task tightly

"Improve the error handling" is a request an agent will pursue across your entire project. "Add error handling to the three functions in upload.js that call the S3 client" is a task it will finish, and one you can actually review.

If you cannot describe what a finished version looks like, the task is too big — split it.

Give it a way to check its own work

This is where agents genuinely outperform chat. An agent that can run your tests, or start your app and hit a URL, can find and fix its own mistakes before you ever see them. If your project has any way to verify itself — tests, a linter, a type checker, even a script that curls an endpoint — tell the agent about it and ask it to run it after every change.

Projects without any verification are the ones where agents flail, because nothing contradicts a wrong assumption.

Read the diff. All of it.

The temptation is to check that the feature works and move on. The problems are rarely in the part you asked for. They are in the file that got reformatted, the dependency that got added, the config value that got "cleaned up", the test that got changed to pass.

If a diff is too big to read, that is information about the task, not about your patience. Revert, split it in half, and run it again.

What to escalate to a human

Agents are least reliable exactly where mistakes cost most: schema migrations, anything touching money, authentication and permissions, deletion of any kind, and infrastructure changes. Use them there — but read those diffs line by line, and have a rollback plan before you deploy.