Aider, Continue, and the CLI-first workflow

I use both worlds. Cursor and Claude Code own most of my actual coding sessions. But for a specific class of work — long-running refactors, batch script tasks, anything I want to script myself — Aider and the CLI-first family of tools are still where I land.

Here's the mental model.

The two camps#

Editor-integrated: Cursor, Continue (in IDE), Claude Code (when run in interactive TUI mode), GitHub Copilot Chat, Zed AI. The AI is wired into the editor's context — open files, current selection, git state, the active project. Best for "I'm editing code right now and need a hand."

CLI-first: Aider, Plandex, Continue (via CLI), llm (Simon Willison's CLI), goose. The AI runs as a process that reads/writes files in a directory. Best for "I want to give a single instruction and walk away."

The split isn't strict — Claude Code and goose straddle both camps — but the design center matters.

Why CLI-first sometimes wins#

I reach for Aider when:

1. The task spans many files and I don't want a chat UI. Aider's "edit n files at once" mode just does the edit, runs the test, commits the change, and stops. No back-and-forth.

2. I want to script the AI's involvement. Aider can be invoked from a shell script. Cursor can't.

for repo in services/*/; do
  cd "$repo"
  aider --message "Bump httpx to ^0.27 and update any breaking imports" \
        --auto-commits --yes
  cd -
done

3. I'm working in a small repo where editor scaffolding is overkill. A 5-file Python script doesn't need Cursor running; it needs an AI that can edit the 5 files.

4. I want auto-commit per change. Aider commits after every accepted edit, with a meaningful message including which model it used. Easy to roll back individual changes.

Aider's killer features#

After a year of off-and-on use, the things that keep me coming back:

Repo map. Aider builds a compressed summary of your repo (file structure + signatures) and includes it in every prompt. This means the model has some awareness of code outside the files you've explicitly added, without paying tokens for the full content.

Voice mode. aider --voice actually works for "drive while talking." Niche, but excellent when it fits.

Multi-model. You can run Aider with one model for high-effort code generation and a different (cheaper) model for editing. --model claude-sonnet-4-6 --weak-model claude-haiku-4-5 saves real money.

Read-only file mode. Add a 50KB constants file as read-only — the model sees it but can't edit it. Stops the model from "improving" your config when you wanted help with the controller.

A representative session#

$ aider services/billing/invoice.py services/billing/refund.py

Aider v0.79.0
Model: claude-sonnet-4-6 with whole edit format
Git repo: ../../.git, ./.aiderignore
Repo-map: using 1024 tokens, 23 files

> The refund.py module crashes when invoice.line_items is empty.
  Add a guard, and a test in tests/test_refund.py.

Editing services/billing/refund.py:
  added if not invoice.line_items: return Refund.empty()

Editing tests/test_refund.py:
  added test_refund_empty_invoice

Running tests... 47 passed.

Committed as: "fix: guard against empty line_items in refund (claude-sonnet-4-6)"

> /undo
Reverted commit. What would you like to do instead?

> Same fix, but raise an EmptyInvoiceError instead of returning a sentinel.

Note the /undo command. The model committed; you can revert; you steer the next iteration. The git-aware loop is the differentiator.

Continue: the editor-and-CLI middle path#

Continue (continue.dev) is interesting because it ships both a VS Code extension and a CLI binary that share the same configuration. Same model setup, same custom commands, two interfaces. If you switch contexts a lot, this matters.

The custom-commands feature is underrated:

# .continue/config.yaml
slashCommands:
  - name: explain-test
    prompt: "Explain what the failing test on line 12 of {currentFile} is checking, and why it might be failing."
  - name: bisect-bug
    prompt: "Use git log to find the commit that introduced this regression: {input}. Walk through suspects and confirm via test runs."

You define /explain-test once, it's available in both the editor and the CLI. Sharing the slash-command set across tools is one of those small productivity wins that compounds.

Plandex: the agent-first option#

Plandex pushes further into the "long-running" territory. It maintains a context across many invocations, supports branching plans (try approach A, branch off and try approach B, compare), and applies changes in batches you can review.

It's less mature than Aider and the model-cost is higher (it pays heavily for branching and re-evaluating context), but for genuinely complex multi-step work — "rewrite this service with a different framework" — it's worth a look.

When to use which#

A rough guide:

Task	Best fit
"Add an endpoint to this controller"	Cursor / Claude Code
"Refactor 12 files to use httpx instead of requests"	Aider
"Add a tested feature with code, migration, integration tests"	Claude Code (agent mode)
"Run an AI on every repo in this org and fix linter errors"	Aider in shell loop
"Rewrite this service with a different ORM"	Plandex or Claude Code agent
"Talk through this PR with me"	Cursor chat / Continue
"Generate a one-off script to munge this CSV"	`llm` CLI or Aider

It's not Cursor or Aider. It's both, picked by the shape of the work.

The shared lesson#

What all these tools converge on is the same insight: the unit of AI-assisted work is moving from token → completion → task → plan. Editor-integrated tools nailed the completion-and-task layers. CLI-first tools are pushing into "give me a plan, execute it" territory because that fits a shell-pipe workflow naturally.

Both approaches are right. Pick the one that matches today's task. Keep both installed.