
Key takeaways
- We moved from GitHub Copilot to Cursor with Claude because the Copilot we used at the time, with its limited context and single file focus, could not handle multi file features, large refactors or architecture reasoning. Copilot has since added agent mode and a coding agent.
- Cursor puts AI at the IDE level: agent mode edits many files from one prompt, chat reads the whole project, and every suggestion arrives as a reviewable inline diff.
- Claude became our primary model for deeper reasoning, fewer hallucinations on architecture, more production quality code and test suites that need fewer corrections.
- The team switch took two to three weeks, eased by Cursor being built on VS Code, so keybindings, extensions, themes and settings all carried over.
- After three months, scaffolding was roughly 40% faster and test generation time dropped by about 50%, while complex refactors went from hours to minutes.
We Were Early Adopters of GitHub Copilot
When GitHub Copilot launched in 2021, our team at RG INSYS signed up on day one. As an AI first software engineering company, we saw the potential immediately. An LLM that could autocomplete code, suggest entire function bodies, and generate boilerplate in real time? That was exactly the kind of tool we wanted in our stack.
For the next two years, Copilot was part of our daily workflow. Every developer on the team used it. We built internal guidelines around it, learned how to write comments that produced better suggestions, and integrated it into our onboarding process for new engineers. Copilot became as natural as syntax highlighting.
What Copilot Does Well
To be fair, Copilot is excellent at what it was designed to do. Its strengths are real and worth acknowledging:
- Inline completions are fast and frictionless. You type a few characters, and a gray suggestion appears. Press tab and move on. The speed of this interaction is hard to beat.
- Boilerplate generation saves real time. Writing repetitive code like API route handlers, model definitions, or test setup blocks becomes significantly faster.
- It works inside VS Code natively. There is no context switch. No separate window. It just lives in the editor you already know.
- Pattern matching across your open file is solid. If you define a function for one entity, Copilot can often generate the equivalent for a similar entity without being asked.
For small, contained tasks, Copilot is genuinely excellent. We still use it for quick inline completions when we are writing code that follows predictable patterns. But as our projects grew in complexity, we started hitting its ceiling.
Where Copilot Started Falling Short
The limitations became obvious on larger projects. Three problems kept surfacing:
Limited context window. The Copilot we used primarily saw the file you were working in and a few recently opened tabs. It did not understand the entire codebase. When we were building a feature that touched a database schema, an API layer, a service module, and a frontend component, Copilot could only see one piece at a time. Its suggestions were often locally correct but globally inconsistent.
No multi file awareness for edits. When we needed to rename a type across twelve files, restructure a module boundary, or move a utility function and update all its imports, the Copilot of that time could not help. It operated at the single file level, so complex refactors still required fully manual work. That has changed: Copilot now offers agent mode in the IDE, which decides which files to change, edits them and runs commands, and a coding agent that prepares pull requests for review. We have not rerun our comparison against those features, so treat this section as the reason we switched, not a verdict on Copilot today.
Shallow reasoning on architecture decisions. When we asked Copilot (through its chat feature) to help design a service layer or evaluate trade offs between two approaches, the responses were often generic. They lacked the depth needed to make real engineering decisions on production systems.
"Copilot was an incredible autocomplete engine. But we needed something that could reason about our codebase as a whole, not just the file in front of us."
Discovering Cursor: AI at the IDE Level
We first tested Cursor in mid 2024. What immediately stood out was that Cursor is not just an editor plugin. It is an entire IDE built around AI interaction. The difference is fundamental.
In Cursor, the AI model has access to your full project. You can reference files, folders, and documentation directly in your prompts. Agent mode allows you to describe a change in natural language and have the model edit multiple files simultaneously, showing you a diff for each one before you accept.
Here is what changed for our team:
- Multi file edits in a single prompt. We could describe a feature and watch the model create or modify files across the frontend, backend, and tests, all in one pass.
- Codebase aware chat. When we asked "how does the authentication middleware work in this project," the model could actually read the relevant files and give a specific, accurate answer.
- Inline diffs for every suggestion. Instead of accepting a gray autocomplete blindly, we review a proper diff. This makes it far easier to catch errors before they enter the codebase.
- Terminal integration. The AI can see terminal output, error messages, and logs. When a build fails, you can ask "why did this fail" and get an answer grounded in the actual error, not a generic guess.
The combination of these capabilities meant that Cursor was not just a faster autocomplete. It was a genuine collaborator that could reason about our projects at the level our engineers do.
Why Claude as the Model
Cursor supports multiple LLM backends, but we settled on Claude (from Anthropic) as our primary model. The reasons came down to practical experience across dozens of projects:
Deeper reasoning on complex tasks. When we ask Claude to design a database migration strategy, evaluate the trade offs of a caching approach, or refactor a tangled service layer, it produces responses that reflect genuine understanding of the problem. It considers edge cases, warns about pitfalls, and proposes alternatives without being prompted.
Fewer hallucinations on architecture. With previous models, we frequently received confident but incorrect suggestions, especially around library APIs and framework conventions. Claude hallucinates less often in our experience, and when it is uncertain, it tends to say so rather than fabricate an answer.
Better at generating complete, production quality code. Claude consistently produces code that is closer to what our engineers would write by hand: proper error handling, sensible naming, correct types, and appropriate abstractions. The gap between "AI generated" and "human written" is noticeably smaller.
Strong performance on test generation. Test suites generated by Claude require fewer corrections. It handles edge cases, boundary conditions, and error scenarios more thoroughly than other models we have tested.
The Transition: Two to Three Weeks
Switching the entire team from Copilot in VS Code to Cursor with Claude was not instant, but it was faster than we expected. Here is how it went:
Week one: Half the team switched to Cursor while keeping Copilot active as a fallback. Engineers spent time learning the agent workflow, understanding how to reference files in prompts, and adjusting their habits from "wait for autocomplete" to "describe what you want."
Week two: The remaining engineers switched over. We held two internal sessions where early adopters shared tips, common prompt patterns, and mistakes to avoid. By the end of this week, everyone was comfortable with the core workflow.
Week three: We refined our internal guidelines, documented best practices for Cursor prompts, and established conventions for when to use agent mode versus inline chat versus inline edits. At this point, the transition was effectively complete.
The learning curve was gentler than expected, primarily because Cursor is built on VS Code. Keybindings, extensions, themes, and settings all carry over. The editor feels familiar. The AI integration is the new part, and that is the part our team was already eager to learn.
Measurable Productivity Impact
After three months of using Cursor with Claude as our primary setup, we tracked the impact across several dimensions:
- Scaffolding speed improved by roughly 40%. Setting up new modules, API routes, database models, and frontend components takes significantly less time when the model can generate across multiple files at once.
- Test generation time dropped by about 50%. Claude produces comprehensive test suites that need fewer corrections, so our engineers spend less time fixing generated tests and more time reviewing them.
- Documentation quality improved. We now use Claude to generate inline documentation, API docs, and README files as part of the development process. The quality is high enough that it rarely needs more than light editing.
- Complex refactors went from hours to minutes. Tasks that previously required manual edits across dozens of files, like renaming a core type, restructuring a module, or updating an API contract, can now be completed in a single agent session.
- Fewer context switches. Because the AI understands the full project, engineers spend less time jumping between files to remind themselves how things connect. They describe the intent and let the model handle the navigation.
What We Still Use Copilot For
We did not abandon Copilot entirely. Some of our engineers keep it enabled alongside Cursor's built in completions for specific use cases:
- Quick inline completions when writing straightforward, repetitive code. Copilot's tab to accept flow is still the fastest way to complete predictable patterns.
- Single file edits where the change is small and localized. Not every task needs the full power of agent mode.
The key insight is that, in our workflow, Copilot and Cursor serve different needs. We use Copilot as a fast autocomplete engine and Cursor with Claude as a reasoning partner. The best workflow uses both where each excels.
The Broader Lesson
AI coding tools are evolving at an extraordinary pace. The tool that was best in class eighteen months ago may not be the best choice today. Teams that lock themselves into a single tool and stop evaluating alternatives fall behind gradually and then suddenly.
At RG INSYS, we allocate time every quarter to evaluate new tools, models, and workflows. This is not a distraction from delivery. It is how we ensure that every project we take on benefits from the most capable tools available at that moment.
Our recommendation is simple: use the best tool for each task, not just one tool for everything. The AI landscape rewards teams that stay curious, test new approaches, and adapt their workflows based on evidence rather than habit.
Frequently asked questions
Why switch from GitHub Copilot to Cursor?
Switch when your work outgrows single file autocomplete. In our experience the Copilot we used at the time mainly saw the current file and a few open tabs, could not coordinate edits across many files, and gave generic answers on architecture. Cursor gives the model access to the full project, edits multiple files from one prompt and shows a diff for each change before you accept it.
How long does it take a team to move from Copilot to Cursor?
It took our team two to three weeks. In week one, half the engineers switched while keeping Copilot as a fallback. In week two, everyone else switched and early adopters shared tips in internal sessions. In week three, we documented prompt conventions and when to use agent mode versus inline chat. Cursor's VS Code base kept the learning curve gentle.
What productivity gains did Cursor with Claude deliver?
After three months, scaffolding speed improved by roughly 40% and test generation time dropped by about 50%. Complex refactors, such as renaming a core type or updating an API contract, went from hours to minutes in a single agent session. Documentation quality also improved, and engineers made fewer context switches because the model understood the whole project.
Is GitHub Copilot still useful alongside Cursor?
Yes, for quick inline completions on predictable, repetitive code and for small single file edits. Some RG INSYS engineers keep Copilot enabled alongside Cursor's built in completions because its tab to accept flow is still the fastest for routine patterns. In our workflow Copilot serves as a fast autocomplete engine, while Cursor with Claude works as a reasoning partner.
Sources and further reading
- Cursor Agent, Cursor. Official documentation of Cursor Agent, which searches the codebase, edits multiple files and runs terminal commands.
- Models & Pricing, Cursor. Lists the Anthropic, OpenAI, Google and other models available inside Cursor.
- About GitHub Copilot, GitHub Docs. Official overview of GitHub Copilot features, from inline suggestions to agentic tasks.
- Using agent mode in your IDE, GitHub Docs. Describes Copilot agent mode, which chooses files to change, makes multi file edits and runs commands.
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, Peng et al. arXiv (2023). Controlled experiment in which developers with Copilot completed a coding task faster than a control group.
Related Articles
- How LLMs Actually Improve Engineering Productivity
- The AI Native Software Company: What It Means and Why It Matters
- AI Led vs Traditional Software Development: What Actually Changes
Want to see what an AI native engineering team can deliver?
Get a free scope, timeline, and cost estimate within 48 hours. No commitment required.
Book a Free Consultation