Guides for engineering managers
Performance reviews when your engineers use AI agents
What counts as impact when agents write the code, and how to write reviews that reward judgement and ownership instead of volume.
- When AI agents write much of the code, output volume stops telling you anything about an engineer. Pull requests, lines and tickets are cheap now.
- Review what still takes skill: outcomes, judgement, problem framing, review quality, and ownership of what the AI produced.
- Do not reward raw output or AI usage, and do not penalise people for using the tools well.
- Update your written expectations so engineers know what "good" means now, and write every review with specific examples.
Performance reviews were already hard to get right for engineers. AI coding agents make one part of them much harder. If an engineer can open fifteen pull requests in a day with an agent's help, the usual memory-joggers (commits, tickets closed, lines changed) were weak signals before and are close to meaningless now.
That does not mean you can't review engineers fairly. It means you have to be clearer about what you were really evaluating all along: the decisions, the results, and the responsibility someone took for them.
What counts as impact now
When generating code is cheap, the scarce parts of the job are deciding what to build, checking it is right, and standing behind it. Those are the things to look for.
Outcomes
What changed for users, the team or the business because of their work? A feature customers adopted, a recurring incident that went away, a migration that finished. This was always the most important part of a review. With AI in the loop, it is the part that has not been inflated.
Problem framing
Agents are good at solving the problem they are given. Someone still has to decide which problem that is, break it into pieces, and write a spec clear enough that the result is right. Engineers who frame problems well get much more out of AI tools, and their teammates do too.
Judgement
Knowing when to use an agent and when not to. Knowing when generated code is subtly wrong, when a simpler approach exists, and when to stop and ask. Judgement shows up in the decisions behind the work: the design that was rejected, the scope that was cut, the risk that was flagged early.
Review quality
More generated code means more code to review, and review is now one of the main places quality is won or lost. Look at the reviews someone gives: do they catch real problems, question the approach, and teach? Look at what happens to their own pull requests in review: are they easy to review, or does the reviewer find the problems the author should have found?
Ownership of AI output
The author owns every line, however it was produced. Strong engineers can explain their AI-assisted changes, test them properly, and respond when something breaks in production. Weak ownership looks like large unexplained changes, "the agent did it" in an incident review, and bugs that a careful read would have caught.
What not to reward
- Raw output volume. Pull requests, commits, lines and tickets now say more about tool use than about contribution. Use them to jog your memory, never as evidence of impact.
- AI usage itself. Token spend, agent sessions and "percentage of code written by AI" are inputs, not results. Rewarding them invites people to inflate usage instead of delivering results.
- Speed without consequences counted. Shipping fast and leaving the team to clean up is not high performance. Count the follow-up incidents and rework too.
- Avoiding the tools on principle. The reverse mistake. An engineer who refuses to use tools the team has agreed on, and is slower for it, has a real gap. Discuss it like any other skill.
If your company tracks team-level delivery metrics, keep them there. DX notes that research shows developers don't like metrics aimed at measuring individual engineers. That advice matters more, not less, when activity numbers are this easy to inflate.
Update your expectations language
If your career ladder was written before AI agents were part of daily work, engineers are guessing what you now expect. Add a few lines per level. You do not need a new ladder; you need to make the existing one explicit about AI-assisted work.
Expectations language you can adapt
- All levels: "Owns every change they ship, including AI-generated code. Can explain how it works, how it was tested, and what could go wrong. Keeps pull requests reviewable."
- Mid-level: "Uses AI tools effectively on well-defined tasks and knows when not to. Catches errors in generated code before review. Gives reviews that find real problems."
- Senior: "Frames problems and writes specs that lead to correct results from people and tools alike. Makes sound calls on where AI-assisted work is safe and where it needs extra care. Raises the review standard for the team."
- Staff and above: "Shapes how the team works with AI tools: norms, review practices, where agents are and are not used. Judged on the team's outcomes and reliability, not their own output."
Weak and strong review examples
The same principles as any good review apply: specific examples, outcomes over activity, behaviour over personality. Here is how that looks when AI tools are part of the work. All names and details are illustrative.
Impact
Dana was our most productive engineer this half, with over 400 merged pull requests, and she made great use of AI tools.
Dana took the reporting backlog that had sat for two quarters and cleared it in six weeks. She wrote a short spec for each report, had an agent produce the first version, and checked every one against real customer data before release. Support tickets about reports dropped sharply afterwards, and none of the new reports needed a fix after launch.
Ownership of AI output
Marco moves fast, but sometimes there are bugs in his code.
Two of Marco's large agent-generated changes this half caused incidents: the billing export in May and the cache change in July. In both cases the problem would have shown up in a careful read of the diff, and in July he was not able to explain the change during the incident. For next half, we agreed he will split changes over a few hundred lines and write a short note on what he checked before asking for review.
Review quality
Lena does a lot of code reviews and is very thorough.
Lena has become the reviewer people ask for on risky changes. In the permissions work she caught that a generated query skipped the tenant filter, which would have exposed data between customers. Her reviews explain why, not just what, and two newer engineers named them in peer feedback as how they learned to review agent-written code.
Problem framing and judgement
Omar is a strong technical thinker.
When sales asked for a "flexible export API", Omar spent two days with three customers before writing anything, and came back with a much smaller spec covering the two formats they actually used. It shipped in a week. He also decided against using an agent for the data migration behind it, wrote it by hand with a rollback plan, and it ran without issues.
Gathering evidence that holds up
Volume metrics are now noisy, so you need better raw material. Through the half, keep a dated line per person when you see one of the signals above: a good spec, a sharp review, an incident handled well, a change that caused rework. Read the pull request descriptions and review threads, not just the counts. Ask peers specifically about review quality and who they trust on risky changes. Keel does this record-keeping from GitHub, Jira and Slack, but a simple note per person works too.
For the full review structure, see how to write an engineering performance review. If your team is in the middle of an AI rollout, our 30-day plan for becoming AI-native covers the team norms these reviews depend on.