Iro AIWhat you'll be able to do
- Pick the right mode for the size of the change
- Write a rules file that actually changes the output
- Keep the model pointed at the files that matter
- Catch the failure mode that costs most: plausible code solving the wrong problem
Inside the path
A focused set of five-minute lessons. Each one ends with a hands-on exercise, not a quiz you can guess.
Three modes, three jobs 5 min
Inline, Composer, Agent: when each one is the right amount of autonomy.
Rules that survive 5 min
What to put in .cursor/rules, and why long sessions quietly forget it.
Context is a budget 5 min
Pointing at the right files instead of hoping the model finds them.
Reviewing like a skeptic 5 min
Reading generated diffs for what is wrong, not for whether they look reasonable.
Try a sample exercise
This is the kind of card you'd practice inside Iro: you do the thinking, then get feedback.
◆ Sample exercise · Tool judgment
You need to rename a database column and update every usage across about fifteen files, including two migrations and a handful of tests.
Your task: Choose the approach most likely to land this cleanly.
- Use Agent mode with the prompt "rename the column and fix everything", then accept the result once the tests pass.
- Use Composer, name the old and new column, list the migration and test files explicitly, then review each file's diff before accepting.
- Use inline edit in each of the fifteen files one at a time.
- Ask Cursor in chat how to do it, then make all the edits by hand.
See why the second approach wins
The second option wins on two counts. First, Composer shows a diff per file, so you approve fifteen small reviewable changes rather than one opaque result. Second, naming the migration and test files explicitly stops the model guessing at scope, which is where renames usually go wrong. Agent mode with a vague prompt is the expensive failure: passing tests prove the tests still pass, not that the rename was complete or that a migration was not silently rewritten. Inline editing fifteen files is slow and invites you to miss one. Doing it entirely by hand throws away the leverage.
Three modes, and how much rope to give
Cursor offers escalating levels of autonomy, and matching the level to the task is most of the skill.
- Inline edit for a single function or block. You see exactly what changed.
- Composer for changes across several files. It proposes a diff per file and you accept or reject each one. This is the workhorse.
- Agent mode for longer tasks where you want it to read the codebase, run commands, watch output, and iterate. Powerful and the easiest to misuse.
A useful rule: the more files a change touches, the more you want to see diffs rather than outcomes. Agent mode is best on work you could describe precisely to a competent contractor, and worst on work you have not fully thought through yourself.
Rules files, and why they stop working
Rules live in .cursor/rules and tell the model your conventions: the packages you use, the patterns you want, the APIs that are off limits. Good rules prevent the two most annoying agent failures, importing packages that do not exist and using APIs from an older version of your framework.
The catch is that in long sessions, context gets compacted and rules can be silently dropped. If output starts drifting from your conventions halfway through a session, that is usually what happened. Re-mention the rule or the file explicitly rather than assuming it is still in play.
Keep rules short and specific. A rules file that explains standard patterns wastes context on things the model already knows. Spend it on what is unique to your codebase.
Reviewing generated code
Cursor writes faster than you read. That inverts where your time goes, and most people have not adjusted: the bottleneck stopped being typing and became reviewing.
Read a generated diff looking for what is wrong, not checking whether it looks reasonable. Agreeable-looking code is exactly what these models are best at producing. Specifically:
- Does it solve the problem you described, or a slightly different one? This is the most expensive failure and the hardest to spot.
- Did it touch files you did not expect?
- Did it handle the edge case, or add a comment claiming it did?
- Do the tests actually exercise the change, or did the model write tests that pass by construction?
What Cursor does not fix
An AI editor makes a good engineer faster. It does not make an unclear specification clear. If you cannot describe what you want precisely, the model will produce something plausible in the wrong direction, and you will spend longer unpicking it than you would have spent writing it.
The skills that compound here are the same ones that transfer to every model release: specifying constraints up front, reading adversarially, and knowing which tasks are faster done by hand.