Team shape and ownership when agents do the typing

Most engineering organisations are organised around a shortage that no longer exists. Team size, sprint capacity, hiring plans and career ladders all assumed that producing code was the limiting factor.

When that stops being true, several things that used to be automatic have to be made explicit.

Ownership stops being implied

Authorship used to carry ownership without anyone arranging it. The person who wrote the module answered questions about it, got the alert, and decided on a change. It was informal, it worked, and it disappeared when the author became a session that no longer exists.

The replacement has to be written down: a named owner per service or domain, whose job is not to write the code but to know what it is supposed to do, what it must never do, and what it depends on. That person is accountable for the standard, the gates, and how the system runs.

Two mistakes to avoid. Do not assign ownership to a team without naming a person, because when an alert fires at three in the morning, a team with no named owner does nothing. And do not let ownership pass by default to whoever happened to accept the last change, which is the default in the absence of a decision and produces owners who never agreed to own anything.

Accountability at the company level is a separate matter and sits with the organisation releasing the software, not with the engineer on call. Ownership is about who knows and who decides; it is not a mechanism for locating blame.

What the roles become

Four kinds of work grow in value, and they are worth naming because they change what you hire for.

Specification. Turning a business need into criteria a machine can check. This is a real skill, closer to analysis than to coding, and it is the input the whole pipeline runs on. Teams that are bad at this generate large volumes of confidently wrong software.

Judgment on correctness and risk. Reading output and knowing what is wrong with it, quickly. This is experience, and it is why senior engineers are more valuable rather than less: DORA's 2025 study found 30 percent of nearly 5,000 respondents report little or no trust in AI-generated code [1], and Stack Overflow's 2025 survey found 45.7 percent distrust its accuracy against 32.7 percent who trust it [2]. Somebody has to be able to decide.

System design. The decisions that are expensive to reverse, covered in the decisions that stay with your engineers.

Operations. Running the thing, which gets harder rather than easier when the code was generated, as covered in observability and incident response.

Notice that none of these is typing, and all of them are what senior engineers were already doing between the typing.

Plan the review load like on-call

Review is now a capacity, not an activity people fit around their work. At high change volume it is the resource most in demand in the team, and if nobody plans it, it is done by whoever feels most responsible, which is a reliable way to lose that person.

Three practices help.

Make it a scheduled duty. Someone is on review this week the way someone is on call, with the expectation that other work is reduced accordingly. Pretending review is free is how it becomes the slowest step, as described in the review queue is the new bottleneck.

Shrink what humans review. The gates handle the routine checks, and people read the changes that touch money, credentials, personal data, public contracts and migrations. That policy is in the quality gates that should block a merge, and it is what makes the remaining review deep rather than done only for show.

Watch the queue as a delivery number. Time in review is part of change lead time, and a growing queue is an early signal that the team can now generate more code than it can judge.

Size the team to judgment, not to tickets

The old sizing question was how many people are needed to build this. The new one is how much judgment and operational load the work will create, because the amount of code AI can generate can grow almost without limit and human attention cannot.

That changes how you hire. Adding a fast producer to a team whose constraint is review makes throughput worse, not better. Adding a senior engineer who can take on review work, own a domain and improve the gates makes the whole pipeline faster. Our post on how to size a team when generation is cheap covers this in more detail.

It also changes what a small team can do. A senior-heavy team of four with good gates can now deliver what used to take twelve, which is the argument in a small senior team outbuilds a big one. The limit becomes how much they can be accountable for, not how much they can produce.

What to interview for now

If the valuable work has changed, the interview has to change with it, and most processes have not.

Asking a candidate to write an algorithm on a whiteboard now tests a skill that is genuinely less scarce than it was. The signals that predict performance in an AI-native team are different, and they are testable.

Give them generated code with a real defect in it and ask what is wrong. This tests the thing you are actually hiring for: the ability to read output critically and quickly, including the confidence to say that something plausible is wrong. Give them a vague requirement and ask them to turn it into acceptance criteria, then ask what they would refuse to build without an answer. Ask how they would verify a change they did not write, and listen for whether verification means running it or proving it.

Two things to watch for beyond the answers. Candidates who cannot say when they would not use an agent usually have not used one on anything hard. And candidates who describe reviewing generated code as reading it, rather than as running something against it, are describing a habit that does not scale past a few changes a day. Our post on how to interview an engineer in the age of AI has the format.

The junior engineer problem, stated honestly

The work juniors used to do, the well-specified small tasks that a senior could check quickly, is exactly what agents do best. That is a real problem and it deserves a direct answer rather than reassurance.

Two things are true at once. Juniors are not economically obsolete: a junior who is good at directing agents, reading output critically and asking the right questions produces real value quickly. But the path that turned juniors into seniors, which was writing a lot of code and getting it wrong under supervision, has been partly removed, and nothing has replaced it automatically.

So it has to be built deliberately. In practice that means giving juniors work where the judgment is the point rather than the typing: reviewing generated output with a senior, writing specifications and acceptance criteria, running an incident with support, and doing the debugging that requires understanding rather than pattern matching. It also means resisting the temptation to have them watch over large volumes of generated code, since watching an agent produce code you cannot evaluate teaches nothing.

There is a further effect worth naming. When juniors spend their time directing agents rather than writing code, they get good at directing agents faster than they get good at knowing whether the output is right. That order is the reverse of what the team needs, and it produces engineers who are productive and cannot yet tell when they are producing something wrong. The fix has to be deliberate: pair them on review, ask them to explain why a generated change is correct rather than whether it works, and give them the debugging that has no shortcut.

Teams that stop hiring juniors entirely are making a decision about their own supply of senior engineers in four years. That may still be the right decision for a small company, but it should be made on purpose rather than by accident. Our post on what changes when your junior engineers use agents covers the practice.

Where this connects

Team structure determines whether the rest of this model is affordable: who writes the definition of done, who owns the gates, and who answers when something breaks. The numbers that tell you whether the team structure is working are in measure delivery, not generated output. The adoption path for a team moving to this way of working is moving a team to AI-native development. The main guide sets out the whole model.