O'Reilly Radar：应按控制层而非厂商选择编码 harness

O'Reilly Radar· Nicole Koenigstein·2026-11-06 19:54· 34 分钟前AI 评分65

Choose Your Coding Harness by What You Need to Control—Not by Who Built It

AI 导读

O'Reilly Radar 作者提出应按需要控制的层级而非厂商来选择编码 harness，并对比了 Claude Code（运行内控制）、Codex（执行隔离）、Pi（外层生命周期）和 DeepSeek harness（插件组合）的控制重心。

正文 · 原文

Remember back in 2019, when you had only a handful of language models to choose from, all with limited context windows? That world is gone, and it feels like a forgotten past. Today, flagship providers and open source projects compete across model families, sizes, capabilities, and deployment options. Coding harnesses seem to be heading in the same direction.

On the surface, Claude Code, Codex, Pi, DeepSeek Harness, and the other coding harnesses all seem to do the same thing: help you build software with models. Look closer, though, and each one gives you control over different parts of the harness. What can the model see and change? How does it use tools? Where does it run, and what happens when it fails? So instead of asking which coding harness is best overall, ask:

Which layers of the harness do you need to control?

Thanks for all the harnesses! Now what?

Choosing a coding harness isn’t only about which model writes the best code. You’re also choosing what the harness provides, what you can change, and what you must build yourself. If it doesn’t give you verification, durable state, repair routing, or an enforced execution boundary, those responsibilities stay with you. You remain accountable for the workflow’s reliability and governance.

In general, each harness has a center of gravity: a layer that gives you the most direct control. The following table is a deliberately high-level overview of where that center sits. It’s not a feature matrix, and the boundaries overlap in practice. Claude Code can also run noninteractively and inside sandboxes, Codex also reads repository instructions, and all of them are changing quickly. The point is to show where each harness gives you leverage by default, and where the engineering work is likely to stay with you.

Table 1. Where each coding harness puts its primary control

Read the table as a map, not a ranking. A harness that hands you more control also hands you more to build, and a harness that does more out of the box decides more on your behalf. Which trade-off is right depends on which layer your project actually needs to own.

Claude Code: Control inside the run

Claude Code buys you detailed control over how implementation unfolds. CLAUDE.md provides standing instructions, skills add task-specific playbooks, subagents divide the work, and hooks intercept actions before and after tool calls. Unlike a permission rule that simply refuses an operation, a hook can explain the refusal or immediately return a compiler or policy failure to the agent.

These controls let you steer the coding loop extensively, but they operate within Claude Code’s existing lifecycle. If you need to control the outer lifecycle itself, you need another layer.

Codex: Control through separation

Codex buys you separation between a coding task and its execution environment. A noninteractive codex exec run can work on a narrow task in a specified repository, under an OS-enforced sandbox, and return a schema-constrained result.

This is useful for independent verification. You can give Codex a clean checkout, exclude the builder’s instructions, restrict writable paths, and run separate reviews for code quality, test gaps, persistence, or user-visible behavior. The sandbox depends on the operating system, but it moves scope enforcement out of the prompt and into the execution boundary.

Pi: Control over the loop

Pi buys you control over the coding loop itself. Its tools, commands, event handlers, context, models, and session state can be extended or replaced. This lets you decide which steps remain agentic and which follow deterministic policy.

For example, a local defect can return to implementation, a repeated defect can force replanning, and conflicting findings can trigger a recheck or human review. Pi can also run agents inside this lifecycle, so it’s more than a deterministic orchestrator. For my example below, I used its programmability to make the outer decisions deterministic—that was my design choice, not Pi’s definition.

DeepSeek’s harness: Control through composition

DeepSeek’s harness is useful when you want to swap out whole parts of the harness rather than steer or wrap them. Tools, sessions, lifecycle behavior, verification, and governance are all composable plug-ins, and so is the loop itself. That lets you replace one component without rebuilding the rest.

The trade-off is that your control is only as good as the plug-ins you compose. Where Pi gives you a minimal core to build on, DeepSeek’s harness gives you a set of parts to assemble.

A practical example

Let me give you the problem I was actually trying to solve: migrating a legacy Python 2.7 application reliably, without changing years of accumulated behavior or corrupting its persisted data. Getting the code to run on Python 3 was only one part of it. I also needed to preserve behavior, verify the data across both runtimes, control what the coding agents could change, and decide what should happen when a test or verification step failed.

So I approached the choice of coding harnesses from a very different perspective. Instead of asking which one was best, I asked what each one would buy me in terms of control, isolation, and lifecycle management. The answer led me to use more than one:

• Claude Code built the port because I wanted internal steering, specialized skills, hooks, and a factory of implementation and review subagents.
• Codex verified it in isolated runs because I wanted an independent model context, clean workspaces, constrained writes, and structured findings.
• Pi owned the outer lifecycle because I wanted durable state, evidence validation, bounded repairs, replanning rules, and human escalation.
• Frozen acceptance, including Playwright and Python 2/3 differential checks, ran outside the agents so neither the builder nor the verifier could redefine success.

I didn’t use DeepSeek’s Harness here because I wanted a very small outer lifecycle I could read end to end, not because it can’t do the job. To first check whether this setup would actually make a difference, I built a small Python 2 application with the same kinds of traps as the real migration. I then compared the composed setup with a single Claude Code session, in which Claude could verify and test its own code.

Interestingly, both setups passed all 25 hidden behavior tests. Yet the single-session setup silently collapsed two distinct Python 2 dictionary keys, the Unicode u’é’ and byte string ‘é’, into one Python 3 string. After the data was saved, one entry was permanently lost. The single-session setup also changed a Python 2 Unicode value into bytes without documenting it.

The test suite missed it. Claude’s own tests missed it. Hundreds of recorded behavior comparisons missed it. Even my hand-written reference port had the same hole.

But what happened next was even more interesting. Two isolated Codex verifiers independently reproduced the defect. Claude didn’t simply accept the finding; it contested it. Pi then launched a fresh Codex run that received only the finding and Claude’s argument. The independent recheck upheld the finding, and Claude accepted it. Pi routed the defect into a bounded repair, and the next verification round confirmed that both keys and their original types now survived.

It’s also ironic because models are often criticized for being sycophantic. They apologize and rewrite working code the moment you ask, “Are you sure?” Here, the opposite happened. Claude contested a defect that two independent verifiers had reproduced. Its session context contained its own implementation history and passing tests, all of which supported the patch. A fresh verifier context broke that self-reinforcing frame. Independent verification matters not because the second model is automatically right, but because it’s not anchored to the same history.

The important point is that no individual harness deserves all the credit. The better result came from combining the controls I needed: internal steering, independent execution, frozen behavioral evidence, and deterministic lifecycle policy.

How to choose your coding harness

When choosing a coding harness, start with the level of control you need and how much of the remaining harness you are prepared to engineer yourself. A useful comparison could begin with questions like these:

• Do I want to configure an existing coding loop, extend it, or replace parts of it?
• Can I control tools, context, memory, and model selection at the level my project requires?
• Where are permissions, allow lists, and policies enforced: in instructions, application logic, or the operating system?
• Can I intercept actions and lifecycle events before and after they happen?
• How much of the orchestration, state management, and session lifecycle can I change or orchestrate?
• What does the harness expose for observability, verification, and structured evidence?
• Which reliability and governance controls does the harness provide, and which ones remain mine to build?
• Can the harness work with other tools and harnesses if my requirements cross several control layers?

These are some examples to get you started, not an exhaustive checklist. The questions that matter for you will also depend on what you’re building, how much autonomy you’re willing to give the coding agent, and what you remain accountable for when it fails.

Your answers may lead you to Claude Code, Codex, Pi, DeepSeek’s harness, or another coding harness entirely. In the end, the developer’s name only tells you who packaged the runtime, not where your guarantees live. Whether you settle on one harness or orchestrate several, the principle is the same: Choose the tool by the boundary of control it gives you, and ask whether you want the agent to define the terms of its own success.

来源：O'Reilly Radar · oreilly.com