How I Work With Coding Agents Today

A few months ago I started using agents for coding work. An agent is a program that hands a task to an AI model and lets it work on its own: it reads the code, changes it, runs the tests. I don’t use them as a copilot suggesting lines while I type, but as a team that works while I’m not around. I learned something quickly though: agents don’t replace the driver, they free you to drive better.

Here’s how it breaks down. Grind work, the heavy and repetitive kind, agents do on their own: well-defined tasks, changes that look alike, automated reviews. Critical paths I still drive myself: architectural decisions, the things that actually matter. There I use Cursor, Codex, or Claude Code, three tools for coding with AI, but I’m at the wheel. What changed is how much heavy lifting I can delegate without losing control of what ships.

The flow

Tasks live in Linear, the tool where I write down and sort pending work. Each task is an issue. When one is ready for an agent to pick up, I give it the “Ready For Claw” label. That’s the starting signal.

The orchestrator is OpenClaw, an agent that runs in the background with a heartbeat, a periodic pulse: every so often it wakes up and checks Linear. If there are “Ready For Claw” tasks, it kicks off the coder, the agent that writes code. If there are PRs in “In Review”, it kicks off the reviewer, the agent that reviews. A PR is a proposed change to the code, ready for someone to review before it goes in. Without that heartbeat nothing happens: it’s the clock that sets everything else in motion.

The coder is Cursor CLI, the version of Cursor you drive from the terminal by typing commands. It runs headless, with no window or editor open, inside the repo. It picks up the task, reads the context, and gets to work. When it’s done, it runs the repo’s three automated checks. Lint looks for common mistakes and formatting slips, typecheck verifies that the data types line up, and the tests prove the code does what it’s supposed to. If they pass, it opens a PR and moves the issue to “In Review”. If they fail, it logs what broke and leaves the issue in “In Progress” for the next attempt. The one who decides it’s done isn’t the agent: it’s the tests.

The reviewer is the same tool with a different AI model and a different prompt, the instructions it gets when it starts. It reads the diff, the exact lines that changed, reads the task notes, and looks for bugs, architectural problems, broken logic. No style nitpicks. If it finds something, it kicks the task back to the coder: it hands it back with the list of what it found. If not, it leaves the task ready for my approval. There are two safety rules. After three kickbacks without a fix, it notifies me and stops. And on any doubt, not only when it hits the kickback limit, it notifies me too. The agent doesn’t guess when it’s unsure.

All persistent state, everything that has to survive from one run to the next, lives in my personal Obsidian vault. Obsidian is the app where I take notes, and the vault is the folder holding all of them. The agents’ notes go in an Agent Notes/ folder next to the project, not inside the code repo. That matters to me. Context lives beside the project, not embedded in it, and I navigate it like any other note: with the graph view, backlinks (which notes point to this one), and search. The structure:

Agent Notes/
  tasks/LINEAR-ID.md    ← per-task history
  runs/YYYY-MM-DD.md    ← daily log of what ran
  decisions/adr-NNN.md  ← architectural decisions

Each task has its own note with the history of attempts and what the reviewer found. Each day has its run log, a record of what executed, what happened, and how long it took. Big decisions get written up as ADRs, short notes that say what was decided and why. Agents are amnesiac by nature. Files on disk aren’t.

And there are two output channels not to confuse. The Obsidian notes are detailed context for the next agent, written for a machine to read. The Linear comments are summaries for me, written for a person to read. Every agent action writes to both.

My part is the same as always. I review the PRs the reviewer approved, merge what looks good (fold it into the main code) and handle the ambiguous cases. And for anything on the critical path I sit down and drive directly with Claude Code, Cursor, or Codex. The agent brings the grind and I bring the judgment.

Why it works

Three things hold it together.

Persistence. Agents forget everything when a session ends. The system doesn’t. Every attempt is written down: what was done, what failed, what the reviewer found. The next agent starts with real context, not from zero.

External verification. The agent doesn’t self-assign “done”. Tests, lint, and typecheck are what decide if the work is correct. Without that external signal, agents ship with full confidence even when the code is broken.

Separation of concerns. The coder codes, the reviewer reviews, I approve. Each has a clear role and they don’t overlap. The reviewer never rewrites, it only reports. I never merge without going through the flow, even when I could.