A county IT team is refactoring an authentication module. The work is a sequence of steps, but every step edits the same three source files and later steps depend on naming decisions made in earlier ones. How should this work be structured?
Select an answer to reveal the explanation.
Short Explanation
Every step is elbow-deep in the same three files and depends on what the last one named things. Hand that to parallel agents and you get two people rewriting one paragraph.
Full Explanation
The deciding test for splitting work across agents is independence: can the slices proceed without seeing each other's results? An authentication refactor where every step edits the same three files and later steps consume earlier naming decisions fails that test on both axes—shared write surface and sequential dependency.
A single agent holds the whole change in one context, so a naming decision made in the first step is simply present when the fourth step needs it, and no two writers touch the same file concurrently. Nothing has to be serialized into prose and re-communicated across a boundary, which is the expensive and lossy part of any delegation.
Splitting by file still leaves each agent editing code the others are changing underneath it, and a final merge pass must resolve semantic conflicts no agent had the context to anticipate. Coordinating step-agents through a lock file serializes them anyway, paying the full overhead of delegation while surrendering the parallelism that was the only reason to split. Running a writer and a reviewer over the files simultaneously points the reviewer at a moving target, producing findings that are stale before they are reported.
Exam caveat: the same refactor becomes splittable once it is decomposed into modules with disjoint files—coupling is a property of the plan, not a law of the codebase. Operational check: list the files each proposed slice would write; if any file appears twice, keep the work in one agent.