I use three AI coding tools most weeks and they are not interchangeable. That took me a while to work out. For about six months I used whichever one was already open, got inconsistent results, and assumed the variation was in the models. It was mostly in the shape of the task versus the shape of the tool.
The useful distinction is not which model is behind them. It is how much of your codebase each one can see, and who is driving the loop — you or the tool.
Here is how I actually divide work between them, and the workflow habits that made the biggest difference.
Three Different Shapes, Not Three Competing Products
GitHub Copilot is fundamentally about completion inside the editor. It sees your open files and predicts what comes next as you type. The interaction cost is nearly zero — you keep typing and accept or ignore — which makes it excellent for the continuous small stuff and largely irrelevant for anything requiring a plan. Its chat sidebar has grown capable, but the heart of it is still the inline suggestion.
Cursor is an editor built around the model rather than an editor with a model bolted on. The important difference is codebase awareness: it indexes the project, so you can reference files and symbols and get changes that respect what exists elsewhere. Multi-file edits with a diff you approve are its centre of gravity.
Claude Code runs in the terminal and works agentically — it reads files, runs commands, sees the output, and iterates. Nobody is holding its hand between steps. That makes it the right tool for tasks with a verifiable finish line, and the wrong tool for tasks where you want to inspect every line as it appears.
The through-line: as you move from completion to editor to agent, you give up moment-to-moment control and gain the ability to hand over larger units of work. Choosing well means being honest about which of those you want for the task in front of you.
How I Split the Work
Inline completion for the flow work. Writing a function whose shape I already know, filling in a switch statement, adding the next test case in a file of similar tests, typing out a type definition. I want zero interruption and I am reading every suggestion as it appears.
Editor-level AI for changes that span a few files and need to match existing conventions. Adding an endpoint that follows the pattern of five other endpoints. Refactoring a service to use a new interface. Anything where I want to read a diff, argue with it, and apply it selectively.
Terminal agent for work with a clear success condition and a lot of mechanical steps. Migrating a deprecated API call across forty files. Getting a failing test suite green. Bumping a major dependency version and fixing the fallout. Writing tests for an untested module. The common factor is that something other than my judgement can tell whether it worked — the tests pass or they do not.
That last category is where the largest time savings live, and it is the one people use least, usually because handing over a whole task feels riskier than accepting a completion. It is riskier. That is what the verification step is for.
The Habits That Made the Difference
Write the conventions down once. All three tools read repository instruction files. Six lines of project rules cut the "that is not how we do it here" corrections noticeably.
# Conventions
- NestJS modules, one feature per module. No logic in controllers.
- Validate input with Zod at the boundary.
- DB access only through repository classes.
- Check src/common/utils before writing a new helper.
- Tests: Jest, arrange-act-assert, one behaviour per test.
- Never edit files in /generated.
The last line is the kind of thing people forget until an agent helpfully rewrites a generated file.
Commit before you hand over a big task. A clean working tree means git diff shows exactly what the tool did and git checkout . undoes all of it. This one habit turns an agentic run from a leap of faith into a cheap experiment.
Give it a way to check its own work. An agent with a test command is a different tool from an agent without one. "Make this test pass" produces a tight loop with a real signal; "improve this code" produces confident changes nobody can verify. If a repository has no fast test command, adding one is the highest-leverage thing you can do before using agentic tooling on it.
Ask for the plan on anything substantial. "List the files you would change and why, before changing anything." Twenty seconds to read, and it catches wrong approaches before three hundred lines exist.
Scope tightly. "Fix the failing tests in the billing module" works. "Fix the failing tests" invites the tool to wander into unrelated code. Vague scope is the most common cause of a run you end up discarding.
What They Are Still Bad At
Being specific here matters more than the enthusiasm, because knowing the limits is what lets you use them aggressively everywhere else.
Decisions with no local evidence. Whether to add a queue. Whether this belongs in a separate service. Which of two data models will survive the next year of requirements. The tool has no access to the roadmap, the team's capacity, or the political reality of the client. It will confidently produce an answer that is textbook-correct and wrong for you.
Knowing your codebase has already solved this. Improved by indexing, still imperfect. Duplicate utilities creep in quietly and are best caught in review.
Large refactors that require holding an invariant. Anything where correctness depends on a property maintained across many files — a locking discipline, an ordering guarantee, a security boundary. The tool optimises locally and the invariant is global.
Knowing when to stop. An agent asked to improve error handling will keep improving error handling. Bounded tasks with an explicit finish line produce far better outcomes than open-ended ones.
The Review Question Changes
The thing I have had to teach most on my team: when the code was generated, "does this work?" is the wrong review question, because it usually does work for the case in front of you. The useful questions are different.
Does this handle the empty case, the null case, the concurrent case? Does it duplicate something we already have? Does it introduce a dependency nobody evaluated? Is the error path real or is it a catch block that swallows and logs? Would I be able to explain this to someone in six months?
Generated code is fluent. It reads like a competent engineer wrote it, which disables the instinct reviewers rely on. The subtle wrongness is in the middle of well-structured, well-named, idiomatic code — and skimming does not catch it.
Which One Should You Actually Pay For
If you are picking one and you write code in an editor all day, an AI-native editor gives the broadest coverage — inline completion plus multi-file editing in one place.
If you already have inline completion through your organisation and want to add something, add the terminal agent. It covers a genuinely different category of work rather than overlapping with what you have.
And if you are choosing for a team, spend the budget on the tools and then spend an afternoon on the conventions file, the test command and the review guidance. The tooling difference between the options is smaller than the difference between a team that set those three things up and a team that did not.
