Who owns code that was generated by an assistant?

The developer who submits it: they must understand it, test it and answer for it in review and in production.

Why are PR counts and lines of code poor measures of AI impact?

They reward volume; teams can produce more and larger changes while quality and delivery outcomes get worse. Outcome metrics such as lead time and change failure rate show real impact.

How do teams keep assistants consistent with their conventions?

By checking a shared project instructions file (conventions, commands, structure) into the repository, which every developer's assistant reads.

Team Practices: Reviews, Ownership and Measuring Impact — Coding with AI Assistants

The problem

A team adopts AI assistants and reports that it "ships twice as many pull requests". Three months later, incidents are up, reviews are rubber-stamped because PRs are huge, and nobody can explain parts of the codebase. Measuring PR count made things look better while quality got worse.

Real-world analogy

A kitchen that buys a faster oven still needs a head chef who tastes every dish. Speed in one step is only useful if quality checks keep up.

The idea

The author owns the code, however it was written: they must understand it and answer for it in review.
Small pull requests stay the rule; assistants make large diffs easy, which makes review harder.
Shared project instructions (conventions, commands) checked into the repository so everyone's assistant follows the same rules.
Measure outcomes, not output: lead time, change failure rate, time to restore, defects found after release, alongside developer experience surveys. PR counts and lines of code reward volume.
Keep learning: use assistants to explain and to give feedback, and still write and debug code yourself regularly.

The code

Two teams compared on output metrics and on outcome metrics:

Output metrics versus outcome metricsTry it yourself

teams = {
    "team A (more PRs)": {"prs_per_week": 42, "avg_pr_lines": 900, "change_failure_rate": 0.24, "lead_time_days": 3.1},
    "team B":            {"prs_per_week": 25, "avg_pr_lines": 180, "change_failure_rate": 0.08, "lead_time_days": 1.4},
}
for name, m in teams.items():
    print(f"{name:18} PRs/week {m['prs_per_week']:3}  lines/PR {m['avg_pr_lines']:4}  "
          f"failed changes {m['change_failure_rate']:.0%}  lead time {m['lead_time_days']} days")
best_output = max(teams, key=lambda t: teams[t]["prs_per_week"])
best_outcome = min(teams, key=lambda t: teams[t]["change_failure_rate"] * teams[t]["lead_time_days"])
print("looks best by output:", best_output, "| best by outcomes:", best_outcome)

Output

team A (more PRs)  PRs/week  42  lines/PR  900  failed changes 24%  lead time 3.1 days
team B             PRs/week  25  lines/PR  180  failed changes 8%  lead time 1.4 days
looks best by output: team A (more PRs) | best by outcomes: team B

Common mistakes

Treating "generated by AI" as a reason to review less, or as an excuse in incidents.
Letting PR size grow because generating code is cheap.
Measuring adoption by lines of code or PR counts.
Skipping fundamentals entirely, so nobody can debug without the assistant.

Key points

Authors own and must understand every line they submit.
Keep PRs small, share project instructions, and keep reviews meaningful.
Measure delivery outcomes and quality, not volume.

Further reading: DORA: software delivery performance metrics · Claude Code best practices