---
title: "Leading Teams Where Agents Write Half the Code"
url: https://pragmaticleader.io/leading-engineering-teams-ai-agents/
author: "Aaron Wise"
published: 2026-10-28
description: "Leading engineering teams with AI coding agents: make review the main job, keep a named human owner per system, and retrain juniors for judgment."
categories: ["Leadership & Management"]
tags: ["engineering leadership", "human-AI collaboration", "code quality", "team accountability", "career growth"]
---

# Leading Teams Where Agents Write Half the Code

> “The death of a program happens when the programmer team possessing its theory is dissolved.”  
> — Peter Naur, “Programming as Theory Building” (1985)

When coding agents write a large share of the first draft, change three things on purpose: treat review as the main engineering job and staff it that way, keep ownership of every system with a named human who understands it, and rebuild how junior engineers learn around judgment instead of routine output. Leave the rest of the operating model alone until the evidence says otherwise.

"Half" in the title is a figure of speech. On some teams agents write a little of the code, on others most of it, and the share moves every few months. The number matters less than the shift underneath it. The first draft of a growing part of your codebase now comes from something that can't be paged at 2am, can't be promoted, and won't remember why it made a choice. Every management system you have (review, on-call, career ladders, hiring plans) was built on the assumption that the author of the code was a person who would still be around next quarter.

## The productivity claim deserves a harder look

The usual reasoning runs like this: agents make engineers faster, so the team ships more, so the main leadership task is adoption. Get licences out, run some training, and watch throughput rise.

The evidence is more mixed than that. The [2024 DORA report](https://dora.dev/research/2024/dora-report/) found that AI adoption raised individual productivity, flow and job satisfaction, and at the same time was associated with lower software delivery throughput and stability. A [randomized trial by METR](https://arxiv.org/abs/2507.09089) went further: experienced open-source developers working on codebases they knew well took 19% longer with AI tools allowed, while believing the tools had made them about 20% faster. Neither study is the last word. The METR trial had sixteen developers and early-2025 tools, and survey data like DORA's shows association, not cause. What both point to is the same gap: the feeling of speed is real, and the delivered result depends on what happens after the code is written.

The case for agents is still strong, and it deserves a fair hearing. For well-specified, bounded work (a migration, test scaffolding, a new endpoint that follows an existing pattern) agents save real time, and engineers who have learned to plan before prompting get far more out of them than those who haven't. Agents help. The help arrives as more code to read, and reading is where most teams have not adjusted.

## Review becomes the main job

Writing code got cheap. Reading it did not. A team that adopts agents without changing its review habits ends up with more pull requests, larger pull requests and reviewers who skim, because the old norm (a colleague wrote this carefully, so review means checking for slips) no longer holds.

A few norms help. The person who opens the pull request is its author, whoever typed it, and must be able to explain any line a reviewer asks about. "The agent did that" is a reason to look closer, never an answer. Keep changes small. An agent will happily produce a two-thousand-line change in one go, and nobody reviews that well; DORA's own finding that small batch sizes still matter applies with more force here. Move part of the review earlier, so a short plan or spec gets agreed before the agent starts, which is where design mistakes are cheapest to catch.

Tests need particular attention. When the agent writes both the code and the tests, the tests tend to confirm what the code does rather than what it should do. A human should own the intent of the tests even if the agent types them, in line with the view that [quality is everyone's job](https://pragmaticleader.io/quality-team-sport-testing-everyones-job-engineering-right/), which now includes checking the agent's assumptions.

Treat reviewer load as a real cost. Picture a forty-person engineering team at a Series B company that rolls out agents to everyone in a quarter. Merged pull requests go up by a third. The six most senior engineers, who approve most changes to the payment and permissions code, now spend the bulk of their week reviewing. The platform migration they were meant to lead slips a quarter, and nobody decided that it should. That is a capacity decision made by accident. Make it on purpose: put review time into planning as a line item, and decide which systems need a senior reviewer and which don't.

Managers need to stay close enough to the work to see this happening. A manager who only reads the merge-count dashboard will see a productive quarter. One who reads a sample of the pull requests will see the skimming. That is the case for [zooming in](https://pragmaticleader.io/management-spectrum-zoom-step-back/) for a while after a change this large, then stepping back once the norms hold.

## Ownership stays human

Every service, module and pipeline still needs a named person or team who understands it well enough to change it safely and to be woken up when it breaks. Agents make it easy to grow a codebase faster than anyone's understanding of it. Ownership is a behavior, as [the argument about product ownership](https://pragmaticleader.io/owns-product-no-one-owns-title/) makes for products, and here it means someone who can explain the system's design without reading the code back to you.

Accountability follows the same line. When an agent-written change causes an incident, the postmortem stays blameless, and "the agent wrote it" ends the inquiry no faster than "an intern wrote it" would. The useful questions are what review let it through, which test didn't exist and what guardrail was missing, the same systemic questions a [blameless postmortem](https://pragmaticleader.io/postmortems-turning-tech-fails-team-wins-blamelessly-brilliantly/) always asks. [Single-point blame](https://pragmaticleader.io/beyond-the-blame-game-transforming-single-point-accountability-into-collaborative-success/) was a poor model before agents, and blaming a tool is a new version of it.

## Growing junior engineers when agents do the routine work

This is the hardest part, and the one most teams haven't thought through. Juniors used to learn by doing routine work: small bug fixes, simple endpoints, test coverage, a migration. That is exactly the work agents do well. If juniors only prompt and merge, you get people who can produce code but can't debug it, and in a few years a shortage of mid-level engineers who understand systems from the inside.

Keeping juniors away from agents is the wrong answer. Redesign the apprenticeship around judgment instead, since that is what the job now needs earlier.

Have juniors review agent output, and ask them to explain it in the review rather than approve it. Put them on debugging and incident work alongside a senior engineer, because a failure in production teaches what no generated code can. Include them in the planning step, where a senior engineer decides what to ask the agent for and why. Now and then, have them build a small piece of a core system without an agent, framed as training, the way a pilot still practices hand-flying.

Change how you assess them too. Throughput is a poor signal when an agent can inflate it. Better signals are whether they can explain a change, find a bug's real cause, and say no to an approach that looks plausible but is wrong. Your career ladder probably describes judgment as a senior trait. It now needs to appear, in smaller form, at the first levels. If it doesn't, promotions will reward whoever merges the most, which is the [failing-up pattern](https://pragmaticleader.io/climbing-wrong-ladder-failing-breaks-teams/) with a new accelerant.

Keep hiring juniors. The opposing case is easy to make in a budget meeting: agents cover the routine work, seniors are more productive with them, so why pay to train people? Because a team that stops hiring at the bottom is borrowing against its own future, and the bill arrives when the seniors leave and there is nobody two years behind them. Hire fewer if the numbers say so, but keep the pipeline open and make the training deliberate, as part of a [hiring engine that scales](https://pragmaticleader.io/art-science-hiring-building-talent-engines-scale/) rather than an annual decision.

## How it changes by stage

**Seed.** A handful of experienced engineers, heavy agent use and speed as the priority. That is the right trade at this stage. The real risk is that eighteen months on, nobody fully understands the codebase, which shows up first in due diligence and in the first senior hire's onboarding. Keep a short architecture note current, agree plans before large agent sessions, and make sure every major component has someone who could rebuild it.

**Series A to B.** The first junior and mid-level hires arrive, and the apprenticeship design above starts to matter. Write the review norms down, set a size limit on pull requests, and give reviewing explicit time in planning. Watch change failure rate and recovery time closely, because they show whether faster writing is costing you in production. They are also what the board should see, rather than the share of AI-written code, as the case for [reporting engineering without vanity metrics](https://pragmaticleader.io/engineering-metrics-for-the-board/) argues.

**Later stage.** A platform or developer-experience team can own the guardrails: agent configuration, sandboxing, required checks and data on review load. Career ladders and promotion criteria need a deliberate rewrite, because the evidence of seniority has changed. Expect this to take a full performance cycle, and involve the managers who will have to apply it.

## What good and bad look like

Good looks like engineers who use agents heavily and can still answer "why does it work this way?" about anything they've merged, juniors who are visibly getting better at debugging and design, and review treated as real work with time set aside for it. Delivery metrics hold steady or improve while the volume of code rises.

Bad looks like rising merge counts alongside rising incidents, seniors buried in review, juniors who have shipped a great deal and understood little of it, and postmortems that end at "the agent made a mistake".

For the next leadership meeting, put one question on the agenda: if our two most senior engineers left next month, who could explain the code the agents wrote this year, and what would we do differently starting now to make sure someone can?