Output doubled, Done did not move

Start from the honest signals. Story points flat is noise - points measure size, not value. The number of items reaching 'Done' is the real signal, and it has not moved despite a 50% rise in merged pull requests. Work is being produced faster than it can be integrated, verified and made useful. That is a flow problem, and the tool merely made it visible faster.

Diagnosis, in order of causal weight:

1. Work in progress has exploded. Eleven open pull requests is inventory, not progress. Large PRs plus a fast author equals long review cycles, and long review cycles raise the chance of conflicting merges and stale branches.
2. Review is the constraint, and it is being pushed harder. 'Review faster' at a constraint increases queue length and reduces review quality - which shows up later as escaped defects. A constraint is relieved by reducing what arrives at it or by adding capacity, not by exhortation.
3. The Definition of Done is not covering AI-assisted work. Duplicated helper code passed 'code reviewed and tests pass' because nothing asked whether the functionality already existed, or where the snippet came from. The DoD is the team's quality contract; leaving it unchanged while the production method changed is the root cause of the incidents, not the assistant.
4. Duplication is a context symptom. A model that cannot see the internal library will reinvent it. The fix is giving it context and giving reviewers a check, not banning generation.

What not to conclude: that the tool is bad, or that the enthusiast is the problem. The system let the change in without updating its own guardrails.

DoD additions (each one must be checkable, not aspirational):

• Provenance stated. The author notes which parts of the change were AI-generated and what they personally verified. Accountability sits with the author, never with the tool.
• Batch size limit. No pull request over an agreed size (for example, roughly 400 changed lines excluding generated or vendored files); larger changes are split. This directly attacks the eleven-item queue.
• Duplicate check. Before merge, the author confirms the change does not duplicate existing internal library functionality, and records what they checked. This is the direct counter to the two incidents.
• Tests that would fail without the change. Existing tests passing is not evidence; a new behaviour needs a test that fails before and passes after.
• No secrets, no real customer data in prompts. Stated explicitly, because 'we did not think about it' is the usual failure mode.
• Licence and provenance check for generated snippets in any code the organisation distributes - required, not optional, and owned by whoever reviews.
• Human review of intent, not syntax. Reviewers are asked to review design and correctness; the author is responsible for the code being readable and minimal.

Working agreement additions:

• The team agrees that the measure of success is items reaching 'Done' and cycle time, not lines or PRs merged.
• Any change to how work is produced triggers a review of the DoD at the next retrospective - a standing item, not a one-off.
• Disagreement about a review is resolved by the working agreement, not by one person opting out of reviewing.

Reasoning to share: none of this is anti-AI. Every item is a guardrail that lets the team keep the speed while restoring the property the DoD existed to protect - that 'Done' means usable.

Treat it as one system problem with three people in it, and address the safety issue first.

With the enthusiast, privately:

• Lead with the genuine result - merged PRs up 50% is real, and he should hear that it is noticed.
• Then reframe the bottleneck claim with data he cannot dismiss: the queue is eleven items and three days deep, so the fastest thing he can do for throughput is make each item smaller. 'Review faster' is asking the constraint to absorb more; 'open smaller' relieves it.
• Make the provenance and duplicate checks feel like craft, not bureaucracy: 'you are the person who knows what the model produced - stating what you verified is what makes your work reviewable at speed.'

With the two reviewers, separately:

• Find out what specifically they are avoiding. Reviewing a very large AI-generated change is genuinely harder - the reviewer has to reconstruct intent that was never written down. That is a legitimate complaint, not resistance to change.
• Protect them from being framed as blockers. Their withdrawal is a signal about the working agreement; if it stays silent, it becomes a personality conflict.

With the team, in the retrospective:

• Put the numbers on the wall: PR size, queue depth, cycle time, escaped defects. Let the team conclude that batch size is the lever.
• Have the team, not you, own the DoD changes and the review expectations. A rule the team wrote is enforceable; a rule the Scrum Master imposed is negotiable.
• Keep one explicit experiment budget so experimentation stays legitimate: the team agrees what it is trying next and what would make it stop.

What to watch: if the enthusiast continues to bypass an agreed working agreement, that is no longer a tool question - it is a team accountability question the team must address, with your coaching, in the open.