The prediction you hear is that teams get smaller. Fewer engineers, more agents, a flatter org chart. I think that's the wrong shape of answer, and Conway's law explains why.
Conway's observation is that organisations produce systems which copy their own communication structure. It has held up for sixty years, and it is a statement about communication rather than about labour. That distinction is the whole argument here.
Why doesn't an agent change the structure?
Because it adds production capacity without becoming a participant in the communication.
An agent doesn't attend the design review and disagree with the proposed boundary. It doesn't hold a position across three meetings and refuse to move. It isn't in the conversation where two teams work out who owns the shared table, and it cannot be accountable when the decision turns out badly. If team structure needs to survive contact with a marketing team, XenGrowth's growth engineering practice has the operational side.
Those conversations are the thing Conway was describing, and they're the thing that determines your architecture. Adding an agent to a five-person team gives you five participants and more throughput — not six participants.
Conway's law is about who has to agree with whom. An agent never has to agree with anyone, which is exactly why it doesn't change the shape of what you build.
Meyer et al.'s instrumented study bounds this quantitatively. Collaborative activities took 24.4% of the developer workday — more than coding at 21.0%. The largest single block of a developer's time is the part an agent cannot participate in. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
So what does change?
Review becomes a staffed function
This is the clearest consequence and it's already measurable. DORA's 2025 data shows throughput rising while delivery stability falls. More reaching production, more of it wrong.
Review has historically been unstaffed work — something engineers do between their own tickets, with no budget line and no capacity model. That works when the volume of code needing review is bounded by how fast humans can write it. Remove that bound and review becomes the constraint, immediately and permanently, because reading for correctness requires the understanding that reading is supposed to produce.
Veracode's 45% flaw rate is the size of the workload arriving. Teams that keep treating review as goodwill will find their change-failure rate answering the question for them.
Ownership boundaries get harder, not softer
A person who needs to change code owned by another team feels friction. They have to find the owner, ask, justify, wait. That friction is annoying and it is also load-bearing: it's the mechanism by which boundaries stay meaningful and by which the owning team finds out their assumptions are about to be violated.
An agent doesn't feel it. Asked to make a change, it changes what needs changing, and the fact that four teams depend on that module is not a consideration it can weigh — because it cannot see the org chart at all.
GitClear's numbers show a version of this already: block duplication per million changed lines up from 40.3 in 2023 to 73.0 in 2026, with refactoring collapsing from 24.1% to 9.5% of changed lines. That's a codebase where the same logic exists in more places, which is what you get when the cost of writing it again in a new place drops below the cost of going to ask whether it already exists. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
Structural element | What used to enforce it | What happens now |
|---|---|---|
Module ownership | Friction of asking the owner | Bypassed silently; boundaries need explicit enforcement |
Architectural consistency | One person holding the whole design in their head | Needs written decision records, because the writer has no memory |
Review as quality gate | Bounded by human writing speed | Unbounded input; must be staffed and capacity-modelled |
Onboarding through code reading | New hires learned by reading a human-authored codebase | Codebase now contains code nobody built a model of |
Incident accountability | The author knew what they meant | No author intent to recover; the accepter is accountable |
There is a second-order effect here that takes about a year to show up. New engineers have always learned a system by reading it, and what they were reading was a record of decisions people made — odd code meant somebody hit a case, a strange abstraction meant a requirement you had not met yet. Onboarding worked because the codebase was, in effect, a written account of the team's accumulated understanding. A codebase where a large share of the content was accepted rather than authored is a much weaker teaching artifact, because a good deal of its oddness means nothing at all and the reader has no way to tell which is which.
On-call gets worse before anyone notices
This is the cost nobody puts in the business case. Incident load is a function of change volume, and change volume is precisely what went up.
Cook's third observation — catastrophe requires multiple failures, single faults are not enough — is the mechanism. Each individually-plausible change shifts an assumption slightly. Ship many more of them, each with less shared understanding behind it, and you increase the rate at which individually-insufficient faults combine into something that pages someone at 3am.
And Cook's seventh observation makes the aftermath worse. Post-incident attribution to a root cause was already fundamentally wrong; with more contributors and no author to ask what they were trying to do, the postmortem that names one cause is going to be even further from useful than it used to be. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
Does the two-pizza team still make sense?
The small-autonomous-team model was never really about capacity. It was a bet that coordination cost grows faster than the output of the people you add, so you should keep the number of people who must agree with each other small and give that group everything it needs to ship without asking permission. Nothing in that reasoning refers to how fast anyone types.
Which means the model survives, and arguably gets stronger. If production capacity is no longer what limits a small team, then the case for keeping teams small and boundaries clean is now almost entirely about coordination and ownership — the two things that did not improve. A team of four that owns its surface end to end and can ship without a cross-team negotiation is in a better position than it was, because the constraint that used to make it wish it were a team of eight has partly lifted.
The version that does break is the team held together by shared context in people's heads rather than by written boundaries. That arrangement works at small scale because everybody has read everything, and it fails quickly once a meaningful share of the codebase was accepted rather than authored. Those teams will feel the change as a sudden loss of the sense that someone understands the whole thing, usually about six months in and usually without connecting it to the cause.
So the structural advice is not to resize teams. It is to convert the parts of your structure that currently run on shared memory into parts that run on written record — ownership, decisions, interfaces — because shared memory was a property of humans authoring everything, and that assumption has quietly stopped holding.
What should you actually do about the org chart?
Give review an owner and a capacity number. If nobody's job description contains it, it will be done badly by tired people at the end of the day, and DORA's stability line is what that looks like on a chart
Write ownership down and enforce it mechanically. CODEOWNERS, required approvals, whatever your tooling supports. The social friction that used to protect boundaries has been removed and needs replacing with something explicit
Staff architecture decision records properly. The single reason they matter more now is that generated code carries no author intent, so the only recoverable record of why something is the way it is has to be one somebody wrote deliberately
Model on-call load against change volume rather than headcount. If deploys per week doubled and the rota didn't change, you have quietly doubled the load on the same people and are running an unfunded liability
Measure throughput and change-failure rate together, on the same chart, in the same meeting. Separating them is how a team reproduces DORA's finding while believing things are going well
Do not shrink the team on the strength of a throughput number alone. Throughput is the metric that improved. It is not the metric that was constraining you
Expected structural change | Likely actual change |
|---|---|
Fewer engineers per team | Same headcount, different work mix, review-heavy |
Flatter hierarchy | More explicit ownership, because implicit ownership stopped working |
Less coordination overhead | Unchanged — coordination is external and human (24.4% of the day) |
Fewer meetings | Same meetings; the design disagreements did not go anywhere |
Juniors replaced by agents | Juniors not hired, seniors doing review, shortage deferred five years |
The bottom row is the one I'd watch most carefully, because it's the change that's actually happening and it isn't a structural improvement — it's a deferred cost. A team that replaces its junior pipeline with agent capacity has more output this year and no one to promote in four.
Conway's law has a corollary that's useful here. If you want to change the system, change the communication structure. An agent doesn't change the communication structure, so it doesn't change the system — it just changes how fast you can build the one you were always going to build.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth covers the go-to-market side of team structure, which this piece deliberately leaves alone.
