I have been using Aider on and off for a couple of months now. I have found its defaults to be pretty bad (at least for me), and so I decided to write up on how I use it and the configuration I use with it.

Note: ‘model’ in this text refers to large language models (LLMs), and more specifically, those that are reasonably good at reasoning/coding tasks. Currently I am using mainly Claude 3.7 Sonnet, but the model I use seems to change every month (o3-mini high-reason was the one I used last month), and the recent Deepcoder release makes it possible I will try using local model again soon as my main model.

Disclaimer: I never update my blog posts, although some of the data here (e.g. read-only handling) has been verified quite seriously by looking at source code to make sure I am not making things up. Due to that, the recommended configuration is only point-in-time snapshot of what I use, not what I use next month, year, or whatever - as a matter of fact, I may have found something better than Aider next week anyway.

Aider - what is it about?

The basic idea of Aider is pretty simple - it creates map of your git repository files, and based on it and your request, the model can prompt for files to include and shell commands to execute to do what you want.

First of all, Aider has three of modes, to interact with models:

  • /code mode (the default) - whatever you type, Aider tries to do (edit files, run scripts)
  • /ask - Aider will discuss your code, but not make changes until you tell it to Do it in non /ask request
  • /architect - two models collaborating (advanced version of code mode), I haven’t seen much better results from it so I have not used it much

As far as files go, Aider does not change any file you have not given it access to, or execute shell commands. It will prompt you for both as the model sees necessary. When starting Aider, you can pass it files that it can edit, or you can in the interactive CLI use:

  • /add <file-or-glob> which adds file that model can change
  • /read-only <file-or-glob> which adds file that model can refer to, but cannot change

My Aider workflow

As noted in the previous blog post, I have couple of different shell aliases which invoke Aider with different models.

alias aider-claude='aider --model anthropic/claude-3-7-sonnet-latest'
alias aider-gpt-o3-mini='aider --model o3-mini --reasoning-effort high'
alias aider-gpt-4o='aider --model chatgpt-4o-latest'
alias aider-local='aider --model ollama_chat/deepcoder'

Mostly I use Claude right now. GPT-4.5 I dropped as it is expensive and not substantially better than the two other GPT options (see previous blog post).

Case 1: Interactive CLI

Typical usage for me is something like this:

some-directory-in-git> aider-claude feature*.go
^ include both feature and feature_test.go
Analytics have been permanently disabled.
────────────────────────────────────────────────────────────────────────────────
Aider v0.81.1
Main model: anthropic/claude-3-7-sonnet-latest with diff edit format, prompt
cache, infinite output
Weak model: anthropic/claude-3-5-haiku-20241022
...
Repo-map: using 4096 tokens, files refresh
Added CONVENTIONS.md to the chat (read-only).
...
> do X
...
> nono. do Y
...

During iteration, I usually look at git diff in another window, and yet another window has watchman-make running automatically unit tests on code change. Once I am happy with what I see in the git diff, and tests pass, I commit the changes (either amending existing commit or adding new commit). I may also edit the files by hand in Emacs which is yet another window.

Case 2: Aider in Emacs

Alternatively, if I am doing only changes to a single file, I go to the file and insert a relevant comment within the buffer in Emacs, e.g.

... code ..
Fix the code above AI!
.. even more code ...

and due to watch-files mode (see below), Aider detects the file change, the AI! ending line, and treats it as CLI command to run in /code mode. Once Aider is done editing file(s), Emacs auto-revert-mode reloads the buffer, and AI replaced version is there for me to admire.

My non-default configuration

This is how much I have to tune the Aider configuration to get the non-default behaviour for the workflows I use ( .aider.conf.yml in my home directory ):

# Differences to defaults - from
# https://aider.chat/docs/config/aider_conf.html

## Show release notes on first run of new version (default: None, ask user)
show-release-notes: false
#^ I autoupgrade via pyinfra script every now and then, and this is just distraction

## Enable caching of prompts (default: False)
cache-prompts: true
#^ This is brilliant; /read-only files and others are prompt cached, and on supported providers, the result is much faster. I don't know why default is False and I am too afraid to ask.

## Number of times to ping at 5min intervals to keep prompt cache warm (default: 0)
cache-keepalive-pings: 2
# ^ prompt cache by default expires in 5min - sometimes I may be going for cuppa or something, so 15 minutes seems safer

## Enable/disable adding .aider* to .gitignore (default: True)
gitignore: false
# ^ I have bit custom .gitignores, and the default is annoying

## Enable/disable git pre-commit hooks with --no-verify (default: False)
git-commit-verify: true
# ^ if I use commit, I definitely want to follow hooks (this doesn't work with auto-commit or dirty-commits well, btw)

## Enable/disable auto commit of LLM changes (default: True)
auto-commits: false
# ^ this is the most puzzling feature of all in Aider. By default it commits AI garbage commits at furious rate, and at some point I used this option and spent lots of time doing 'git rebase -i' to fixup these commits and eventually I realized I just rather operate git by hand.

## Enable/disable commits when repo is found dirty (default: True)
dirty-commits: false
# ^ again, manual is better

## Enable/disable watching files for ai coding comments (default: False)
watch-files: true
# ^ This is the killer feature of Aider - AI? (ask mode) and AI! (code mode) prompt detection in subtree

## Enable/disable automatic testing after changes (default: False)
auto-test: false
# ^ I have vacillated between true and false here, and that is why I have it in the file even if it is the default now. Weirdly enough, Claude frequently still wants to test its changes, GPT-4O less so.

## Permanently disable analytics
analytics-disable: true
# ^ Not a fan.

## Check for new aider versions on launch
check-update: false
# ^ Updates elsewhere

Additionally in all git repositories I use with Aider, I have following .aider.conf.yml:

read:
- /absolute/path/to/gitroot/CONVENTIONS.md

and then I stick the preferred coding style hints in the CONVENTIONS.md. For example, subset of my last weekends vibe coding exercise file contains following:

# Conventions and information for Aider

- For any new code, implement a test for it too in the corresponding
  test file

- Assume pre-commit binary is already installed

- Assume uv binary is already installed, and Python should be invoked using it

- Files used by tests should be in testdata subfolder

- Do not use type hints in Python code

- Do not add special cases but instead try to come up with generic code

- You are not allowed to edit testdata/ content if it exists. The code
  should be fixed to conform instead.

Note: the read paths in configuration are NOT same as what using /read-only within CLI does. /read-only uses git directory offset, and allows for globbing, and read statement only uses relative path to current work directory and-or absolute path, either to a file OR directory (if directory, all files are added).

Disclaimer: This is 2025-04-11 / Aider v0.81.1, in case it changes later on.

Is it worth it?

For me, definitely. I use it as mainly as a super clever auto-complete - I can get blocks of code by typing one or two lines of description. I then may refine them by typing line or two more, or not.

Why not

  • Cursor? Not fan of custom editors, or using mouse while working for that matter
  • Continue? Not a fan of the editors they support
  • Github Copilot? It is bit limited autocompletion only, and not really in same category

Anyway, this is it, I just decided to write this down to share the read-only file handling pain point I noticed (and some other stuff as side effect).