How to Use Aider, an AI Coding Tool
Introduction
While AI agents like Devin and AI tools for integrated development environments (IDEs) such as Windsurf and Cursor exist, Aider remains a persistently used tool (among at least three people I know).
This article was created with the hope that by understanding Aider's advantages and how to actually use it, you will consider it as one of your AI development environment options.
Initially, I tried to create this article itself using Aider, but it didn't go very well.
Therefore, this is a manually and extensively revised version of text that was voice-inputted and then structured into Markdown format by AI.
What is Aider?
Overview
Aider is an AI pair programming tool created by Paul Gauthier.
There's a reason I specifically call it a pair programming tool.
On Aider's Discord channel, many questions and comments arise about using Aider as an agent. However, Paul Gauthier consistently replies, "Aider is an AI pair programming tool."
Being a pair programming tool means there's a driver and a partner, with the partner constantly observing the driver's actions. This differs from the structure where an AI agent advances tasks, and a human checks everything at the end. The crucial point is that it's a pair programming tool for real-time collaborative work, watching over the process.
By checking the implementation details and providing detailed feedback along the way, you can achieve high code quality.
Differences from Other Tools like Devin and Windsurf
Agent-oriented tools like Devin and Windsurf basically continue processing until a task is completed once an instruction is given.
Aider, on the other hand, progresses development by executing one process at a time in response to an instruction, similar to chat tools like ChatGPT.
This characteristic has its pros and cons. While it has the weakness of not being able to handle a large number of tasks at once like an agent, it offers the advantage of improving processing accuracy.
I use both Devin and Windsurf, switching between them based on their respective characteristics.
I'm considering writing an article to organize my current thoughts on this topic sometime.
Advantages of Using Aider
Easier Precise Control of Context
I believe this is Aider's greatest advantage.
Tools like Devin, Windsurf, and Claude Code can be cumbersome when adding context. While it's possible to open files or use incremental search with at-mentions (@) to load files one by one, it takes time.
Especially when you want to use multiple files as context, you either have to do this every time or copy and paste the content into the prompt, which is very tedious.
Also, as far as I know, apart from RooCode, it's difficult to differentiate context modes, such as making specific contexts read-only while designating only certain files as editable.
When using AI development tools, you might have experienced unintended files being edited. Aider can solve this problem.
Easy Integration with Other Tools as a CLI Tool
Since Aider is a CLI tool, it can be used flexibly, such as by combining it with shell scripts or running Aider commands as one-liners.
Leveraging this feature, I created a Vim plugin called aider.vim which I find very useful, but I won't go into detail in this article.
Lower Financial Cost
If you're reading this article, you might have experienced exceeding your LLM usage limits with Windsurf or Cursor, or quickly depleting your credits (ACU) with Devin, leading to high costs. I've been there too. I still am.
Aider uses LLMs only for necessary processing, significantly reducing costs. At the very least, you can avoid situations where tens of dollars disappear in 2-3 hours.
While it's understandable that Devin incurs high costs due to its advanced processing, for those of us who aren't oil barons, cost is a significant issue.
How Aider's Creator Uses It
Prerequisites
To explain how to use it, let's first organize commonly used Aider commands.
/ask
This allows you to send instructions to Aider via a prompt, but it's a special mode that doesn't edit files.
The creator's recommended usage is to first set all necessary context in this /ask mode and then proceed to editing.
/add
This allows you to add files to Aider as context for editing. Using this command prevents unintended files from being edited.
/read-only
Conversely to the /add command, this adds files as read-only context. By using this in conjunction with /add, you can prevent accidental file edits.
/architect
With this command, Aider proposes a code modification strategy, and the user can choose whether to proceed with the implementation based on that proposal.
This is similar to the functionality where an agent tool makes a proposal, and the user decides whether to approve it.
The primary purpose of the original /architect command is to use different LLMs for inference and code editing, but I use it as described above. In most cases, this works fine.
If you want to further improve code accuracy, combining the /ask command with the /code command (which only performs implementation) will yield better quality. This is the method recommended by Paul Gauthier.
Overview
Basically, you load all necessary files as context, making only the files to be edited editable with /add.
Next, you register the context of what you want to implement as a prompt using the /ask command, and finally, you implement it with the /code command.
This process is repeated.
What's Good About It?
By registering only the necessary context, you can reduce the risk of unintended code output.
Also, since the output is kept to a minimum, it helps save on LLM API usage fees.
My Way of Using It
Challenges I Felt
While I generally follow Paul Gauthier's usage, I had some concerns.
When adding context with the /ask command, the reusability of the question content is low.
Especially in business system development, it was necessary to load similar contexts every time, which was very tedious. If you're writing code for a one-off project, Paul Gauthier's method would likely be fine.
Creating a Plan Document
The development process is basically the same as recommended by Aider's creator, but with some modifications.
The difference from Paul Gauthier's method is the creation of a plan document in Markdown.
In this plan document, I describe in detail the purpose, necessary context, and implementation details in a Markdown checklist format.
This effectively means I'm writing the content of the /ask command, and it also has the advantage that this document can be reused when developing similar features.
Below is an example of a plan document for a fictional business system development (it's actually much more detailed, but I've shortened it for brevity):
# title: Create User Information API
### Overview
- Create a user information API
### Mandatory Rules
- Always refer to ./CONVENTION.md and adhere to the rules.
- Especially, strictly follow the phpdoc specifications for documentation rules.
### Development Goals
- Implementation of userController.php is complete.
- Implementation of userUseCase.php is complete.
- All unit tests pass.
### Context for Generative AI Training
#### UnitTest: userTest
- Develop using TDD, so create tests first.
- The reference file for creating unit tests is `/path/to/userControllerTest.php`.
- Use DatabaseTransactions.
- Create test data.
#### Model: Necessary model classes
Refer to model classes under the /path/to/Eloquents directory.
- UserModel.php
- XxxModel.php
#### Screenshot: path/to/file
- /path/to/xxx.png
<!-- Aider can add images as context with the /paste command, so use as needed -->
### Process
#### process1: Create necessary files
When creating files, include phpdoc for classes, methods, class properties, and constants.
For phpdoc conventions, refer to CONVENTION.md#Documentation Rules.
- [ ] Create /path/to/UserController.php
- [ ] Refer to @ref /path/to/YyyController.php
- [ ] Create /path/to/UserUseCase.php
- [ ] Create get() method
- [ ] Use Eloquent's UserModel
- [ ] Extract only usernames after retrieval
#### process2: Follow-up
##### sub1: Refactor UserController.php
- [ ] Refactor the code.
##### sub2: Code correction
- [ ] Update phpdoc for context target files.
- [ ] Reflect the latest method arguments in @param.
- [ ] Reflect the latest method return values in @return.
- [ ] Reflect the latest method exceptions in @throws.
Execution
First, load the plan document with the /add command, then add the necessary context files as read-only.
Finally, load the files to be edited with the /add command.
Once these preparations are complete, I issue instructions like, "Execute the items in the 'Process' section of the plan document (e.g., process1 sub2)."
After Aider finishes outputting the code, I review the content, and if there are no issues, I instruct it to "Check the corresponding task in the Markdown," which automatically updates the checkbox for the completed task.
Below are examples of the execution prompt and checkbox update prompt I actually use.
# Execution
{process
Please execute the following processes in order from 1.
For each process, output a log detailing specifically what edits were made.
1. For confirmation, please display all work content for dev_plan.md process1 sub1.
2. Execute dev_plan.md process1 sub1 in order from the top of the checklist.
3. If it was already implemented, please inform me that 'nothing was done'.
process}
# Update Checkbox
/code {process
target: dev_plan.md
Please execute the following processes in order from 1.
For each process, output a log detailing specifically what edits were made.
1. In dev_plan.md process1 sub1, for items that have been implemented, execute only turning ON the checklist.
Tell me the basis for turning the check ON.
2. Please only update dev_plan.md. Editing other files is prohibited.
process}
Follow-up
Those who have read this far might wonder how to handle situations where the plan document has omissions and additional work is needed.
In this case, I either add a new checkbox to the implementation items in the plan document and instruct, "Implement the unchecked items," or I add a 'Follow-up' section at the end of the 'Process' section in the plan document, describe unplanned/unexpected tasks there, and have Aider execute them.
Finally
By using the method introduced, I have been able to generate code that I am satisfied with.
The approach of creating a plan document can probably be applied to other tools like Devin and Windsurf (although I personally don't use AI agent tools for implementations that require a plan document).
I hope this method will be helpful to you in some way.
Discussion