anotherpaulg

It works like normal git blame -- it literally uses git blame.

Whoever changed a line last gets credit. Only the new or newly changed lines in each release are considered.

So no, "lines/diffs otherwise untouched" are NOT considered written by aider. That wouldn't make sense?

You can use an .aiderignore file to ensure aider doesn't use certain files/dirs/etc. It conforms to the .gitignore spec.

Thanks for your interest in aider.

Yes, absolutely you can work with local models. Here are the docs for working with lmstudio and ollama:

https://aider.chat/docs/llms/lm-studio.html

https://aider.chat/docs/llms/ollama.html

Glad to hear you’re finding aider useful!

There’s a faq entry about how these stats are computed [0]. Basically using git blame, since aider is tightly integrated with git.

The faq links to the script that computes the stats. It’s not designed to be used on any repo, but you (or aider) could adapt it.

You’re not the first to ask for these stats about your own repo, so I may generalize it at some point.

[0] https://aider.chat/docs/faq.html#how-are-the-aider-wrote-xx-...

> 99% of the code in this PR [for llama.cpp] is written by DeekSeek-R1

It's definitely possible for AI to do a large fraction of your coding, and for it to contribute significantly to "improving itself". As an example, aider currently writes about 70% of the new code in each of its releases.

I automatically track and share this stat as graph [0] with aider's release notes.

Before Sonnet, most releases were less than 20% AI generated code. With Sonnet, that jumped to >50%. For the last few months, about 70% of the new code in each release is written by aider. The record is 82%.

Folks often ask which models I use to code aider, so I automatically publish those stats too [1]. I've been shifting more and more of my coding from Sonnet to DeepSeek V3 in recent weeks. I've been experimenting with R1, but the recent API outages have made that difficult.

[0] https://aider.chat/HISTORY.html

[1] https://aider.chat/docs/faq.html#what-llms-do-you-use-to-bui...

Yes, aider can also work in architect/editor mode [0] which tends to produce the best results [1]. An architect model solves the coding problem and describes the needed changes however comes naturally to it. The editor model then takes that solution and turns it into correctly formatted instructions to edit the files.

Too much context can still confuse the LLMs in this situation, but they may be somewhat more resilient.

[0] https://aider.chat/2024/09/26/architect.html

[1] https://aider.chat/2025/01/24/r1-sonnet.html

This is a harsh foot-gun that seems to harm many ollama users.

That 2k default is extremely low, and ollama *silently* discards the leading context. So users have no idea that most of their data hasn’t been provided to the model.

I’ve had to add docs [0] to aider about this, and aider overrides the default to at least 8k tokens. I’d like to do more, but unilaterally raising the context window size has performance implications for users.

Edit: Ok, aider now gives ollama users a clear warning when their chat context exceeds their ollama context window [1].

[0] https://aider.chat/docs/llms/ollama.html#setting-the-context...

[1] https://github.com/Aider-AI/aider/blob/main/aider/coders/bas...

I'm guessing you're interesting in R1+Sonnet because of the recent SOTA benchmark result? It does seem to be a powerful architect/editor combo.

https://aider.chat/2025/01/24/r1-sonnet.html

Yes, that is true. Aider expects to work with the LLM to automatically apply edits to the source files. This requires precision from the LLM, which is what breaks down when you overload them with context.

In my experience with AI coding, very large context windows aren't useful in practice. Every model seems to get confused when you feed them more than ~25-30k tokens. The models stop obeying their system prompts, can't correctly find/transcribe pieces of code in the context, etc.

Developing aider, I've seen this problem with gpt-4o, Sonnet, DeepSeek, etc. Many aider users report this too. It's perhaps the #1 problem users have, so I created a dedicated help page [0].

Very large context may be useful for certain tasks with lots of "low value" context. But for coding, it seems to lure users into a problematic regime.

[0] https://aider.chat/docs/troubleshooting/edit-errors.html#don...

Mostly I just review the chat output. But I also use /diff to see actual unified diffs of the last AI change. Or if I have made a sequence of changes, I'll use my normal git tools to diff the entire branch, etc.

I use aider to work on the aider code base, which is approaching 30k lines of python. Aider writes about 70% of the new code in each release [0]. So it's doing some fairly heavy lifting in a non-trivial code base.

Some pragmatic tips:

- Work with AI like a junior developer, except with unlimited energy and no problem being corrected repeatedly.

- Provide the AI with guidance about conventions you expect in your code base, overall architecture, etc [1]. You can often use AI tools to help write the first draft of such "conventions" documents.

- Break the work down into self-contained bite sized steps. Don't ask AI to boil the ocean in one iteration. Ask it to make a sequence of changes that each move the code towards the goal.

- Be willing to explore for a few steps with the AI. If it's going sideways, undo/revert. Hopefully your AI tool has good checkpoint/undo/git support [2].

- Lint and test the code after each AI change. Hopefully your AI tool can automatically do that, and fix problems [3].

- If the AI is stuck, just code yourself until you get past the tricky part. Then resume AI coding when the going is easier.

- Build intuition for what AI tools are good at, use them when they're helpful. Code yourself when not.

Some things AI coding is very helpful for:

- Rough first draft of a change or feature. AI can often speed through a bunch of boilerplate. Then you can polish the final touches.

- Writing tests.

- Fixing fairly simple bugs.

- Efficiently solving problems with packages/libraries you may not have known about.

[0] https://aider.chat/HISTORY.html

[1] https://aider.chat/docs/usage/conventions.html

[2] https://aider.chat/docs/git.html

[3] https://aider.chat/docs/usage/lint-test.html

Absolutely! Code has vastly more useful structure than prose.

Aider exploits all this structure, using a "repository map" [0]. It use tree-sitter to build a call graph of the code base. Then runs a graph optimization on it with respect to the current state of the AI coding chat. This finds the most relevant parts of the code base, which aider shares with the LLM as context.

Your first link to RepoGraph is an adaptation of the actual aider repo map implementation. In their source code [1], they have some acknowledgements to aider and grep-ast (which is part of aider).

[0] https://aider.chat/docs/repomap.html

[1] https://github.com/ozyyshr/RepoGraph/blob/79861642515f0d6b17...

I ran a few experiments by adding 0, 1 or 2 "write better code" prompts to aider's benchmarking harness. I ran a modified version of aider's polyglot coding benchmark [0] with DeepSeek V3.

Here are the results:

        | Number of 
        | "write better code"
  Score | followup prompts
  ---------------------------
  27.6% | 0 (baseline)
  19.6% | 1
  11.1% | 2
  

It appears that blindly asking DeepSeek to "write better code" significantly harms its ability to solve the benchmark tasks. It turns working solutions into code that no longer passes the hidden test suite.

[0] https://aider.chat/docs/leaderboards/

I have long relied on a print-debug function I wrote for python called dump(). You do dump(foo) and it will print out "foo: value". Where the variable name "foo" is magically pulled out of the source code and "value" is a json-dump of its value. So dicts look pretty, like the example below.

This is similar to the "debug f-strings" introduced in python 3.8: print(f"{foo=}"). But it's much easier to type dump(foo) and you get prettier output for complex types.

  x = 3 
  foo = dict(bar=1, baz=dict(hello="world"))
  dump(x) 
  dump(foo)
  
  # prints...
  
  x: 3 
  foo:
  {
      "bar": 1,
      "baz": {
          "hello": "world"
      }
  }

https://github.com/Aider-AI/aider/blob/main/aider/dump.py

Super interesting, thanks for sharing. How large a corpus of domain specific text do you need to obtain a useful knowledge graph?

Aider has been doing PageRank on the call graph of code repos since forever. All non trivial code has lots of graph structure to support PageRank. So it works really well to find the most relevant context in the project related to the currently active task.

https://aider.chat/docs/repomap.html#optimizing-the-map

I found a related set of experiments that include gpt-3.5-turbo-instruct, gpt-3.5-turbo and gpt-4.

Same surprising conclusion: gpt-3.5-turbo-instruct is much better at chess.

https://blog.mathieuacher.com/GPTsChessEloRatingLegalMoves/

This is exactly how aider shares code context with LLMs using a “repo map”. It uses tree sitter to collapse relevant files into this sort of folded version, showing function signatures but eliding their bodies.

https://aider.chat/docs/repomap.html

The new Sonnet tops aider's code editing leaderboard at 84.2%. Using aider's "architect" mode it sets the SOTA at 85.7% (with DeepSeek as the "editor" model).

  84% Claude 3.5 Sonnet 10/22
  80% o1-preview
  77% Claude 3.5 Sonnet 06/20
  72% DeepSeek V2.5
  72% GPT-4o 08/06
  71% o1-mini
  68% Claude 3 Opus

It also sets SOTA on aider's more demanding refactoring benchmark with a score of 92.1%!

  92% Sonnet 10/22
  75% o1-preview
  72% Opus
  64% Sonnet 06/20
  49% GPT-4o 08/06
  45% o1-mini

https://aider.chat/docs/leaderboards/

You can do this to quickly work on a small script:

  aider --no-git oneoffscript.py

The article describes experiments with aider that show the benefits of using a pair of LLMs to make changes in an existing code base:

  - An Architect model solves the coding task.
  - An Editor model edits the source code.

This approach set a new SOTA on the aider code editing benchmark, using o1-preview as the Architect and either DeepSeek V2.5 or o1-mini as the Editor.

The new Gemini models perform basically the same as the previous versions on aider's code editing benchmark. The differences seem within the margin of error.

https://aider.chat/docs/leaderboards/

OpenAI o1-preview is SOTA at 79.7% on the aider code editing leaderboard, with "whole" edit format. With the practical "diff" format, it ranks between GPT-4o & Sonnet.

  80% o1-preview whole
  77% Sonnet diff
  75% o1-preview diff
  75% Sonnet whole
  71% GPT-4o diff

Yi-Coder scored below GPT-3.5 on aider's code editing benchmark. GitHub user cheahjs recently submitted the results for the 9b model and a q4_0 version.

Yi-Coder results, with Sonnet and GPT-3.5 for scale:

  77% Sonnet
  58% GPT-3.5
  54% Yi-Coder-9b-Chat
  45% Yi-Coder-9b-Chat-q4_0

Full leaderboard:

https://aider.chat/docs/leaderboards/

There’s a little demo video in the Twitter link that might be worth checking out.

But ya, aider can: code something for you, run it, capture the terminal output with pexpect and iterate further based on that.

I just used python pexpect [0] for a fun project. I believe pexpect was inspired by the original Unix expect command.

I used it to let aider suggest and run shell commands [1]. This is handy, so aider can offer to run the code it just wrote for you, run migrations, install dependencies, etc.

Using pexepect makes it easy for aider to run interactive shell commands and capture their output. This allows aider to fix bugs or suggest next steps based on the command’s output, error messages, etc.

[0] https://pexpect.readthedocs.io/en/stable/

[1] https://x.com/paulgauthier/status/1827012590406607040

An aider community member made a neovim plugin. It provides the aider style pair programming chat UX. Not the cursor/copilot AI autocomplete function.

https://github.com/joshuavial/aider.nvim

LLMs produce lower quality code if they’re asked to return it as part of a structured JSON response. This seems to be true for many top models, including those with specialized support for JSON. Benchmarks show that models struggle with syntactic issues related to quoting and escaping. The benchmark results also imply a decreased capacity for solving coding problems due to the burden of JSON formatting.

Not much. I spent $25 on Anthropic in July.

As a comparison, I use aider every day to develop aider.

Aider wrote 61% of the new code in its last release. It’s been averaging about 50% since the new Sonnet came out.

Data and graphs about aider’s contribution to its own code base:

https://aider.chat/HISTORY.html