Course: Master Course · Deep-Dive: DD-02 · Duration: 60 min · Prerequisites: Modules 0–12, DD-01
3 years of iteration. Git-first philosophy. Created the Aider Polyglot Benchmark — the field's de facto coding-agent benchmark. The thin-medium reference.
| Metric | Value |
|---|---|
| Language | Python |
| Stars | 44,500+ |
| License | Apache 2.0 |
| Model flexibility | 100+ via LiteLLM |
| Tools | ~8 |
| System prompt | ~2,000 tokens |
| Permission model | Git-gated |
| Total LOC | ~25,000 |
Aider is the benchmark creator. It invented the Aider Polyglot Benchmark — the de facto standard for evaluating coding agents across languages. Three years of iteration (2023–2026) have made it the most mature coding agent in the thin-medium range.
Aider is Python — significantly larger than Pi (~25k LOC vs ~1.2k) but still readable. The entry point is aider/main.py. The git-first philosophy is visible immediately: Aider treats git as the substrate for everything — checkpoints, rollback, diff-based editing, and the permission model.
The system prompt (~2k tokens) is larger than Pi's but still thin — it specifies the editing format (search/replace blocks), git conventions, and behavioral guidelines.
Loop: ReAct-derived, but specialized for code editing. Instead of generic tool-use, Aider uses a diff-based editing format — the model outputs search/replace blocks that Aider applies to files. This is more reliable than "write the whole file" (the write_file approach) because it targets specific changes.
Tools (~8): read_file, write_file, edit (search/replace blocks), bash, search, plus git-specific operations. More than Pi's 4, but each is purpose-built for the coding use case.
Permission model: Git-gated. Aider commits after each change; the user can review the git diff and git reset if the change is wrong. This is a distinct permission architecture — not per-action approval (Module 6), but per-commit review with native rollback. It trades real-time approval for post-hoc review with version control.
Stop conditions: end_turn, max-iterations. Plus: the user can interrupt at any time (Ctrl+C). No token budget, no error threshold. Similar to Pi here.
| Module | Pattern | Tradeoff | vs Pi |
|---|---|---|---|
| 1 Loop | ReAct + diff-based editing | specialized; less general | more reliable for code |
| 2 Tools | ~8, git-integrated | more than Pi; purpose-built | +capability, +noise |
| 3 Context | repo-map (AST-based file index) | better than Pi's nothing | real context management |
| 4 Memory | git as checkpoint | version-controlled state | real multi-session via git |
| 5 Sandbox | none (OS process) | same blast radius as Pi | no improvement |
| 6 Permission | git-gated (post-hoc review + rollback) | distinct bet; not real-time | better for coding, worse for destructive |
| 7 Errors | model self-corrects via diff failures | relies on model | similar to Pi |
| 8 State | git commits | native rollback | much better than Pi |
| 9 Verification | the diff IS the verification (human reviews) | implicit verification | clever coding-specific |
| 10 Subagents | none | — | same as Pi |
| 11 Observability | git log as the trace | human-readable history | better than Pi's console.log |
| 12 Prompt | ~2k (editing format + git conventions) | more than Pi, still thin | +explicit behavior control |
The git-first philosophy is the differentiator. Pi has no memory, no checkpointing, no verification. Aider gets all three — for free — by using git as the substrate. This is the architectural insight that makes Aider the thin-medium reference: git gives you state (Module 8), memory across sessions (Module 4), verification (Module 9 — the human reviews the diff), and permission (Module 6 — git-gated review), all from one infrastructure choice.
Same blast-radius issue as Pi: bash is full shell; no sandbox; no filesystem scope. Git-gating means changes are reviewable, but a compromised Aider process can still read ~/.ssh and exfiltrate before the human reviews the diff. The git review catches wrong changes, not malicious ones — if the model is prompt-injected, it can commit a change that looks benign but includes an exfiltration payload.
Aider's defining contribution: the Aider Polyglot Benchmark. A standardized set of coding tasks across multiple languages, used by the field to evaluate coding-agent performance. Most published coding-agent benchmark numbers you see trace back to Aider's benchmark methodology. This is why Aider is the reference — not because it's the best harness, but because it defined how the field measures "best."
| Module | Score | Key decision | vs Pi |
|---|---|---|---|
| 1 Loop | 4 | ReAct + diff editing | = |
| 2 Tools | 4 | ~8, git-integrated | -1 (more noise, but purposeful) |
| 3 Context | 4 | repo-map (AST index) | +2 |
| 4 Memory | 3 | git as checkpoint | +2 |
| 5 Sandbox | 1 | none | = |
| 6 Permission | 3 | git-gated | +1 |
| 7 Errors | 3 | diff-failure self-correct | +1 |
| 8 State | 4 | git commits | +3 |
| 9 Verification | 3 | diff-as-implicit-verification | +2 |
| 10 Subagents | — | n/a | = |
| 11 Observability | 3 | git log as trace | +1 |
| 12 Prompt | 4 | ~2k, editing format | -1 (less thin, but more capable) |
| TOTAL | 32/60 | +7 vs Pi |
The +7 over Pi comes almost entirely from the git-first philosophy: +2 context (repo-map), +2 memory (git), +3 state (git), +2 verification (diff review), +1 permission (git-gated), partially offset by slightly more tool noise and prompt density. Git is the multiplier.
Aider optimizes for coding reliability via git-as-substrate — using version control to get state, memory, verification, and permission from one infrastructure choice. It sacrifices generality (diff-based editing is coding-specific) and blast-radius safety (no sandbox, same as Pi). Build on Aider for any code-editing task where git is available; it is the field's most mature coding agent and the creator of the benchmark everyone else measures against.
Aider's git-gating provides change review and rollback but NOT injection defense — a prompt-injected model can commit a benign-looking change that contains an exfiltration payload, passing human diff-review while executing maliciously.
# Deep-Dive DD-02 — Aider: The Benchmark Creator **Course**: Master Course · **Deep-Dive**: DD-02 · **Duration**: 60 min · **Prerequisites**: Modules 0–12, DD-01 > *3 years of iteration. Git-first philosophy. Created the Aider Polyglot Benchmark — the field's de facto coding-agent benchmark. The thin-medium reference.* --- ## Learning Objectives 1. Apply the 6-phase methodology to Aider; produce a scored card. 2. Explain Aider's git-first philosophy as a distinct architectural bet. 3. Compare Aider (thin-medium) against Pi (thin) — what does the medium thickness buy? 4. State why Aider's benchmark creation makes it the field's reference for coding-agent performance. --- ## The Subject | Metric | Value | | --- | --- | | Language | Python | | Stars | 44,500+ | | License | Apache 2.0 | | Model flexibility | 100+ via LiteLLM | | Tools | ~8 | | System prompt | ~2,000 tokens | | Permission model | Git-gated | | Total LOC | ~25,000 | Aider is the benchmark creator. It invented the Aider Polyglot Benchmark — the de facto standard for evaluating coding agents across languages. Three years of iteration (2023–2026) have made it the most mature coding agent in the thin-medium range. ## Phase 1 — First Contact Aider is Python — significantly larger than Pi (~25k LOC vs ~1.2k) but still readable. The entry point is `aider/main.py`. The git-first philosophy is visible immediately: Aider treats git as the substrate for everything — checkpoints, rollback, diff-based editing, and the permission model. The system prompt (~2k tokens) is larger than Pi's but still thin — it specifies the editing format (search/replace blocks), git conventions, and behavioral guidelines. ## Phase 2 — Architecture Map **Loop**: ReAct-derived, but specialized for code editing. Instead of generic tool-use, Aider uses a **diff-based editing format** — the model outputs search/replace blocks that Aider applies to files. This is more reliable than "write the whole file" (the `write_file` approach) because it targets specific changes. **Tools** (~8): `read_file`, `write_file`, edit (search/replace blocks), `bash`, search, plus git-specific operations. More than Pi's 4, but each is purpose-built for the coding use case. **Permission model**: **Git-gated**. Aider commits after each change; the user can review the git diff and `git reset` if the change is wrong. This is a distinct permission architecture — not per-action approval (Module 6), but per-commit review with native rollback. It trades real-time approval for post-hoc review with version control. **Stop conditions**: end_turn, max-iterations. Plus: the user can interrupt at any time (Ctrl+C). No token budget, no error threshold. Similar to Pi here. ## Phase 3 — Design Decision Audit | Module | Pattern | Tradeoff | vs Pi | | --- | --- | --- | --- | | 1 Loop | ReAct + diff-based editing | specialized; less general | more reliable for code | | 2 Tools | ~8, git-integrated | more than Pi; purpose-built | +capability, +noise | | 3 Context | repo-map (AST-based file index) | better than Pi's nothing | real context management | | 4 Memory | git as checkpoint | version-controlled state | real multi-session via git | | 5 Sandbox | none (OS process) | same blast radius as Pi | no improvement | | 6 Permission | git-gated (post-hoc review + rollback) | distinct bet; not real-time | better for coding, worse for destructive | | 7 Errors | model self-corrects via diff failures | relies on model | similar to Pi | | 8 State | git commits | native rollback | much better than Pi | | 9 Verification | the diff IS the verification (human reviews) | implicit verification | clever coding-specific | | 10 Subagents | none | — | same as Pi | | 11 Observability | git log as the trace | human-readable history | better than Pi's console.log | | 12 Prompt | ~2k (editing format + git conventions) | more than Pi, still thin | +explicit behavior control | **The git-first philosophy is the differentiator.** Pi has no memory, no checkpointing, no verification. Aider gets all three — for free — by using git as the substrate. This is the architectural insight that makes Aider the thin-medium reference: git gives you state (Module 8), memory across sessions (Module 4), verification (Module 9 — the human reviews the diff), and permission (Module 6 — git-gated review), all from one infrastructure choice. ## Phase 4 — Security Audit Same blast-radius issue as Pi: `bash` is full shell; no sandbox; no filesystem scope. Git-gating means changes are reviewable, but a compromised Aider process can still read `~/.ssh` and exfiltrate before the human reviews the diff. The git review catches wrong changes, not malicious ones — if the model is prompt-injected, it can commit a change that looks benign but includes an exfiltration payload. ## Phase 5 — Benchmark Aider's defining contribution: the **Aider Polyglot Benchmark**. A standardized set of coding tasks across multiple languages, used by the field to evaluate coding-agent performance. Most published coding-agent benchmark numbers you see trace back to Aider's benchmark methodology. This is why Aider is the reference — not because it's the best harness, but because it defined how the field measures "best." ## Phase 6 — Score & Synthesize ### Scoring sheet | Module | Score | Key decision | vs Pi | | --- | --- | --- | --- | | 1 Loop | 4 | ReAct + diff editing | = | | 2 Tools | 4 | ~8, git-integrated | -1 (more noise, but purposeful) | | 3 Context | 4 | repo-map (AST index) | +2 | | 4 Memory | 3 | git as checkpoint | +2 | | 5 Sandbox | 1 | none | = | | 6 Permission | 3 | git-gated | +1 | | 7 Errors | 3 | diff-failure self-correct | +1 | | 8 State | 4 | git commits | +3 | | 9 Verification | 3 | diff-as-implicit-verification | +2 | | 10 Subagents | — | n/a | = | | 11 Observability | 3 | git log as trace | +1 | | 12 Prompt | 4 | ~2k, editing format | -1 (less thin, but more capable) | | **TOTAL** | **32/60** | | **+7 vs Pi** | The +7 over Pi comes almost entirely from the git-first philosophy: +2 context (repo-map), +2 memory (git), +3 state (git), +2 verification (diff review), +1 permission (git-gated), partially offset by slightly more tool noise and prompt density. Git is the multiplier. ### Architect's Verdict (3 sentences) > *Aider optimizes for coding reliability via git-as-substrate — using version control to get state, memory, verification, and permission from one infrastructure choice. It sacrifices generality (diff-based editing is coding-specific) and blast-radius safety (no sandbox, same as Pi). Build on Aider for any code-editing task where git is available; it is the field's most mature coding agent and the creator of the benchmark everyone else measures against.* ### MLSecOps Relevance (1 sentence) > *Aider's git-gating provides change review and rollback but NOT injection defense — a prompt-injected model can commit a benign-looking change that contains an exfiltration payload, passing human diff-review while executing maliciously.* ### 3 things Aider does better than any other 1. **Git-as-substrate**: state + memory + verification + permission from one infrastructure choice. No other harness gets this much from a single decision. 2. **Benchmark creation**: defined how the field measures coding-agent performance. Every benchmark number traces to Aider's methodology. 3. **Diff-based editing reliability**: search/replace blocks are more reliable than whole-file writes. Three years of iteration have refined this to the field's best. ### 3 things to fix 1. Add a sandbox (Docker) — the blast radius is the host, same as Pi. 2. Add untrusted-content tagging on file reads — a README read by the agent could contain injection. 3. Add a token budget — 3 years of iteration hasn't added one; a long session can still run away. --- ## References 1. **Aider source** — [github.com/Aider-AI/aider](https://github.com/Aider-AI/aider) 2. **Aider Polyglot Benchmark** — the field's de facto coding-agent evaluation. 3. **DD-01 (Pi)** — the thin reference; Aider is +7 via git. 4. **Modules 4, 8, 9** — git as memory, checkpoint, verification.