The six disciplines
Updated May 29, 2026Mitchell Hashimoto's adoption arc, restated in agents-cli commands.
Drop the chatbot
A chatbot window asks you to copy code in and copy code back out. For real work, you want an agent that can read your files, run your tests, and write changes to disk. The chat tab is the wrong shape for that.
agents-cli is the surface that runs those agents. One install gives you claude, codex, and gemini as first-class subcommands, sharing the same session log, secrets, and project config.
agents run claude "find the bug in src/auth/refresh.ts and fix it"
agents run codex "port the same fix to the python sdk"Reproduce your own work
Before you trust an agent with a task, do the task yourself once. The point is not the output. The point is to feel the shape: how many files the task touches, which decisions need human taste, and which steps are mechanical. The mechanical ones are what you delegate next.
When an agent has already taken a pass at something, read the transcript back as markdown. Every run is captured in agents sessions; replaying it is how you internalize the agent's task breakdown and notice where it guessed.
agents sessions
agents sessions <id> --markdownEnd-of-day agents
Research, triage, and exploration do not need you watching. Kick them off before you stop for the night. The agent runs against the same repo and the same harness; you wake up to a session you can read like any other.
A background run detaches the process and streams its log to disk. For recurring runs (a nightly dependency audit, a Monday triage), the routines skill wraps the same command in a cron entry.
agents run claude --background "audit deps for CVEs and open issues for each"Outsource the slam dunks
A slam dunk is a task you would bet money the agent gets right on the first try: a typo across forty files, a config rename, a test you already wrote in your head. Hand those off and keep your attention on the work that actually needs it.
Dispatch a fresh agent inside a team so the work has its own session, working tree, and exit signal. You stay in your main session; the delegated run shows up under agents teams status when it lands.
agents teams create rename-feature-flag
agents teams add rename-feature-flag claude \
"Rename FEATURE_X to FEATURE_NEW_X across the repo. Update tests." \
--name rename
agents teams start rename-feature-flagEngineer the harness
Every time you watch an agent make a mistake, prevent that mistake structurally. Arguing with the agent in chat does nothing for the next run. The fix lives in the harness, and it takes one of two shapes: a line in AGENTS.md the agent reads on every run, or a script the agent invokes instead of guessing.
The line in AGENTS.md:
cat >> AGENTS.md <<'EOF'
- Tests live next to source. Never under /tests.
EOFThe script the agent can invoke. When the agent keeps misreading the UI, give it eyes:
agents browser screenshot --url http://localhost:3000/signup --out /tmp/ui.png
# then add to AGENTS.md:
# Before changing a page, run agents browser screenshot and read the result.The same pattern covers filtered test runs, log scrubbers, and any other tool that lets the agent see what it could not see before. Each one is one less thing the agent will get wrong tomorrow.
Always have an agent running
Once the harness is good, there is almost always a task worth handing over. The discipline is not parallelism for its own sake — coordinating six agents at once costs more attention than it saves. It is continuity: a session in flight, ready to pick up.
See what is mid-flight, watch the parallel work you did spin up, and resume the session you closed yesterday.
agents sessions --active
agents teams status rename-feature-flag
agents run claude --resume <id>What this is not
None of this is a claim that agents replace engineers. It is a practice. The skill is choosing what to delegate, watching where the agent fails, and turning each failure into a line in the harness. The tools above are just the surface that practice runs on.