{/* banner prompt: Warm, realistic analog photography of a cluttered but organized workshop desk, where a long ticker tape of computer output unspools from a vintage telegraph machine, with sections circled in red ink and handwritten notes in the margins, representing an AI agent debugging code through text logs, all in soft, natural window light, 16:9. */}

We called the [previous post](/blog/2026/06/13-the-coding-agent-shootout-and-the-best-harness-we-could-not-read/) the last in the series. That was the telescope view: what agents *are*, what a [harness does](/blog/2026/06/13-what-an-ai-agent-harness-actually-does/), how they [learn](/blog/2026/06/13-skills-and-memory-how-ai-agents-actually-learn/), which one wins. But a developer doesn't experience an agent as an architecture diagram. You experience it one edit at a time: it changes three lines, runs the tests, reads the failure, tries again. So here is the microscope view: how a coding agent actually turns an instruction into a working, tested change, held up against how a human programmer does the same thing.

## The human inner loop

Picture your own setup. You have an editor where you type, a terminal where you compile and run, and some way to *see the result*: a test runner's green bar, a printed value, a web UI you reload in a browser. Around it sits the big lifecycle everyone draws on whiteboards: idea → plan → architecture → design → write. But that's the outer loop. The thing you actually do all day is the **inner loop**, and it's tight: write a little, run it, look at what happened, adjust. Seconds per cycle.

Two habits define how humans fill that loop. First, we mostly **build small and grow** (a few lines, run, a few more), keeping a working program at almost every step, rather than generating a whole finished file and hoping. Second, we choose a direction: **vertically** (one feature sliced end-to-end through every layer until it runs) or **horizontally** (one layer built out across features). Either way the program is *alive* in front of us the whole time. We glance at the screen and instantly know if it's broken.

That last point is the one that matters most for what follows, because it's exactly the sense an agent doesn't have.

## The agent inner loop

An agent runs the same shape of loop (instruction in, change out, observe, repeat), but through a fundamentally narrower keyhole. Its loop is: the harness sends the model the context, the model emits a **tool call** (edit this file, run this command), the harness executes it and feeds the **text result** back, and the model decides what to do next. That's it. The agent has no eyes. It cannot glance at a screen. **Its only senses are the text that tools return**: file contents, stdout, stderr, an exit code. Everything a human takes in visually (the rendered web page, the debugger paused on a line, the red squiggle under a typo) has to be converted into text and handed back, or it doesn't exist for the agent at all.

This single fact explains almost everything distinctive about how agents code. It's why output truncation matters (an 80,000-line log blinds it as surely as a wall of noise), why edit-acceptance is fiddly, why verification has to be deliberate, and why debugging, the most *visual* and interactive thing a human does, is the hardest part to translate.

It also shifts the economics of "small and grow." Each model round-trip costs real tokens and seconds, so an agent can't afford the human's keystroke-level incrementalism; it tends to write a whole function or file in one shot, then verify. The good ones pull back toward small steps anyway (write, run, read, fix), because a 200-line blob that fails gives the model almost nothing to reason about, whereas a 20-line change that fails points right at the problem. The tension between "big chunks are cheaper per round-trip" and "small chunks are debuggable" is the central rhythm of agentic coding.

## The crux: turning intent into a changed file

Here is the most under-appreciated micro-mechanic in the whole stack: how does the model's *intention* to change code become an actually-changed file on disk? This step, call it **output acceptance**, is where coding agents most visibly differ, and where they most often fail. The five harnesses we read take three distinct approaches:

- **Exact string replacement.** The model supplies the old text and the new text; the tool finds the old verbatim and swaps it. This is what Claude Code's `Edit` and Pi's `edit` do. It's surgical and the resulting diff is trivially reviewable, but it's brittle: if the model's remembered snippet is off by a space, the match fails. Pi softens this with a *fuzzy fallback* that normalises smart quotes, Unicode dashes and trailing whitespace before giving up.
- **A patch grammar.** The model emits a structured diff in a format it was trained on, such as Codex's `*** Begin Patch … *** End Patch` `apply_patch` syntax. This handles multi-hunk edits cleanly and reads like a real patch, at the cost of the model having to produce exactly-valid patch syntax.
- **Self-correcting replace.** Gemini CLI's `replace` tool, on a failed match, fires a follow-up model call to *repair its own edit* rather than just erroring, trading tokens for a higher landing rate.

A failed edit is the single most common micro-failure in agentic coding, and each of those designs is one harness's answer to it. It's also exactly where your "native programmer versus scripter" observation enters, but that deserves its own section below.

## Calling the tools: compile, run, build, spawn

Once a file is changed, the agent needs hands to *do* something with it, and those hands are a single tool: shell execution (`Bash` in Claude Code and Pi, `exec`/unified-exec in Codex, a PTY shell in Gemini and Kimi Code). Through that one door it compiles, runs the test suite, starts a build, installs a dependency, spawns a server.

The interesting wrinkles are all about state and blindness:

- **Statefulness.** A naive `subprocess.run` can't hold a REPL open or answer an interactive prompt. Codex's "unified exec" gives the model a persistent PTY it can write stdin to; the mature shells track background processes so the agent can start a dev server and keep working while it runs.
- **Truncation.** Every harness caps tool output (Kimi Code's read tool stops at 1,000 lines or 100 KB; Pi spills overflow to a temp file). Without it, one chatty build destroys the context budget.
- **The blind spot, literally.** The agent can `npm run dev` and start a web UI, but it cannot *look* at the page. So it `curl`s the endpoint, greps the logs, or, increasingly, drives a headless browser and feeds itself a screenshot through a vision model. Watching an agent start a server it fundamentally cannot see is the clearest reminder of the text-keyhole problem.

## Tests and verification

Because the agent can't eyeball correctness, **running things is its substitute for seeing**, which makes tests and verification not a virtue but a necessity.

On creating tests, agents are comfortable both ways: writing the test first and coding to green (some skills enforce test-first explicitly), or writing tests after to lock in behaviour. Their real edge is that they are tireless about *running* the full suite, the linter and the type-checker on every change, the chores humans skip when tired.

Their matching weakness is that a language model will cheerfully announce "done" without having run anything. This is why mature harnesses and skills bolt on a **verification discipline**: re-read the file you just edited, run the build, run the tests, and only then claim success: evidence before assertion. The agent's superpower (re-run the world twenty times without complaint) and its failure mode (declare victory unverified) are two sides of the same coin, and verification gates exist to keep it on the right side.

## Debugging: the widest gap of all

Now the part of the inner loop that translates worst. Here is the canonical human bug hunt, in \*nix muscle memory:

1. `grep` the error string across the tree.
2. Open the file at the offending line, read the surrounding context.
3. Set a **breakpoint**.
4. Run, and when execution pauses, **step** through it (step over, step into, step out), watching variables change.
5. Catch the moment the state goes wrong, and you've found the cause.

An agent does steps 1 and 2 almost exactly as a human does: grep the error, read the context around the line. Then the methods fork hard, because **step 3 is mostly unavailable to it.** Agents rarely drive an interactive debugger; they can't easily sit at a paused frame and inspect live state. (Some can speak the Debug Adapter Protocol through an MCP server, but it's the exception, not the daily path.) So instead of stepping, the agent debugs the way we all did before debuggers existed, just faster: it inserts `print`/log statements, re-runs, reads the output, reasons about it, removes them. Printf debugging at machine speed.

The deep difference is one of *substrate*. A human debugs a **live, paused, inspectable** program. You can poke it while it's frozen mid-thought. An agent debugs a **dead transcript** of what the program already emitted. It loses the ability to interrogate a running frame, and it compensates with two things humans can't match: it will happily re-run the failing case fifty times with different instrumentation, and it can hold the entire call path in context at once rather than stepping through it line by line. Slower per insight, but relentless and wide.

## The observation: native programmer vs. scripter

Which brings us to the thing you actually notice after watching these agents work for a while: **they have different programming temperaments, and Claude Code behaves the most like a native \*nix programmer.**

By "native" we mean it reaches, by default, for the same surgical tools a seasoned terminal user does: `grep` to locate, a targeted read of the exact line range, a precise string-replace edit, the right small command for the job. And it leaves behind a clean, reviewable trail of minimal diffs. Watching it is like watching someone who has `grep`, `sed`, `cut`, `head` and `tail` in their fingers and uses them with intent.

The contrast: when faced with a bulk change (rename this symbol across forty files, rewrite every import), some agents (Codex and Gemini among them, in our observation) are more inclined to **write a throwaway script to do it**: a `python3 -c "..."`, a `perl -pi -e`, a `sed -i` one-liner run through the shell, rather than a series of surgical edits. It works, and for genuinely mechanical mass-edits it's even the *right* call. But it has a cost: a thrown-away script's effect is harder to review than a diff, since you have to reconstruct what it did, and a slightly wrong regex can silently mangle forty files at once, where a string-replace edit simply fails loudly on the one it couldn't match.

Two honest caveats, because this is the part most easily overstated. First, it's a *tendency*, not a wall: every one of these agents can use native tools, and every one can write a script; the difference is which it reaches for first, and that's shaped as much by the model's temperament as by the harness's tool design (a patch-grammar editor nudges toward batch thinking; a string-replace editor nudges toward surgical thinking). Second, these behaviours drift from model version to model version, so any snapshot like this one has a short shelf life. The durable point isn't "Claude Code wins the bug hunt." It's that **there is a real, observable spectrum between surgical and scripted code-editing, and it changes how reviewable and how safe the agent's work is.** When you pick an agent, that temperament is something you can feel within an hour, and it matters more to the day-to-day than any benchmark.

There's a fitting irony to end on: this post about how agents wield `grep` and surgical edits was itself drafted by one, reaching for exactly those tools as it went. The microscope, it turns out, works on the thing holding it.

## Where micro meets macro

Across five posts the same theme keeps surfacing from different distances. The harness (macro) decides which tools exist and how their results come back; the model (micro) decides which tool to reach for and how big a bite to take. A great coding experience is when those align: a native-feeling toolset in the harness, and a model with the judgement to be surgical when a scalpel is called for and to script when a bulldozer is. The model sets the ceiling; the harness and the editing temperament decide how close to it you actually get to live, one edit, one test, one bug at a time.

*This is a micro-level companion to our four-part series on AI agent architecture. All six harnesses behind these observations are open source; the best way to see the difference between a surgical edit and a thrown-away script is to watch two agents solve the same task and read what each left behind.*

37e17e97233f7397bb5ccb79b71f8fd079867b511dcd41109dbbb81fe5f3bcc2

A micro-level look at how AI coding agents write, run, test, verify and debug code: the edit loop, output acceptance, the exec tool, and why some agents feel like native command-line programmers while others feel like scripters.

The first four posts in this series took the telescope view of AI agents. This one takes the microscope: how a coding agent turns an instruction into a working, tested change (how it edits, compiles, runs, tests and debugs), and why Claude Code behaves like a native *nix programmer while others reach for a throwaway script.

How a Coding Agent Actually Writes Code

{/* banner prompt: A retro technical poster in the style of a 1970s engineering manual, diagramming five different abstract 'coding agent' mechanisms, with bold sans-serif typography labeling 'THE HARNESS' and 'MODEL CORE', using a limited-print color palette of navy blue and burnt orange on a cream paper texture, 16:9. */}

This is the fourth and final post in our series on AI agent architecture. The first three were about *how* agents are built: we [compared three of them](/blog/2026/06/13-codex-pi-and-hermes-three-agents-three-species/), dissected [what a harness does](/blog/2026/06/13-what-an-ai-agent-harness-actually-does/), and looked at [skills and memory](/blog/2026/06/13-skills-and-memory-how-ai-agents-actually-learn/). This one answers the question everybody actually asks first: **which coding agent should I use?**

We read the source of five open coding agents end to end: OpenAI's [Codex CLI](https://github.com/openai/codex) (the Rust harness is open even though the models aren't), [Pi](https://pi.dev/), [OpenCode](https://github.com/sst/opencode), Moonshot's [Kimi Code](https://github.com/MoonshotAI/kimi-code), and Google's [Gemini CLI](https://github.com/google-gemini/gemini-cli). Below is the honest shootout: strengths, weaknesses, and a ranking. But there's an asterisk we owe you up front, so here it is in plain sight. **The best harness in the field belongs to a tool we deliberately did not put under the microscope: Claude Code.** We'll get to why at the end.

(We're leaving [Hermes Agent](https://github.com/NousResearch/hermes-agent) mostly out of this one. It can code, but it's an assistant-first agent, and judging it as a coding tool would be judging a Swiss Army knife by its corkscrew.)

## How to judge a coding agent

A coding agent's quality is the product of two things that multiply rather than add: **the model** doing the reasoning, and **the harness** that decides what the model sees, what it can touch, and what happens when it's wrong. A great model in a sloppy harness flails on long tasks; a great harness can't make a weak model reason past its ceiling. So the axes that matter are:

- **Model strength on hard tasks:** can it actually fix the gnarly bug, not just the toy one?
- **Harness reliability:** does it survive a forty-minute run: compaction, recovery from loops, checkpoints?
- **Safety:** what stops it running `rm -rf` or leaking a secret?
- **Extensibility & ownership:** can you bend it, script it, run your own models?
- **Cost and friction:** what does a day of heavy use actually cost?

No single agent wins all five. That's the whole point.

## The contenders

**OpenAI Codex CLI**: *the strongest engineer in the room.* Codex pairs the best coding models available (the GPT-5.x-Codex family) with a harness that takes the hard problems seriously. It's the only one of the five where **sandboxing is architecture, not an afterthought**: every command runs inside an OS-enforced jail (Seatbelt on macOS, bubblewrap on Linux) with network denied by default, and the model can *request* escalation as part of its tool schema. The core is a protocol-first Rust engine, so one codebase drives the terminal, the IDE extension, `codex exec` and the cloud. And because OpenAI trains the models *with* this harness (they speak its custom patch format natively), model and harness reinforce each other. It's also the most token-efficient of the lot. Weaknesses: the models are closed and get deprecated on OpenAI's schedule, the cloud model isn't selectable, and its extension story (hooks, skills, plugins) is younger than its rivals'.

**Gemini CLI**: *the most feature-complete, and free.* Google's CLI is the most generous on-ramp in the field: a real free tier, a 1-million-token context window, and a genuinely impressive harness: loop detection that *injects corrective guidance* instead of just giving up, automatic fallback to a faster model on quota exhaustion, shadow-git checkpointing with `/rewind`, an A2A server for multi-agent setups, a VS Code companion, skills, hooks and subagents. It has quietly absorbed the best ideas from everyone. Weaknesses: it's at its best on Gemini models, the feature surface is sprawling, and on the hardest reasoning tasks community sentiment still places it a notch below Codex and Claude.

**OpenCode**: *the architecture astronaut's pick, in a good way.* OpenCode is built server-first: an HTTP server with an OpenAPI spec, and the TUI, desktop app, web UI and GitHub bot are all thin generated-SDK clients of it. It's aggressively provider-agnostic (bring any model), expresses "plan mode" and sub-agents as plain **permission rulesets** rather than hard-coded modes, ships git-based checkpoint/revert, and is mid-flight on an event-sourced V2 redesign. Weaknesses: that rewrite means churn, there's no sandbox, and your experience is only as good as the model you plug in.

**Kimi Code**: *the cleanest layering, and a cost story.* Moonshot's CLI is the best-factored codebase of the group, built as three crisp layers (`kosong` for LLM abstraction, `kaos` for OS abstraction, `agent-core` for the loop) with event-sourced persistence you can replay in a visual debugger and cache-aware compaction that weighs prompt-cache economics before squashing history. Kimi models are strong coders and cheap, and it speaks ACP for editors like Zed. (A fun detail: its TUI is built on Pi's own UI library.) Weaknesses: it's tuned best for Kimi models, it's newer, and the community around it is still small.

**Pi**: *not really a product; a masterclass.* Pi ships zero models and refuses features on principle (no sandbox, no permission popups, no plan mode), pushing everything to a TypeScript extension system. What it *does* ship is the cleanest minimal agent core we read (about 2,700 lines), the best multi-provider abstraction (40-plus providers behind one interface), and a session-as-a-tree design that makes branching and time-travel free. Weaknesses as a daily driver: no safety rails, no cross-session memory, a bus factor of roughly one, and quality that depends entirely on the model you bring. You run Pi to *understand* agents, or to build your own on top of it, which plenty of people, including the OpenClaw and Kimi Code teams, have done.

<Table data={
    {
        headers: ['Agent', 'Strongest at', 'Weakest at', 'Open?'],
        rows: [
            ['Codex CLI', 'Model strength, sandboxing, reliability', 'Closed models, younger extensibility', 'Harness yes, models no'],
            ['Gemini CLI', 'Free tier, features, recovery, 1M context', 'Best only on Gemini; sprawling', 'Fully open'],
            ['OpenCode', 'Client/server architecture, ownership', 'Mid-rewrite churn, no sandbox', 'Fully open'],
            ['Kimi Code', 'Clean layering, event sourcing, cost', 'Kimi-first, young, small community', 'Fully open'],
            ['Pi', 'Minimal core, provider abstraction', 'No safety, no memory, bus factor ~1', 'Fully open'],
        ]
    }
} />

## A note on lineage: who built on whom

It's tempting to read these as five isolated inventions. They aren't. This is a small field whose teams read and reuse each other's code, and the family tree is worth tracing because it tells you where the reusable ideas actually live.

The clearest root is **Pi**. Its "toolkit, not product" philosophy isn't just rhetoric. Other agents are literally built from its parts. **Kimi Code did not write its own terminal UI; it depends on `@earendil-works/pi-tui`, Pi's own TUI library**, and built its component layer on top (you can see it right there in `apps/kimi-code/package.json`). And **OpenClaw**, one of the most popular open personal assistants, is built on Pi's agent packages; its whole agent stack is Pi underneath. So while Pi loses a head-to-head as a *daily driver*, it quietly wins as *infrastructure*: when you use Kimi Code or OpenClaw, you're partly using Pi.

Then there's the softer lineage of shared conventions, where an idea from one agent becomes a standard everyone adopts:

- **`AGENTS.md`**, the project-instructions file, was originated by Codex and is now read by Pi, OpenCode, Gemini CLI (as `GEMINI.md`) and others.
- **The [agentskills.io](https://agentskills.io) `SKILL.md` format** is shared, independently, by Pi, Hermes, OpenCode, Kimi Code and Gemini CLI: five teams converging on one open standard.
- **Shadow-git checkpointing** (snapshot before risky edits, `/rewind` to undo) shows up in both OpenCode and Gemini CLI using the same underlying git trick.
- **The read / edit / grep / glob / bash tool ergonomics** that all five share trace largely back to Claude Code, which is part of why, as we'll see, it casts a long shadow over a comparison it isn't formally in.

The lesson for anyone building an agent: you are not starting from a blank page. The good patterns are already open, already converging, and in Pi's case already packaged as libraries you can import.

## The verdict among the five

Of the agents we actually read the code for, **Codex is the best coding agent**, and it isn't especially close on the axis that matters most for serious work. Hard engineering is where the model-times-harness product is most punishing, and Codex maxes both terms: the strongest coding models in the industry, co-designed with a harness that sandboxes by default and is built to grind through long autonomous runs. If your test is "fix the difficult bug in an unfamiliar codebase without supervision and without `rm -rf`-ing my home directory," Codex is the safe bet.

That doesn't make it the right pick for everyone. If you want zero cost and maximum features, Gemini CLI. If you want to own the whole stack and run your own models, OpenCode or Pi. If you live in Kimi's ecosystem and care about cost, Kimi Code. "Best" is conditional on what you're optimising for, but if you force a single ranking on *raw coding capability*, Codex tops the five.

## The asterisk: the best harness we couldn't read

Here's the honesty the title promised. We left **Claude Code** out of the code study for a simple reason: its harness isn't open source the way the others are, so there was nothing to dissect at the same depth. But leaving it out of the *code* study is not the same as leaving it out of the *conversation*, because by reputation, by community blind-comparison, and by the simple fact that everyone else keeps adopting its conventions, Claude Code arguably has the **best harness in the field.**

Consider the evidence that doesn't require reading its source:

- **It set the conventions the others copied.** The ergonomics of the modern coding-agent tool suite (the read / edit / grep / glob / bash design, the `AGENTS.md`-style project memory, plan mode, sub-agents, the skills format, MCP support) trace largely to Claude Code, which either originated or popularised much of this. When you see five independent harnesses converge on the same patterns, a lot of those patterns trace back to one place.
- **Blind output comparisons keep favouring it.** In the community write-ups that pit agents head-to-head on real tasks, Claude Code's output is preferred more often than not, frequently over Codex, even when Codex uses fewer tokens. The recurring verdict is "Codex is more efficient, Claude Code is more *right*."
- **Its harness sophistication is visible from the outside.** Sub-agent orchestration, a genuinely good permission UX, hooks, output styles, tight IDE integration, careful context management: the surface area you interact with is the most polished in the category, and polish in a harness is exactly what determines how much of the model's capability you actually realise.

So the fair summary is not "Codex is best, full stop." It's: **Codex and Claude Code sit at the top tier, trading blows**, with Codex winning on raw model strength, sandboxing and token efficiency and Claude Code winning on harness craft and output quality, while the five open agents below them serve different masters (cost, ownership, learnability, ecosystem). The reason Codex "wins" our shootout is partly an artefact of the rules: we ranked the agents whose code we could read, and the strongest harness in the field wasn't one of them.

There's a small irony worth admitting: the research behind this entire series (cloning six repos, reading tens of thousands of lines, drafting these posts) was itself done with a coding agent. The tools have gotten good enough to study, and explain, each other.

## What to actually use

- **You want the strongest autonomous coding agent and don't need to own it:** Codex, or Claude Code. Try both on your own hard task and trust your eyes over any benchmark; these two are close enough that fit-to-your-workflow decides it.
- **You want maximum capability at zero cost:** Gemini CLI.
- **You want to own the stack, pick your models, or self-host:** OpenCode (as a product) or Pi (as a foundation).
- **You're cost-sensitive or already in Moonshot's ecosystem:** Kimi Code.
- **You're building your own agent:** read Pi for the core, Codex for sandboxing, OpenCode for the client/server split, Kimi Code for event sourcing, Gemini CLI for recovery engineering, and study how Claude Code behaves, because it's the reference the others are quietly chasing.

The models will keep leapfrogging each other quarter by quarter; the rankings above have a short shelf life. What won't change is the lesson under all four posts in this series: the model sets the ceiling, but the harness decides how close to it you get to live. Choose the harness you'll actually enjoy operating. That, more than any benchmark, is what determines whether the agent helps you.

*That closes our four-part series on AI agent architecture. All six harnesses we studied are open source; if these posts made you curious, the code is the best teacher we found.*

c3eb856d2353baa1c60afada9ea2a11681b3b0ea10aa6fda67c80db70bc35600

A strengths-and-weaknesses comparison of the open coding agents Codex, Pi, OpenCode, Kimi Code and Gemini CLI, plus why Claude Code arguably has the best harness despite being closed.

After reading the source of five open coding agents (OpenAI's Codex, Pi, OpenCode, Kimi Code and Gemini CLI), here is how they actually stack up, strengths and weaknesses, which one wins, and why the best harness of all belongs to a tool we deliberately left out of the code study: Claude Code.

Tag: Claude Code

Tag: Claude Code

How a Coding Agent Actually Writes Code

The Coding Agent Shootout and the Best Harness We Could Not Read