FIELD NOTE / X
Six agents can make one engineer slower.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved X edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
Six agents can make one engineer slower.
Video caption
Six agents can make one engineer slower. Owner attention and integration are finite. Measure accepted work, not agent count. #EricFieldNotes
Full written post / accessibility read
Six coding agents can produce six plausible diffs before lunch. If one engineer must review all six, reconcile shared architecture and decide the product tradeoffs, the review queue may grow faster than it drains. More agent concurrency does not automatically create more shipped value.
For each stream, estimate review time, shared files, acceptance evidence and owner decisions. Separate independent work from changes that must be serialized. A stream with no acceptance contract is not parallelized work; it is future detective work placed on a queue.
Give an agent one worktree, a defined outcome, test oracle and escalation point. Do not send every token to the owner. Let a supervisor relay exceptions and evidence cards at scheduled review gates. Pause the next task when the review backlog exceeds the team's ability to decide carefully.
My rule: increase parallel agents only while review latency, rework and escaped defects stay within the team's budget. Do this because an unattended output queue is not acceleration; it is delayed integration work. The engineer's focus is a resource worth scheduling.
#EricFieldNotes
Four-beat scene transcript
1. Six agents can make one engineer slower.
Six coding agents can produce six plausible diffs before lunch. If one engineer must review all six, reconcile shared architecture and decide the product tradeoffs, the review queue may grow faster than it drains. More agent concurrency does not automatically create more shipped value.
Visual: Output is not accepted work.
2. Name the constraint before adding agents.
For each stream, estimate review time, shared files, acceptance evidence and owner decisions. Separate independent work from changes that must be serialized. A stream with no acceptance contract is not parallelized work; it is future detective work placed on a queue.
Visual: Owner attention and integration are finite.
3. Bound each lane.
Give an agent one worktree, a defined outcome, test oracle and escalation point. Do not send every token to the owner. Let a supervisor relay exceptions and evidence cards at scheduled review gates. Pause the next task when the review backlog exceeds the team's ability to decide carefully.
Visual: Explicit artifact and stop condition.
4. Scale decisions before streams.
My rule: increase parallel agents only while review latency, rework and escaped defects stay within the team's budget. Do this because an unattended output queue is not acceleration; it is delayed integration work. The engineer's focus is a resource worth scheduling.
Visual: Measure accepted work, not agent count.
Research and claim limits
- OpenAI Agents SDK/Codex orchestration example (S07)
- DORA State of AI-assisted Software Development 2025 (S152)
The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.