Engineering Manager AI Code Review Policy: What Requires Human Sign-Off
How engineering managers and VP Engineering can design a code review policy that categorizes AI-generated changes by risk and assigns the appropriate level of human...
AI coding tools: code completion, AI-suggested refactors, automated test generation: are now standard in many engineering teams. Most teams have informal practices around reviewing AI-generated code. Few have a written policy. The result is inconsistent review depth, unreviewed changes in security-sensitive paths, and no clear accountability when an AI-generated change introduces a bug in production.
This article provides a code review policy template for engineering managers who need to decide which AI-generated changes require what level of human review.
Why informal practice is insufficient
When review practice is informal, each engineer decides how much to review AI-generated code based on personal judgment. This creates three problems:
- Inconsistent depth. Senior engineers may apply rigorous review while junior engineers accept AI suggestions without reading them.
- Security path gaps. AI coding tools are good at generating code that looks correct but can introduce subtle security issues in authentication, cryptography, session management, and input validation paths.
- No accountability trail. When an AI-generated change causes a production incident, it is unclear who reviewed it, what they checked, and what standard they applied.
A written policy answers all three: it sets the standard, applies it uniformly, and creates an accountability trail.
Three-tier policy model
The policy categorizes changes by risk, not by whether they were AI-generated. The question "did AI generate this?" is secondary to "what does this change affect and what happens if it is wrong?"
Tier 1: AI-only changes (no mandatory human review before merge)
Changes that the team has agreed are low-risk enough to merge without a human reviewer:
- Test additions or modifications (unit tests, integration test fixtures) where the test suite gate catches regressions.
- Comment and documentation updates within the codebase.
- Generated boilerplate files (ORMs, type stubs, OpenAPI specs) where the generator is pinned and the output is deterministic.
- Localization file updates where the string change is straightforward.
Gate: The CI quality gate must pass. Tier 1 does not mean no gate: it means the gate is automated, not human. If the CI gate fails, the change is not merged regardless of tier.
Risk: Tier 1 is only appropriate if the CI gate is comprehensive and the team has confidence that test-only or doc-only changes cannot introduce security issues in the current codebase structure.
Tier 2: Human spot-check required (one reviewer, targeted review)
Changes that require a human reviewer, but where the review is focused on the specific change area rather than a full review:
- Refactors that do not change external behavior but restructure internals.
- Performance optimizations, caching changes, or query rewrites.
- Configuration updates (feature flags, rate limit values, timeout values).
- Dependency upgrades where the change surface is bounded.
- New feature code in non-sensitive areas (UI components, non-auth API endpoints).
Gate: One designated reviewer reads the change and explicitly approves. The reviewer's focus is on the change area, not the full codebase context.
Reviewer note: For refactors and dependency updates, the reviewer should verify that existing tests cover the changed path. An AI-generated refactor with no test coverage for the refactored path is a Tier 2 change with a coverage gap.
Tier 3: Full review required (at least two reviewers, security-qualified reviewer required for listed paths)
Changes that require thorough review before merge, including at minimum one reviewer with security or domain qualification:
- Authentication and authorization code (session management, token validation, permission checks, OAuth flows).
- Payment processing, financial transaction logic, or billing code.
- Database migrations and schema changes.
- Cryptographic operations (key generation, signing, verification, encryption).
- PII handling, data export, or data deletion logic.
- Infrastructure-as-code for production environments.
- Any change to the CI/CD pipeline itself.
Gate: At least two human reviewers approve. At least one reviewer must be a named security-qualified reviewer or domain specialist. The reviewer must attest that they have read and understood the change, not merely approved it. Approval without review is not a valid gate.
Specific to AI-generated changes in Tier 3 paths: Ask explicitly: does this AI-generated code introduce any input that is not validated, any permission that is not checked, any secret that is not managed through the secrets store, or any external call that is not rate-limited?
Worked example: three-tier policy in practice
Team: 20-person backend engineering team. AI coding tools in use: GitHub Copilot, in-IDE suggestions, AI-assisted test generation.
Policy excerpts:
| Change type | Tier | Reviewer requirement | AI-specific check |
|---|---|---|---|
| New unit test | 1 | CI gate only | Test must be for a real case, not a tautology |
| Docstring update | 1 | CI gate only | No code path affected |
| API response schema refactor | 2 | One reviewer | Verify existing contract tests cover changed schema |
| Dependency upgrade (non-auth) | 2 | One reviewer | Verify dependency verification per guide |
| Session token validation change | 3 | Two reviewers, security lead | Input validation, no hardcoded secrets, permission check present |
| Payment webhook handler | 3 | Two reviewers, payments domain specialist | Idempotency, logging of sensitive fields excluded, error handling |
| Database migration | 3 | Two reviewers, DB owner | Rollback procedure documented, tested in staging |
| CI pipeline change | 3 | Two reviewers, DevOps lead | No new secret exposure, build isolation maintained |
AI-specific checklist for Tier 3 (appended to PR template for Tier 3 paths):
- Is every external input validated before use?
- Is every permission check present and tested?
- Are secrets retrieved from the secrets store, not hardcoded or logged?
- Are external calls rate-limited and have timeout handling?
- Is error handling explicit (not swallowed or silently ignored)?
- Does the change affect any data the team has agreed not to log or store?
Diagram
See the accompanying diagram (engineering-manager-ai-code-review-policy-desktop.svg) showing the change classification matrix with AI output type to required human review level and reviewer role.
Implementing the policy
Start with the Tier 3 list. The most important part of the policy is the list of paths that require full review. Write this first, and get agreement from the team on what belongs on the list.
Add the policy to the PR template. The PR template should ask: which tier does this change fall into? If Tier 3, which paths are affected? This makes tier classification visible and auditable.
Review the tier-3 list quarterly. New paths will be added as the codebase grows. Security-sensitive paths that the team did not anticipate belong on the list as soon as they are identified.
Track override rate. If Tier 2 or Tier 3 changes are regularly merged with insufficient review (e.g., reviewers approving without commenting), that is a signal that the review standard is not being followed. Track it.
Failure modes
Tier inflation: classifying Tier 3 changes as Tier 2 for convenience. This happens when team velocity pressure outweighs review discipline. If Tier 3 changes consistently ship with one reviewer instead of two, the policy is not working.
Reviewer approval without reading. An approval stamp from a reviewer who did not read the change provides no protection. The PR template checklist forces reviewers to attest to specific checks, not just click approve.
AI-generated Tier 3 code that looks correct. AI tools produce code that is syntactically valid and passes tests. Security issues in AI-generated code often appear in edge cases: missing null checks, permission checks that apply to the happy path but not to error paths, or hardcoded values that should be configurable. The Tier 3 checklist items are designed to catch the specific patterns AI tools are most likely to miss.
What to do next
Write the Tier 3 path list for your codebase before writing the rest of the policy. Agree on it with your security lead. For the dependency verification specific to AI-generated code, see the AI generated code dependency verification resource. For Amazon CodeGuru Reviewer, which could identify security issues in code as part of CI, see the CodeGuru Reviewer documentation. Note that as of November 2025, new repository associations cannot be created in CodeGuru Reviewer; verify current AWS tooling for static analysis before recommending it to your team. The Agentic Workflows page describes how Ampity designs human-AI development workflows.
Primary references
- Amazon CodeGuru Reviewer documentation, source checked 2026-11-05
- AWS Bedrock Responsible AI, source checked 2026-11-05
Related resources
Verify Dependencies Before Running AI-Generated Code
Check package identity, exact versions, installation behavior and operational ownership before accepting a dependency suggested by an AI coding assistant.
Code Review Evidence When AI Wrote the Change
Review AI-written changes against independently defined behavior, failure paths and the actual tested revision, rather than relying on generated tests alone.
Code Review Best Practices: Risk, Feedback and Approval
Improve code review with risk-based scope, useful feedback and explicit approval ownership. Includes a worked review record and a reusable pull-request checklist.
AI Governance Framework: Production Decisions, Controls and Evidence
Build proportionate AI governance with a decision inventory, a worked routing example, release evidence, calibrated monitoring and explicit stop conditions.