Coding Agents

The Architectural Fault-Lines of Three Coding Harnesses

Background & Principles

Put all three on one coordinate system and the split is instant. The horizontal axis is autonomy (who decides the next step: you or the model); the vertical axis is how edits land (how the model changes files):

• Aider: git-native CLI. You explicitly /add files into context, the model returns changes as search/replace diff blocks, and each change is auto-git commited. Control flow stays mostly with you — it's a highly controllable "semi-auto pairing," not a free-roaming agent. Wins: git history as audit trail, instant /undo, extremely token-thrifty.
• Cursor: IDE-native. Its core is two-stage — the foreground uses a frontier model for planning (chat / composer), the background uses a specially trained fast-apply model (~70B, ~1000 tok/s) to land intent into a file diff. Tab completion is a separate lightweight autonomy track. Wins: zero context-switch inside the editor, blazing apply.
• Claude Code: terminal-native agent. A full agentic loop — it Greps/Reads to explore on its own, decides which files to change, uses the Edit tool for string replace, runs Bash to verify. Control flow lives with the model; you constrain it via permission gate + plan mode. Wins: highest autonomy for open-ended tasks.

Key insight: these three aren't "who's stronger," they're three autonomy levels. Aider fits batch execution where you already know the exact change; Cursor fits high-frequency small iterations inside the editor; Claude Code fits open-ended tasks of "I'm not sure how to change it, go explore." Picking the wrong level costs more than picking the wrong model.

Edit Format: The Coding Agent's Underrated Hidden Bottleneck

Background & Principles

A counterintuitive fact: many coding-agent failures aren't logic errors, they're failed edit application — the model's search block doesn't match the file's actual text (whitespace, quotes, hallucinated old code), so the patch silently drops or errors. Aider's leaderboard quantifies exactly this as a core metric: the model must not only write correct code but successfully apply every change without human intervention. The four mainstream edit formats each trade off:

• Whole file: model emits the entire file. Easiest for the model to "get right," but tokens explode, large files exceed limits, and it tends to mangle unrelated lines.
• Unified diff: standard @@ diff. Token-thrifty, but the model often miscounts line numbers/context, giving a high apply-failure rate.
• Search/replace block (Aider's mainstay): a precise old-text + new-text pair. More robust than unified diff (matches by text, not line number) — a sweeter spot of token cost vs reliability.
• Apply model (Cursor's route): the frontier model only emits "intent + rough diff," then hands it to a specially trained small model to land it precisely. This decouples "think clearly" from "write accurately" — the core of Cursor's 1000 tok/s instant apply.

The core trade-off: whole file is easiest to get right but priciest; diff is cheapest but most prone to apply failure; search/replace splits the difference; apply model buys reliability with a second model. This is why different harnesses perform so differently on the same base model — the edit contract differs.

Example

The exact shape of a search/replace block (same lineage in Aider / Claude Code) — the SEARCH segment must match the file character-for-character:

src/auth.py
<<<<<<< SEARCH
def verify_token(token):
    return jwt.decode(token, SECRET)
=======
def verify_token(token):
    try:
        return jwt.decode(token, SECRET, algorithms=["HS256"])
    except jwt.ExpiredSignatureError:
        raise AuthError("token expired")
>>>>>>> REPLACE

Practical takeaways: (1) before the agent edits a large file, make it Read the exact slice first — hallucinated old code is the #1 cause of apply failure; (2) keep changes small and local, one semantic unit per replace — far higher apply success than rewriting a whole function; (3) when the model repeatedly fails to apply, falling back to whole-file mode beats stubbornly forcing diffs.

Plan Mode: Separating Research-Plan-Implement Is Engineering, Not UX

Background & Principles

Anthropic's Claude Code best practices stress one rule repeatedly: separate research/planning from implementation. The biggest risk of letting an agent code straight away isn't sloppy code — it's solving the wrong problem: patching the symptom and bypassing the root cause you actually wanted fixed. Plan mode has three layers of engineering value:

• Problem locking: explore read-only first (Grep / Read), produce a plan, force the agent to articulate "what to change and why" before touching anything. A wrong direction gets caught here — this is the cheapest verification, far cheaper than reviewing hundreds of lines of diff after the fact.
• Physical isolation: Claude Code's plan mode forbids Write/Edit/Bash at the harness layer — not a prompt begging it not to act, but a physical block. No matter how "itchy" the model gets, it can't change files (echoing Day 3's permission gate).
• Auditability: the plan is text, so on failure you can tell whether the "plan was wrong" or the "execution was wrong" — far clearer than debugging a pile of messy diffs.

The counterintuitive point: plan mode's payoff doesn't come from the model thinking more (that's reasoning's job), it comes from giving a human a low-cost correction checkpoint. For open-ended tasks (debugging, cross-file refactors, new features) planning first is almost always worth it; for a one-line change, planning is pure overhead.

Example

Bake "explore → plan → code → commit" into a workflow rather than letting the agent write right away:

# Claude Code: enter plan mode (Shift+Tab), read-only explore + produce a plan
> Study how the payment module handles retries. Don't change code yet —
  give me a plan to fix the double-charge bug: which files, risk points, how to test

# You review the plan, stop wrong directions, then switch back to execute
> Plan looks good, but don't touch the webhook handler. Implement it, and run the relevant tests after each file

# Aider equivalent: use /ask to ask-only first, then switch to code mode
/ask Where in this retry logic could it double-charge? How should it be fixed?
# once satisfied: /code to land it

Key discipline: require the agent to explicitly list "what NOT to touch" in the plan. A coding agent's most common overreach is casually "improving" code you never asked it to change — drawing boundaries at the plan stage beats intercepting at review.

The Autonomy Spectrum and Closing the Loop

Background & Principles

"AI pair programming" isn't one mode, it's an autonomy spectrum. Each step right raises throughput but weakens your ability to review every line and propagates errors further. What decides the level is the task's verifiability — can the agent know on its own whether it's right:

• Tab completion: you write, it continues. You review every token. Good when you have the code in mind and just want to type faster.
• Chat / inline edit: you describe a local change, it emits a diff, you apply one by one. Good for clear small changes.
• Full-auto agent: give a goal, it loops explore→edit→test→fix on its own. Good for open-ended tasks, but only safe when the loop can be closed by verification.

Whether the right-end full-auto works depends almost entirely on closing the loop: can the agent run tests / lint / type-check after editing and feed failures back to itself to fix? If the loop closes (tests exist, errors are clear) → let it iterate autonomously; if it can't close (UI tweaks, scripts with no tests) → drop back to a lower level and be the "test" yourself. This echoes Day 3: feeding errors back is the root cause of an agent's self-repair.

Example

Give the full-auto agent an explicit verification loop, not just a goal then walk away:

> Fix the race condition in #482. Work discipline:
  1. First write a failing test that reproduces the bug (red)
  2. Change code to make it green
  3. Run `pytest tests/ -q` + `mypy src/`; done only when all green
  4. Any step red: paste the full error, analyze, then fix — don't skip

# Key: give it an objective "done" criterion (green) and verification tools,
# so the agent can close its own loop. Without this it self-declares "fixed" and leaves hidden bugs

This is why test-first matters more for AI agents than for humans: tests are the agent's only trustworthy "right/wrong signal." Without them, an agent's self-eval is wildly unreliable — it tends to declare success (backward rationalization, see Day 5). Only with a red test first dare you let full-auto run.