Aider vs Continue: Two Modes of Terminal AI Coding

The Problem With Picking An AI Coding Tool

You’ve got Claude. You’ve got Sonnet. You know LLMs can write code. But the difference between having access to an LLM and actually using it well is the UX layer — and there’s a yawning gap between two popular approaches right now.

One approach: Aider. A terminal-native Git-aware pair programmer. You start a conversation, it edits your files, makes commits, handles diffs. It’s like having a junior dev in your terminal who actually knows what files changed and why.

Other approach: Continue. An IDE plugin that sits in VS Code (or JetBrains, Neovim, etc.) and lets you highlight code, ask questions, generate features, refactor inline. It’s like having a copilot who’s always looking over your shoulder.

They solve the same problem — getting an LLM to write and edit code — but the workflow is fundamentally different. And I don’t mean “different enough to argue about at lunch.” I mean: one will save you an hour on a task, the other will waste it.

Let’s dig in.

Aider: The Terminal Git-Aware Pair Programmer

Aider is a Python CLI tool that turns your terminal into a pair-programming session. You run it, point it at your repo, and start chatting. When the LLM suggests code, Aider actually edits your files — and commits the changes with a sensible message.

That last bit is key. Most “AI coding” tools are read-only from the LLM’s perspective. You get a suggestion, you manually copy it into your editor. Aider does the opposite: it assumes the LLM is collaborative and hands the keyboard over to it.

How Aider Actually Works

Fire it up:

cd /path/to/your/project
aider

You get an interactive prompt:

Aider v0.50.0
Type 'exit' to quit the chat, 'help' for commands.
Repo: /home/user/my-project (.git)
Model: claude-3-5-sonnet-20241022

Now you type a request:

aider> add a function that takes a list of URLs and returns their HTTP status codes

Aider does a few things:

1. Sends your request + the full context of your repo to Claude (or your chosen LLM)
2. Claude responds with a plan and code
3. Aider parses the response, identifies which files need edits
4. It actually edits them — diffs the changes in real-time
5. You get a chance to accept or reject
6. If accepted, it commits with a message like: Add function to fetch HTTP status codes

Here’s a real example. Say your repo has utils/http.py and you ask:

aider> add a function to check if a URL is reachable, with timeout

Aider might respond:

I'll add a `check_url` function to utils/http.py.

utils/http.py
<<<<<<< ORIGINAL
import requests

def get_status(url):
    return requests.get(url).status_code
=======
import requests
from urllib.parse import urlparse

def get_status(url):
    return requests.get(url).status_code

def check_url(url, timeout=5):
    """Check if a URL is reachable within the timeout."""
    try:
        response = requests.head(url, timeout=timeout)
        return response.status_code == 200
    except requests.RequestException:
        return False
>>>>>>> UPDATED

You see the diff. You type y to accept or n to reject. If you accept:

git add utils/http.py
git commit -m "Add check_url function with timeout handling"

Done. The code is in your repo, committed, with a clear history.

The Mental Model: Collaborative Editing

Aider forces you to think of the LLM as a collaborator in the codebase, not a snippet generator. Because the LLM sees your actual files, it understands context:

• It knows your existing functions and classes
• It sees your import structure and naming conventions
• It knows what’s already in utils/ vs. models/
• It can refactor across files if needed

This is why Aider’s @ commands are so useful:

aider> @web.py generate a form handler for login

The @web.py prefix tells Aider: “only show Claude this file” (or “add this file to context”). If your repo is huge and Claude would be confused by everything, you can isolate the conversation.

You can also explicitly list files:

aider> @models/user.py @models/auth.py add a password reset token system

And Aider will only give Claude those two files, plus any it auto-detects as dependencies.

The Downside: It’s A Conversation

Because Aider is interactive, you have to stay in the loop. You can’t just say “build me a full authentication system” and walk away for 20 minutes. You have to guide it, accept each diff, course-correct when it goes sideways.

Also: it’s terminal-only. No syntax highlighting, no IDE integration. If you’re someone who lives in VS Code, you have to context-switch.

Continue: The IDE Sidecar

Continue is a different beast. It’s an IDE plugin (VS Code, JetBrains, Neovim, Zed) that gives you an AI assistant in a sidebar panel. You highlight code, ask questions, and it answers. You can generate code blocks, refactor selection, explain logic.

How Continue Works

Install the VS Code extension, configure your LLM (Claude, Ollama, local, remote, whatever), and you get a chat panel on the right side of your editor.

Typical workflow:

1. Highlight some code
2. Ask a question about it — “why is this slow?” or “refactor this to use async”
3. Continue responds in the chat panel
4. Copy the suggestion or use the Insert button to drop it at your cursor

Or you can use slash commands:

/edit refactor this function to be more readable
/explain what does this code do
/tests write a test for this function
/optimize make this faster

When you type /edit, Continue shows you a diff preview, and you can accept or reject the changes. It’s less aggressive than Aider — the edits stay in the editor, not in your git history, until you manually save.

The Mental Model: Always-On Reference

Continue treats the LLM as a reference tool that’s always available. You’re in your editor, you highlight something, you ask a question, and the answer pops up in a sidebar. No context switching. No terminal. No modal interaction.

This works beautifully for:

• Understanding code you didn’t write — “explain this regex”
• Quick refactors — “make this more Pythonic”
• Generating test cases — highlight a function, /tests, boom
• Inline documentation — “/explain as comments”

And because it’s not committed-focused, you can be exploratory. You can ask silly questions, get messy suggestions, iterate without worrying about polluting your git history.

The Downside: Stateless Edits

Continue doesn’t know about your git repo. It doesn’t auto-commit. It doesn’t track what’s changed. If you accept five inline edits and want to group them into a coherent commit, you have to manually stage and commit them yourself.

Also: it’s editor-centric. If your IDE dies, your chat history is gone (well, Continue does have persistence, but it’s not git-backed). And if you’re working across multiple files, Continue has to be told about them explicitly — it doesn’t auto-discover dependencies the way Aider does.

Side-By-Side: The Key Differences

When To Use Aider

Pick Aider if:

• You’re building something from scratch — a new feature, a CLI tool, a microservice. The fact that it auto-commits means your repo has a clean trail of what happened.
• You’re doing a large refactor — moving code around, changing APIs, updating imports. Aider can see the dependencies and won’t leave you with broken references.
• Your repo is large and you want to isolate context — use @ prefixes to hand Claude only the relevant files.
• You want a transcript of what the LLM did — git log tells the story. Each commit has the request baked in (you can add context if you want).
• You live in the terminal anyway — if you’re a tmux warrior, switching to an IDE just to chat with an LLM is annoying.

Example workflow:

# Tired of manual pagination logic? Ask Aider to build it.
aider
> @models/post.py @utils/ add a paginator class that handles limit/offset

You get a diff, you accept, it commits. Done. Your git history shows when you added pagination and why.

When To Use Continue

Pick Continue if:

• You’re exploring or understanding code — you didn’t write it, it’s confusing, and you need an expert to explain it.
• You want to refactor inline without commitment — try five different approaches in the editor, keep what works, discard the rest, then commit once as a single logical change.
• You’re in flow state in your IDE — breaking context to fire up Aider just to fix a type hint is overkill.
• You’re doing one-off edits across multiple files — Continue lets you highlight, ask, and manually stage each edit.
• You want zero git pollution — if you’re paranoid about your commit history, Continue lets you think and edit without auto-commits.

Example workflow:

# In VS Code, you see a gnarly regex in a parser.
# Select it, type: /explain
# Continue tells you what it does.
# Then: /optimize
# You get a faster version, copy it, save the file.
# One clean commit at the end.

The Real Difference: Commitment vs. Exploration

Here’s what it comes down to: Aider is commit-first, Continue is explore-first.

Aider says: “Let’s edit the repo, commit it, and move on.” It’s opinionated. It trusts the LLM to edit your files directly. Your repo is the source of truth.

Continue says: “Let me help you think about code.” It’s collaborative but non-committal. You keep the keyboard. The LLM is a consultant, not a coworker.

One’s not better. They’re for different moods:

• Deadline? New feature? Building momentum? Aider. Let the LLM drive and commit.
• Exploring a codebase? Refactoring carefully? In flow? Continue. Keep the IDE, ask questions, stay in charge.

The Practical Truth

Most teams end up using both. Aider for feature branches and new modules. Continue for code review, understanding, and inline refactoring. It’s like having a junior dev who handles the grunt work (Aider) and a mentor who explains things when you’re stuck (Continue).

If you had to pick one? Start with Continue. It’s less commitment (literally), it doesn’t override your editor, and it fits into existing IDEs. You can always add Aider later for big builds.

But if you’re writing a lot of code and you’re tired of copy-pasting LLM suggestions into your editor, Aider is a revelation. Seriously. Try it once. The first time you watch an LLM edit your files and commit them with a sensible message, something clicks. You stop thinking of it as a snippet generator and start thinking of it as an actual pair programmer.

And maybe that’s the real lesson: the tool that works best is the one that changes how you think about AI coding. Right now, that’s different for everyone. But at least now you know what each one is actually built for.

Related Reading

• Continue.dev + Ollama: Local Code Assistant for Cheap
• 1-Bit LLMs: The Quantization Endgame
• Agentic Browsers: Browser-Use & Skyvern Reviewed
• Aider & Cline: Terminal AI Coding That Actually Ships
• AMD Lemonade: Local LLM Serving for AMD GPUs