Skip to content
devzakaria — home

Plan, build, review: how I direct several coding agents at once

One agent plans, another writes, another reviews — and a human reads every change. How I split the work between coding agents, keep them on track, and decide what never gets delegated.

Zakaria Binsaifullah · · 3 min read

Most of my client work now involves several AI coding agents working on the same job. People ask what that actually looks like day to day, and whether it is safe. Short answer: it is fast, it is safe if a senior developer stays in charge, and the hardest part isn't the agents — it's writing down what you want clearly enough.

Here is how I run it.

Three roles, not one super-agent

I don't ask one agent to "build the feature". I split the job into three roles, which maps closely to how a small team works:

  1. Planner — reads the brief and the existing code, and writes a task list: what changes, in which files, in what order, and how we'll know it works.

  2. Builder — takes one task at a time and writes the code and the tests for it.

  3. Reviewer — runs the checks (types, lint, tests, build), reads the diff against the plan and flags anything that drifted.

Splitting roles keeps each agent's context small and focused, and it gives me natural checkpoints. I approve the plan before any code exists, and I read the diff before anything merges.

Which agents I use

I use whichever tool fits the task rather than one for everything: Claude Code, Codex, Cursor, Gemini and Antigravity, OpenCode, Command Code, and models like DeepSeek and MiniMax when they suit the job. Agents with long context and good tool use are best at planning across a large codebase; fast ones are great for well-specified, repetitive tasks; a second agent from a different vendor makes a useful reviewer because it doesn't share the first one's blind spots.

The specific names change every few months. The workflow around them is what stays.

The brief is the product

The quality of agent output tracks the quality of the brief almost exactly. A good brief for a task has:

  • The goal in one sentence, from the user's point of view.

  • Constraints: the stack, files not to touch, performance or accessibility requirements.

  • Done means…: the test that passes, the page that renders, the number that changes.

  • An example of the target output whenever there is one — the exact HTML, the API response, the screenshot.

Writing this takes ten minutes and saves hours. It's also the document I hand back to the client, so they can see exactly what was agreed.

Guardrails that keep agents on track

  • Small tasks. One task is one reviewable diff. If I can't review it in a few minutes, the task was too big.

  • Tests first where it matters. For anything with logic — pricing, permissions, data migration — the test is written before the implementation, and the builder's job is to make it pass.

  • Real checks, not vibes. Type checking, linting, unit tests, a production build, and end-to-end browser tests run on every change. An agent saying "done" means nothing until the checks agree.

  • No secrets in reach. Agents never see API keys or production credentials. Secrets go straight into the platform (for example, Worker secrets) and the code reads them at runtime.

  • Git as the safety net. Every change is a commit I can read and revert. Nothing is applied to production that isn't in the repo.

What I never delegate

Some decisions stay with me on every project:

  • Architecture and data model. Where data lives, how it's cached, what the URL structure is. These are expensive to change later.

  • Security-sensitive code. Authentication, authorisation, payment flows, anything handling personal data. Agents can draft it; I write and review it line by line.

  • The final review. I read every change before it reaches the client. That is the whole point of hiring a senior developer who uses agents, rather than just using agents.

  • Talking to the client. You talk to me, not to an agent.

What it means for a project

On a typical build the agents take care of scaffolding, boilerplate, repetitive refactors and first-draft tests. That frees time for the parts that make a product good: the data model, the edge cases, the editing experience, performance and accessibility. Projects move faster, and the review step means the code is still something you'd be happy to own — and you do own it, all of it.

If you'd like to see how this would work on your project, book a 20-minute call or brief my agent with a few lines about what you're building.

Available now — can start right awayDhakaGMT+6I overlap with US mornings and EU afternoons

Let's build it.

Tell me what you're building. You'll talk to me, not an account manager.

  • Reply within 12 hours
  • You own 100% of the code
  • Every agent-written line is reviewed and tested by me
esc