Aider: The Git-Native Pair Programmer
Deep-Dive DD-02 · Harness Engineering Master Course
60 minutes · The thin-medium reference — the first harness to the right of Pi, and the comparison question: how much thickness does git buy, and why?
~8 tools, ~2k prompt, ~25k LOC, git-gated. Three years of iteration. Created the Aider Polyglot Benchmark — the field's de facto coding-agent evaluation. The git-first philosophy is the differentiator.
Deep-Dives
The thesis — git-as-substrate is the multiplier
Aider's git-first philosophy is the differentiator. Pi (DD-01) has no memory, no checkpointing, no verification. Aider gets all three — plus permission and observability — for free by using git as the substrate. One infrastructure choice yields five rubric modules. This is the +7 over Pi.
Pi (DD-01) — 25/60
4 tools, <1k prompt, trust-the-model. No memory, no checkpoint, no verification. The thin reference.
Aider (DD-02) — 32/60
~8 tools, ~2k prompt, git-gated. Git yields memory + state + verification + permission + observability. +7, almost entirely from git.
Git-as-substrate — five modules from one choice
M4
Memory
Commits = checkpoints across sessions. git log is the history.
M8
State
git reset = native rollback. Every change is a recoverable checkpoint.
M9
Verification
The diff IS the verification — the human reviews git diff.
M6
Permission
Git-gated: review every change. Post-hoc, not real-time, but native rollback.
M11
Observability
git log is the trace — human-readable history of every change.
M3
Context
+ the repo-map (AST-based file index) — structure without reading every file.
No other harness gets this much from a single decision. Git is the multiplier. The entire +7 over Pi comes from this one infrastructure choice.
The 12-module audit — where the +7 comes from
| Module | Pi | Aider | Delta | Source |
|---|
| M3 Context | 2 | 4 | +2 | repo-map (AST index) |
| M4 Memory | 1 | 3 | +2 | git commits = checkpoints |
| M6 Permission | 2 | 3 | +1 | git-gated review |
| M7 Errors | 2 | 3 | +1 | diff-failure self-correct |
| M8 State | 1 | 4 | +3 | git commits = rollback |
| M9 Verification | 1 | 3 | +2 | diff-as-implicit-verification |
| M11 Observability | 2 | 3 | +1 | git log = trace |
| M2 Tools | 5 | 4 | -1 | more tools = more noise (purposeful) |
| M12 Prompt | 5 | 4 | -1 | ~2k (editing format) vs <1k |
| M5 Sandbox | 1 | 1 | = | none (blast radius = host) |
TOTAL: 32/60 (+7 vs Pi). The +7 comes almost entirely from git: +2 context, +2 memory, +3 state, +2 verification, +1 permission, +1 observability. The two -1s are the cost of specialization.
The security nuance — git-gating catches wrong, not malicious
Git-gating CATCHES the honest mistake
Model produces a wrong edit (misunderstood the task). Human reviews git diff, spots the error, git reset HEAD~1 — rolled back. Git-gating works.
Git-gating does NOT catch the injection
Model is prompt-injected (README contained ASI01). Produces a benign-looking "refactor" that also reads ~/.ssh/cred + curls to attacker. Human reviews the diff — payload may look like part of the refactor. MISS. Commit executes — exfiltration succeeds.
Git-gating is a change-QUALITY control, not an injection DEFENSE. The diff-review answers "is this the change I asked for?" not "is this change safe to apply?" A prompt-injected model produces a change that is exactly what the attacker asked for.
Three decisions I agree with
Git-as-substrate. The multiplier. Five modules from one choice. No other decision in the roster delivers this much.
Diff-based editing. Search/replace blocks are more reliable than whole-file writes. Less token cost, fewer hallucinated-full-file errors. Three years of iteration refined this to the field's best.
The repo-map. AST-based structure, not padding. Gives the model the repository's symbol graph without reading every file. A clean middle path between Pi's nothing and a thick harness's full retrieval.
Three decisions I would make differently
Add a sandbox (Docker). Blast radius is the host, same as Pi. Git-gating catches wrong changes but not malicious exfiltration. A compromised Aider process can read ~/.ssh before the human reviews the diff.
Add untrusted-content tagging on file reads. A README read by the agent could contain injection that survives the diff-review (the injection case above). This is the M2.4 / ASI01 gap.
Add a token budget. Three years of iteration hasn't added one; a long session can still run away. The cheapest missing stop condition.
Aider's defining contribution — the benchmark
Aider created the Aider Polyglot Benchmark — the de facto standard for evaluating coding agents across languages. 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." Every coding-agent benchmark you read is either Aider's or measured against Aider's.
Maturity: three years of iteration (2023–2026). The diff-editing, the repo-map, and the git integration are battle-tested in a way no newer harness matches.
Anti-patterns
"Aider has git-gating, so it's secure." Git-gating catches wrong changes, not malicious ones. Add untrusted-content tagging if the agent reads attacker-controllable files.
"Aider's diff-editing makes it general-purpose." The diff format is coding-specific. Do not deploy Aider for non-coding tasks. Use Pi for general tool-use; use Aider for code.
"Aider's ~8 tools violate the 4-tool philosophy." The 4-tool philosophy is a noise-reduction strategy for GENERAL tool-use. Aider's ~8 tools are coding/git-specific and purpose-built — they add capability without dispatch noise. Evaluate tool count against use case.
What you can now do
- Apply the 6-phase methodology to Aider and produce a scored card with file:line evidence.
- Explain Aider's git-first philosophy as a distinct architectural bet — git-as-substrate yielding 5 modules from one choice.
- Compare Aider (thin-medium) against Pi (thin) module-by-module: the +7 comes from git.
- State why Aider's benchmark creation makes it the field's reference for coding-agent performance.
- Articulate the critical limitation: git-gating catches wrong changes, not malicious ones.
- Identify the three changes that move Aider from "mature" to "production-grade" without compromising git-first value.
The lab: model Aider's git-gated loop as a trace, score Aider against Pi module-by-module to confirm the +7 from git, and construct the "malicious-but-benign-looking" scenario that defeats git-gating.
Next: DD-03 — OpenCode: The Terminal-Native Harness