Phase 1 · Months 0 to 2

Direct coding agents and read their code

Why this phase comes first

Agents build everything else in this roadmap under your direction, so the quality of your direction sets the quality of every later phase. Job postings for both kinds of role ask for this skill directly. Product postings ask you to "drive AI coding agents hard, review what they give you, own what you merge". Staff postings ask for someone to get a whole engineering organisation using Claude Code and MCP. You cannot lead adoption of a way of working you have not mastered yourself.

Learn one coding agent in depth

Pick one coding agent and learn it in depth. Claude Code is the obvious choice, because platform job postings name it. Learn enough about Codex, Cursor, and OpenCode to compare them fairly. In depth means you know its configuration as well as its prompts. Learn these features:

• Context files. Learn what goes in CLAUDE.md or AGENTS.md, and how to keep the file short and current.
• Planning. Have the agent propose a plan, correct the plan, then let the agent run.
• Skills, custom commands, and subagents. Package know-how once, so that agents and colleagues reuse it.
• Hooks. Run formatting, tests, secret scanning, or policy checks automatically before or after agent actions.
• MCP servers. Give agents controlled access to tickets, docs, logs, and databases.
• Permission modes and sandboxes. Decide what the agent may do without asking, and where it runs.
• Headless runs in CI. Run the same agent in pipelines without a person watching. The Claude Agent SDK is the programmable version of the same loop, and Phase 5 builds on it.

Run several agents at once

You get the biggest gain in output when several agents work at the same time. For example, one agent builds a feature, one writes tests, and one investigates a bug. For that to work, you need three things. Each agent needs its own git worktree or container, so the agents do not overwrite each other. You need to see which agent is working, which is waiting for your approval, and which is idle. Sessions need to keep running when you close your laptop or lose an SSH connection.

A new kind of tool handles exactly this. Herdr is a good example. It is an open-source terminal multiplexer that knows about agents. It runs Claude Code, Codex, Cursor, or OpenCode side by side, shows the state of each agent, and keeps sessions alive on local or remote machines. It also has a socket API that lets one agent start and prompt other agents. tmux or Zellij with git worktrees covers much of the same ground. They are more mature, but they do not know what state an agent is in.

Make agent output checkable

Make the agent's work checkable before you look at it. Require tests with every change, and read what each test asserts, because agents often write tests that pass without proving anything. Put most of your trust in practical tests that run the real system: end-to-end tests, replayed production traffic, and property-based tests. Use types, linters, and CI so that the agent can check its own work.

Set up one reviewer agent that runs on a different model from the author agent. Give it a narrow brief, such as authorisation bugs only, and access to the spec and the tests. Then measure it. Plant bugs in a few diffs and count how many the reviewer catches. Read in depth only the code where a mistake costs the most, as the page "Read code well and write it rarely" describes. Keep a log of the defects that reached you and the ones you missed. The log shows where your checking is weak.

Build a raw agent service with an agent

Write a one-page spec. Then have your coding agent build a small FastAPI or TypeScript service that calls one model API directly and runs the tool loop itself. The service accepts a task, calls the model, validates each tool call the model requests, runs the tool, returns the result to the model, and streams the final answer. Do not use LangChain or LangGraph yet, because you want to see how the loop works. Store each run in Postgres with the model, prompt version, token counts, tool calls, duration, and outcome. Add Docker, health checks, retries with a limit, timeouts, and CI.

Then do the exercises that build understanding. Draw the loop as a sequence diagram from memory. Inject five failures and predict each result before you run it: a model timeout, malformed tool arguments, a duplicate request, a cancellation, and a tool that hangs. Ask the agent to plant bugs and find them.

Write down your agent setup

Put the setup you settle on into a small repository that someone else could clone. Include your context-file conventions, two or three skills, a few hooks, your worktree and multiplexer setup, and a review checklist. This repository becomes the start of Forge and of the adoption work in Phase 12.

You are done when

You can go from a written spec to a deployed, tested service in one day with agents. At least three agents run in parallel while you do it, and you know what each one is doing. You can explain every step of the agent loop, predict how it fails, and find planted bugs in a diff that an agent wrote. Another engineer can adopt your agent setup from its README.

Exit checklist