After thirteen codebases,
what is still worth reading

1. Aider — “less is more” taken seriously inside coding agents

GitHub: Aider-AI/aider · Python · Apache-2.0

What you already have: among the thirteen coding agents, Claude Code is on the order of 40 tools, hermes 74 tools, Codex a 126-crate workspace—heavy lineages. A large fraction of those codebases is tool systems, permission systems, compaction, sub-agent management.

Aider’s answer: as light as it gets. The core is a map–edit loop: the model first reads the project and emits a “code map,” then edits files from that map. No elaborate tool taxonomy, no multi-layer permission tribunal, no sub-agent pool. Core source is about an order of magnitude smaller than any coding agent you have analyzed here.

What you will learn:

• A field answer to “how much agent infrastructure is surplus.” Aider tests, with very little code, how far model + map-style edits + simple retry covers real programming work
• Map-style editing vs tool-call editing. Agents you have read are “model calls a tool → tool reads a file → result is fed back → model calls again.” Aider is “model draws the whole map → edits many files in one go.” The former is flexible and slow; the latter is fast and needs a model that can hold a global view
• A Polyglot suite they maintain themselves. Aider’s Polyglot (225 items, 6 languages) is an industry reference. Read how they design items, filter difficulty, and control cost—then you can design an eval

Suggested reading entries (in Aider’s tree):

• aider/coders/base_coder.py: the map–edit loop; the essential difference from a while-tool-loop
• benchmark/README.md: how Polyglot was designed—how 697 candidates became 225, how cost is controlled
• aider/repomap.py: how a repo’s file structure is compressed into a map a model can read

Contrast with analyses you already have:

2. SWE-agent — the inventor of AGENTS.md, a cultural gene

GitHub: SWE-agent/SWE-agent · Python · MIT

What you already have: across the thirteen analyses you keep meeting AGENTS.md / CLAUDE.md / .cursorrules—each project has its own way of shipping “a project manual written for the model.” Who invented the idea? Why a Markdown file and not JSON / YAML / a database?

SWE-agent’s answer: in early 2024, while building a coding agent, the team found that a model entering a new repo needs “how this project builds, how it tests, what the conventions are.” The old move was to hard-code that into the system prompt—but every project differs. Their invention: a human writes a Markdown file at the repo root; on startup the agent reads it and injects it into the system prompt. That decision spread through the whole ecology.

What you will learn:

• How a simple design decision becomes an industry standard—not because the technology is deep, but because it is simple enough (anyone who can write Markdown can participate)
• Markdown as an agent–human interface. Simplicity is the feature (zero learning cost). The costs are missing structure (the agent may misread, skip, or drown in a long file)
• Contrast with Codex’s AGENTS.md as analyzed in this station. Codex adds a 32 KiB shared budget, AGENTS.override.md precedence, and per-directory discovery—engineering reinforcement on SWE-agent’s original idea. Those mechanisms are cited in the Codex analysis; this paragraph does not re-measure them

Suggested reading entries (in SWE-agent’s tree):

• sweagent/agent/agents.py: the Agent class—how simple the original AGENTS.md load is
• config/: YAML templates for prompts—a different philosophy from Claude Code assembling prompts in TypeScript

3. LangGraph — an explicit state graph instead of a while loop

GitHub: langchain-ai/langgraph · Python · MIT

What you already have: the core of the thirteen agents is a while loop—while True: call the model → if tool_use then execute → fill results → loop. grok-build’s Goal Mode kit and nanobot’s AgentLoop state machine have a notion of “state,” but they still sit inside a while loop.

LangGraph’s answer: an explicit state graph instead of a while loop. Execution is not “loop until the model says stop.” It is “jump between nodes under conditions.” Each node is a determinate operation (call model / run tool / branch). Each edge is a transition (“if the model returned tool_use, go to the tool node”).

What you will learn:

• While loop vs state graph—two control paradigms. A while loop is flexible and hard to predict (you do not know what the next round will do). A state graph is determinate and rigid (you must pre-declare states and transitions)
• Recoverability and debuggability. Every node has determinate I/O—you can pause, inspect, continue from a checkpoint. A while loop’s history is “one stream”—you replay from the start
• Checkpointer (state persistence). LangGraph checkpoints after each step. The motive rhymes with hermes-agent’s “persist before you act,” but under a graph the exactly-once story is more natural

Suggested reading entries (in LangGraph’s tree):

• langgraph/graph/state.py: StateGraph—node + edge + state
• langgraph/checkpoint/: checkpoint implementation

4. Cline — an agent that lives as an IDE plugin

Contrast: agents you have read run in a terminal (Claude Code’s Ink TUI, CodeWhale’s ratatui, opencode’s SolidJS TUI). Cline lives in the VS Code sidebar. The same problems (how a permission prompt appears, how a diff is shown, how context is prepared) get different answers in a plugin than in a TUI. After Cline you will re-read every “terminal-shaped” design and ask which parts are general agent needs and which parts only exist because the UI is a terminal.

This station already contains a full Cline source analysis and a from-scratch tutorial (English under analyses/cline.md and tutorials/build-cline.md once published). Use those for path:line claims. This entry is here because the further-projects Chinese original listed Cline as a contrast class before that analysis existed; keep the contrast, and prefer the later analysis for citations.

Suggested reading entry (in Cline’s tree): src/core/ for task execution and tools. Watch how the permission modal is implemented in a VS Code WebView—versus Claude Code’s terminal modal.

5. browser-use — a browser-agent sample

Contrast: tool systems you have read operate code (read, write, run, search). browser-use’s tools operate pages (click, fill, scroll, screenshot). Same loop (model → tool → model), different tool set. MiroFish is your only non-coding agent so far; browser-use is a second, but its tool abstraction, context engineering (how a page becomes text for the model), and stop rule (how you know “the page finished loading”) are unlike MiroFish.

Suggested reading entries: browser_use/agent/service.py (the loop—how “browse the web” is modeled as tool calls); browser_use/dom/ (DOM extraction—how “a page” becomes text a model can use).

6. Anthropic Computer Use reference — screenshots instead of tool calls

Contrast: this is the hardest challenge to the picture you have. Every agent you have read operates the computer through a tool API—the model never sees the screen, only tool results (file contents, command output). Computer Use replaces that with screenshots: the model looks at pixels and emits click coordinates and keystrokes. There is no tool schema. Anything that can appear on screen can be operated. Does the idea of an “agent harness” itself get overturned? If you can drive any software without defining tools, how much of the fifteen engineering-pattern chapters is still load-bearing?

Suggested reading entry: Anthropic’s computer-use-demo repository. Screenshot resolution, coordinate normalization, and action latency are the engineering bones of Computer Use.

7. AutoGen (Microsoft) — multi-agent conversation

Core idea: not “one agent does the work,” but “several agents meet.” Each has a role, capabilities, and a conversation policy; they coordinate by messages. Contrast with MiroFish as analyzed here: MiroFish lets agents evolve (social simulation). AutoGen lets agents collaborate on a script (engineering orchestration)—the same “multi-agent” phrase, two opposite extremes.

8. CrewAI — role-play multi-agent orchestration

Contrast with AutoGen: AutoGen leans toward free conversation; CrewAI leans toward task orchestration—“researcher searches → writer writes → reviewer reviews,” closer to a pipeline.

9. Dify — an LLM application platform, not a pure agent

What to look at: visual orchestration—drag-and-drop instead of code. Contrast: every analysis you have is “a programmer writes an agent in code.” Dify is “a non-programmer assembles an AI app.” The loop is still model → tool → model. The interaction surface, engineering complexity, and intended user are not.

10. Google A2A (Agent-to-Agent) — an interoperability protocol

What to look at: how agents from different vendors discover, talk, and collaborate. Contrast: your analyses are all “how one agent is designed inside.” A2A is “how two agents collaborate.”

11. E2B / Daytona — sandbox-as-infrastructure

What to look at: sandbox as a service. The agent executes code in a remote sandbox through an API; isolation is not the agent’s job. Contrast: Codex implements three layers of sandbox itself; nanobot integrates bwrap itself—those are “the agent repo owns the sandbox,” as cited in those analyses. E2B turns the sandbox into a replaceable infrastructure component. Security stops being a debt inside the agent and becomes a dependency.