mirror of
https://github.com/Aider-AI/aider.git
synced 2025-06-01 02:05:00 +00:00
copy
This commit is contained in:
parent
6d5575c705
commit
0b6c3f1c28
2 changed files with 40 additions and 1 deletions
|
@ -219,6 +219,36 @@ In particular, chaining older LLMs would have been quite slow and
|
|||
contrary to aider's goal of providing a rapid, interactive,
|
||||
pair programming AI coding experience.
|
||||
|
||||
## Code reasoning and code editing
|
||||
|
||||
Aider uses a variety of
|
||||
[edit formats](/docs/more/edit-formats.html)
|
||||
to allow LLMs to specify edits to local source files.
|
||||
All of aider's editing formats require the LLM to return source code edits in a specific text
|
||||
format, so that aider can process the edits and apply them to the local source files.
|
||||
|
||||
Normally, aider asks the model to solve the coding problem by returning a well
|
||||
formatted series of file edits.
|
||||
Aider encourages "chain of thought" by asking the model to explain the solution
|
||||
before diving into code edits.
|
||||
But this all happens in a single prompt/response round trip to the LLM,
|
||||
and the model has to spend some attention on confirming to the edit format.
|
||||
|
||||
The Senior/Junior approach splits this into two round trips, possible
|
||||
using two different LLMs:
|
||||
|
||||
- Ask how to solve the coding problem (Senior).
|
||||
- Ask for the solution as a series of well formed code edits (Junior).
|
||||
|
||||
The Senior/Junior approach allows the Senior to focus on solving the coding problem
|
||||
and leaves the task of turning that into properly formatted edits to the Junior.
|
||||
This gives the Senior more reasoning capacity to focus just on solving the coding
|
||||
task.
|
||||
We can also assign the Senior task to a strong reasoning model like o1-preview,
|
||||
and give the editing task to an appropriate model based on cost, editing skill, etc.
|
||||
Similarly, the Junior can focus all of its attention on properly formatting the edits
|
||||
without needing to reason much about how to solve the coding problem.
|
||||
|
||||
## Results
|
||||
|
||||
The graph above and the table below show the
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
parent: More info
|
||||
nav_order: 1000
|
||||
nav_order: 960
|
||||
description: Aider uses various "edit formats" to let LLMs edit source files.
|
||||
---
|
||||
|
||||
|
@ -17,6 +17,9 @@ the `--edit-format` switch.
|
|||
The "whole" edit format is the simplest possible editing format.
|
||||
The LLM is instructed to return a full, updated
|
||||
copy of each source file that needs changes.
|
||||
While simple, it can be slow and costly because the LLM has to return
|
||||
the *entire file* even if just a few lines are edited.
|
||||
|
||||
The format expects the file path just before the fenced file content:
|
||||
|
||||
````
|
||||
|
@ -36,6 +39,9 @@ if __name__ == '__main__':
|
|||
## diff
|
||||
|
||||
The "diff" edit format asks the LLM to specify file edits as a series of search/replace blocks.
|
||||
This is an efficient format, because the model only needs to return parts of the file
|
||||
which have changes.
|
||||
|
||||
They are formatted using a syntax similar to the git merge conflict resolution markings,
|
||||
with the file path right before a fenced block:
|
||||
|
||||
|
@ -74,6 +80,9 @@ from flask import Flask
|
|||
|
||||
The "udiff" edit format is based on the widely used unified diff format,
|
||||
but [modified and simplified](/2023/12/21/unified-diffs.html).
|
||||
This is an efficient format, because the model only needs to return parts of the file
|
||||
which have changes.
|
||||
|
||||
It was mainly used to the GPT-4 Turbo family of models,
|
||||
to reduce their "lazy coding" tendencies with other edit formats.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue