The roles don't disappear. They move.
Agentic delivery doesn't remove the reviewer, the architect, or the PM from the picture. It moves their judgment one level up the stack, from doing the work to defining and gating the workflow that does it.
The debate about agentic engineering keeps collapsing into two camps. One says the reviewer, the architect, and the PM are becoming redundant, the agent does the work now. The other says none of this really works, an agent can’t replace the judgment a real engineer brings. Both camps are arguing about the wrong thing, because both assume the role either survives intact or disappears. Neither is what actually happened here.
What a reviewer used to do, and what a reviewer does now
A reviewer used to read every diff, line by line, and decide whether it was safe to merge. That was the job. In this factory (~/hekton/agents/review-agent.md), a reviewer’s actual job is defining the protocol every diff gets checked against: a Dual Verdict of spec compliance and code quality, findings graded Critical, Important, or Minor, with any maturity claim gated on real evidence links a human has to have actually verified, not just asserted.
That’s not a smaller job. It’s a different, and arguably harder, one. Deciding “this specific diff looks fine” is a local judgment you make once. Deciding “here is the exact, checkable protocol and severity rubric that separates a fine diff from a bad one” is a judgment that has to hold up across every diff that will ever be checked against it, including ones nobody has written yet. The reviewer who used to read code now writes the rubric the review runs against, and personally re-checks anything the rubric flags high-stakes, because a wrong rubric fails silently on every future diff instead of loudly on one.
Judgment doesn’t disappear when a role changes. It relocates to wherever the rule gets written.
The architect moved from the diagram to the promotion gate
The architect used to draw the target-state diagram and defend it in review. In this factory (architecture-map-lab/docs/retire-promote-review.md), the architect owns something more durable: a maturity model with real evidence, documentation, code, and operating-model gates that decides whether a piece of work is allowed to graduate from an experiment to load-bearing infrastructure, with the decision owner named explicitly as human, not the agent that built the thing.
That’s the same judgment, applied earlier and more durably. Instead of reviewing one diagram once, the architect defines the bar every future component has to clear, and the bar itself, evidence of real use, a documented interface, a validated promotion review, does the work of preventing premature architecture that used to depend on the architect personally noticing and objecting.
The PM moved from the backlog to the scoring model
The PM used to look at the backlog and decide, by feel, what mattered most this week. In this factory (~/hekton/scripts/pm/hekton_pm.py), the PM’s judgment is encoded in a deterministic scoring model, weighing value, reuse, risk reduction, momentum, and complexity, and the PM’s actual job became setting each task’s inputs to that model honestly, not running the triage by hand every day. The weights themselves are fixed in the script, not a dial the PM turns daily; the judgment that moves is deciding what a given task’s value, risk, and momentum actually are, which the script cannot know on its own.
The output is a brief that never silently changes anyone’s task status and never guesses at priority the PM hasn’t already defined the rules for. The PM didn’t get replaced by the script. The PM’s judgment got moved into the rules the script applies, which means that judgment runs every time the script does, whether that’s once a week or once a sprint, instead of only when the PM has time to look at the board.
| Role | Was | Now |
|---|---|---|
| Reviewer | Reads every diff | Defines the review protocol and severity rubric an agent applies |
| Architect | Draws the diagram | Owns the promotion bar and evidence requirement |
| PM | Triages the backlog by feel | Calibrates the scoring model the backlog runs on |
Why this reframe matters more than the capability debate
If you’re deciding how to bring agentic delivery into a team, the capability question, can the model do the work, is mostly settled and mostly beside the point. The actual design question is where each of your team’s existing judgment calls should move to, not whether they survive.
A reviewer who insists on reading every line personally will burn out trying to keep pace with agent-generated volume. A reviewer who moves their judgment into a checkable rule scales without burning out, and their judgment runs on every diff, not just the ones they had time to read. The same shift applies to every role in the room.
The reviewer, the architect, and the PM each lost the same thing: doing the work one instance at a time. None of them lost the judgment.
The people who get this wrong tend to make one of two mistakes: they assume their judgment is no longer needed, and disengage, or they insist on applying it the old way, one instance at a time, and get run over by volume. The people who get it right ask a specific question about their own role: what is the rule I would write, if I had to write one, that captures the judgment I currently apply by feel. That question is usually answerable. Answering it is the actual work of moving into an agentic operating model, and it’s harder than reading one more diff, which is exactly why it’s the part that still needs a human.
Next time: what happens when the same discipline gets applied to learning itself, and what a coding agent does to an exercise the moment the criteria are visible to it.