ai-codingaidercursorterminalopen-source

Why I Switched from Cursor to Aider for Terminal-First AI Coding

Billy C

Why I Switched from Cursor to Aider for Terminal-First AI Coding

I spent most of last year inside Cursor. It was, and still is, a very polished editor with an enormous amount of work going into product polish. But somewhere along the way I noticed that almost every productive AI session I had was happening in a terminal split next to my editor, not in the editor chat panel. I was running tests, tailing logs, poking at containers. The AI assistant felt like a guest at the wrong party.

So I moved my daily pair programming over to Aider, a terminal-based open-source CLI tool. This is a first-person take on what changed, what I gained, and what I gave up.

Why a terminal-first workflow won me over

Aider is, at its core, a Python program you launch in the directory of the repo you are editing. You start it, you tell it which files to add to the context, and you talk to it. It reads files, proposes edits, and applies them as patches. Everything happens in plain text, in the same place your shell prompt lives.

That sounds boring on paper. In practice it removes a lot of friction:

  • I do not have to alt-tab between an editor chat panel and my terminal to run the change I just got.
  • The model sees real diffs and real test output because that output is right there in the same buffer.
  • I can pipe context in and out using the same shell tools I use for everything else.

When I am debugging a flaky integration test or working on a CLI tool, this matters. Cursor is great when the canonical "view" is your file tree plus a buffer. The moment my work spills into ad hoc shell pipelines, the terminal wins.

Git is a first-class citizen

The single feature that made Aider stick for me is the git integration. Every change Aider applies to my repo is committed automatically with a sensible commit message. According to the Aider repository, this is core to the product: "Aider automatically commits changes with sensible commit messages. Use familiar git tools to easily diff, manage and undo AI changes."

In practice this turns the AI session into a sequence of small reversible commits. If a change is wrong, I run git reset HEAD~1 and I am back. If it is mostly right, I keep going and squash later. I do not have to babysit a "preview" UI or click "accept" buttons. The unit of work is the same unit of work I have used for fifteen years.

# Typical session start
aider --model sonnet src/auth.py tests/test_auth.py

# Inside aider, after a request
> Please add a unit test for the new token refresh path.

# In another terminal pane
git log --oneline -n 5
git diff HEAD~1

Cursor has good diff review, but it sits inside a UI I cannot script around. Aider sits inside git, which I script around all day.

Model flexibility I actually use

The other big shift is that I stopped being locked into one provider. Aider supports Claude (including Sonnet), OpenAI models like GPT-4o and the o-series, DeepSeek, and "nearly any LLM, including locally-hosted models" per the project README. That means the same CLI works whether I am pointing it at Anthropic, OpenAI, or a local server.

This matters for two reasons. First, different models have different strengths. I tend to use Sonnet for refactors that span many files, and a strong open-weights model on a self-hosted endpoint for repetitive boilerplate. Second, I do a fair amount of contract work where the client decides which provider I am allowed to send code to. Aider just takes a different --model flag and an API key. No new tool to learn.

If you want to point Aider at a local server, you run something like a local OpenAI-compatible endpoint and pass the base URL. I have written a separate walkthrough on that side of things in Self-Hosted AI Coding Tools, which goes deeper on the local-model side.

What I gave up moving away from Cursor

I want to be honest. Cursor does some things Aider does not.

  • Inline ghost-text autocomplete tuned for code. Aider is conversational, not "Tab to accept". When I want speedy single-line completion, I still reach for an IDE-resident tool.
  • Click-through diff review with rich syntax highlighting and side-by-side panels. Aider gives you a unified diff. If you live in a GUI, the GUI is nicer.
  • Multi-file refactors with a visual project tree. Aider does multi-file edits, but you have to add files to the chat context yourself.
  • Built-in semantic search of the whole repo. Aider has a repository map, but Cursor's indexing is more aggressive and feels more "magic" out of the box.

If you are mostly editing TypeScript in a single repo with a tight feedback loop, Cursor is still very good. The argument for Aider is sharpest when your workflow already lives in the terminal.

A quick note on Cline and Continue

Two open-source tools come up every time I write about this. Cline is a VS Code extension that runs as an "autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser." It keeps a human-in-the-loop GUI to approve every file change. If you want VS Code as your primary surface but you also want agent-style autonomy, Cline is the most natural pick.

Continue is the other open-source option I keep recommending. Its current direction is interesting: a CLI plus IDE extensions, plus a markdown-based system for defining checks that can run in CI on pull requests. If your team wants AI checks gated in CI, not just at the developer's keyboard, Continue is worth a serious look.

I land on Aider mainly because the terminal is where I actually work. If your editor is your home, Cline makes more sense.

How I structure a typical session

A pattern that emerged for me:

  1. Start Aider in the project root with the two or three files I expect to edit.
  2. Describe the change in one paragraph, including the test I want to pass.
  3. Let Aider edit and commit. Run tests in another pane.
  4. If the test fails, paste the failure into the Aider prompt. It almost always proposes a corrected patch.
  5. When the feature is done, squash the commits to a single clean one before opening a PR.

The whole loop sits inside git, the shell, and a single text-mode AI session. Nothing else. That simplicity is the thing I missed in a richer editor without realizing it.

The bottom line

I have not uninstalled Cursor. It is still a great tool and I will keep recommending it to people who want a polished IDE experience. But for my own daily work, the terminal won. Aider being open source under Apache 2.0, model-agnostic, and built around git made it the natural home for the way I already write code.

If you have been frustrated that your AI assistant lives in a panel that does not understand the rest of your workflow, try a week of Aider. The first hour feels weird. By day three the IDE chat panel feels like a toy.

Tools mentioned in this post

  • Aider: open-source terminal-based AI pair programmer with deep git integration and broad model support.
  • Cline: open-source VS Code extension that runs as an autonomous coding agent with human approval for each step.
  • Continue: open-source AI agent platform with CLI, IDE extensions, and markdown-based PR checks.

Related Tools

More Articles