{ "id": "DD-02-EXAM", "title": "DD-02 — Aider: The Git-Native Pair Programmer", "deep_dive": "DD-02", "duration_minutes": 25, "pass_threshold": 0.70, "total_questions": 15, "bloom_distribution": { "recall": 0.20, "application": 0.40, "analysis": 0.40 }, "questions": [ { "id": "Q01", "bloom": "recall", "question": "What is Aider's permission model?", "options": [ "Trust-the-model (no per-action approval)", "Git-gated (post-hoc diff review + rollback via git reset)", "Per-action human approval for every tool call", "Sandboxed execution with filesystem scoping" ], "answer": 1, "rationale": "Aider commits after each change; the user reviews `git diff` and `git reset` if wrong. This is post-hoc per-commit review with native rollback — a distinct architecture, not per-action approval (Pi) and not sandboxed (Aider has no sandbox)." }, { "id": "Q02", "bloom": "recall", "question": "What is the repo-map?", "options": [ "A vector-store retrieval index for semantic file search", "An AST-based symbol-graph index presented to the model as context", "A git branch containing the repository's documentation", "A token-budget tracker that maps context usage per turn" ], "answer": 1, "rationale": "The repo-map parses source files, extracts the symbol graph (classes, functions, signatures), and presents a compact index to the model — structure without reading every file. It serves Module 3 (Context Management). Not a vector store (that is a thicker-harness pattern)." }, { "id": "Q03", "bloom": "recall", "question": "Why is Aider called 'the benchmark creator'?", "options": [ "It has the highest rubric score of any thin-medium harness", "It created the Aider Polyglot Benchmark — the de facto coding-agent evaluation", "It was the first harness to publish a SWE-bench score", "It invented the 12-module harness-engineering rubric" ], "answer": 1, "rationale": "Aider created the Aider Polyglot Benchmark, the standardized coding-task suite used field-wide. Most published coding-agent benchmark numbers trace to Aider's methodology. Aider is the reference because it defined how the field measures 'best,' not because it has the highest rubric score." }, { "id": "Q04", "bloom": "application", "question": "You fork Aider to harden it for a team that processes untrusted pull-request descriptions. Which change most directly addresses the git-gating injection gap?", "options": [ "Increase the system-prompt token budget so the model has more context", "Add Docker sandboxing to contain blast radius if exfiltration executes", "Add untrusted-content tagging on file/PR-description reads so injected instructions are treated as data", "Reduce the tool count from ~8 to 4 to lower dispatch noise" ], "answer": 2, "rationale": "The injection gap (ASI01/ASI07) is that attacker-controlled content enters context as instructions. Untrusted-content tagging treats it as data, breaking the injection chain at the source. Docker (B) contains blast radius but does not prevent the injection itself; it is a useful second layer. (A) and (D) are unrelated." }, { "id": "Q05", "bloom": "application", "question": "A team wants to use Aider for a DevOps automation task — running terraform and kubectl against production. Is Aider the right tool?", "options": [ "Yes — Aider's git-gating provides safe review for infra changes", "Yes — Aider's maturity makes it suitable for any scripted task", "No — Aider's diff-editing format is coding-specific and assumes parseable source files; use Pi or a general-purpose harness", "No — Aider's tool count is too low for DevOps work" ], "answer": 2, "rationale": "This is the 'diff-editing makes it general-purpose' anti-pattern. Aider's search/replace blocks assume source files with parseable structure. DevOps work (imperative shell commands against stateful infra) does not fit the diff-edit model. Use a general-purpose harness. Tool count is not the issue." }, { "id": "Q06", "bloom": "application", "question": "You are scoring Aider on Module 8 (State). What justifies a 4/5 versus Pi's 1/5?", "options": [ "Aider persists conversation history to a SQLite database", "Aider has a context-window compaction algorithm that preserves state", "Git commits make every change a recoverable checkpoint; `git reset` is native rollback", "Aider runs as a long-lived daemon that holds state in memory" ], "answer": 2, "rationale": "Module 8 scores state/recoverability. Aider's git commits mean every change is checkpointed and `git reset` provides native rollback — +3 over Pi (which is stateless). Not a database (A), not compaction (B, that is Module 3), not a daemon (D)." }, { "id": "Q07", "bloom": "application", "question": "A user says 'Aider is secure because git-gating means every change is reviewed.' Which response is correct?", "options": [ "Correct — git-gating is a complete injection defense", "Partially correct — git-gating reviews change QUALITY, but does not defend against prompt injection that produces benign-looking exfiltration diffs", "Incorrect — git-gating provides no security value at all", "Correct only if the user reviews every diff line-by-line" ], "answer": 1, "rationale": "Git-gating is a change-quality control, not an injection defense. A prompt-injected model produces a diff that is exactly what the attacker asked for — which may look like a legitimate refactor while burying an exfil payload. Even line-by-line review (D) can miss a well-disguised payload. The correct framing is B." }, { "id": "Q08", "bloom": "application", "question": "You trace a single Aider edit-cycle: model emits a search/replace block → block fails to apply (search string not found) → model sees the error → model emits a corrected block → applies. Which module does this self-correction serve?", "options": [ "Module 1 (Execution Loop) — it is a loop-control decision", "Module 3 (Context Management) — it manages what the model sees", "Module 7 (Error Handling) — diff-failure feedback enables retry", "Module 9 (Verification) — the failed apply is a verification signal" ], "answer": 2, "rationale": "This is Module 7 (Error Handling): the diff-apply failure is surfaced as a tool-result error, and the model self-corrects by emitting a corrected block. Aider scores 3/5 on M7 (Pi scored 2) — the diff-failure feedback loop is a coding-specific error-recovery pattern. The verification (D) is the human diff-review, a separate step." }, { "id": "Q09", "bloom": "application", "question": "Which single change would move Aider's Module 5 (Sandboxing) score from 1 to 3+ without compromising git-first value?", "options": [ "Run Aider inside a Docker container with the repo mounted read-write and ~/.ssh excluded", "Replace bash with a restricted-shell wrapper that allowlists commands", "Add filesystem-scoping to write_file so it cannot write outside the repo", "Move git operations behind a permission-gated proxy" ], "answer": 0, "rationale": "Docker with the repo mounted RW and ~/.ssh excluded contains blast radius while preserving git-first workflow (commits still work inside the container). Restricted shell (B) and write-scoping (C) help but are partial — bash can still read ~/.ssh. A permission proxy (D) fights the git-first design. Docker is the standard answer and the one the teaching doc recommends." }, { "id": "Q10", "bloom": "analysis", "question": "Aider scores 32/60; Pi scores 25/60. The +7 is attributed to 'git-as-substrate.' Which analysis is most accurate about WHERE the +7 comes from?", "options": [ "+7 comes entirely from Module 8 (State) alone", "+7 is distributed: +3 state, +2 context, +2 memory, +2 verification, +1 permission, +1 observability, offset by -1 tools, -1 prompt", "+7 comes from adding ~4 more tools than Pi", "+7 comes from a larger system prompt that gives the model more capability" ], "answer": 1, "rationale": "The +7 is distributed across six modules (state +3, context +2, memory +2, verification +2, permission +1, observability +1 = +11 gross) offset by two -1s (tools, prompt). State alone is +3, not +7 (A). More tools and a denser prompt are the -1 offsets, not the source of the gain (C, D)." }, { "id": "Q11", "bloom": "analysis", "question": "An attacker plants an ASI01 payload in a README that Aider's agent reads. Construct the most likely attack sequence that defeats git-gating.", "options": [ "Payload overwrites the system prompt at runtime → model becomes malicious → all commits are attacks", "Payload instructs the model to produce a legitimate-looking refactor that also reads ~/.ssh/cred and curls to attacker → human reviews diff, sees a valid refactor, approves → exfiltration executes at commit time", "Payload causes the model to `git push --force` to the attacker's remote", "Payload disables the git-gating review step so commits auto-apply" ], "answer": 1, "rationale": "The defining git-gating weakness: the injection produces a diff that looks like a legitimate refactor (the bait) while burying an exfil payload (the hook). The human reviews for 'is this the change I asked for' and approves a valid-looking refactor. Exfil executes at commit. (A) overstates — payloads cannot overwrite system prompts. (C) and (D) require capabilities Aider does not grant the model." }, { "id": "Q12", "bloom": "analysis", "question": "Compare Aider and Pi on Module 2 (Tools): Aider scores 4, Pi scores 5. Why does the harness with MORE tools score LOWER, and is this a real regression?", "options": [ "Real regression — more tools always means worse dispatch; Aider should cut to 4 tools", "Not a regression — Aider's ~8 tools are coding/git-specific and purpose-built, adding capability with modest dispatch noise; the -1 reflects the noise cost, not a design failure. The 4-tool philosophy is for general tool-use, not coding-specific tools", "Regression — Aider copied Pi's tools and added noise without capability", "Not a regression — the rubric is wrong; more tools should always score higher" ], "answer": 1, "rationale": "The 4-tool philosophy is a noise-reduction heuristic for GENERAL tool-use. Aider's tools are domain-specific (read, write, edit, bash, search, git ops) — each maps to a real coding task. The -1 is the modest dispatch-noise cost of having ~8 tools, not a design failure. Evaluating tool count against use case is the correct frame." }, { "id": "Q13", "bloom": "analysis", "question": "A colleague argues: 'Aider inherits memory (M4) from git, so its memory is as good as a harness with a dedicated vector database.' Analyze this claim.", "options": [ "Correct — git commits ARE a vector database", "Partially correct — git provides checkpoint/resume memory (you can return to any prior state), but not semantic-retrieval memory (you cannot ask 'find the commit where we changed auth logic' and get a ranked answer). Different memory types; Aider has version memory, not semantic memory", "Incorrect — git provides no memory value at all", "Correct — git commits are strictly superior to a vector database for memory" ], "answer": 1, "rationale": "Git gives version/checkpoint memory (return to any prior state, resume across sessions) — this is why M4 scores 3 vs Pi's 1. But a vector DB provides semantic-retrieval memory (ranked recall by meaning), which git does not. They are different memory types. Aider's M4=3 reflects real version-memory value, not parity with semantic retrieval." }, { "id": "Q14", "bloom": "analysis", "question": "Aider's MLSecOps Relevance note states git-gating 'does NOT defend against injection.' Why does the exfiltration succeed BEFORE the human reviews the diff, even though the commit happens AFTER?", "options": [ "Because git commits execute shell commands automatically", "Because the exfiltration happens at TOOL-EXECUTION time (the model calls bash to read ~/.ssh and curl), which is BEFORE the change is committed and reviewed. The diff-review sees the file changes, not the side effects of bash calls that already ran", "Because the human reviewer is always too slow", "Because git-gating only reviews the commit message, not the diff" ], "answer": 1, "rationale": "The critical timing: tool execution (bash read + curl) happens during the loop, BEFORE Aider commits the file change. By the time the human reviews `git diff`, the exfiltration has already occurred. Git-gating reviews the file-change artifact, not the side-effects of tool calls that ran during the turn. This is why the teaching doc emphasizes 'git-gating is downstream of the damage.'" }, { "id": "Q15", "bloom": "analysis", "question": "Three years of iteration have not added a token-budget stop condition to Aider. Analyze whether this is a defect or a coherent design choice.", "options": [ "Coherent design choice — a token budget would conflict with git-first philosophy", "Defect — a token budget is cheap, prevents runaway cost, and does not conflict with git-first value. Its absence in a 3-year-mature harness is surprising and is one of the three recommended fixes", "Coherent — Aider's user-interrupt (Ctrl+C) makes a token budget redundant", "Defect — without a token budget, Aider cannot score above 30/60" ], "answer": 1, "rationale": "The teaching doc lists 'add a token budget' as one of three fixes. It is cheap, prevents runaway cost on long sessions, and does not compromise git-first value — so its absence is a defect, not a design choice. User-interrupt (C) requires a human watching; a budget is automatic. (D) overstates — Aider scores 32 without one. (A) is wrong; budgets do not conflict with git." } ] }