From AI-generated code to a reviewable change
Make an AI-generated change reviewable by agreeing its scope before editing and requiring evidence against that scope before asking for approval. The reviewer should be able to see what changed, why it changed, and which checks support it.
This checklist describes how we approach a shared team workflow. It is not a promise that an agent or a passing test can replace human judgement.
What should the task brief contain?
Start with the outcome the user or system needs. Include one concrete example of the current behaviour and the intended behaviour. State what is outside the task, especially when nearby code could invite a larger rewrite.
Name the files or areas to inspect if you know them. If you do not, ask for an investigation before an implementation. The agent should identify the relevant code and explain its plan before changing it.
Agree acceptance checks with the people who own the requirements. Product, design, engineering, and QA may each hold part of the answer. A technically correct implementation of an incomplete brief still creates rework.
What context belongs beside the task?
Give the agent the existing conventions, relevant decisions, and approved tools it needs. Keep reusable instructions in the repository where your team can review and maintain them. Link to the source of a rule rather than copying long, inconsistent versions into every prompt.
Use your existing access and data policies. Clarify which actions need a person to approve them. A workshop can help turn those policies into practical steps; it does not replace your security or compliance decisions.
What evidence should a reviewer receive?
| Question | Evidence to include | Who decides? |
|---|---|---|
| Does it solve the agreed task? | Behaviour checked against acceptance criteria | The task owner and reviewer |
| Does it fit the codebase? | Relevant conventions and an explanation of the approach | The engineering reviewer |
| What was tested? | Checks run, their results, and known gaps | The reviewer responsible for acceptance |
| What remains uncertain? | Unchecked assumptions and a proposed next check | The person who owns that risk |
Ask for this evidence before handoff. "Tests pass" is incomplete when the tests do not cover the requirement. A command that was suggested but never run is not a test result.
How do you keep the change small?
Split work at a boundary that a reviewer can understand. Complete one behaviour or a safe preparatory step, then inspect the result before continuing. Avoid combining unrelated cleanup with the requested change.
There is no universal line-count limit. The useful question is whether the reviewer can assess the purpose, behaviour, and risks with the time and context available. If the answer is no, reduce the scope or plan a different review.
What can a team try in its next sprint?
- Pick one real task with an available owner and reviewer.
- Agree the brief and acceptance checks before the agent edits.
- Ask for one bounded change with the evidence listed above.
- Record review effort and corrections, then adjust the team instruction.
Use our measurement guide to check whether the workflow improves delivery. Avoid declaring success from the first impressive demonstration.
Where does training fit?
If people use different planning and review methods, practise the same task together. Compare the briefs, inspect the changes, and discuss why the evidence is sufficient or incomplete. This makes the team's standards explicit.
Our AI training for teams adapts those exercises to your roles and codebase. You can also start with the free Delegate, Review, Own guide.