Claude Code vs Aider on Same 10 Tasks — One Finished 8, the Other 5
I picked ten tasks I’d already scoped out for a real project and ran each one twice: once through Claude Code, once through Aider. Same repo, same prompts, same Sonnet 4.6 underneath. Different endings.
Claude Code finished eight. Aider finished five. What stuck with me was which three tasks Aider failed on while Claude Code cleared them, plus the one task Aider quietly won that I hadn’t seen coming.
Both tools work. What follows is a per-task readout so you can see where each one bends.
The ten tasks
I mixed shapes on purpose. Vibes benchmarks (a big repo + “make it better”) tell you almost nothing. Task shape matters more than model choice.
- Bugfixes (3): null-pointer in auth middleware, race condition in cache invalidation, off-by-one in pagination
- Refactors (3): extract a service class out of a fat controller, dedupe scattered error handling, migrate class components to hooks
- Greenfield (2): SQLite-backed migration CLI, sliding-window rate-limiter middleware
- Migrations (2): Jest → Vitest, axios → fetch
Both agents used Claude Sonnet 4.6. Aider ran in architect mode with Sonnet 4.6 as the architect and Sonnet 4.6 also as the editor. I kept the models identical on purpose so anything that diverged could only be pinned on the harness. Claude Code ran with Plan Mode on for planning-heavy tasks and off for the trivial bugfixes.
The scoreboard
| Task | Claude Code | Aider | Notes |
|---|---|---|---|
| Bug: null-pointer auth | ● | ● | Both one-shot |
| Bug: cache race | ● | ● | Aider slightly cheaper |
| Bug: pagination off-by-one | ● | ◐ partial | Aider fixed the query, missed the boundary test |
| Refactor: extract service | ● | ✕ | Aider lost the controller context on turn 3 |
| Refactor: dedupe error handling | ● | ● | Aider was faster |
| Refactor: class → hooks | ● | ✕ | Props drilling broke; Aider stopped mid-file |
| Greenfield: migration CLI | ● | ● | Both worked, different shapes |
| Greenfield: rate limiter | ◐ partial | ✕ | Both failed the burst edge case, Claude Code got closer |
| Migration: Jest → Vitest | ● | ● | Aider was noticeably faster here |
| Migration: axios → fetch | ◐ partial | ✕ | Both left the interceptor layer inconsistent |
Legend: ● complete · ◐ partial · ✕ failed
Counting only clean passes: Claude Code 8, Aider 5.
If you’re grading generously (accept partials as complete-enough), it’s 10 vs 6. The ranking doesn’t flip.
Where Aider actually won
Aider was faster and cheaper on tight, well-scoped tasks. The Jest → Vitest migration was the clearest example: Aider finished in 4 minutes and used roughly a quarter of the tokens Claude Code did on the same task. The cache race bug was similar. Aider’s diff was smaller and shipped in one turn.
The morphllm folks published a benchmark showing Aider uses 4.2× fewer tokens than Claude Code on file-edit tasks, and my numbers line up. When the task is “change this file, ship a diff, commit,” Aider’s git-native design is a real advantage. It doesn’t try to hold the whole world in its head.
I did not expect that. Going in, I assumed Claude Code would take everything. It didn’t.
Where Aider fell apart
Multi-file refactors. All three refactor failures shared the same shape: task requires holding the semantics of file A while editing file B, then coming back to file A. Aider’s context in architect mode narrows aggressively between turns, and on the “extract service class” task it forgot the controller’s contract by the time it was three turns into writing the new service. Claude Code kept the plan alive.
The class-components-to-hooks migration was the ugliest failure. Aider correctly moved componentDidMount into useEffect and this.state into useState in isolation, but when a parent-child pair needed a coordinated change to useEffect dependencies, it stopped and asked me to confirm the change. When I did, it edited only one side. I gave up at turn 6.
Claude Code did the same task in one plan-then-execute pass. Sonnet is literally the same model in both harnesses. Claude Code just kept both files in its working set for the entire task.
The rate-limiter failure that surprised me
The sliding-window rate-limiter task was the one where both tools failed, and how they failed said more than the scoreboard.
Aider produced a fixed-window limiter and claimed it was sliding-window. Both the reading and the write hovered near the spec without landing on it, and the diff looked fine until you actually ran something against it. I only caught it because the burst test I wrote afterward blew up at the exact boundary.
Claude Code produced an actual sliding-window structure but got the burst-cleanup wrong under concurrent load. Its reading of the spec was right and the code lined up with that reading, yet it still shipped a bug. The bug lived somewhere a real test could find it.
This keeps showing up. My earlier ChatGPT Codex vs Claude Code comparison hit the same wall: both agents will lie about correctness, they just lie with different accents. Aider declares victory earlier. Claude Code hands you something closer to the shape you asked for and then breaks inside it.
Cost and wall-clock
Rough numbers across all 10 tasks:
- Claude Code: 47 minutes, ~$5.20 in API cost (Sonnet 4.6 via the CLI, plus a bit of Opus for two plans)
- Aider: 31 minutes on the tasks it completed, ~$2.10 in API cost, but it left five tasks unfinished
If I only had budget for one tool and had to pick, Claude Code paid for itself on the three tasks Aider couldn’t finish, because I would’ve spent 30+ minutes cleaning up each partial and probably given up on the class → hooks task.
If I only had one-file diffs to ship, I’d pick Aider and pocket the difference. I’m already moving a category of “small, well-scoped, single-file” tasks over to Aider for exactly this reason.
The natural-language layer neither tool exposes
Both agents are made of the same three parts: a model, a prompt, and a set of hooks that turn the model’s output into filesystem changes. The difference in scores above is almost entirely the third part. Same Sonnet 4.6, different scaffolding.
I’ve written more about this in the natural-language agent harness post: once the models converge, the harness is where the actual differentiation lives. Aider bet on small, git-native, one file at a time. Claude Code bet on a large working set, planning first, spanning many turns. Both bets pay off on different task shapes.
What I’d actually recommend
Pick by the shape of the task in front of you:
- Multi-file refactors, cross-file coordination, greenfield with several moving parts: Claude Code
- Bugfixes with a known file, single-file migrations, tight diffs where cost matters: Aider
- Anything you’re going to test rigorously afterward: either, but write the test first if the spec has edges (see the rate-limiter section)
I’m keeping both installed. That’s the honest answer. The five minutes it takes to notice “this task is one-file, Aider it” pay for themselves immediately.
Method notes
- 10 tasks, run in the same order for both agents, same repo state (fresh checkout each time)
- Both agents on Sonnet 4.6, Aider in architect mode with Sonnet 4.6 as editor
- Each task capped at 10 turns before I called it failed
- “Complete” means the diff compiled, tests passed, and the acceptance criteria I wrote before starting were met
- “Partial” means the diff worked for the happy path but I caught a real bug in a test I wrote afterward
- Rate-limiter tests included burst behavior and clock-skew cases — the interesting failures are in the edges
Related book Practical Claude Code The field guide for engineers who use Claude Code every day — CLAUDE.md, Plan Mode, and team workflows from a year of real production use View the book page → Was this article helpful?