How to Use Claude Code and Cursor Together

I use both Claude Code and Cursor every day. Not as a compromise, and not because I haven’t made up my mind — because they cover genuinely different parts of my workflow. For a long time the conversation around these tools has been framed as a competition. Pick one, commit, move on. I think that framing misses the point entirely. Once I started treating them as complementary rather than competing, my productivity noticeably shifted. This post explains exactly how I use them together.

The Basic Principle

The clearest way I can put it: Claude Code is for tasks you’d describe to another developer. Cursor is for work you’re actively doing yourself, with AI assistance alongside you.

That distinction sounds subtle but it changes everything about how you reach for each tool. When I have a task that I could hand off — “write a full test suite for this authentication module,” “refactor this service to use dependency injection,” “add error handling across these API routes” — that’s a Claude Code task. I describe it, I hand it over, and I go do something else. Claude Code works through it autonomously, makes decisions, runs commands, edits files. I come back and review.

When I’m in the middle of writing something myself — a new feature, a tricky function, a PR review where I want a second opinion on a specific block of code — that’s a Cursor moment. I want inline suggestions, I want to highlight a selection and ask a question, I want the AI woven into my active editing session. Cursor is built for that mode of working. Claude Code isn’t trying to be.

Different modes of working. Different tool. Run them both.

A Typical Day

Here’s roughly how a working day looks when both tools are in play.

Morning. I open the terminal and fire up Claude Code. There’s usually something on my list that’s significant enough to delegate entirely: yesterday it was writing integration tests for a data-pipeline service I’d just finished. I described the task, pointed it at the relevant files, and let it run. Claude Code goes off and works — it reads the codebase, decides on test structure, writes the files, runs the tests, and iterates on failures. This takes anywhere from 5 minutes to 30 minutes, depending on the scope.

Meanwhile. I switch to Cursor and work on something entirely separate. This morning that was a new feature in a different part of the codebase. I’m writing the code myself, but Cursor’s inline completions fill in repetitive parts, and when I reach a decision point, I ask it directly in the chat panel. The two tools are running in parallel — in different terminals, with different concerns, no collisions.

Coming back to Claude Code. When the task finishes, I review the diff. This is where Claude Code’s conversational interface earns its keep. I can ask questions inside the same session: “Why did you structure the mocks this way?” or “Can we simplify this setup block?” It explains its reasoning, and if I want changes, I ask for them. The iteration loop stays in one place.

Afternoon. More of the same pattern, scaled down. Smaller background tasks in Claude Code — maybe updating API documentation, or making a consistent change across a set of files. Smaller active work in Cursor — polishing the feature I started in the morning, or fixing a bug that came up in review. The rhythm is parallel rather than sequential, and that’s the whole point.

Managing Context

The main discipline this workflow requires is keeping the two tools separate. The rule I follow is simple: don’t have both touching the same file at the same time.

It sounds obvious, but it’s easy to let it slip. Claude Code is working on a module, and you get curious and open the same file in Cursor to check something. Now you’ve got two processes with potentially conflicting views of that file. If you edit it in Cursor while Claude Code is mid-task, you risk confusing the session or creating a merge situation when Claude Code writes its changes. It’s not catastrophic — git handles it — but it’s unnecessary friction.

A cleaner mental model is to think of Claude Code handling macro tasks and Cursor handling micro ones. Macro: refactoring a whole service, writing a complete test suite, and implementing a feature end-to-end from a spec. Micro: writing the body of a function, adjusting a component’s behavior, fixing a specific bug. There’s naturally less overlap when you frame it that way. Macro tasks tend to be scoped to files or modules you’re not actively working in. Micro tasks are the files you have open right now.

When there is overlap — when Claude Code finishes on a file you then need to work in — just let the task complete, review the diff, and then pick it up in Cursor. The handoff is clean.

The CLAUDE.md and .cursorrules Connection

Both tools support persistent project-level instructions, and keeping both up to date is one of the highest-leverage things you can do for this workflow.

Claude Code reads CLAUDE.md at the start of every session. It’s where you put project conventions, architectural decisions, and things that should always or never be done in this codebase. Cursor reads .cursorrules for the same purpose — it informs inline completions and chat responses with context specific to your project.

The practical implication is that both tools can share the same understanding of your project if you keep these files consistent. They don’t need to be identical — Claude Code CLAUDE.md tends to be more verbose and can include workflow instructions, while .cursorrules: It is typically more terse and focused on completion. But they should agree on the fundamentals: naming conventions, the patterns you use, the patterns you avoid, and the testing approach.

Here’s the kind of thing I put in .cursorrules:

# Project conventions

## Language and runtime
- TypeScript strict mode throughout
- Node 20+, ESM modules only (no require/CommonJS)

## Code style
- Functional components in React; no class components
- Named exports only — no default exports
- Async/await over .then() chains
- Explicit return types on all exported functions

## Testing
- Vitest for unit tests; files co-located as *.test.ts
- Integration tests live in tests/integration/
- Mock at the boundary (HTTP clients, DB), not inside business logic

## Patterns to avoid
- No any type unless absolutely unavoidable; use unknown instead
- No barrel files (index.ts re-exporting everything)
- No mutation of function arguments

## Naming
- Components: PascalCase
- Hooks: camelCase prefixed with use
- Utilities: camelCase
- Constants: SCREAMING_SNAKE_CASE

# Project conventions

## Language and runtime
- TypeScript strict mode throughout
- Node 20+, ESM modules only (no require/CommonJS)

## Code style
- Functional components in React; no class components
- Named exports only — no default exports
- Async/await over .then() chains
- Explicit return types on all exported functions

## Testing
- Vitest for unit tests; files co-located as *.test.ts
- Integration tests live in tests/integration/
- Mock at the boundary (HTTP clients, DB), not inside business logic

## Patterns to avoid
- No any type unless absolutely unavoidable; use unknown instead
- No barrel files (index.ts re-exporting everything)
- No mutation of function arguments

## Naming
- Components: PascalCase
- Hooks: camelCase prefixed with use
- Utilities: camelCase
- Constants: SCREAMING_SNAKE_CASE

That same set of conventions belongs in CLAUDE.md too — perhaps with more explanation of the reasoning behind each one. When both files are up to date, both tools push in the same direction. You stop getting suggestions that violate your conventions, and you stop having to correct the same things repeatedly.

What This Unlocks

The biggest thing this workflow changes is the bottleneck of waiting. Anyone who has used an agentic AI tool on a substantial task knows the experience: you kick off a task, and then you sit there watching it work, occasionally nudging it, mostly waiting. That waiting time is expensive. It’s not just the clock — it’s the context-switching cost of re-engaging with your own work once the AI finishes.

Running Claude Code and Cursor in parallel largely eliminates that. The time Claude Code spends on a task becomes productive time in Cursor, not dead time. By the time I come back to review what Claude Code has done, I’ve moved something else forward. The two streams of work interleave rather than queue.

There’s also a quality effect. Because Claude Code is handling the tasks it’s genuinely well-suited to — autonomous, long-horizon, requiring consistent changes across many files — and Cursor is handling the tasks it’s well-suited to — tight feedback loop, in-context suggestions, working with what you have in front of you — neither tool is being asked to do something it does poorly. You’re playing to the strengths of each.

The combined workflow means you’re rarely blocked. Claude Code is working on something in the background. You’re moving forward in Cursor. The bottleneck of “waiting for AI to finish” largely disappears.

It took me longer than I’d like to admit to stop treating these tools as competitors and start treating them as a stack. If you’re currently using one or the other, I’d genuinely encourage you to try both in parallel for a week. The workflow takes a day or two to feel natural, and then it’s hard to go back to the sequential approach.

If you’re new to Claude Code and want to understand what it actually does before diving in, start with What is Claude Code. And if you want to go deeper on getting the most out of it as a standalone tool, the 7 Claude Code Skills post covers the techniques I rely on most.