The teams getting durable value from coding agents in 2026 aren't pointing one assistant at one file. They run a small number of coordinated agents against a codebase whose conventions, guardrails, and backlog are written down in a form the agent can read. The shift is from pairing — guiding one agent in real time, bounded by one context window — to orchestrating: planning work, handing it out, and verifying results. That's the skill set of an engineering manager, not a coder. This leaf is the execution playbook; the foundation it stands on lives one link away.
Pairing is sequential and real-time: you steer one agent through one task inside one context window. Orchestrating is a different job — you decompose work, dispatch it to agents that don't share your memory, and check what comes back. Five ideas do most of the work, and none of them is “a bigger model”:
A single-maintainer repo with one workstream needs almost none of the apparatus below. It earns its cost specifically when multiple people and multiple parallel streams share one codebase. Scale the ceremony to the coordination you actually have — running an orchestration fleet against a solo side-project just burns tokens and attention.
Orchestration only works on top of two things this branch already covers in full. This leaf assumes them rather than repeating them — get them right first.
An agent-legible codebase: a lean root convention file (the map and the non-negotiables) with scoped per-directory detail, deterministic hooks that enforce guardrails instead of trusting the model to remember them, path-scoped skills for on-demand expertise, language-server (LSP) access so the agent searches by symbol not string, and all of it bundled into a version-controlled unit so a new developer — or a fresh agent session on another machine — inherits identical setup on day one. And a backlog that carries context: a “ready” gate, stream/size/agent-ready fields, and tickets written as specifications, not reminders.
Software for agents is the agent-legible codebase in full — repo-as-context, CLAUDE.md / SKILL.md, agent PRs, CI as the safety net. Planning with agents is the backlog as interface — spec-as-prompt, the ready gate, cadence, and what to measure. If those aren't in place, start there; nothing below compensates for a codebase an agent can't navigate or a ticket it can't execute.
Several organisations have created a hybrid PM/engineer role — an “agent manager” or DRI — sitting under developer experience, responsible for the conventions, the guardrails, and keeping them current as models and tools change. Without a named owner, good setups stay tribal and fragment. The rollouts that spread fastest had this infrastructure built by a small team, sometimes one person, before broad access — so the first experience was productive rather than frustrating (practitioner-reported).
Three ways to task an agent, from most-supervised to least. Most day-to-day work is Mode 1; the others earn their place as the work gets wider or more parallel.
Run the agent read-only: it investigates and proposes an approach touching no files, you correct the plan in a sentence, then it implements. The highest-leverage habit for multi-file work — a wrong plan costs one sentence, a wrong 300-line diff costs hours.
Give each stream its own branch checked out into its own directory. Git worktrees are the native, cheap way — they share one underlying repository, so no re-cloning or duplicated dependencies. One session per stream; serialise anything touching shared files.
For wide mechanical work (a migration, an audit, a coverage sweep), drive the agent non-interactively from a script or CI, one invocation per unit, with tightly scoped permissions. Use a cheaper model for triage and classification; reserve the stronger one for the build.
| Mode | Best for | Supervision | Isolation |
|---|---|---|---|
| Interactive planning | Anything non-trivial & multi-file | Plan boundary + diff | One session |
| Isolated worktrees | 2+ streams running at once | Per-stream, at the diff | Branch + directory each |
| Headless / scripted | Wide mechanical fan-out | Evidence + CI gates | Scoped tool permissions |
# one shared repo, two isolated checkouts — no re-clone, no dep duplication git worktree add ../proj-auth -b stream/auth origin/main git worktree add ../proj-billing -b stream/billing origin/main # run one agent session in each directory; they never touch the same files # serialise work on genuinely shared files (root config, shared components)
When one person managing a handful of agents stops scaling, two patterns exist. Understand the distinction before reaching for either — and price the tokens honestly.
| Pattern | How it works | Best when | The cost |
|---|---|---|---|
| Orchestrator / subagent (hierarchical) | One lead holds the plan and delegates bounded subtasks to workers, each with its own context; workers report concise summaries; the lead reconciles them into one reviewable change set. | Tasks split into specialised responsibilities (backend, frontend, tests, review) that don't need to talk to each other. | The orchestrator's context accumulates every summary — on large pipelines it can balloon. |
| Peer team / shared list (lateral) | Agents coordinate through a shared queue — like a kanban board — claiming tasks, posting outputs, unblocking each other, with a lead seeding the top-level items. | Workers genuinely need to share findings and challenge each other across a change that spans layers. | More coordination surface; no single agent holds the whole history (which keeps per-agent context lean). |
Multi-agent setups use substantially more tokens than a single session doing the same work sequentially — a three-worker team roughly three-to-four times the tokens is a commonly cited figure (largely vendor-reported; verify against your own runs). They pay off on large, genuinely divisible work and waste money on sequential tasks, same-file edits, or anything with heavy dependencies. Built-in team features in agent runtimes are, at time of writing, often experimental and off by default — treat them as promising, not production-hardened, and keep humans approving anything that ships.
Have agents show evidence rather than assert success: the command run and its output, the test result, the diff between the branch and the base. Reviewing evidence is faster than re-deriving it, and it works for runs you didn't watch. The powerful pattern is a fresh-context reviewer — one agent (or a human) whose only job is to try to refute the first agent's claim of success, because a worker is biased toward the code it just wrote. One hard constraint of most subagent models: a worker can't pause to get your approval mid-task — so investigation belongs in subagents, approval-gated edits belong in the parent session or a human.
Three layers of forge automation, from least to most automated. Each is useful on its own; together they close the loop from an incoming issue to a merged, reviewed change.
A mention (@-tag in an issue or PR comment) hands the agent a bounded task; it reads the repo, opens or revises a PR honouring your convention files, and reports back. Install adds the app, a workflow file, and an API secret — usually needs repo-admin rights.
Run the agent in CI on PR events as a read-only reviewer — no write access, so it advises but can't modify. Turns a 30–60-minute first review pass into a sub-five-minute one (vendor/practitioner-reported), catching style, missing error handling, and pattern violations so humans focus on architecture.
Have the agent return validated JSON that downstream steps branch on: auto-triage an incoming issue into stream/size/ready fields and move it to the right column; detect a flaky test and re-run CI. A cheap model is enough for most classification, so it can run on every issue.
Name an owner early. And review the whole configuration every few months or after a major model release — instructions written for a weaker model can actively constrain a stronger one.
For SA teams the good news is the same as the rest of this branch: the apparatus that makes agents productive at scale is engineering hygiene, not a frontier budget. Worktrees, a ready-gated board, and a read-only CI reviewer are free discipline anyone can adopt. A small team — often one agent-manager — builds the convention files, guardrails, and forge config once, and every contributor (and every fresh agent session) inherits it. Start with interactive planning and one repo; add parallelism and multi-agent orchestration only when you genuinely have the concurrent streams to justify the token bill. And the by-product is the compliance artifact POPIA and FSCA reviews ask for: the versioned spec, the PR trail, and the evidence each agent showed are your change-control record, produced as you work.
Provenance: the load-bearing patterns come from primary vendor documentation and engineering writing; practitioner and community sources corroborate the permissions, orchestration, and token-economics points. Figures on time saved and token multipliers are vendor- or practitioner-reported and labelled as such in the text — indicative, not independently benchmarked. Feature names and version-specific mechanics reflect mid-2026 tooling and should be re-checked before you rely on them.