diff --git a/aider/website/_posts/2024-09-26-senior-junior.md b/aider/website/_posts/2024-09-26-senior-junior.md
index b7b6b39c5..8217a850c 100644
--- a/aider/website/_posts/2024-09-26-senior-junior.md
+++ b/aider/website/_posts/2024-09-26-senior-junior.md
@@ -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
diff --git a/aider/website/docs/more/edit-formats.md b/aider/website/docs/more/edit-formats.md
index 9540a61a6..6c590d810 100644
--- a/aider/website/docs/more/edit-formats.md
+++ b/aider/website/docs/more/edit-formats.md
@@ -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.