Ask an engineering leader how their team has changed since AI coding tools arrived and the answer is usually about tooling: which assistant, which licence, which policy. Ask how the team structure has changed and the answer is often "it hasn't". The same squads, the same ratios, the same rituals, now with an agent that can produce a pull request in minutes.

That gap matters. AI changes where the work sits. Drafting gets cheaper; reviewing, integrating and owning the result does not. A team designed for humans writing most of the code will bottleneck in new places when that stops being true.

Where "seniors plus AI" breaks down

The common shortcut is to keep a small group of senior engineers and let AI fill the gaps. It works for a while. Then three problems appear.

• Review becomes the bottleneck. Agents produce more code than seniors can review carefully, so either review quality drops or throughput stalls.
• Context concentrates. Fewer people understand more of the system, which raises the cost of every absence and every resignation.
• Nobody knows if it is working. Without measurement, "we feel faster" becomes the business case.

The last point is the most common. In LeadDev's AI Impact Report 2025, 59% of engineering leaders said they feel more productive using AI coding tools, yet 82% of engineering organisations said they do not measure the impact of those tools, and 60% named the lack of metrics as a key challenge.

Five design principles for AI-era engineering teams

1. Name the roles around the work, not the tool. In an agent-heavy team, three jobs matter: the author who frames the task and the specification, the reviewer who judges what the agent produced, and the owner who is accountable for the component in production. One person can hold several, but every change needs all three covered explicitly.

2. Size review capacity deliberately. If agents double the volume of proposed changes, review time has to come from somewhere. Track how long pull requests wait for review and how much of a senior engineer's week goes on it. When review time climbs, add reviewers or narrow the scope of what agents may change, rather than letting standards quietly slip.

3. Treat specifications as first-class work. Agents are only as good as the instructions and context they are given. Clear acceptance criteria, architectural constraints and test expectations used to live in people's heads. Now they need to be written down, reviewed and kept current, which is real engineering work and should be planned and credited as such.

4. Measure outcomes, not output. Lines of code and number of pull requests rise easily with AI and tell you little. Measure what the business feels: lead time from idea to production, change failure rate, time to restore service and the time changes spend waiting for review. Take a baseline before rolling out a new tool so you can see the real effect.

5. Keep a flexible capacity layer. AI shifts demand towards specialist skills, such as platform engineering, security, data and test automation, often for a few months at a time. Rather than hiring permanently for every peak, many teams keep a stable core and add specialists or a managed team when a programme needs them, with the client staying in control of priorities and delivery.

Three mistakes to avoid

Rolling out tools before agreeing standards. If the team has not agreed what "good" looks like for tests, naming and architecture, agents will reproduce whatever patterns they find, including the bad ones.

Removing the people who hold context. Agents are excellent at local changes and poor at knowing why a system is the way it is. Losing the engineers who carry that history is the fastest way to turn speed into rework.

Letting review become rubber-stamping. When volume rises, reviews shrink to a glance. Set a clear expectation for what every review must check, and protect the time to do it.

A practical starting template

For a product team of around eight engineers, a workable shape looks like this:

• One tech lead who owns architecture and agrees what agents may and may not change.
• Two or three senior engineers whose objectives include review and mentoring, not only delivery.
• Two or three mid-level and junior engineers who author specifications, drive agents and own components.
• A shared test automation and platform capability, in-house or flexible, so quality checks keep pace with output.
• A fortnightly review of four outcome measures, and a standing item on where AI is helping and where it is creating rework.

The exact numbers matter less than the principle: design the team for the way work now flows, then adjust as the tools change.