Copilot, Cursor or Claude Code: which AI coding tool is actually worth the money in 2026

The conversation almost always starts in the same place: which is better, GitHub Copilot, Cursor or Claude Code?

In January a tech lead put it to me over coffee, slightly embarrassed to be asking at all: "Matteo, the team pays for three different subscriptions. Nobody can tell me what each one is actually for. Do I keep them all?"

His question is the same as yours, with different names on the list.

It is anything but a naive question. It is the right one, asked two years late, because in the meantime nobody had bothered to explain it to him.

In 2026 you no longer ask yourself whether to use artificial intelligence to write code. You ask which one to use, and for what.

The answer you give today decides how much work you can genuinely delegate, how much time you claw back every week, and how much money you are burning on licences you use at a third of their value.

Three tools have defined the categories:

• GitHub Copilot, the most widely adopted, the way in for most developers.
• Cursor, the development environment built around artificial intelligence, which has taken a sizeable share of the professional market.
• Claude Code, the agent that works directly on the files in your project.

Windsurf and the other alternatives deserve a chapter of their own, and they get one.

What you are about to read does not come from a laboratory benchmark, nor from a feature table copied off the vendors' websites.

It comes from real work on .NET: refactoring existing code, adding a new feature inside a solution that already exists, generating tests, hunting a bug, making sense of a repository you have never seen before.

The results change a great deal depending on the task, and that is precisely the part every comparison skips.

Then there is the bill.

Copilot costs around ten dollars a month, Cursor twenty, Claude Code sits inside a plan that can run to a hundred.

If you pay a hundred dollars a month and use thirty per cent of what you bought, you are not investing: you are making a donation to a vendor.

The right choice depends on how you actually work, not on the enthusiasm of someone speaking from a conference stage sponsored by the vendor.

One honest caveat: this is a snapshot of prices as of August 2026.

This market moves fast, some of the features described here may already have shifted to different plans, and prices should always be checked on the official sites before you sign up for anything.

Autocomplete, IDE, terminal agent: the three categories comparisons never separate

Copilot, Cursor and Claude Code end up side by side in the same table, but they do three different jobs: autocomplete inside the environment you already use, a development environment built around the model, and an agent that works on its own in the terminal.

It is the difference between a power screwdriver, a workbench, and the craftsman you hand the piece to.

Three years ago the debate was whether these tools would replace developers.

That debate is over, and it did not end with a dramatic verdict: people who use them well produce more than people who do not use them.

Full stop.

The useful question today is far more practical, and nobody frames it properly because they get the comparison wrong from the very start: they treat the three as if they did the same job, which is exactly why so many teams buy badly.

The first category is intelligent autocomplete inside the environment you already use. You type, and the tool proposes the rest of the line or the method.

GitHub Copilot dominates here, with more than 1.3 million subscribers in 2024 and a presence in every major development environment.

The second is the category of environments built around artificial intelligence, where the model is not an add-on but the centre of the experience.

Cursor invented this category, and Windsurf by Codeium is its main competitor.

The third is terminal agents: programs that work on their own on the filesystem, run commands, read and modify files without you opening a single window.

Claude Code by Anthropic is the reference point, alongside OpenAI Codex CLI and Gemini CLI.

Put side by side, the three categories differ in one thing only, which is how much work you are prepared to delegate:

These three categories are not mutually exclusive.

Plenty of senior developers in 2026 keep two of them open at once and pick according to the task, the way you would with tools in a workshop.

Understanding which category covers which kind of work is the precondition for any sensible choice: without it, all you are comparing is prices.

And your context matters more than anyone tells you.

If you open Visual Studio every morning, the game is different from the one played in VS Code.

If you work on an enterprise line of business system running to hundreds of thousands of lines, your needs are not those of someone building a young product of twenty thousand.

Generic comparisons ignore precisely the variables that decide the answer.

GitHub Copilot in 2026: what it still does better than anyone, and where it leaves you stranded

GitHub Copilot is still the most natural way in for anyone who has not yet built artificial intelligence into the way they work, and the reason is mundane: it does not force you to change anything.

You install it as an extension in the environment you already use, and if you write code for a living you have paid back the subscription within the first week.

Autocomplete as you type, where it is still the best

Copilot's autocomplete today is not what it was in the early days.

It looks at the file you are working on, the files you have open and, in the Business version with workspace indexing, the whole indexed project.

On C# this shows: types, interfaces and ASP.NET Core patterns are recognised accurately.

Inside Visual Studio the integration is the smoothest you will find anywhere for .NET work.

It performs well in C# files, in xUnit and NUnit tests, in CSHTML views and in configuration files.

On nullable types, LINQ chains and generics it is above the competition's average.

Chat and Agent mode

Copilot's chat answers inside the development environment with the context of the open file.

Agent mode, introduced in 2024 and improved through 2025, lets you describe a more involved task that the tool then carries out in several steps.

This is where the party ends, and nobody tells you: Copilot's Agent mode sees less of the surrounding code, plans changes spread across many files worse than Cursor does, and touches the filesystem far more timidly than Claude Code.

For serious agentic work it is not the right tool. Blaming it for that is like blaming the screwdriver for not driving nails.

When Copilot is the honest answer

Copilot is the right choice in four specific situations:

• You work in Visual Studio or JetBrains Rider and have no intention of moving;
• The team is already on GitHub and you need centralised governance;
• The budget for these tools is limited;
• You want something that does not upend your day.

The individual plan costs about as much as a streaming subscription, and you can verify the return in the first week.

The team version costs roughly twice as much per person and adds policy management, team usage tracking and integration with GitHub Enterprise.

If someone tells you this is an expense that needs lengthy consideration, they have never worked out what an hour of your time costs.

GitHub Copilot vs Cursor: when paying twice as much makes sense

The difference between Copilot and Cursor is not a longer feature list. It is that you stop suggesting lines and start assigning tasks.

Forget the idea of a plugin: Cursor is a complete development environment, built on VS Code, where the model is part of the structure instead of being bolted on top.

From that come capabilities an extension cannot replicate, however well written it is.

Composer and Agent mode

The feature that separates Cursor from the rest of its category is Composer, now renamed Agent mode.

Picture the difference between dictating word by word to a colleague and handing them the specification for the job: that is it.

A concrete case on a .NET project, where DTOs are the objects that carry data between layers: "add validation to every DTO in the project using FluentValidation, following the same pattern as the validator I already wrote for OrderDto".

Cursor reads the whole project, finds every DTO, studies the OrderDto pattern and proposes the changes across all the files at once.

You review them in the side by side diff and apply them with one click.

The same job with Copilot takes dozens of manual steps, one at a time, with you acting as the conveyor belt.

Chat that knows the whole repository

Cursor indexes the repository locally, and that changes the kind of questions you can ask.

Ask "why does OrderService depend on CustomerRepository instead of using a domain event?" and you can get an answer that reasons about the architecture you actually wrote, with references to the files where the important parts live.

Here is the moment this feature saves your day: first day on a project with 200 files, the documentation is a README from 2023, and the person who wrote it left a few months ago.

Being able to ask architectural questions and get answers anchored to the code saves days of reading.

Cursor and .NET: the price that is not on the price list

The real limitation of Cursor for .NET developers lies in the foundation it is built on, not in the model.

Moving to Cursor means leaving behind the advanced Visual Studio debugger, the built-in profiler, the diagnostic windows for ASP.NET and native support for WPF and Windows Forms.

If your work rests on those things, Cursor does not replace Visual Studio, and anyone who tells you otherwise has never had to profile a production service at the end of a quarter.

If, on the other hand, you are already in VS Code for .NET, or you are willing to be for your main development sessions, Cursor is clearly more powerful than Copilot on complex work.

Weighing what you lose against what you gain is something only you can do, by looking at what you actually do in a typical week.

Cursor Pro costs twice what Copilot does, and the difference justifies itself on the first serious refactoring: the job that normally eats an hour takes ten minutes in Agent mode.

The rest of the month is profit.

Stop for a second and answer this: could you say right now, without hesitating, which of the three you will use tomorrow morning and what for?

If the answer is slow in coming, the tools are not the problem.

What is missing is the judgement that sits above them, and that judgement is built on a system, with someone telling you where you are going wrong while you are doing it: that is the reason the AI Software Architect Course exists.

It is designed for building .NET systems where AI is part of the architecture, not an accessory stuck on top.

The longer you wait, the more generated code you will have to review with the judgement you have now.

Claude Code: the terminal agent that plans the work instead of suggesting lines

Claude Code is not playing the same game as Copilot and Cursor, and anyone who puts it in the same table is comparing a consultant with a screwdriver.

It lives in the terminal and works directly on the files in your project: it reads, runs commands, edits and navigates the repository with a level of autonomy you decide.

So how does it work?

You start it with the claude command inside the project folder.

You describe what you want, and off it goes: it opens the files it needs, reconstructs the architecture, decides which changes to make and in what order, and carries them out, asking for confirmation when the stakes are high.

It can build, run the tests, commit, install dependencies.

A plugin inside a development environment does not go anywhere near any of that.

The characteristic that matters is multi-step planning. Ask it for a new feature and it does not hand you back a block of code to paste.

It reasons about the context, lists the files to create or modify, accounts for the dependencies between the changes and works through them in order.

This is the work it was built for, and it is also the work that eats your days when you do it by hand.

The three tasks where Claude Code pulls away

Existing code that nobody documented: "explain how authorisation works in this project" produces a reconstruction that walks through the relevant files, recognises the patterns in use and flags what does not add up.

If inheriting other people's systems is your job, this alone changes your month.

Architectural refactoring: "move this system from a hand rolled repository pattern to MediatR", or "extract this module into a separate service following the Strangler Fig pattern".

The advantage here is clear cut: understanding the architecture that exists and planning coherent changes across many files is exactly what the other two do worst.

Tests written from scratch: Claude Code reads the business logic, writes unit and integration tests for the cases that genuinely matter, runs them and fixes the ones that fail.

This is not the boilerplate that fills your test folder and leaves real coverage exactly where it was.

The limitation, put plainly

There is no graphical interface.

If you are not used to the terminal, the rhythm of work will feel awkward for a while, and as an absolute first tool it is the wrong choice.

Not because it is only for veterans: it is because you would be learning to program and to steer an agent at the same time, and neither would go well.

Who it is for is not decided by the price: Claude Code is included even in the entry level Claude plan, and moving up a tier does not buy you extra features, it buys you headroom before you hit the usage limit.

It is decided by how you use it.

For a senior developer or a tech lead working on architectural questions every day, the higher plan pays for itself in the first week; for someone who opens it twice a month, the entry plan is more than enough.

If what you want is autocomplete as you type, Claude Code is the wrong tool at any price: that job is done better, and for less, by autocomplete inside your environment.

Windsurf, Continue.dev and Zed: the alternatives that make sense, and who for

The three big names do not exhaust the market, and in three specific situations you are better off looking elsewhere.

The reason is simple: you have a constraint that Copilot and Cursor were not designed to respect.

Windsurf makes sense if Cursor costs too much, Continue.dev if the code cannot leave the company, Zed if the machine is slow.

In these three situations you are not choosing the best tool, you are choosing the one that fits through your door: you have a constraint that Copilot and Cursor were not designed to respect.

Windsurf, Cursor's direct competitor

Windsurf by Codeium does more or less the same things as Cursor: Agent mode across several files, chat that knows the repository, advanced autocomplete.

The difference is in the price and in the policy on models.

The free plan is more generous than Cursor's, which makes it the cheapest way to work out whether an environment built around artificial intelligence suits you before you reach for your wallet.

On many tasks Agent mode holds its own, although the integration ecosystem and the community are younger.

One factor technical comparisons never take into account: Codeium is a smaller company than Anysphere, which is behind Cursor, and than GitHub, which sits inside Microsoft.

How long the tool will last is a legitimate question. For an enterprise team that has to standardise for three years, it can be the decisive one.

Continue.dev, when the code cannot leave

Continue.dev is an open extension for VS Code and JetBrains that lets you connect whichever model you want, including models running on your own machine through Ollama.

It is the answer for teams with a genuine confidentiality constraint on their code that cannot send it to an external service, or for anyone who wants to cut costs by using local models.

The price of that freedom is configuration: it takes more upfront work than Copilot or Cursor, and the quality of what you get depends heavily on the model you choose.

If you want something that works straight away without thinking about it, this is not the road.

Zed, for those who have left the VS Code ecosystem

Zed is an editor built with speed as an obsession, written in Rust, with artificial intelligence integrated natively.

On machines with limited resources it is noticeably faster than VS Code and Cursor.

The flip side is .NET support: outside the Microsoft editors, C# code analysis and debugging rely on less complete components, and Zed inherits that limitation.

Worth keeping an eye on, not worth adopting as your main editor.

GitHub Copilot vs Cursor, and where Claude Code pulls ahead of both

Every general ranking of these tools is hot air, and the reason is simple: change the task and you change the winner.

So no podium.

Five jobs you genuinely do in a week on .NET, and who handles each one best.

Building out a new feature

You need to add a new endpoint to an ASP.NET Core project, using the structure already in place and preparing the basic tests as well.

GitHub Copilot: with Agent mode it gets a good part of the job done, but unless you give it detailed context it tends to produce files that follow generic patterns instead of yours.

You need to sit there and steer it.

Cursor in Agent mode: this is its element. It takes an existing endpoint as a model, recognises the conventions and generates everything in line with them.

The side by side diff makes review quick before you apply.

Claude Code: a similar result to Cursor, with one addition that counts: it immediately runs the tests it has written and fixes the ones that fail.

That build, run, fix cycle is its advantage.

Call it a tie between Cursor and Claude Code, with Copilot third.

Two: refactoring across many files

You need to rename and move a domain class used in 40 files, update every reference and every dependency injection while keeping the namespaces tidy.

GitHub Copilot: for this job the refactoring tools in Visual Studio or Rider are better than artificial intelligence.

Copilot adds little to a mechanical task the environment already handles well.

Cursor in Agent mode: it copes, though for a pure rename the native tools are more precise.

Cursor starts to earn its keep when the refactoring brings changes in logic with it, not just in names.

Claude Code: when you need to extract a class into a separate bounded context, update every injection point and add the right mapping, contextual planning makes the difference.

On complex refactoring, Claude Code takes it.

When it is just a mechanical rename, stick with the environment's native tools, and that is perfectly fine.

Three: working out why that thing is broken

An endpoint returns the wrong result under specific conditions. You have to find the cause.

GitHub Copilot: in chat it helps you reason if you paste in logs and code.

Its ace is integration with the Visual Studio debugger: contextual suggestions while you step through.

Cursor: chat that knows the repository spares you the constant copying and pasting of fragments.

Being able to ask "show me every place where this value is modified" is extremely convenient.

Claude Code: superior when the bug is architectural.

"Why is this service receiving null values despite the validation?" produces an analysis that follows the flow along the entire call chain, which is precisely the point where you usually lose an afternoon.

Claude Code wins on architectural problems, Copilot when you are already inside the debugger.

Four: writing the tests

You need to cover a business logic service with 15 methods with unit tests, edge cases included.

GitHub Copilot: fine on simple methods, but it stays on the surface: it covers the happy paths and leaves you exposed on exactly the cases that blow up later.

Cursor in Agent mode: better than Copilot on edge cases once you explain the business rules.

Seeing the full implementation of the service helps it considerably.

Claude Code: the best, no argument.

It analyses the logic, identifies the edge cases that matter, writes the tests, runs them and fixes the red ones on its own.

The quality of what is left behind is on another level.

No contest here: Claude Code.

Five: documenting

You need to add XML documentation to the public methods of a library, write the README for a module, explain the less obvious patterns.

GitHub Copilot: on XML comments in C# it is unbeatable. Tag completion is precise and does not slow you down.

For this specific task it is the smoothest of the three.

Cursor: good, but on mechanical documentation Copilot's autocomplete flows better.

Claude Code: excellent on high level documentation and architectural explanations, less suited to filling in line by line comments.

Copilot for comments, Claude Code for architectural documentation.

Five tasks, three different winners. Anyone selling you an absolute winner has not tried all five.

If you want it at a glance, here is the summary:

What Copilot, Cursor and Claude Code really cost: list prices and hidden costs

The prices below are those of August 2026 and they change often: before you decide, check the official sites.

The price list, though, is the easy part. What catches you out sits underneath it.

GitHub Copilot

Individual costs around ten dollars a month, or a hundred a year.

It includes autocomplete, chat and Agent mode, with a monthly cap on requests to the more expensive models.

Business, at nineteen dollars per person, adds centralised policy management, usage tracking, exclusion of specific repositories and integration with GitHub Enterprise.

There is an economic advantage that appears in no table: on Visual Studio, Copilot is natively integrated.

You do not have to buy, learn and maintain a second development environment, and that cost is real even if nobody invoices it.

Cursor

The free plan includes a limited number of monthly requests to the advanced models.

Pro, around twenty dollars a month, gives you monthly credits on the best models and Agent mode with no practical limits for normal use.

Business adds team governance and centralised billing.

Here is where the hidden cost sits: when the monthly credits run out, you carry on paying per request.

If you use Agent mode intensively, the real figure at the end of the month can drift a long way from the twenty dollars on the price list.

Nobody is defrauding you, the usage based model is stated openly. But if you do not know it in advance, you find out from your statement.

Claude Code

Claude Code is no longer available only in the most expensive plan.

It is included in Claude Pro, around twenty dollars a month, and in Claude Max, which starts at a hundred and goes up to two hundred: what changes between the two is not access to the tool but how much you can use it before you hit the limit.

If you work with it every day on architectural tasks, the more expensive plan pays for itself.

If you open it twice a month, the hundred dollar plan is not for you, and nobody should tell you otherwise.

There is still the route of a pay as you go API key, with the tool configured on its own.

Since Claude Code entered the Pro plan, that advantage has narrowed considerably: it only makes sense if your usage is genuinely sporadic and concentrated in a handful of sessions a year.

Do the arithmetic before you go down that road.

Three items no price list shows you, and they change the total:

• on Visual Studio, Copilot is natively integrated, so you are not paying for a second development environment to buy, learn and maintain;
• usage beyond the included credit is no longer a Cursor only issue: since June 2026 Copilot also bills on credits, so with both of them the real end of month figure drifts away from the list price if you use Agent mode every day;
• Claude Code does not require the hundred dollar plan: it is included in Claude Pro, and for occasional use that is enough.

The real sum is done in hours

Comparing ten, twenty and a hundred dollars against each other means nothing.

The only comparison that counts is between what you pay and what you get back.

A four hour refactoring that becomes half an hour is worth far more than a hundred dollars a month to anyone whose hourly cost is above thirty, and that is arithmetic, not enthusiasm.

In 2026 the price of these tools is the least of your problems. The problem is knowing which to use for what, and on that no price list helps you.

A hundred dollar tool used well gives you back more than a ten dollar one used badly, and the difference is made by whoever is steering it.

A hundred dollars a month wasted is a small problem.

The big one is the trajectory: a year of tools used at thirty per cent leaves you exactly where you are now, with more lines to review.

If you want to change direction, the AI Software Architect Course is the way to do it, because it starts from your code and not from a case study.

A software architect who looks at your decisions and tells you where you are going wrong.

Waiting is not free, it is simply a cost that never appears on an invoice.

Junior, senior, team lead or freelance: which AI tool makes sense for you

The variable here is not the technology. It is you: how far along you are, the kind of problems that land on your desk, who holds you to account when something breaks.

Same question, four different answers.

If you are starting out

GitHub Copilot. Minimal learning curve, no change of environment, affordable cost.

You see the return immediately on repetitive work: in an ASP.NET Core project that means the DTOs that mirror the entities, the AutoMapper profiles that map them field by field, the basic tests, the XML comments.

The most powerful option is elsewhere, but nothing else gives you as much while changing so little.

One warning I give gladly, because it is the thing I see damaging more young careers than any other: accepting completions you do not understand feels like speed and is in fact debt.

The tool should accelerate what you already know how to do, not paper over what you have not yet learned.

The difference between the two becomes visible the moment a serious technical interview asks you why you wrote that line.

If you are midway and want to push

Cursor Pro.

Agent mode makes a tangible change to how you approach complex work.

If you already work in VS Code, or are willing to, the step up from Copilot to Cursor pays for itself in the first serious refactoring session: ten dollars more a month is nothing.

If instead you work in Visual Studio and cannot move, Copilot Business remains the practical choice.

Just know that you are leaving something on the table, and that it is a choice, not a life sentence.

If you are senior on complex projects

Claude Code as your main tool for architectural work, with Copilot or Cursor in your environment for the everyday.

The problems that reach you are of a different kind: legacy systems to decipher, refactoring that touches half the project, new features with an impact on modules nobody has looked at in two years.

Claude Code was built for that, and on those tasks the gap is wide.

The practical combination: Copilot or Cursor open all day for autocomplete, Claude Code in the terminal when you sit down to do the hard thing.

If you lead a team

Claude Code, for the work a tech lead actually does.

Assisted code review: "what does not line up in this implementation compared with the pattern we agreed on?".

Onboarding new people: "explain to a newcomer how this system works".

Architectural documentation generated from the code that exists, not from the code you hoped you had.

Then there is the governance side: GitHub Copilot Business for organisation level policies and centralised control. They are two different jobs and you need both.

This is where you see the difference between a tech lead who copes and one who drowns, and you do not see it on the subscription line.

You see it in the ability to decide which work you delegate to the machine and which stays your own judgement.

You build that ability in one way only: someone with more mileage than you looks at your decisions on your project and tells you where you are going wrong.

If you work for yourself

It depends on the volume and the type of client, and for once "it depends" is the right answer.

If you jump from one codebase to another, Claude Code saves you the worst days, the ones where you still do not know where to start.

If instead you work at length on the same projects you know by heart, Cursor Pro is almost always the more efficient choice.

Using two tools together without losing your mind: the two tier workflow

Keeping two tools open looks like indecision, and is in fact how the most effective senior developers work in 2026.

What you need is a rule about when to use what, otherwise you spend the day choosing instead of working.

The two tiers

Tier one, autocomplete in your environment.

Copilot or Cursor for everyday work: quick things, autocomplete as you type, basic tests, documentation.

It stays on in the background, you do not think about it.

Tier two, agent sessions.

Claude Code when you stop for something that needs thought: architectural refactoring, analysis of a system you do not know, scaffolding something large, a bug that refuses to be found.

You open it when you have an objective, not to browse.

That way the two tools do not tread on each other, because they cover different work. The redundancy disappears by itself.

The five minute rule

The practical rule fits in three lines:

• Under five minutes: use whatever you already have open in your environment;
• Over thirty minutes: consider Claude Code;
• Complex but inside the environment, and you have Cursor: Agent mode.

And do not switch horses halfway. Choose before you start, see it through, then judge whether the choice was right for next time.

Changing tool mid task is the most elegant way there is to lose an hour without noticing.

The files that must never end up in the context

There is a practical detail that only surfaces when it is too late. All three tools send your code to an external service to process it.

Environment variables holding credentials, configuration files with API keys, test data with sensitive information: none of that should enter what the tool reads and sends.

All three have a mechanism for excluding files, similar to .gitignore.

Configuring it is the team's responsibility, not something to leave to default settings and good luck.

It is the classic thing that costs ten minutes beforehand and a week afterwards.

GitHub's 55% and McKinsey's 20-45%: what the data says and what it does not

Two numbers do the rounds in every presentation on this subject, GitHub's 55% and McKinsey's 20-45%.

Treat them like a car's official fuel consumption figures: properly measured, but on a route that is not your commute.

Look at them closely before you rest a budget decision on top of them.

The data that exists

The 55% comes from a controlled experiment run by GitHub, published in September 2022 and later written up in a paper with Microsoft Research: 95 professional developers, one single task, writing an HTTP server in JavaScript.

Those with Copilot finished in one hour eleven minutes, those without in two hours forty one.

The 20-45% comes from Unleashing developer productivity with generative AI, McKinsey Digital, June 2023: from 20-30% of time saved on refactoring to 35-45% on writing new code.

On documentation McKinsey reaches 45-50%, which is the most favourable case of all and is, unsurprisingly, the one that ends up in the slides.

They should be taken for what they are.

An HTTP server in JavaScript written from scratch looks nothing like your Tuesday morning inside a .NET solution of three hundred thousand lines: tests under controlled conditions measure clean, isolated tasks, with no meetings in between and no colleague interrupting you with a quick question, and they tend to overstate what happens in real work.

The most interesting data comes from companies that have measured in house.

The biggest benefit, though, lies elsewhere: in the time you no longer lose rebuilding a context you had put down, and in what you save when you land on code you do not know.

How to measure it in your own team

Time the real tasks, before and after. End to end: understanding the problem, writing it, testing it, getting it reviewed.

Typing speed has nothing to do with it.

A method that works: pick five tasks typical of your workflow, for example scaffolding a feature, refactoring a module, writing tests, hunting a bug.

Measure without the tool.

Measure with the tool.

The difference is your real return, not the one in the press release.

Watch out for two distortions: carried along by enthusiasm, we all tend to underestimate how long things used to take, and to overestimate the benefits of a new tool in the first few days.

Measurements worth anything arrive after two to four weeks of regular use.

When the return does not arrive

It is not automatic, and when it is missing the reasons are nearly always the same three.

You use the tool on tasks so simple you were faster by hand.

You never learned the features that matter, Agent mode and repository chat, and you use ten per cent of what you pay for.

Or you use it to help you understand something, rather than to speed it up.

That applies to the code you write yourself, and it applies twice over to the code a model writes for you.

This is also why serious technical training is worth more today, not less.

A multiplier applied to very little stays very little. Applied to solid skills, it puts you in a category of professionals who are rare in 2026 and visible from a distance.

What happens to your code when you use Copilot, Cursor or Claude Code?

No comparison takes on this chapter, and I understand why: it does not help sell subscriptions.

But it is the first thing a CTO or a security lead asks the moment these tools are mentioned in a meeting.

Where does the code go? Who reads it? Is it used to train the models? How long is it stored?

The answers differ from tool to tool, and in an enterprise setting the differences matter.

This is not a detail to postpone until after the purchase: privacy is one of the seven criteria for choosing the AI you program with, not an annex to the contract.

GitHub Copilot: the best equipped on governance

Copilot Individual and Business send code fragments to GitHub and Microsoft servers to generate completions, together with the surrounding context: the open file, the other files in the editor and, with workspace indexing, an index of the repository.

On training, GitHub takes an explicit position: the suggestions generated do not feed the base model, and on Business and Enterprise plans the prompts sent are not retained persistently.

It is in the official terms of service, which are worth reading directly rather than trusting someone else's summary.

Business adds what makes Copilot manageable inside a company: exclusion of files and folders from indexing, centralised per user tracking, organisation level policies, for instance switching off suggestions that reproduce open source code under certain licences, and integration with corporate authentication.

For anyone working with health, financial or public sector data, Copilot Enterprise adds isolated processing, the ability to choose the infrastructure region for data residency requirements, and service levels compatible with an audit.

Cursor: privacy mode and what stays outside your control

Cursor has a privacy mode which, when active, guarantees that your code does not end up in the logs on their servers and is not used to improve the model.

On Business plans it is on by default.

There is one point to understand before subscribing, though.

Cursor does not generate with its own models: it uses third party models, mainly those from Anthropic and OpenAI.

The code you send to Cursor then reaches those providers for processing.

With privacy mode Cursor states that it does not retain it, but the processing still happens on the servers of the underlying models.

If you have strict constraints on where data may travel, this is the point to bring to the meeting.

In practice, for a team: switch on privacy mode from the centralised setting, and put a .cursorignore file in the root of the repository to keep out credentials, production configuration and sensitive test data.

The format is the same as .gitignore.

What to exclude as standard: appsettings.Production.json, .env, certificates, folders with test data containing personal information, any file with production keys or connection strings.

This configuration is standardised once by the platform team, not left to each developer individually.

Claude Code: what changes when the tool reads on its own

Claude Code works locally on the filesystem and sends Anthropic the code it needs.

The rules are those in Anthropic's terms of service: for customers on standard API plans, the code sent is not used to train the models.

The thing to watch is its very nature. Claude Code reads actively to build its context, and in a normal session it can open dozens of files before answering you.

The volume of code leaving your machine in a session is therefore higher than with an autocomplete that only looks at the open file.

That is how it works, and it is legitimate: but you need to know it beforehand, not afterwards.

The tool reads a CLAUDE.md file in the project root and at user level, where you put your project instructions.

That is also where explicit instructions about what it must not read belong. It is a team standard to set before rolling the tool out, not after the first incident.

Put side by side, the three positions on your source code read like this:

The three questions to ask before adopting them as a team

Does the code contain secrets or intellectual property that must not leave the company infrastructure?

Then look at tools that run locally, Continue.dev with local models through Ollama, or enterprise versions with isolation guarantees.

Does the project fall under specific regulations, GDPR, HIPAA, PCI-DSS, NIS2?

Check the provider's certifications and that the contract includes an adequate data processing agreement.

GitHub and Anthropic provide one for Business and Enterprise plans.

Do you work on repositories belonging to clients or partners with confidentiality obligations? Sending that code to an external service may breach the contract you signed.

You check that with your legal people beforehand, not after somebody notices.

Four practices always hold, whichever tool you choose: never send credentials, API keys or connection strings into the context, never use real production data in assisted sessions, configure file exclusion before you start rather than afterwards.

And explain to the team what must never enter the context, because until you have told them it is not obvious to anyone.

The professionals who stand out in 2026 are not the ones with the right subscription.

They are the ones you can hand a system they have never seen and who, within two days, tell you where it will break.

That way of thinking can be taught, and the AI Software Architect Course is where I teach it, on real code rather than on slides.

Start now and in six months you are leading the team. Start in six months and you are watching.

Cursor plus Claude Code, or Copilot plus Claude Code: the two setups that hold up

The two setups that hold up over time differ in one detail only: what you keep open in your environment. Cursor if you are in VS Code, Copilot if you are in Visual Studio. Claude Code in the terminal is the constant in both.

The people who get the best results decided in advance which work goes where, and then stopped thinking about it.

The first: Cursor in the environment, Claude Code for architecture

This is the most common combination among people working on complex .NET projects in 2026.

Cursor covers the day: autocomplete, chat about the code, work across several files of moderate complexity.

Claude Code comes in when you need to understand the whole system at once.

The concrete division: Cursor for implementing new features on components that already exist, for writing tests with the implementation in front of you, for reasoning about the code while hunting a bug, and for refactoring up to ten or fifteen files.

Claude Code for legacy systems with no documentation, for planning architectural migrations, for example from a monolith to separate modules, for end to end tests that require understanding the domain, and for reviewing complicated pull requests.

The second: Copilot in the environment, Claude Code for architecture

If you want to stay in VS Code without changing environment, this combination works just as well.

On paper it costs more, ten dollars of Copilot plus a hundred of Claude Max, but you keep a lighter environment and you give up none of the extensions you have used for years.

The practical advantage is that your day does not change one bit: the configuration you spent years getting right stays exactly where it is.

All you add is a terminal alongside it for the sessions that deserve one.

The people who live in the terminal

A sizeable minority of senior developers, particularly those working on the backend and on infrastructure, use Claude Code as their main tool and open the development environment almost only to navigate the code and use the debugger.

It works, but it requires being genuinely comfortable with the terminal and with describing in words what you want to achieve.

A typical day starts in the terminal. You describe the objective, for example "add multi-tenant support to the authentication service".

Claude Code reads the code, asks you the questions it is missing, proposes a plan and begins, asking for confirmation whenever a change is significant.

You supervise, then open the environment to review and commit.

Bringing someone on board without burning them out

This is where the most common disaster happens, and it is not the fault of the person arriving.

Give a new colleague access to Cursor or Claude Code without explaining anything, and they will use them at surface level: generic questions, no context, and the expectation of a perfect answer first time.

The results disappoint, the conclusion is "it is not worth the money", and the tool goes in a drawer for a year.

A path that works fits into three weeks.

The first, autocomplete as you type and nothing else, no Agent mode and no complex chats: the aim is to find the rhythm without losing control of what ends up in the file.

The second adds chat on the open file for questions about the code, assisted debugging, explanations of patterns you do not know.

The third moves on to complete tasks in Agent mode on contained features, with systematic review before every commit.

The real timescales, since you would discover them yourself anyway: two to four weeks of regular use to be productive with Cursor's Agent mode.

Four to six for Claude Code on architectural work, because there you also have to learn to describe tasks in a way that can be planned.

It is a skill, and like every skill you can learn it on your own by banging your head against it, or with someone telling you where you are going wrong while you do it.

Three rules the best teams paid to learn

Never commit generated code without having read and understood it.

What comes out is a starting point, not a finished product, and reviewing assisted code takes more attention, not less.

Write your project instructions. Cursor reads .cursorrules in the root, now renamed .cursor/rules; Claude Code reads CLAUDE.md.

That is where the conventions go, the architectural patterns you have chosen, the libraries you prefer, the naming rules.

Without that file the tool produces generic code, and you spend your time correcting a style that is not yours.

Keep agent sessions separate from ordinary work. Do not sit all day with Claude Code open: use it in blocks of thirty to ninety minutes, on defined objectives.

The value comes out when you know where you are going, not when you are exploring. None of these tools makes you a better engineer.

They make you faster at being what you already are.

If what you already are is solid, they multiply the work you close in a week.

If it is not, speed only makes the trajectory worse, and it shows sooner than you would think.

Some people spend years chasing the newest tool, and some build the craft underneath and then choose their tools calmly.

You decide which side to be on, but decide now.