The comparison posts flooding your feed right now have a problem. They test each tool on different codebases, different tasks, and different complexity levels, then draw conclusions as though they conducted a controlled experiment. They didn't. They tested four different things and called it a comparison.
We decided to do it properly.
Same codebase. Same four tasks. Same evaluation criteria. Thirty days. No sponsorships, no affiliate links, no predetermined conclusion. We run these tools daily on client engagements at Dextra Labs and wanted to know, with actual data, which tool performs best on which type of work.
The codebase: a production Python/FastAPI backend with 47 modules, PostgreSQL, Redis caching, Celery task queues, and roughly 38,000 lines of code. Real-world complexity, not a tutorial project, not a greenfield demo. An existing system with technical debt, inconsistent patterns, and the kind of accumulated decisions that real production codebases carry.
The tools: Cursor Pro ($20/month), Claude Code on Max ($100/month), Windsurf Pro ($20/month), and OpenAI Codex via ChatGPT Plus ($20/month). All tested during June-July 2026 on their latest available models.
The four tasks
We chose tasks that represent the actual work developers do daily, not synthetic benchmarks.
Task 1 - Refactor: Extract the authentication middleware from a monolithic route file into a separate module with proper dependency injection, updating all 14 files that import from it. This tests multi-file understanding, import chain management, and architectural coherence.
Task 2 - Greenfield feature: Add rate limiting to the API with Redis backing, configurable per-endpoint limits, proper HTTP headers (X-RateLimit-Remaining, Retry-After) and comprehensive tests. This tests feature implementation from scratch, including edge case handling.
Task 3 - Bug fix: A reported production bug where concurrent Celery tasks were occasionally double-processing the same job. Root cause was a race condition in the task deduplication logic. This tests debugging ability, concurrency understanding, and fix quality.
Task 4 - Test generation: Generate meaningful tests for the payment processing module, which had 11% coverage. Not just coverage, tests that catch real regressions. We evaluated generated tests by running mutation testing against them.
Scoring methodology
We scored each tool on five dimensions for each task, each on a 1-5 scale.
Correctness: does the output work without modification? Completeness: does it handle edge cases and error paths? Code quality: is the code clean, maintainable, and consistent with existing patterns? Time-to-PR-ready: total time from prompt to a PR we'd actually merge, including our review and fixes. Review overhead: how much human correction was needed after the tool finished.
Total possible score per task: 25. Total possible across all four tasks: 100.
Task 1 results: Refactor
Claude Code dominated this task. It loaded the entire codebase context, identified all 14 files that needed updating, and produced a complete refactor in a single planning pass. The import chain was handled correctly. The dependency injection pattern it chose was consistent with the existing codebase conventions. One minor issue: it renamed an internal helper function unnecessarily, which we caught in review. Time-to-PR-ready: 23 minutes. Score: 22/25.
Cursor handled the refactor well through its Composer agent mode but required two iterations. The first pass correctly extracted the middleware but missed two import updates in files that imported indirectly through a barrel export. After pointing this out, the second pass fixed it cleanly. Time-to-PR-ready: 38 minutes. Score: 19/25.
Codex produced a clean initial extraction but struggled with the import chain complexity. It correctly updated 11 of 14 files. The three it missed were in subdirectories that imported the auth module through a re-export pattern. We fixed these manually. Time-to-PR-ready: 52 minutes. Score: 16/25.
Windsurf's Cascade mode completed the extraction with good coherence, it maintained a single context throughout and the changes were internally consistent. It missed one edge case where a test file imported the middleware directly rather than through the application module. Time-to-PR-ready: 41 minutes. Score: 18/25.
Task 2 results: Greenfield feature
This is where the tools were most evenly matched, and where Cursor's IDE integration gave it a practical edge.
Cursor delivered the most complete implementation. The rate limiting middleware included Redis backing, per-endpoint configuration, proper HTTP headers, sliding window algorithm, and tests that covered the happy path, rate-exceeded path, and Redis connection failure fallback. The inline development experience, writing code, testing in the integrated terminal, iterating on failures, was the most fluid. Time-to-PR-ready: 34 minutes. Score: 23/25.
Claude Code produced the highest quality code architecturally, cleaner separation, better error handling, more thorough documentation, but the terminal-only workflow meant more manual verification. The implementation was excellent but took longer to validate. Time-to-PR-ready: 42 minutes. Score: 22/25.
Windsurf delivered a solid implementation with good test coverage. The sliding window logic had a subtle off-by-one error in the expiry calculation that we caught during review. Time-to-PR-ready: 48 minutes. Score: 19/25.
Codex produced a working implementation but made a security-relevant choice we disagreed with, storing rate limit counters with a fixed TTL rather than a sliding window, which creates a predictable reset point an attacker could time around. Functionally correct, strategically questionable. Time-to-PR-ready: 55 minutes. Score: 17/25.
Task 3 results: Bug fix
The race condition bug was the hardest task and produced the widest performance gap.
Claude Code found the root cause in its first analysis pass. It identified the deduplication logic, recognised the TOCTOU (time-of-check-to-time-of-use) vulnerability, and proposed a fix using Redis SETNX for atomic deduplication. The fix included a test that specifically reproduced the race condition using concurrent task execution. Time-to-PR-ready: 19 minutes. Score: 24/25.
Cursor identified the area of the codebase where the bug likely lived but proposed adding a database lock rather than fixing the deduplication logic. The fix would have worked but was heavier than necessary and would have introduced latency on every task execution. After pointing this out, it proposed the SETNX approach as an alternative. Time-to-PR-ready: 44 minutes. Score: 17/25.
Windsurf struggled with this task. It identified the deduplication module but proposed adding retry logic rather than addressing the race condition itself. The proposed fix would have reduced the symptom frequency without eliminating the root cause. Time-to-PR-ready: 62 minutes after we redirected it to the actual problem. Score: 14/25.
Codex correctly identified the race condition but the proposed fix had its own concurrency issue, it used a Python threading lock in a Celery context where tasks may run in separate processes. The fix wouldn't have worked in the production configuration. Time-to-PR-ready: 58 minutes after we caught and corrected this. Score: 15/25.
Task 4 results: Test generation
Cursor generated tests the fastest and with the highest raw coverage, 87% on the payment module. However, mutation testing revealed that 31% of the generated tests were implementation-detail tests that would pass even with deliberate bugs injected. Effective mutation kill rate: 62%. Time-to-PR-ready: 28 minutes. Score: 18/25.
Claude Code generated fewer tests but with notably higher quality. Coverage reached 78%, but the mutation kill rate was 81%, meaning the tests were genuinely catching bugs, not just executing code paths. It also generated property-based tests for the amount calculation logic, which none of the other tools attempted. Time-to-PR-ready: 35 minutes. Score: 22/25.
Codex generated comprehensive tests with decent coverage (82%) and reasonable mutation kill rate (68%). The tests were conventional and well-structured. No surprises, positive or negative. Time-to-PR-ready: 32 minutes. Score: 19/25.
Windsurf generated tests with 79% coverage but the lowest mutation kill rate at 54%. Many tests asserted that functions returned specific values without testing the business logic that produced those values. Time-to-PR-ready: 40 minutes. Score: 16/25.
The aggregate scorecard
What the numbers actually mean
Claude Code won on total score, but Cursor won on the task most developers do most frequently, greenfield feature implementation within an IDE workflow. The daily experience of writing new code in Cursor is more fluid than any other tool we tested. The tab autocomplete alone is worth the subscription for inline development speed.
Claude Code's advantage is concentrated in tasks that require deep codebase understanding, the refactor, the race condition bug, the high-quality test generation. These are the tasks where the 1M token context window and terminal-native agentic architecture create a measurable difference. If your bottleneck is complex architectural work, Claude Code is the clear winner.
Codex and Windsurf performed similarly in aggregate but for different reasons. Codex is strong on well-defined, straightforward tasks. Windsurf's Cascade provides better contextual coherence on multi-file edits but struggles when the task requires reasoning about concurrent systems or subtle bugs.
What we actually use daily
After thirty days of controlled testing, here's what we landed on: Cursor for daily inline development, feature implementation, quick edits, code exploration. Claude Code for complex refactors, bug investigations, test suite improvements, and any task that benefits from holding the entire codebase in context. We don't use them interchangeably. They're complementary tools for different cognitive tasks.
For teams evaluating these tools, the comparison of Claude Code vs Cursor vs Windsurf covers the feature-by-feature breakdown with recommendations by team size and workflow type.
For enterprise teams evaluating these at scale, the criteria change, data residency, SSO, audit logs, and centralised cost management matter more than accuracy on any single task. We wrote the enterprise-focused breakdown separately because the procurement decision is fundamentally different from the developer experience decision.
Published by Dextra Labs, AI Consulting and Enterprise Agent Development
Top comments (0)