Choosing a harness
What to actually compare when every product claims the same model and the same benchmark scores.
You are not choosing a model. You are choosing a harness: the context assembly, the tool set, the permission model, and the ergonomics. Here is a comparison that stays useful as products churn.
The seven questions
- Can I see the context? Does it show token counts, what it loaded, and what it dropped? A harness that hides this makes every lesson in Module 02 impossible to apply.
- Can I see every tool call? You need to know what it read and what it ran, not just what it concluded.
- Does it read a project instruction file? A file in the repo, checked into git, loaded at session start. Without it, steering is per-person and does not survive onboarding.
- How granular are permissions? Per-tool and per-command, ideally with a persistent allowlist, not a single on/off switch.
- Can it run my check command? Shell access is the difference between an agent that verifies itself and one that hands you unverified code.
- Can I script it? Non-interactive invocation matters for the automated review and unattended patterns in Module 06.
- Where does the code go? Provider, retention, training opt-out. Answer this before anything else if the code is not yours.
Three shapes, three jobs
| Shape | Strength | Weakness |
|---|---|---|
| Terminal agent (Claude Code, Codex CLI, Aider, Gemini CLI) | Full shell, scriptable, visible tool calls, easy to sandbox. Best for learning, because nothing is hidden. | No editor context; you paste or point rather than select. |
| Editor-integrated (Cursor, Copilot agent mode, Windsurf, Zed) | Knows your selection and open files; the review loop is right there in the diff view. | Context assembly is often implicit, which makes it harder to know what the agent actually has. |
| Hosted / async (background agents, PR bots) | Runs unattended in a clean environment; output arrives as a reviewable pull request. | Long feedback loop; needs a genuinely good spec, because you cannot course-correct mid-run. |
Most people end up using two: a terminal or editor agent for the work, and an async one for well-specified chunks. That is a reasonable destination. Start with one.
Watch out
Do not switch harnesses to solve a process problem. "It keeps forgetting my conventions" is not fixed by a different product — it is fixed by an instruction file. Changing tools resets your muscle memory and hides whether the change helped.
Try it
Run the seven questions against whatever you use today and write the answers in your log. Any question you cannot answer is a gap in your understanding of your own tool, not a missing feature.
Takeaways
- Compare context visibility, tool transparency, project instruction files, and permission granularity.
- Terminal agents are the best teaching surface because nothing is hidden.
- Switching tools does not fix a process problem; it just resets your muscle memory.
Why does "does it load a project instruction file from the repo" matter more than it sounds?
Because it decides whether steering is a property of the project or of one person’s machine. A repo-level file is reviewed, versioned, and shared, so every teammate’s agent inherits the same conventions. Per-user settings mean the same task produces different code depending on who ran it.
A course by Pieter Zandbergen