What it is
A tempting but wrong way to adopt agents is to take the existing org chart and workflow and drop an agent into each human-shaped slot: an agent "developer," an agent "reviewer," an agent "PM," each doing roughly what the person did. This is cargo-culting the old shape of work, and it preserves the inefficiencies that shape encoded — the handoffs, the serialized stages, the coordination overhead that existed because humans are expensive and serial. The opportunity is not to staff the old workflow with tokens; it is to redesign the work around what models and tools can now actually do, which often looks nothing like the human process it replaces. A related error is measuring AI maturity by the percentage of code the model generated, as if the goal were to maximize machine authorship. That metric tracks the wrong thing entirely. The question that matters is not who typed the code; it is whether the organization ships better, safer, and more valuable work. An organization can generate ninety percent of its code with agents and ship worse outcomes, or generate far less and ship dramatically better ones. Redesign for the outcome, and let the division of labor between humans and machines fall out of that — not out of a desire to fill slots or hit a generation percentage.
When to reach for it
- When introducing agents into an existing process: ask what the work would look like if designed from scratch around current model and tool capabilities, before mapping agents onto current roles.
- When a workflow still has serialized human-era handoffs that exist only because human labor was expensive and slow, treat those as candidates to redesign away rather than to automate in place.
- When leadership starts citing "percent of code generated" as a maturity metric, redirect the conversation to outcome quality, safety, and value shipped.
- When an agent is being slotted in to do exactly what a person did, pause and ask whether the task itself should still exist in that shape.
- When measuring an agentic initiative, define success as better, safer, more valuable work — not authorship share.
When NOT to
- Redesigning work is disruptive; do not tear up a workflow that is genuinely serving its purpose just to avoid the appearance of filling slots.
- Do not over-rotate into endless redesign — at some point you ship; redesign is a means to better outcomes, not a perpetual reorganization.
- This is not a claim that role-shaped agents are always wrong; sometimes the cleanest design genuinely does map an agent to a familiar role — judge by the outcome, not the shape.
- Do not discard generation metrics as telemetry; the error is treating them as the goal, not tracking them at all.
Exemplars
- Michael Hammer, "Reengineering Work: Don't Automate, Obliterate," *Harvard Business Review* (July–August 1990) — https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate — classic antecedent: the original argument that technology should obliterate outdated processes rather than automate them in place; Ford's 75% accounts-payable reduction came from redesigning the process, not staffing it with faster clerks