Aider connects a local Git working tree to a language model: it sends your request with the files you selected and a concise map of the wider repository, then translates the model’s response into local file edits. Git integration lets you inspect and undo recorded changes, but it does not establish that the code is correct.
How an Aider request becomes a code change
Aider is a terminal-based pair-programming application. The user supplies a request and chooses which project files to bring into the chat; Aider adds repository context, asks a configured model for a response, and applies edits using an appropriate edit format.
- Start in the project and select files. Files can be named when launching Aider or added during the chat. Aider’s usage documentation recommends adding files that should be edited.
- Build context. Aider can also supply a repository map summarizing files and important symbols, such as key definitions and signatures. Its repository-map documentation says, “Aider sends a repo map to the LLM along with each change request from the user.”
- Send the request to a configured model. Aider supports hosted and local model options. The model interprets the request and returns a response; Aider then processes that response according to its edit format.
- Apply the proposed edits locally. The format determines how changes are represented and how Aider can apply them to files.
- Review the result in Git. Aider’s Git integration records changes and provides ways to inspect differences and undo the last change.
How Aider understands a codebase
There are two complementary kinds of context: the files explicitly added to the chat and the broader repository map. The selected files provide direct context for the task. The map gives the model a concise view of other files and notable symbols, helping it relate a change to definitions or abstractions elsewhere in the project.
The map is a summary, not a complete semantic representation of every file. Aider’s repository-map documentation describes what it includes and how it accompanies change requests. If a task depends on details in a file, explicitly add that file rather than assuming the map contains its full contents.
#1 Best Overall
Who decides what changes: the model or Aider?
The language model proposes a response to the request. Aider’s edit-format machinery interprets that response and applies supported changes to the local repository. The model’s output and Aider’s file-editing workflow are separate parts of the process: a proposed edit is not itself proof that the change works.
Aider offers different chat modes, each suited to a different kind of interaction:
- Code mode: makes requested code changes.
- Ask mode: discusses code and answers questions without editing files.
- Architect mode: separates solution design from implementation. One model proposes a solution in plain language; an editor model turns it into concrete file edits.
- Help mode: answers questions about Aider itself.
Users can switch modes for one message or change the active mode. Aider can be configured using command-line switches, a YAML file, environment variables, or a .env file; see its configuration documentation.
How Aider represents edits
The model’s response must use a format Aider can interpret. The available approaches trade off output size and how precisely a change is expressed:
Rank #3
| Edit approach | How it represents a change | Practical trade-off |
|---|---|---|
| Whole-file | The model returns the complete updated file. | Can require substantial output even for a small change. |
| Diff or search/replace | The model returns targeted blocks describing what to replace or change. | Focuses the response on the requested edits rather than reproducing the entire file. |
| Unified diff and other adapted formats | The model returns changes in a format supported by Aider. | Format choice depends on the model and task. |
Aider documents these approaches in its edit-format guide and the project’s coder documentation. A model that does not reliably produce the selected format may return changes Aider cannot apply successfully, so model support and format fit matter as much as the request itself.
What Git does in Aider’s workflow
Aider integrates with Git to record edits with descriptive commit messages and to let users inspect differences or undo the last change. Its Git documentation also says that Aider commits pre-existing uncommitted changes before editing. If your working tree is dirty, check the commit history and diff so you understand what was recorded before Aider begins its requested edits.
Git makes changes reviewable and recoverable; a commit is not a test result. Read the diff, run the checks your project requires, and decide whether to keep the change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What Aider’s workflow does not guarantee
- The repository map does not mean every file’s full contents are included in the model context.
- Aider applying a response does not mean the model’s proposal is correct or compatible with the rest of the project.
- Git commits make changes easier to inspect or undo, but they do not validate behavior.
- Model availability, recommendations, and capabilities change over time. Consult Aider’s model documentation for current options.
Aider documents configurable linting and testing support, but whether and how those checks run depends on project configuration and tools. Do not assume that every edit is automatically validated.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
