Aider was close, but not quite right

On 4 June 2024, I experimented with Aider around version 0.37.0. I returned to Cursor because it fitted my normal editing workflow more closely.

Aider handled bounded, prompt-led changes effectively. Its repository mapping and Git integration were useful. Using it also meant learning a separate terminal interaction, managing which files belonged in the session, and understanding more configuration and source-control behaviour.

No work from the experiment reached production. I cannot use it to make a claim about reliability or code quality. The narrower result was enough: Aider was moving in the right direction, but its interaction did not fit the way I wanted to work.

Aider put the repository in the loop

Cursor had closed the gap between a separate chat window and the editor. Aider moved the centre of gravity again. The repository, terminal, and Git became part of the interaction rather than places where I applied an answer afterwards.

That approach made sense to me. A coding task is rarely a single file with a self-contained answer. It involves the current repository, changes already staged or committed, commands used to inspect the project, and tests that decide whether a change is acceptable.

A terminal-based workflow could include those things more directly. It suggested a closer relationship between the agent and the repository than copying a proposed edit into an editor.

Better repository access still did not amount to understanding the system. It was a useful step towards making the repository the primary interface, though.

The interaction added too much friction

Compared with Cursor, Aider felt crude to use. It required a separate terminal interaction and explicit management of the files included in the session. There was also more configuration and source-control behaviour to understand.

The trial encountered a startup failure caused by an obsolete option in a machine-level Aider configuration file. That was not a defect in Aider version 0.37.0. Diagnosing it still added friction before I could use the tool. Configuration from an earlier installation had become part of the problem, even though the problem was outside the version I intended to try.

I did not have time to learn Aider’s habits deeply enough to separate its limitations from my own unfamiliarity with it. The command-line direction was credible. The path from intention to a useful change felt less natural than it did in Cursor.

That was enough to stop the experiment before Aider became part of my development workflow.

Cursor offered a lower-overhead daily workflow. It retained the familiar VS Code editing environment and combined codebase-aware chat, inline Cmd-K edits, visible context, and predictive completions.

I could ask for a change, see what was in context, edit the result, and continue working in the file without changing interaction modes. That continuity mattered more to me than the possibility of a stronger autonomous multi-file change.

Aider may have been stronger in that area at the time. I did not measure it as a controlled comparison, though. Returning to Cursor was a decision about interaction ergonomics and workflow continuity, not a conclusion that Aider produced inferior code.

A promising direction can still be the wrong fit

It would be easy to turn this into a product verdict. The experiment did not show that Aider was generally unreliable, or that Cursor was generally better.

Aider’s approach to the repository and terminal was close to the interaction I wanted. A technically promising direction still carries a learning cost, and I was not ready to pay that cost for this workflow at that point.

The useful question was therefore larger than whether an agent could reach the files, edit them, and use Git. I needed to understand what it was doing, steer it without unnecessary friction, and review the result within the time available.

Cursor had shown me how much mechanical friction editor integration could remove. Aider showed me that the terminal and repository could become a more complete interface for coding work. I needed both repository access and an interaction I could use repeatedly, while keeping the agent’s actions visible and ordinary Git and test practices intact.

Aider was close to that idea. It was not quite right for me yet.