Claude Code × Cursor × Devin Desktop (formerly Windsurf): A Practical Hybrid Development Setup

3. Setting Up the Hybrid Environment: Configuration File Sync

The biggest challenge when using three tools on the same project is that each tool maintains its own copy of project context. Claude Code has CLAUDE.md, while Cursor and Devin Desktop each have their own rule files — you need a design for keeping these in sync.

Here's the conclusion up front: I have rewritten this sync script twice. The first time because it broke on its second run, the second time because the tools changed where they read rules from. I'll walk through both, because both failure modes are worth being able to reproduce.

Configuration File Hierarchy

The approach I use is to make CLAUDE.md the single source of truth, then propagate the essence to the other tools' config files.

Project root/
├── CLAUDE.md              ← Primary config (detailed, comprehensive)
├── .cursorrules           ← Cursor-specific (now a legacy format — see below)
├── .windsurfrules         ← Devin Desktop (same caveat)
└── .ai-rules/
    └── shared-context.md  ← Rules shared across all 3 tools (the source)

Example .cursorrules (extracted key points from CLAUDE.md):

# Project Rules for Cursor
 
## Tech Stack
- Next.js 16 (App Router) + TypeScript strict mode
- Tailwind CSS + shadcn/ui
- Cloudflare Workers (edge runtime) — Node.js APIs not available
- next-intl v4 for i18n (ja/en)
 
## Critical Rules
- Don't add 'use client' to server components
- API routes go under /app/api/
- Reference env vars via process.env.
 
## Naming Conventions
- Components: PascalCase (ArticleCard.tsx)
- Utilities: camelCase (formatDate.ts)
 
## Code Style
- Error handling required (try-catch or Result type)
- Async/await only — no Promise.then
- Comments in Japanese

CLAUDE.md is a comprehensive document containing detailed design philosophy, historical context, and complex rules. But .cursorrules is loaded on every completion request, so keep it short — only the rules that truly matter day-to-day.

The Sync Script: The Naive Version Breaks

Syncing three config files by hand gets old fast, so scripting it and wiring it to a Git hook is the obvious move. There's a trap here, though. This is what I wrote first.

#!/bin/bash
# scripts/sync-ai-rules.sh (note: this version has a bug)
set -e
 
PROJECT_ROOT="$(git rev-parse --show-toplevel)"
SHARED="${PROJECT_ROOT}/.ai-rules/shared-context.md"
CURSOR_RULES="${PROJECT_ROOT}/.cursorrules"
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md not found"
  exit 0
fi
 
if [ -f "$CURSOR_RULES" ]; then
  tmp=$(mktemp)
  echo "# === Shared Rules (auto-generated from shared-context.md) ===" > "$tmp"
  cat "$SHARED" >> "$tmp"
  echo "" >> "$tmp"
  echo "# === Cursor-Specific Rules ===" >> "$tmp"
  # strip the shared section from the existing file, keep the rest
  grep -v "=== Shared Rules" "$CURSOR_RULES" >> "$tmp" || true
  mv "$tmp" "$CURSOR_RULES"
fi
 
echo "✅ .cursorrules updated"
echo "✅ .windsurfrules updated"

It looks fine. Run it once and nothing seems wrong.

The trouble starts on the second run. In a scratch directory with a 7-line shared-context.md and a 2-line .cursorrules, running this five times in a row produces:

Nine more lines on every commit. The culprit is grep -v "=== Shared Rules". It removes the heading line and nothing else — the shared rules underneath it survive, and a fresh copy gets stacked on top of them each time.

Worse, .windsurfrules was never touched at all. The success message printed regardless. Diffing before and after showed a byte-identical file. For as long as I trusted that "✅ updated" line, Windsurf alone was reading stale project context.

The part that stings: this bug manufactures Pitfall 4 below (config file bloat). The mechanism I built to prevent bloat was the thing causing it. I only noticed when Cursor's completions started dragging in rules I had deleted weeks earlier.

Making It Idempotent

The fix is straightforward — fence the generated region with markers and replace that whole block every run. Delete by range, not by matching individual lines.

#!/bin/bash
# scripts/sync-ai-rules.sh
# Expands .ai-rules/shared-context.md into .cursorrules and .windsurfrules
set -euo pipefail
 
BEGIN="<!-- AI-RULES:BEGIN -->"
END="<!-- AI-RULES:END -->"
 
PROJECT_ROOT="$(git rev-parse --show-toplevel)"
SHARED="${PROJECT_ROOT}/.ai-rules/shared-context.md"
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md not found" >&2
  exit 1
fi
 
sync_one() {
  target="$1"
  [ -f "$target" ] || : > "$target"
  tmp="$(mktemp)"
  {
    echo "$BEGIN"
    echo "# Auto-generated from shared-context.md. Do not edit directly."
    cat "$SHARED"
    echo "$END"
    # drop only the generated block; tool-specific rules survive
    awk -v b="$BEGIN" -v e="$END" '
      index($0, b) { skip = 1; next }
      index($0, e) { skip = 0; next }
      !skip { print }
    ' "$target"
  } > "$tmp"
 
  if cmp -s "$tmp" "$target"; then
    rm -f "$tmp"
    echo "= $(basename "$target") unchanged"
  else
    mv "$tmp" "$target"
    echo "✅ $(basename "$target") updated"
  fi
}
 
sync_one "${PROJECT_ROOT}/.cursorrules"
sync_one "${PROJECT_ROOT}/.windsurfrules"

Five consecutive runs under the same conditions:

The line count stops moving. "Completions in Japanese" in .cursorrules and "the agent starts from type definitions" in .windsurfrules both survive, because they live outside the markers. Add one line to shared-context.md, re-run, and both files go to 13 lines — the diff propagates exactly as intended.

Three deliberate choices in there:

• set -euo pipefail — catches undefined variables and mid-pipeline failures. Plain set -e let the grep failure disappear into || true
• exit 1 instead of exit 0 — a missing shared file is a misconfiguration. A hook script that quietly reports success removes the only chance you had to notice
• cmp -s for change detection — distinguishing "unchanged" from "updated" makes the log honest enough to actually read

Then register it in .git/hooks/post-commit. If you want to go deeper on hook design itself, I've written up configuring and operating Claude Code Hooks separately.

#!/bin/bash
if git diff HEAD~1 --name-only | grep -q "CLAUDE.md\|shared-context.md"; then
  echo "📝 Syncing AI config files..."
  bash scripts/sync-ai-rules.sh
fi

Judge an automation script by its second run, not its first. That's the most expensive lesson I picked up while wiring three tools together.

Single-File Formats Are Now Legacy in Both Tools

This is what actually caused the morning I described at the top. The idempotent script above worked correctly. It just wrote to a location that was no longer the one being read.

Here's where things stand in 2026. Cursor deprecated .cursorrules in late 2024 in favour of .mdc files under .cursor/rules/. Devin Desktop went the same way: the official FAQ states that .devin/rules/ is the preferred location and takes precedence. .windsurfrules and .windsurf/rules/ are still read for backward compatibility, but only as a fallback. There is no .devinrules single-file equivalent.

"If it's backward compatible, where's the problem?" The problem appears when both exist. I reproduced it in a scratch directory. Put Next.js 16 in the shared rules, run the sync script, then drop a stale .devin/rules/stack.md alongside it.

# The sync script did its job
$ grep -o 'Next.js [0-9]*' .windsurfrules
Next.js 16
 
# But this is what actually gets read
$ grep -ho 'Next.js [0-9]*' .devin/rules/*.md
Next.js 14

The script updates .windsurfrules correctly and reports success correctly. The file being read is the one under .devin/rules/. No diff, no error — just an agent quietly working from stale premises. Pitfall #1 (context inconsistency), manufactured by the very mechanism meant to prevent it.

Moving the Sync to Directory Rules

Here's the rewrite. Output goes to directories, and the generated file is pinned to one fixed name. Hand-written rules live in separate files, which removes the need for markers entirely.

#!/bin/bash
# scripts/sync-ai-rules.sh
# Expand .ai-rules/shared-context.md into each tool's directory rules
set -euo pipefail
 
ROOT="$(git rev-parse --show-toplevel)"
SHARED="${ROOT}/.ai-rules/shared-context.md"
GEN_NAME="00-shared-context"   # the generated file always uses this name
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md not found" >&2
  exit 1
fi
 
# $1=output dir  $2=extension  $3=frontmatter
write_rule() {
  dir="$1"; ext="$2"; front="$3"
  mkdir -p "$dir"
  target="${dir}/${GEN_NAME}.${ext}"
  tmp="$(mktemp)"
  { printf '%s\n' "$front"; cat "$SHARED"; } > "$tmp"
  if [ -f "$target" ] && cmp -s "$tmp" "$target"; then
    rm -f "$tmp"; echo "= ${target#$ROOT/} unchanged"
  else
    mv "$tmp" "$target"; echo "✅ ${target#$ROOT/} updated"
  fi
}
 
write_rule "${ROOT}/.cursor/rules" "mdc" \
'---
description: Project-wide shared context
alwaysApply: true
---'
 
write_rule "${ROOT}/.devin/rules" "md" \
'---
trigger: always_on
---'
 
# Leftover single-file formats cause precedence accidents, so say so loudly
for legacy in "${ROOT}/.cursorrules" "${ROOT}/.windsurfrules"; do
  [ -f "$legacy" ] && echo "⚠ Legacy format still present: ${legacy#$ROOT/} (directory rules take precedence)" >&2
done
exit 0

Five consecutive runs in the same scratch directory, starting from a state that already had hand-written rules (90-local.mdc / 90-local.md) in place:

Neither line counts nor file counts move. Both 90-local files kept their contents intact. Add one line to the shared rules and re-run: 11 and 10 lines, with the diff propagating cleanly. The two counts differ because Cursor's .mdc carries a four-line frontmatter while the Devin side carries three.

And the final loop earns its place. As long as a legacy file survives, every run says so:

⚠ Legacy format still present: .cursorrules (directory rules take precedence)
⚠ Legacy format still present: .windsurfrules (directory rules take precedence)

It took me a few days to clear those warnings. Deleting the files takes a minute. What took days was working out which of the rules inside them were still true. Migration isn't a format conversion; it's an inventory.

What Directory Rules Actually Buy You

If this were only about following a moved file, it would be pure maintenance. The real payoff sits elsewhere. Directory-format rules carry activation triggers in their frontmatter: always-on, when the model decides the rule is relevant, when a file matches a glob, or only when invoked manually.

---
description: Cloudflare Workers constraints
globs: ["src/lib/**/*.ts", "src/app/api/**/*.ts"]
---
Node.js APIs (fs / path / crypto) are unavailable.
Get env from getCloudflareContext() before using the ASSETS binding.

A single-file format loads on every request regardless of relevance. Adjusting CSS ships the Workers constraints along with it. That is precisely what pitfall #4 (config bloat) turns out to be. Once you can scope by glob, bloat stops being a "prune this periodically" problem and becomes a "never load it unless it applies" one.

One more welcome change: Devin Desktop also reads AGENTS.md, and can import Cursor's .cursor/rules .mdc files into .devin/rules/. The era of hand-copying configuration between tools is quietly ending.

4. A Real Example: Three-Tool Collaboration on a Cloudflare Workers Project

Here's a concrete scenario showing how the tools collaborate. Task: "add article management to an existing Next.js + Cloudflare Workers app." This involves Cloudflare Workers-specific constraints (no Node.js APIs, 62 MiB bundle limit, ASSETS binding) — making accurate project understanding critical.

Phase 1: Design with Claude Code

claude "I want to add MDX-based article management to this project.
Give me a design that accounts for the Cloudflare Workers 62 MiB 
bundle limit and ASSETS binding constraints. Reference the 
Content Split Architecture in CLAUDE.md."

Claude Code references CLAUDE.md's "Content Split Architecture" section and outputs a proposal aligned with the existing design. This is Claude Code's defining strength: proposing designs while retaining project-specific constraints as context — a qualitative difference from generic AI chat or other tools.

Phase 2: Implementation with Devin Desktop

Pass Claude Code's design straight through:

[Design Summary]
- content/articles/{ja,en}/{category}/{slug}.mdx
- src/generated/articles.json (metadata only)
- public/content/articles/{locale}/{category}/{slug}.html
- Add getArticleContent() to src/lib/content.ts

[Request]
Following this design, implement in order: type definitions →
generateContent script → content.ts functions → page components.
Show a verification command after each step.

The agent works through the steps while tracking progress, making it easy to see where you are even in long implementations.

Phase 3: Fix Details with Cursor

Reviewing the generated getArticleContent(), you notice it won't work in a Workers environment:

// ❌ Generated code — won't work in Cloudflare Workers
import fs from 'fs'  // Node.js API — unavailable in Workers
 
export async function getArticleContent(slug: string): Promise<string> {
  const filePath = `./public/content/articles/${slug}.html`
  return fs.readFileSync(filePath, 'utf-8')  // Node.js API
}

Select this in Cursor, Cmd+K:

"The fs module isn't available in Cloudflare Workers.
Rewrite this to fetch via the ASSETS binding.
Get env from getCloudflareContext()."

// ✅ Fixed by Cursor — Workers-compatible
import { getCloudflareContext } from '@opennextjs/cloudflare'
 
export async function getArticleContent(
  locale: string,
  category: string,
  slug: string
): Promise<string | null> {
  try {
    const { env } = await getCloudflareContext()
    const path = `/content/articles/${locale}/${category}/${slug}.html`
    
    // Fetch HTML via ASSETS binding
    const res = await env.ASSETS.fetch(
      new URL(path, 'https://placeholder.example.com')
    )
    
    if (!res.ok) {
      console.error(`Failed to fetch article content: ${path} (${res.status})`)
      return null
    }
    
    return res.text()
  } catch (error) {
    console.error('Error fetching article content:', error)
    return null
  }
}

This is where Cursor's "instant inline fix" shines. It's faster than delegating to Claude Code, with minimal context-switching overhead.

Phase 4: Final Validation with Claude Code

claude "Validate the article management feature I implemented:
1. Check for TypeScript compilation errors with tsc --noEmit
2. Verify no violations of CLAUDE.md prohibitions (e.g., self-fetch in Workers)
3. Identify any bottlenecks under production-level load
Fix any issues found."

Because Claude Code knows the overall project design, it can flag "this violates the constraint in CLAUDE.md #74." That's Claude Code's irreplaceable value — no other tool can substitute for it here.

5. Cost Optimization Strategy

Using three tools introduces complexity in cost management. Here's the approach I use in practice.

Real Cost Breakdown (April 2026)

Assuming a solo developer working 40–60 hours per month:

• Claude Code (Max plan): ~$100/month — used exclusively for heavy tasks
• Cursor (Pro plan): ~$20/month — mostly lightweight completions
• Devin Desktop: its entry paid tier — mid-sized implementation tasks
• Total: ~$135/month

This might seem high, but combining the three tools actually distributes token consumption rather than concentrating it. By reserving Claude Code for heavy architectural decisions and keeping Cursor completions lightweight, I almost never exceed the Claude Code Max plan limit.

Reducing Claude Code Costs

# ❌ Inefficient — stuffing too much into one session
claude "Check all components in src/components/,
rewrite all useState to useReducer,
then write tests, then update the docs"
 
# ✅ Efficient — split tasks across separate sessions
claude "Rewrite useState to useReducer in src/components/UserCard.tsx"
# Start a new session for the next component

Proactively using Cursor completions is another lever. "Write anything you can in Cursor, only use Claude Code when truly necessary" — this mindset alone can cut monthly costs by 20–30%.

Devin Desktop Cost Management

Long agent sessions consume more credits, so aim to complete large feature implementations in a single session rather than stopping and restarting repeatedly. Devin Local is up to 30% more token efficient than the old Cascade agent, so a single session now covers more ground than it used to. Always specify completion criteria:

[Task] Implement authentication feature (6 files)
[Done when] All files created, zero TypeScript compilation errors
[Constraint] No Node.js APIs (Cloudflare Workers environment)
[Approach] Type defs → utilities → page components → API routes.
           Report "Moving to [next step]" after each step completes.

Explicit completion criteria prevent the agent from wandering mid-task.

6. Common Mistakes and Pitfalls

Here are the specific problems you're likely to hit when starting with three tools.

Pitfall 1: Conflicting Contexts

When working on the same project across three tools, the contexts can become inconsistent. A classic example: Devin Desktop implements something, then Claude Code flags it as "inconsistent with the CLAUDE.md design." As the previous section showed, sometimes the sync script is simply updating a location nobody reads. When you spot a contradiction, check the read path before you blame anyone's discipline.

Solution: Whenever you change an implementation approach, update CLAUDE.md immediately.

# Make updating CLAUDE.md a post-implementation habit
claude "Append today's implementation decisions to CLAUDE.md:
- Decided to use useReducer for state management in UserCard
- Always construct ASSETS paths with new URL() in Workers"

If CLAUDE.md always reflects "the current correct state," context conflicts between the three tools decrease dramatically.

Pitfall 2: Understanding Generated Code

After "the agent did everything," you may find you barely understand the code. Code quality suffers, and bugs become hard to fix later.

Solution: Always have Claude Code review generated code, and read the important parts yourself. Maintain the stance of "code I understood and chose to adopt" rather than "code the AI wrote."

# Mandatory review after agent implementation
claude "Review the generated authentication feature.
Name 3 important logic points I should understand,
and 2 potential bug risks."

Pitfall 3: Tool Selection Overhead

Using three tools introduces the overhead of deciding "which tool do I use?" For beginners, this judgment can take enough time to negate the efficiency gains.

Solution: For the first month, set a rule: "when in doubt, use Cursor." Cursor is the most general-purpose and can handle almost anything adequately. Only reach for Claude Code or Devin Desktop when Cursor is clearly insufficient. Gradually refine the routing as you build experience.

Pitfall 4: Configuration File Bloat

When config files grow too large, the AI stops following the rules. There are documented cases of AI ignoring older rules in projects where CLAUDE.md exceeded 3000 lines.

Solution: Review config files monthly — "are these rules still valid?" CLAUDE.md is most effective when focused specifically on "prohibitions" and "finalized design decisions."

# Monthly CLAUDE.md maintenance
claude "Review CLAUDE.md and clean up any rules that no longer 
match the current project state, or any duplicates.
Explain your reasoning before removing anything."

Pitfall 5: Security Configuration Gaps

When switching between three tools, security settings can fall through the cracks. Mismatches between Claude Code's permission settings and the file exclusion settings in Cursor or Devin Desktop can lead to unintended file access.

Solution: Align each tool's "excluded files" settings with .gitignore.

# .cursorignore (align with .gitignore)
.env
.env.local
.env.production
**/secrets/**
node_modules/

In Claude Code's CLAUDE.md, explicitly document "never write API keys or credentials directly in code," and exclude MCP server connection details as well.

7. Team Operations Design

While solo developers have more freedom to experiment, teams need to standardize how AI tools are used.

Team-Wide Configuration Management

Manage the .ai-rules/ directory in the repository

.ai-rules/
├── shared-context.md     ← Project rules shared across all tools
├── cursor-rules.md       ← Cursor-specific completion rules
└── claude-code-tasks.md  ← List of tasks well-suited for Claude Code

scripts/
└── sync-ai-rules.sh      ← Propagates shared config to each tool

When a new team member joins, running sync-ai-rules.sh sets up all tool configurations in one shot. Onboarding friction drops significantly.

Sample AI Tool Usage Policy for Teams

Having a simple policy document prevents confusion during team rollout:

• Claude Code: Use for architecture decisions, CI/CD, and code review. Update CLAUDE.md at the end of each session.
• Cursor: Use for daily coding, debugging, and small-scope modifications.
• Devin Desktop: Use for new feature implementations spanning 5+ files.
• Editing shared rules: Only in .ai-rules/shared-context.md. Never touch generated files directly.
• AI-generated code review: A human must verify all AI-generated code before opening a PR.
• Sensitive information: Never pass API keys or passwords to AI tools.

Unified PR Review Workflow

Even when team members use different tools, I recommend standardizing PR review to Claude Code. Reviews aligned with CLAUDE.md design principles eliminate the "different review standards because it was written with an AI tool" problem.

# PR review alias (add to .bashrc / .zshrc)
alias ai-review='claude "Review the changes in this branch.
Evaluate on 4 points: security, performance, type safety, 
and CLAUDE.md rule compliance."'

8. Summary

If there's one thing to do today, take inventory of the rule locations in your repository root.

# See which formats are present
ls -d .cursorrules .cursor/rules .windsurfrules .windsurf/rules .devin/rules AGENTS.md 2>/dev/null

If both legacy and current formats come back, the current one wins. Check whether their contents disagree before anything else — that check is exactly what I skipped, and it cost me half a day.

If only one is present, start by getting CLAUDE.md in order. Once the shared rules have a single source, the scripts in this article can handle propagation.

More than the routing design itself, what has actually returned time to me is a mechanism that confirms all three are reading the same thing. Tool names and file locations will keep moving. Build the setup so you notice when they do — after six months of running this, that turned out to be the piece that mattered most.

The CLAUDE.md section of the Claude Code documentation is a good foundation for thinking about cross-tool configuration sync. If you get stuck deciding how finely to split your rules, the criteria in how I pick Claude Code Skills for daily work transfer directly.

Every script in this article was run five times in an isolated working directory, with line counts and diffs checked, before it went into the post. Before dropping any of this into a real project, run it twice in an empty directory first. Renames and format changes will keep coming; I'd rather be set up not to panic each time.

Thank you for reading.