Diff awareness - reviewer knows it's AI code

Diff awareness is the practice of making AI code provenance visible to reviewers at review time - so a reviewer looking at a pull request knows which parts were AI-generated versus hand-crafted. At L2 (Guided), this is implemented through lightweight conventions: a PR label (ai-assisted), a note in the PR description ("The database query in UserRepository.kt was generated by Claude and reviewed by me"), or a commit message convention that distinguishes AI-generated changes.

This awareness is a stepping stone from the L1 state (no distinction between AI and human code) to the L3 state (systematic tracking and policy enforcement). At L2, the mechanism is social and manual - the developer discloses, the reviewer uses the information - rather than automated or enforced. But even manual disclosure provides immediate value: it changes how reviewers allocate their attention.

Knowing a function was AI-generated tells a reviewer something important: the code is likely syntactically correct and stylistically consistent, but may be semantically wrong for the specific business context. AI code tends to be good at the "how" and inconsistent at the "what" - it produces well-structured code that does the wrong thing, or that's missing the crucial edge case that exists only in your specific system's behavior. This is the exact opposite of the typical human-generated code failure mode (correct in intent, inconsistent in execution), and it calls for a different review focus.

Diff awareness doesn't mean AI code gets more review - it means it gets differently focused review. The reviewer can skim the syntax (the AI handled that) and focus on whether the logic matches the business requirement.

Review calibration based on provenance makes review more efficient and more effective simultaneously:

• More efficient - Reviewers don't need to read AI-generated boilerplate as carefully as human-written logic. Knowing a function is AI-generated allows skimming the implementation and focusing on the interface and contract.
• More effective - AI-generated code has characteristic failure modes: plausible-looking but wrong business logic, missing error cases that aren't present in training data analogues, over-engineering for generic cases. Knowing code is AI-generated prompts reviewers to test it against these failure modes specifically.
• Cultural normalization - When developers disclose AI use, it becomes normal. This is healthier than the alternative (silent AI use), where reviewers are reviewing AI code without knowing it and applying inappropriate review heuristics.
• Data foundation - PR-level disclosure (even informal) is the seed of the provenance data you'll need for L3 systematic measurement. You can't analyze AI code quality patterns if you don't know which code is AI-generated.
• Author self-review trigger - The act of writing "this was AI-generated" in a PR description prompts the author to consciously review the AI code before submitting. This alone catches a meaningful number of issues.

The key insight is that AI code is not uniformly higher or lower quality than human code - it's differently distributed in its failure modes. Review practices that calibrate to those specific failure modes get more value from the same review effort.

Diff awareness also sets up a human-skill discipline that gained traction in June 2026: "When I reject AI code even if it works" argues engineers should reject code they cannot personally understand, even when CI is green. Knowing a block is AI-generated is the trigger for that judgement call: a passing test suite tells you the code works today, not that anyone on the team can safely change it tomorrow. Make "I can explain what this does and why" a reviewer's bar for AI-generated logic, not just "the checks are green."

1. Define what "AI-generated" means for your team - Is it: any code from an autocomplete suggestion? Only code where the developer asked for a full function body? Code where more than X% of tokens were AI-generated? A practical definition for L2: AI-generated code is code where the developer accepted an AI suggestion for a complete logical unit (function, class method, significant block) with minimal modification.
2. Create a PR label - Add an ai-assisted label to your GitHub or GitLab project. Document the convention in your team wiki: "Apply this label if AI generated a significant portion of the code changes in this PR."
3. Add AI disclosure to your PR template - Add an optional field to your PR template: "AI contribution (if any): [describe what was AI-generated]." Making it optional (not a required checkbox) reduces friction while establishing the norm.
4. Brief reviewers on review calibration - In a team session, discuss: "When you see an AI-assisted label, what does that change about your review?" Develop shared heuristics: focus on business logic correctness, check edge cases manually, verify that the AI understood the requirement rather than a similar-but-different one.
5. Lead by example with your own PRs - Staff engineers and tech leads disclosing AI use in their PRs normalizes the practice for the whole team. If senior engineers are transparent about using AI, junior developers will be too.
6. Track the disclosed PR rate over time - What percentage of merged PRs have the ai-assisted label? This gives you a coarse measure of AI adoption that grows more precise as the convention becomes habitual.

Making disclosure feel like confession. If AI disclosure carries a stigma ("I didn't write this myself"), developers will omit it. The framing must be: AI disclosure is professional practice, like noting that a component came from a library. It signals transparency, not inadequacy.

Requiring disclosure for every autocomplete suggestion. If the convention is "disclose any AI use," you'll get either zero disclosure (too onerous) or meaningless disclosure (everything labeled, which tells reviewers nothing). A useful threshold: disclose when AI generated a complete logical unit that the developer accepted with minimal modification.

Reviewers ignoring the disclosure. If reviewers acknowledge the label but don't change their review behavior, the disclosure provides no value. Calibration needs to be explicit: "AI-generated code gets extra scrutiny on business logic, less on syntax." Make this a documented team practice.

Assuming all AI code needs more review. In some cases, AI-generated boilerplate (test scaffolding, serialization code, standard CRUD operations) requires less review than hand-written code because there's less room for idiosyncratic errors. The calibration goes both directions: skim AI boilerplate more aggressively, scrutinize AI business logic more carefully.