AI Coding Team Norms: What Developers Owe Reviewers Now

Quiet tension, no rule to point to. The friction at PR review is organizational, not technical.

Updated July 2026: This refresh preserves the original route and publish date, but replaces weak source references, adds current governance evidence, and reframes the argument around PR handoff norms.

An engineer on r/ExperiencedDevs announced that she would no longer review AI-generated PRs. Not quietly decline them. Announce it at a company meeting. Another developer, in the same community, described a different irritation: a coworker using AI to reply to human PR review comments. [9] [10]

Those threads are not representative research. They are practitioner language, and the language is useful because it names the real conflict. The argument is not really about whether AI-generated code is good enough. It is about effort, ownership, and what one developer owes another before asking for review.

Short answer: Teams should keep the same code-quality bar, but rewrite the PR handoff norm. The person requesting review owns the generated change. They should disclose AI use when it changes reviewer context, record what they validated, explain intent and risk, and give reviewers the right to reject a handoff that turns review into first authorship.

That is the missing agreement. Good engineers used to carry it tacitly because authorship and understanding usually arrived together. AI unbundles them. A polished diff can reach review before the submitter has done the work of owning it.

If you are watching your team navigate what professional norms survive when AI enters the discipline, this is the upstream version of the problem: the rule was never written because, until recently, the team could assume the author understood the code they submitted.

The Conflict Is Reviewer Burden, Not Whether AI Is Allowed

The lazy version of this debate is "ban AI code" versus "review it like any other code." Neither position is specific enough to help a team at 4:30 p.m. when a reviewer opens a large PR and cannot tell what the author actually inspected.

Reviewing AI-assisted work is still reviewing code. The bar for correctness, maintainability, security, and fit does not drop because a model drafted part of the diff. But the handoff has changed. When a developer submits human-written work, reviewers usually assume the author can explain the approach, name the risky files, describe trade-offs, and respond to comments with their own judgment.

AI makes that assumption less reliable.

That is why the Reddit threads in the research are useful as community signals. The refusal thread centers reviewer burden and ownership. The AI-review-reply thread centers reciprocal effort and trust. In both cases, the reviewer feels asked to spend human attention on work whose author may not have spent equivalent attention first. [9] [10]

GitHub's guide to reviewing agent pull requests frames the same operational pressure in less emotional language: agent PRs create reviewer-bandwidth problems, and authors should review and annotate agent-generated PRs before requesting review. [7] That advice is practical, but it is also cultural. It says the handoff is part of the work, not clerical packaging after the work.

The norm I would write first is blunt: if you submit it, you own it.

Ownership does not mean pretending the model had no role. It means the submitter is accountable for the accepted output. "The AI wrote it" can explain where a line came from. It cannot explain why the line belongs in the codebase.

AI Makes Confidence And Understanding Diverge

AI-generated code often arrives with the surface features reviewers associate with competence: tidy names, complete comments, a confident PR summary, and tests that at least appear relevant. That surface can be useful. It can also make the handoff feel more complete than it is.

METR's 2025 randomized controlled trial is a good cautionary example when framed carefully. The study tracked 16 experienced open-source developers across 246 tasks. Developers predicted AI would make them 24 percent faster before starting; after the study, they estimated a 20 percent speedup. The measured result was the opposite: completion time increased by 19 percent with the early-2025 AI tools being tested. [1] [2]

That result should not be repeated as "AI slows experienced developers now." The METR page itself warns that newer early-2026 data supersedes the early-2025 result as a current productivity measure. [1] The durable lesson is narrower and more useful: developers can be confident about AI's help while the measured outcome tells a different story.

Reviewers live inside that gap. They see a diff that looks complete, but the author's explanation may not match the confidence of the output. The reviewer asks why a boundary changed, why a reuse point was missed, or why a test covers the happy path but not the risky branch. The author reaches back into a transcript, not into memory of design work they personally performed.

Simon Willison has written about the distinction between responsible agentic engineering and "vibe coding" getting blurrier in his own practice as coding agents improve. [3] That is the point. This is not a sloppy-user problem. Even careful practitioners adjust their review depth as tools become more capable. Team norms need to catch up before that private adjustment becomes a public review conflict.

Governance Has Already Moved From Future Risk To Current Work

The old version of this article leaned on an analogy: when work patterns change, tacit norms become explicit. That still feels true, but the stronger evidence now is current and specific to AI code.

GitLab's 2026 AI accountability research, conducted by Harris Poll with 1,528 developers and technology buyers, reports that 80 percent of organizations adopted AI tools faster than governance policy, 92 percent report governance challenges, 85 percent say bottlenecks shifted to review and validation, and 43 percent cannot reliably distinguish AI-generated code from human-written code. [5]

Treat those as survey claims from one vendor-published report, not laws of nature. Even with that caveat, the pattern matches what reviewers feel locally: generation moved faster than the system around it.

DORA's 2025 AI-assisted software development report makes a related point at the organizational level. AI tends to amplify the system it enters. Strong organizations can get more out of it; weak process, weak trust, and weak feedback loops do not disappear because a model writes code faster. [6]

That matters for PR review because review is where weak process becomes visible. A team can tolerate fuzzy norms when work is slow enough for humans to repair context by conversation. AI changes the ratio. More code, more summaries, more proposed tests, more reviewer questions. If the handoff norm stays implicit, the bottleneck moves to the person trying to reconstruct intent.

There is also a concrete codebase risk. The "More Code, Less Reuse" arXiv abstract reports that LLM agents may miss code reuse opportunities and increase redundancy. [8] That is exactly the kind of issue reviewers need context to catch. A generated implementation can pass tests and still duplicate an existing pattern, bypass a local abstraction, or add another near-copy of a service that already exists.

The answer is not a larger policy binder. Stack Overflow's 2026 guidance argues that coding guidelines for AI agents and people need to be explicit and pattern-grounded because agents do not share tacit human knowledge. [4] That is the useful standard for team norms too: concrete enough that a developer knows what to put in the PR description and a reviewer knows when to send the PR back.

Five AI Coding Team Norms To Write Before The Next PR

The point is not to moralize AI disclosure. The point is to make effort visible before review begins. [12]

### If You Submit It, You Own It

The author of record is the person requesting review. They own the generated code, the prompts they used, the model output they accepted, and the decision to put the result in front of teammates.

This does not require a theatrical confession in every PR. It requires accountability. If a reviewer asks why the change touches a security-sensitive file, the answer cannot be "the assistant did that." If a generated migration has an edge case, the author owns the gap.

This norm also protects responsible AI users. When ownership is explicit, a developer can use a model aggressively while still making the handoff trustworthy. The team is not banning assistance. It is refusing anonymous authorship.

Disclose AI Use As Reviewer Context

AI disclosure should tell reviewers where to spend attention. It is not a moral label.

A useful disclosure sounds like: "The assistant drafted the parser refactor and the new tests. I manually reviewed the existing parser call sites, rewrote the error handling, and verified the migration against the sample fixtures." That gives the reviewer a map. It names what came from the tool, what the author inspected, and where judgment was applied.

A weak disclosure says: "AI assisted." That may be honest, but it does not reduce reviewer uncertainty.

The disclosure norm should be conditional on reviewer context. If autocomplete helped write a small guard clause, nobody needs ceremony. If an agent drafted a multi-file change, generated tests, or responded to review feedback, the reviewer deserves a handoff note.

Record What You Validated Before Review

Tests are not the whole validation story. They are evidence, and the reviewer needs to know what evidence exists.

Before requesting review on an AI-assisted change, the author should record the checks they ran, the risky areas they inspected, and the known non-goals. This is where GitHub's recommendation to review and annotate agent PRs before requesting review becomes a team norm. [7]

For example:

• Generated area: API adapter and retry tests.
• Human validation: compared retry behavior against existing billing adapter.
• Commands run: unit tests for adapter package and typecheck.
• Risk left for reviewer: whether retry timing matches production SLO expectations.

That is a different PR than one that arrives with a model-written summary and no validation trail.

Give Reviewers A Right To Reject Unclear Handoffs

Teams need to say this out loud: a reviewer can reject an AI-generated PR before deep review if ownership, intent, validation, or risky files are unclear.

This is not hostility toward AI. It is queue protection. Deep review is expensive. If the author has not done the handoff work, the reviewer should not become the first person to understand the change.

The rejection should be specific and boring:

• "Please identify which parts were generated and which parts you manually inspected."
• "Please explain why this duplicates the existing helper instead of extending it."
• "Please add validation notes before I review the implementation."
• "Please answer the review comment yourself. AI can help you draft, but I need your judgment."

The tone matters less than the shared backing. A reviewer should not have to make this feel like personal preference. The team norm should carry it.

Do Not Outsource Reciprocal Review Discussion

Using AI to draft a response to a review comment is not automatically disrespectful. Sending a generic model answer instead of engaging with the reviewer's actual concern is.

The difference is easy to test. Can the author defend the response in their own words? Did they address the concern the reviewer raised, or did they produce a plausible paragraph that moves the conversation sideways? Did the response reduce the reviewer's uncertainty, or create more work?

The second Reddit thread in the research is useful because it names the social side of this failure. A reviewer gave careful attention and felt the author returned a machine-shaped reply. [10] That is not a tooling problem by itself. It is a reciprocal-effort problem.

Keep The Handoff State Outside The Agent Chat

Written norms help only if the work state survives long enough for people to use them.

A PR thread can hold some of that state, but it is late in the workflow and tightly tied to one branch. An agent chat can hold rich context, but it is fragile across sessions, tools, and people. If the author changes assistants, hands the task to a teammate, or comes back three days later, the transcript is a poor source of truth.

This is where the cultural norm touches the architecture. The durable state for AI-assisted work should include the task owner, scope, acceptance criteria, validation notes, artifacts, status, comments, and review handoff notes. That state should be readable by humans and by the assistant working on the task.

Agiflow's first-party position is specific: it is a commercial project board for teams using external AI assistants. The assistant remains the agent. Agiflow supplies scoped project-board tools, shared state, artifacts, vault entries, workflow locks, tasks, comments, and statuses. [11] In this context, the value is not that a board replaces GitHub, CI, or code review. It is that the handoff state can live somewhere more durable than a model transcript.

A practical task record for an AI-generated PR might include:

• Owner: the developer requesting review.
• Scope: refactor the billing adapter retry path only.
• Acceptance criteria: existing invoice creation tests pass, retry behavior matches adapter contract, no public API change.
• AI use: assistant drafted the first implementation and test scaffold.
• Validation: author compared against existing adapter, ran targeted unit tests and typecheck.
• Handoff note: reviewer should focus on retry timing and reuse of the shared backoff helper.

That is the same shared-state problem covered in AI coding team shared state and the same context-loss problem behind why AI coding agents lose the plan. The technical control surface matters too, especially when teams decide where the human steering point should live. That companion frame is covered in AI coding tool control surfaces.

The norm becomes enforceable when the state exists. Without it, every review starts by asking the same missing-context questions.

The Team Conversation Is The Work

AI coding team norms do not need to be grand. They need to be explicit enough that people can point to them under pressure.

The best first version is short:

• If you submit it, you own it.
• Disclose AI use when it changes reviewer context.
• Record validation before requesting review.
• Reviewers can reject unclear handoffs.
• AI can assist review discussion, but the author owes human judgment.

Those norms will not settle every argument. They will make the argument reviewable. That is the improvement.

The team that writes this down is not being precious about AI. It is protecting the scarce part of software work: human judgment applied at the right moment, with enough context to matter.

Send this to your team before the next AI-generated PR review.

---