Every engineering organization reorganizing around AI-augmented development is drawing a version of the same org chart. There is a small, fast delivery team pushing spec-driven work into an agent pipeline; there is a review or quality team checking what comes out; and there is some kind of platform or enablement function keeping the pipeline alive. The exact labels differ. The shape does not.
We have watched enough of these rollouts up close to be confident about the following: the structure is directionally right, and it breaks, at a predictable seam, sometime in month two. When it breaks, the engineers who notice it first are the ones who quit. That is how it becomes a retention problem instead of a delivery problem.
This is a note about where the seam is and how to avoid putting it there.
Where the seam lives
The seam is the boundary between who writes the spec and who reviews the agent’s output. Every AI-native org chart we have seen puts these two jobs in different parts of the organization. On paper this looks like classic separation of concerns. In practice it is a factory where the person writing the work order has no feedback loop with the person inspecting the finished good.
The failure mode is specific and repeatable. The spec writers learn to write specs that the agent happily fulfills. The reviewers learn to catch the ways the agent systematically fails. What neither of them learns is the composite skill — writing the kind of spec that, when fulfilled, produces work that does not need to be caught. That skill only forms when the same person watches the full loop from spec to merged diff, lives with the consequences of both ends, and closes the loop in their own head.
Split the job across an org boundary and neither side develops the composite skill. Month one, it looks fine; the reviewers are catching enough that the PRs that ship are acceptable. Month two, you start to see the following symptoms simultaneously:
- Spec writers start blaming reviewers for being too harsh. The reviewers are not being too harsh; they are being accurate about what the specs are producing.
- Reviewers start treating AI-generated PRs as a category, rather than judging each one on its merits. This is how bad PRs get merged and good PRs get rejected.
- Engineers on either side start privately updating their LinkedIn, because the work has become either mechanical spec-writing or mechanical output-catching, and neither is what they signed up for.
By month three the strongest people on both teams have either transferred out or left the company. The reorg has not failed in a way that is visible to executives — the throughput numbers are probably still okay — but the retention line has bent, and the institutional memory of how to improve the loop has evaporated with the people who left.
Why this keeps happening
The intuition to split the job is strong because the roles feel different. Writing a crisp specification does feel like a different skill from reviewing an agent’s PR. The organization is full of people who already do one or the other well. It is natural to organize around existing competencies.
It is also wrong, in the same way it would be wrong to organize an artisan bakery around “people who measure ingredients” and “people who taste the bread.” The measure-and-taste loop is the work. The bakers who can do both are the ones worth having. Splitting the loop produces neither better measuring nor better tasting — it just makes both teams defensive about their own leg of the process.
How to draw the boundary instead
The role boundary that survives month two is not between spec and review. It is between owning a pipeline and owning the tooling that pipelines run on. One group of engineers owns a ticket-to-merged-PR flow end to end, spec through review, for a defined area of the codebase. A separate, smaller group owns the shared infrastructure those pipelines use — prompt templates, evaluation harnesses, cost instrumentation, fallback behavior when a model underperforms, policy on what agents are allowed to touch.
This way, the people writing specs and the people reviewing agent output are the same people, and they live with the feedback loop directly. The platform group has a real, technical, narrow scope instead of trying to legislate how other teams do their work. And the retention risk disappears, because the role that emerges — engineer who owns the loop for an area of the product — is a role with genuine craft in it. People want that job. They do not want the two halves of it separately.
What the 90-day transition looks like
The transition is not subtle and it should not be surprising. You consolidate spec and review under each delivery pod. You formally name a platform-style function with a narrow charter and a small headcount. You publish, in writing, which decisions belong to delivery pods (how the loop works for their area) and which belong to platform (what the tools look like). You do this before engineers start updating their titles, not after. That sequencing matters more than most leaders think, because the narrative “we’re organizing around loops, not specialties” is much easier to buy before people have been labeled.
The AI-Native Team Topology engagement is the long version of this, including the specific role changes, the pod boundaries, and the transition plan that engineering managers can run without breaking delivery. But the short version is: if your reorg is splitting the loop, change it now, before month two.