Structuring an Engineering Team for AI-Assisted Delivery

With around 90% of developers using AI coding tools and roughly 41% of code machine-generated, the constraint in most teams moved. It is no longer how fast people can write code — it is how fast the team can review it, understand it, integrate it and keep it coherent. Team structures optimised for authoring throughput now optimise for the wrong thing.

Where the queue formed

• Review capacity. Output rose; the number of people qualified to review it did not.
• Integration. More parallel changes touching the same surfaces means more conflicts and more coordination.
• Comprehension. Someone must understand the system well enough to judge whether a change is safe, and that capacity is now the scarcest thing on the team.
• Specification. Generation quality is bounded by input precision, so vague requirements now surface as rework rather than as questions.

What this implies for team shape

• Fewer, larger-scoped changes per person. Six half-finished parallel efforts create six review queues; the throughput gain is illusory.
• Explicit ownership of coherence. Someone has to care that the codebase has one way of doing things, because independent generation produces four. Without an owner, convention drift is nobody's job.
• Reviewers as a named capacity, not a favour. If review is the bottleneck, treat it as capacity to be planned rather than time people find.
• Specification as real work. If it is not on the board, it will be done badly under time pressure and paid for twice.

What juniors should be doing

The traditional ramp — write simple code, gradually take harder work — is weaker now that simple code is the cheapest thing to produce. What builds capability is the work that is now scarce: reading unfamiliar systems, tracing bugs to root cause, writing and defending specs, and reviewing under supervision. It is harder to structure and it is the path that leads somewhere.

Practices worth adopting deliberately

• Small changes, enforced. A diff too large to reason about is a diff that gets approved without being reviewed.
• Written intent on every change. What this is meant to do, so review can check against something.
• Decision records. Machine-generated code carries no reasoning; if the why is not written down it does not exist.
• Rotate the reviewing. Concentrating review in two people creates both a bottleneck and a bus factor.
• Measure delivery, not output. Lines and commits became meaningless overnight; change failure rate and time to restore did not.

What did not change

Team topology fundamentals held. Small teams with clear ownership of a bounded domain still outperform large teams with diffuse responsibility, and cross-team dependencies are still where delivery slows. Faster authoring did not fix coordination cost — if anything it exposed it, because the coding was no longer masking it.