Define the Role Before the Agent Takes It

If you lead an engineering organization, you have probably rolled out AI coding tools and are now being asked what they have returned. Much of what makes your teams work is not written down: conventions people learn on the job, and approvals that happen in conversation rather than in a system. An agent has no access to any of that. It will break those rules without knowing it, and reviewers end up with more pull requests to catch and fix.

This article argues that each role in the lifecycle should be defined for people before an agent takes on any part of it. It starts with the research on where AI gains get stuck, then sets out what a role definition should contain and applies it to six stages of the lifecycle. It closes with how to bring an agent into a defined role and where to write that role down so the agent can use it.

Why The Gains Stall

McKinsey's 2026 survey of 1,719 respondents across industries found that 80% say AI has improved their individual productivity. Only 37% say it has contributed to their organization's EBIT, about the same share as the year before. Developers who use AI agents report a similar pattern. In Stack Overflow's 2025 Developer Survey, 69% of agent users said agents had increased their productivity, while 17% said agents had improved collaboration within their team.

Figure 1 · Individual gains that do not become organizational gains

The two surveys cover different groups, so their figures should not be compared directly.

Both surveys show individual gains that are not reaching the team or the business. One likely reason is that code creates no value until it has been reviewed, tested, approved and deployed, and those steps are still organized around people writing all the code. In WWT's AI-Native Maturity Model this is Stage 2, AI-Assisted Engineers: the tools are deployed, but the benefit stays with individuals rather than reaching the team or the business. Most organizations are still at that stage. When writing gets cheaper, more of the effort shifts to checking. In a March 2026 analysis of open-ended survey responses from 1,110 Google engineers, DORA called this "the verification tax" and summed it up this way: "Time saved writing is often re-spent auditing."

There is evidence that this gap can close (see Figure 2). A 2026 field study shows how a company set out to double merged pull requests per engineer, and it did. Across 802 developers, output reached 2.09 times its earlier level, and merge and revert rates held steady. But every one of those pull requests still had to be reviewed. Each reviewer's workload roughly doubled, and the company leaned on automated review to keep up. The paper's title sums it up: AI Writes Faster Than Humans Can Review.

Figure 2 · What throughput costs review

Multiple of the pre-mandate baseline (baseline = 1.0)

As adoption grew, the company's code review was restructured around automation, changing who checked code and how much of the checking was done by machines. The gain and the change to the review role arrived together, and the change happened under pressure from the extra volume rather than by plan. The rest of this article is about making changes like that for each role on purpose, before volume forces them. 

The key takeaway here is that AI moves work from writing code to checking it. If no one plans for that shift, your reviewers absorb it.

Define The Roles First

A simple test shows how much of a role is undocumented.

If the answer is no, an agent will not do any better than that new hire. It will make the same mistakes, only more often, because it works faster. Research by Zhou and Mockus shows how long this knowledge takes to learn. The development managers they interviewed said new developers became productive within a few months, but trusting them with a critical customer issue took several years. The difference is knowledge of the customers, the wider system and the team, and most of it is learned on the job rather than written down.

Agents can now contribute at every stage of the lifecycle, from requirements to incident response. But an agent that can write a change and knows nothing about the on-call rotation, the compliance sign-off or the last three failed deploys is working blind. Every stage already has owners and standards. In most teams, they are understood, not written down.

A role definition should answer three questions. 

• First, what can the role decide on its own, what can it only propose, and what is off limits?
• Second, what counts as done, stated so that someone else can check it?
• Third, who is accountable when the work is wrong?

The table's middle column covers the first question, and its last column covers the other two. None of the answers depend on a particular model, IDE or vendor, so the definition stays valid when the tools change. The rows also line up with the four pillars WWT organizes AI-native engineering around - process, platform, people and governance, so a team that can fill in the table has already done most of the groundwork those pillars ask for.

Table 1. Define each role for a person before you place an agent in it. 

What each row looks like in practice::

Requirements and product analysis. An agent treats a ticket as a full specification. A senior engineer treats it as a starting point and asks what was meant.

Architecture. The risk is rarely an obviously bad choice. It's a reasonable-looking one, like a second cache or a library that duplicates one already in use, and a busy reviewer will wave it through.

Engineering. Unless told otherwise, an agent gives a naming preference the same weight as a rule that money is always stored in integer cents.

Quality assurance. This is where the verification tax shows up: an agent can hit a coverage target at high volume without making the software any safer. WWT makes the same argument in Who decides when your AI coding agent is done?: acceptance tests are what tell an agent it has finished. 

Code review. This is the row the field study is about. If output doubles before anyone decides what human reviewers own, the same reviewers absorb twice the work. Set the limits before that happens.

SRE and incident response. This stage is usually missing from AI plans, even though it's where mistakes surface. Skip it and the person on call inherits a failed change they had no part in.

Onboard In Stages

Once a role is defined, an agent can start the way a new hire does, with a probation period. At first, it drafts the change, the test and the ADR, and a person approves each one until its common mistakes are known. Its autonomy then grows according to risk. An agent can own small, well-contained changes long before it should touch billing or authentication, and each extension of its scope should rest on its record in lower-risk work. This is the same progression WWT uses to take clients from a single contained pilot to AI-native delivery as the default, with the level of human approval set by risk tier at each step rather than relaxed when volume demands it.

A person stays involved throughout, but the level of review should match the risk of the change. Requiring human sign-off on every change would bring back the review bottleneck that the code review row is meant to prevent.

Where to Write It Down: AGENTS.md

Many coding agents read a plain-text AGENTS.md file at the root of the repository before they start work. More in that file is not better. Researchers at ETH Zurich and LogicStar.ai tested this with four coding agents on 438 tasks and found that context files "do not generally improve task success rates, while increasing inference cost by over 20% on average."

Figure 3 · Context files, task success and cost

Change in task-resolution rate (percentage points) and inference cost (%), context file vs. none

Files written by developers did better than files generated by a model, but their gain over no file at all was small (2.4% on average) and not statistically reliable. Repository overviews didn't help. The authors conclude that these files are most useful for spelling out non-standard coding practices. That is the same information the role table asks for:

# AGENTS.md

## Non-negotiable conventions
- All money is integer cents, never floats.
- Public API changes require a version bump and a migration note.

## Definition of done
- A change ships with a test and a rollback plan.
- "Done" means merged and visible on the staging dashboard, not "PR opened."

## Escalation: who signs
- Auth, billing and data-deletion paths need a named human's approval. Never auto-merge.
- Anything touching PII: stop and open a compliance review.

Each section of the file maps to the table. The conventions come from the engineering row, and the definition of done and escalation rules come from the last column. New hires can read the same file, so people and agents work from one set of rules.

Conclusion

Start by writing down what each stage of your lifecycle already assumes: who is responsible, what done means, and who signs off. Most of it is known but unwritten, and writing it down is worth doing before any agent arrives, because every new hire needs the same answers. Once it exists, an agent can be given a role instead of a prompt.

That is where WWT's AI-Native Engineering practice begins with clients. The first question is never which tool to buy; it is which rows of the table you can already answer.