What changes for EPD teams when agents join

An engineer on one of our triads described her Tuesday to a client recently, and the client's first reaction was that it sounded like a staff engineer's Tuesday from a much larger company. She'd reviewed three agent-produced changes against the cycle's recorded constraints, rejected one with a written reason that went back into the context layer, spent two hours on an architecture decision the agent had correctly flagged as outside its authority, and shipped twice. Lines of code typed by hand: maybe forty. Decisions made: more than her previous job asked of her in a week.

That's the honest shape of agents joining the delivery loop. Roles don't disappear; each one moves a level up the abstraction stack, and the day-to-day work changes more than any org chart shows. Here's the role-by-role map.

Engineers move from producing code to directing it

• Specifying intent precisely becomes a daily skill, not a planning ritual
• Review changes character: the question is rarely whether the syntax is right and almost always whether the change matches the decision it claims to implement
• Owning the eval sets that define correct behaviour becomes core engineering work

The engineers who thrive are the ones who were already good at asking why before writing how.

Product managers move from routing to curating

A PM in a traditional loop spends much of the week as a human context bus, re-explaining decisions to whoever needs them next. With a context layer carrying the decisions, that work evaporates. What's left is the harder, better job: making decisions crisp enough to be recorded, with reasoning an agent or an engineer can apply to an edge case. Writing a decision that survives contact with implementation is a craft, and it's now the craft the role centres on.

Designers get the feedback loop inverted

Constraints arrive live in the design tool rather than in a kickoff deck, so the conversation between design intent and technical reality happens while the screen is being drawn. Design systems quietly become more important: a well-structured system is effectively an API that agents build against, and an inconsistent one produces inconsistent agent output at machine speed.

The two questions leadership inherits

1. Levelling. Career frameworks written around output volume stop making sense when output is cheap. Frameworks that reward judgment, specification quality, and eval ownership have to replace them, or the wrong people get promoted within two review cycles.
2. The junior pipeline. Juniors traditionally learned by doing exactly the work agents now do. The teams handling this well give juniors ownership of eval sets and small, fully-owned surfaces: real decisions at low stakes. The alternative is a generation that can direct work it never learned to do, and that bill arrives in about five years.

None of this comes from buying licenses

The roles shift because the delivery system around them carries context and enforces decisions. Inside a system that does neither, the same tools just produce faster drift, which is the thread running through this whole series and the reason our delivery cycle treats the context layer as infrastructure, not tooling.

The question for your own team

If output stopped being scarce tomorrow, what would each of your roles actually be paid for? The answers are the beginning of a real adoption plan.

The AI-PDLC Blueprint includes the role-by-role transition map for your organisation; the Agentic Blueprint covers the harder version where agents act, not just produce. And if the transition needs senior people who've already worked this way, that's what Embedded is for.