AI Services and Tools (4): Coding Agents (Cursor / Claude Code / Codex / Open-Source Agents)#

The reason coding agents get a chapter of their own is clear. In a one-person startup, these tools are the hands that build the product. In my case, the time spent on “coding by typing directly” has dropped dramatically over a few years, and “conveying requirements to an agent and reviewing the results” has filled that space. This chapter lays out how to understand, choose, and use those tools.

First, three words to keep apart: model, agent, client#

The biggest reason this topic is confusing is that model, agent, and client get discussed all mixed together.

• Model: the brain that thinks. The LLM itself, as explained in Chapter 1.
• Agent: the way of working that puts the brain to actual work. It includes the repeating loop of reading files, fixing code, running commands, looking at test results, and fixing again, plus the rules that wrap that loop (the harness).
• Client: the window through which a person uses the agent. Editors, terminals, desktop apps, the web, and messengers all fall here.

A simple analogy: the model is the engine, the agent is the driving style and transmission, and the client is the driver’s seat. Cars that look the same from the outside can feel quite different if only the engine is shared and the driving style differs. For example, choosing an OpenAI coding model in Cursor’s chat and installing the Codex extension inside Cursor are entirely different things. The former is Cursor’s agent using an OpenAI model; the latter is OpenAI’s agent sitting in the driver’s seat called Cursor. Even with the same model, the results differ because which tools it is given, in what order context is loaded, and how it retries on failure all differ. Chapter 4 (Agents and Harnesses) covers this difference in more depth.

Coding agents by shape#

Even among “coding AI,” the characters differ quite a bit, and two axes make them easy to sort. One is who drives. It is a spectrum from assistive tools (autocomplete), where the person leads and the AI helps, to autonomous tools, where the AI takes on the whole task. The other is where it runs: in my local editor or terminal, asynchronously in the cloud, or resident on a server and invoked by messages.

These are different shapes, not a ranking. I use all four and choose by the nature of the task.

Cursor: the AI-first IDE#

Amid the wave of GitHub Copilot delivering a fresh shock to developers, “AI-first IDEs” like Cursor appeared relatively early. Cursor is a tool that, on top of a VS Code-based editor experience, puts a workflow of delegating codebase-wide changes front and center, going beyond code autocomplete / chat. Windsurf and Google’s Antigravity are in the same family.

When I first started using Cursor, it felt like “a bit better than Copilot.” But once the agent feature arrived, the experience changed dramatically. Hand over a requirement and the agent explores the codebase, modifies multiple files, and explains the reasons for changes where needed, getting close to an experience of “pushing the task through to the end.” Today, the agent can open a browser to check the screen, operate external services via MCP, and run multiple tasks in parallel, all inside the IDE.

Claude Code: an agent you hand the repository to from the terminal#

Claude Code is Anthropic’s coding agent; it started in the terminal and has widened its driver’s seats to IDE extensions, a desktop app, the web, and messengers. It starts by reading the rule file at the repository root (CLAUDE.md), and comes with skills that pin recurring work down as procedures, memory that accumulates knowledge across sessions, the ability to split work across subagents, and MCP for attaching external tools. I run this blog’s post writing, translation, and news brief writing as Claude Code skills, and at work I keep Cursor as my main tool with Claude Code as a supporting one.

Codex: OpenAI’s agent runtime#

Codex is OpenAI’s coding agent, and on first encounter it is easy to get confused about what the CLI, desktop app, web, IDE extension, and SDK each are. Going by the official docs, the CLI / app / web / IDE extension are the same Codex agent used from different driver’s seats, and the SDK is the interface for controlling that agent from a program. Choosing an OpenAI model in Cursor’s chat, on the other hand, uses a Codex model but not the Codex agent. I use the CLI as my reference point, and when needed I also use a plugin that calls Codex as a reviewer inside Claude Code (to have the code checked once more from a different model’s perspective).

Open-source and resident agents#

Open-source agents such as OpenCode, Aider, and Cline have the strength that any model can be attached and the code is public. The resident Hermes Agent goes a step further: you run it on a server, drive it with messages from Slack or Discord, it creates skills on its own from work experience, and it runs unattended jobs like daily reports on cron. It also matters that if you choose a container backend such as Docker, you can precisely limit the agent’s range of action to “only the mounted folder.” At work I use Hermes for both product development and ad operations, and for personal use I run it on a remote server so that work continues after I close the laptop. That experience is covered in “Dividing Work Solo” in the Execution section.

How I work: the navigator in pair programming#

Developing with Cursor can be compared to pair programming. The agent takes the driver role (writing / modifying code), and the developer takes the navigator role (setting the development direction / conveying requirements / reviewing results). The essence of the navigator role is not “getting the code written for you,” but giving clear goals / constraints / quality criteria and reviewing the results so that they converge on the intent.

A few habits strongly determine the quality of the result.

• Define “done” with tests. Have the agent write test code and actually run it, so it checks for itself “whether the work is finished.” It is the habit of finishing with “a result whose behavior is verified,” not “a result that looks plausible.”
• Keep instructions in files, not in chat. This is the rule file, skill, and memory structure from Chapter 3. Each tool recognizes a different file name (Claude Code uses CLAUDE.md, Cursor .cursor/rules/, Codex AGENTS.md), so if you write the rules in the main tool’s file and have the other tools’ files reference it, you can manage the rules in one place only.
• Run in parallel, but keep the human rhythm. Running different tasks in several sessions at once has the effect of one developer handling two or three jobs. But the human head switching between sessions becomes the new bottleneck. This problem is covered separately in “Dividing Work Solo” in the Execution section.
• Take a second look with a different model. For important changes, run a review with a model from a different vendor. When the same model writes and the same model reviews, they share the same blind spots.

Finally, I came to feel that coding agents do not stay “tools for developers only.” Beyond writing code, they can read and modify local files, run commands to automate tasks, and connect external tools to extend a workflow. The manuscript of this book itself was written together with a coding agent. The story of applying this approach to non-development work continues in Part 4.

Principles for choosing tools#

At first I agonized over “which tool should I settle on,” but in the end I judged that tools with similar concepts compete with each other and quickly catch up on features, and decided to settle on one for now. Under the assumption that when a new feature appears in another tool, a similar one will soon arrive, I focused on changing the way I work rather than on the cost of tool selection. A few principles emerged after that.

1. Pin down one reference point first. Pick a main tool and build up its rule files and skills as assets. Attach other tools by role (reviewer, parallel worker, resident bot).
2. Use the economics of subscriptions. For a coding agent an individual uses all day, a monthly subscription is far more economical than the API. But do not try to pull that subscription in as the backend of your own product (see the previous chapter).
3. Prevent tool lock-in with the file structure. Keep rules, design docs, and memory as plain Markdown inside the repository, and whichever tool opens it starts from the same context.
4. Do not trust the defaults. The sandbox is off by default, it stalls if a question goes unanswered, and it can still read a file you told it not to read. These limits and the responses to them are covered in the Operations chapter of the Execution section.

Summary#

• Coding agents are only comparable once you split them into three layers: model · agent · client.
• IDE-style, CLI-style, cloud-style, and resident are not a ranking but a choice based on the nature of the task.
• The person is the navigator. Define “done” with tests, keep instructions in files, and review with a different model.
• Pin down one reference point, use the economics of subscriptions, prevent lock-in with the file structure, and do not trust the defaults.