Aider takes a position that separates it from most AI coding tools, which is that every change should be a git commit. Not a diff you accept in a panel, not an edit applied to your buffer, a commit with a message, in your history, revertable with one command. That decision propagates through the whole design and the documentation is built around explaining it. The installation section is straightforward and covers the various ways in, including Docker, Codespaces and Replit for people who do not want to install Python things locally.
The usage section covers chat modes, the in-chat commands, IDE integration and the general shape of a session. Configuration covers API keys, YAML settings, model aliases and the long tail of options. There is a troubleshooting section, screen recordings, example transcripts and the leaderboards. The git integration is the part worth reading slowly.
Every edit becomes a commit with a generated message. This sounds like a small ergonomic choice and it is actually the safety model for the whole tool. Undo is a git operation. Review is a diff.
Bisecting a session where the agent went wrong three steps ago is possible because there are three commits. Compared with tools where an agent has been rewriting files for twenty minutes and your only recourse is a proprietary checkpoint system, this is straightforwardly better engineering. The documentation explains the mechanism and is a little too matter of fact about how much it matters. It does note the requirement that your repository is clean before you start, which trips people up, and could push that warning harder.
The repository map deserves its coverage. Aider builds a compact structural map of your codebase, function and class signatures rather than full contents, and sends that as context so the model knows what exists without you pasting files. The documentation explains what it is, roughly how it is built and how to control it. This is the mechanism that makes the tool work on a repository too large to fit in a context window, and understanding it changes how you use the tool, because you learn to add the two or three files that genuinely matter rather than hoping the map is enough.
The leaderboards are the thing I respect most about this project. Aider publishes a benchmark of how well different models perform at code editing, run consistently, with methodology described and results that are not always flattering to the fashionable model of the month. In a field where nearly every vendor claim is marketing, a maintained public benchmark by someone with no model to sell is a real contribution. It also has direct practical value, because it lets you choose a model for this specific task on evidence.
Provider neutrality is genuine. Aider works with OpenAI, Anthropic, Google, DeepSeek, local models through Ollama and a long list besides, and the documentation does not steer you. There is no upsell because there is nothing to sell. The criticisms.
It is terminal only and the documentation assumes you are at home there. Someone who has never worked in a terminal will find the tool harder than the documentation acknowledges, and there is no gentle on-ramp. That is a defensible choice for the audience the project targets and it does narrow who this material serves. The configuration reference has grown large.
Options accumulate, and the settings pages now sprawl in a way that makes finding the four settings you actually need harder than it was a year ago. A short opinionated starting configuration would help more than another options table. The conventions file is underdocumented for how much it affects output. You can give Aider a file describing your project's conventions, and doing this well is the difference between an agent that writes code in your style and one that writes generic code you then rewrite.
The documentation mentions the capability. It gives you very little help writing a good one. Cost habits are the same gap every tool in this category has. Aider is transparent about tokens and cost per interaction, and the documentation does not really teach the discipline of keeping sessions small, dropping files from context when you are done with them, using architect mode with a strong model for planning and a cheaper one for edits, or noticing when you have been iterating for an hour on something you should have written yourself.
The git assumption cuts both ways. In a well kept repository the design is a gift. In a repository where people commit half finished work to main, keep large uncommitted changes for days, and treat history as disposable, the constraints will feel like an obstacle. The documentation presents the git model as obviously correct without acknowledging that plenty of real teams do not work that way.
My four point one is for a tool with a clear philosophy, documentation that explains that philosophy rather than just its settings, and a maintainer who publishes benchmarks that could embarrass him. The gaps are the usual ones, which are cost discipline and the judgement about what to hand over, and they are smaller here than almost anywhere else in the category.