Aider — The Complete Guide

What is Aider?

Aider runs in your terminal inside a git repository. You describe a change in plain English and it edits the relevant files.

Every change is committed to git automatically with a descriptive message, so undoing anything is a normal git operation.

Why the git integration matters

The biggest risk with AI editing your code is losing track of what changed. Automatic commits remove that entirely — every step is a separate commit you can inspect, revert or cherry-pick.

This makes experimenting genuinely low-risk in a way that editor-based tools often do not.

Who it suits

Developers comfortable in a terminal who want AI assistance without leaving it, and anyone working over SSH or on a remote machine where a GUI editor is impractical.

Repository mapping

Aider builds a map of your repository — the structure, key definitions and relationships — and sends a condensed version as context rather than whole files.

This is what allows it to work on large codebases without exceeding context limits or spending enormous amounts on tokens.

Working effectively with it

Add only the files relevant to the task rather than the whole project. Aider works better with focused context and it is cheaper.

Describe the outcome rather than the implementation. "Add pagination to the results endpoint, 20 per page, with a next cursor" produces better results than instructing it line by line.

Model choice

Aider maintains public leaderboards of how different models perform on its own benchmark of real editing tasks, which is more useful than general benchmarks for this specific use.

Frontier models perform considerably better on code editing than smaller ones. This is a task where model quality genuinely shows.

Against GUI tools

Cursor and Cline offer visual diffs and a more approachable experience. Aider offers speed, scriptability and terminal-native workflow.

Neither is better in general. The choice follows where you already work.

Cost behaviour

Because Aider sends a repository map rather than full files, cost per request is generally lower than naive approaches.

Still, agentic editing consumes tokens. Use caching where the model supports it, and keep the added-file set small.

Working With a Coding Agent Without Losing the Thread

The failure mode is not bad code. It is a large volume of plausible code that nobody has understood, arriving faster than it can be reviewed.

Keep the unit of work small. One change, one purpose, reviewable in a sitting. An agent asked for a large refactor returns something you will approve because reading it properly costs more than the work saved — which is how unreviewed code enters a codebase.

Make the tests the specification. An agent working against a failing test has an objective definition of done; one working against a description has your interpretation of its interpretation.

Commit in small steps and keep the history clean. The ability to bisect is what makes an agent's output safe to accept, and it is the first thing lost when a session produces one enormous commit.

Read the diff, not the summary. The summary is generated from the same process that produced the change, and it is confident about both.

And watch the dependency additions. An agent will reach for a library to solve a problem, and a new dependency is a decision with a long tail that nobody made deliberately.

Evaluating It Against Your Own Work

Vendor demonstrations are built on material the tool handles well, so the only evaluation that predicts anything is one run on your own inputs.

Assemble twenty real examples before the trial starts, including the awkward ones — the messy input, the edge case, the one that went wrong last month. A set of clean examples measures a situation you do not have.

Define what good looks like in writing, before you see any output. Deciding afterwards is choosing the answer rather than measuring it, and it is what makes most tool trials inconclusive.

Time the whole task, not the tool. A tool that halves the generation step and adds a verification step has not saved anything. Measure the end-to-end time including checking and correction, because that is the number your team experiences.

Have two people run the same examples. Tolerance for a given failure varies more between people than between tools, and a decision made by one enthusiast rarely survives contact with the team.

And price the failure, not just the licence. What does a wrong output cost here — a correction, an apology, a customer? That number decides how much checking you need, which is usually the real cost of adoption.