Stop Reviewing Code You Don't Understand Yet — Turn AI Into a Rigorous First-Pass Reviewer That Cites Evidence, Not Style
An AI-assisted workflow that produces evidence-based findings grouped by severity and confidence — so human review is faster, more consistent, and focused on the decisions that need engineering judgment.
Executive Brief
Your Challenge
Code review is one of your most important controls, and it's the one most constrained by time and reviewer availability. Senior reviewers are overloaded, pull requests are too large, and depth varies wildly by reviewer — familiar code gets a glance, unfamiliar code takes an hour just to understand before you can evaluate it. Under deadline pressure, changes get approved, testing gaps surface late, and the same defects recur across projects. The result is production defects, security incidents, emergency patches, and technical debt that accumulates one under-scrutinized merge at a time.
Common Obstacles
The tempting shortcut is to paste a diff into an AI and ask 'is this code good?' — and that fails in predictable ways. A diff without the requirement makes the AI review whether code looks reasonable rather than whether it's correct. A snippet without surrounding code hides the existing validation, authorization, and output contracts that determine whether a finding is real. And an under-specified prompt produces broad, low-value commentary — invented defects, style preferences dressed up as bugs, and confident claims about runtime behavior that can't be confirmed statically. Worse, an unapproved platform or a stray secret in a prompt turns a review into a data-exposure incident.
The ABME Approach
This workflow does it in the right order: gather the requirement, acceptance criteria, and surrounding context first; give the AI an explicit severity and confidence model so every finding is classified and evidence-backed; then run the primary prompt and targeted follow-ups for security, reliability, performance, tests, API compatibility, and database changes. Findings come grouped as must-fix, should-fix, optional, and questions — so a critical authorization defect never gets buried under naming comments. A validation checklist and a security-considerations pass keep the review honest and keep secrets out of the model. AI expands coverage; human reviewers keep accountability.
Insight Summary
AI should expand code-review coverage, not dilute accountability. An AI recommendation is not an accountable approval — human reviewers remain responsible for the merge decision.
A code diff without purpose or surrounding context can only receive a limited review. Without the requirement, the AI reviews whether the code looks reasonable rather than whether it is correct.
Every finding needs a confidence level, and low confidence must be presented as a question, not a defect. The failure mode that erodes trust in AI review is converting uncertainty into false certainty.
Prioritize behavior over formatting. Linters and formatters handle routine style; use AI for the reasoning-intensive review that surfaces failure paths, edge cases, and testable concerns.
The origin of code does not change the approval standard. AI-generated code requires the same or greater scrutiny — invented APIs, hallucinated configuration, and code that compiles but doesn't satisfy the requirement all pass a casual read.
A secret should be considered exposed the moment it enters a prompt to an unapproved service. If sensitive data is required to understand the code, replace it with realistic placeholders that preserve structure.
The Journey
Three phases; each lists the tools you'll use there.
Assemble Context and Set the Bar
- Gather the diff, requirement, acceptance criteria, and relevant surrounding code
- Collect tests, coding standards, runtime versions, and deployment context
- Confirm the AI platform is approved and remove all secrets
- Establish the severity, confidence, and review-category framework
- Define the review objectives the review must answer
Run the Evidence-Based Review
- Run the primary prompt with the full context package
- Require severity, confidence, evidence, and remediation on every finding
- Apply follow-up prompts for security, reliability, performance, and API/database review
- Separate confirmed defects from questions and optional refactoring
- Convert actionable findings into concise pull-request comments or a fix checklist
Validate, Test, and Hand to Human Review
- Reproduce and add a failing test for every Critical, High, or Medium finding
- Run differential, static, and runtime testing to confirm assumptions
- Run the validation checklist against the AI review
- Confirm secrets were never submitted and human review is still required
What's Inside the Execution Layer
Numbered deliverables grouped by phase. Membership unlocks every tool.
Prerequisites Checklist
- Assemble the requirement, diff, and surrounding code before prompting
- Surface security, performance, and data-classification requirements early
- Confirm nothing reviewable is missing from the context
Before using this workflow, gather:
Code Review Prompt Pack
- Run a rigorous first-pass review with classified, evidence-backed findings
- Focus a review on security, reliability, performance, tests, API, or database changes
- Convert findings into pull-request comments, a fix checklist, or a re-review
Primary Prompt
Start here with the full context package — requirement, diff, surrounding code, tests, and constraints.You are a senior software engineer performing a rigorous, evidence-based code review.
I will provide:
• The business requirement
• Acceptance criteria
• The code change or diff
• Relevant surrounding code
• Tests
• Runtime and framework versions
• Architecture constraints
• Security requirements
• Performance requirements
• Operational requirements
• Team coding standards
Your task is to review the change for correctness, security, reliability, performance, maintainability, test coverage, compatibility, and operational readiness.
Do not begin with line-by-line comments.
First:
1. Summarize the intended change.
2. Summarize how the implementation attempts to satisfy the requirement.
3. Identify the affected:
• Components
• Functions
• Classes
• APIs
• Data models
• Configuration
• Dependencies
• Infrastructure
• Tests
• Deployment behavior
4. Identify changed public behavior.
5. Identify potential unintended behavior changes.
6. Identify assumptions required to interpret the code.
7. Identify missing context that materially limits the review.
8. Determine whether the change is appropriately scoped.
Then review the code for:
• Functional correctness
• Edge cases
• Null handling
• Boundary conditions
• State transitions
• Error handling
• Retry behavior
• Timeout behavior
• Cleanup and resource disposal
• Idempotency
• Concurrency
• Race conditions
• Transaction safety
• Input validation
• Authentication
• Authorization
• Injection risks
• Sensitive data handling
• Secret exposure
• Logging safety
• Dependency risk
• Performance
• Scalability
• N+1 queries
• Memory usage
• Blocking operations
• Maintainability
• Readability
• Duplication
• Tight coupling
• API compatibility
• Data compatibility
• Migration risk
• Test coverage
• Observability
• Deployment risk
• Rollback behavior
• Documentation
For each finding, include:
1. Finding ID.
2. Title.
3. Severity:
• Critical
• High
• Medium
• Low
• Informational
4. Confidence:
• Confirmed
• High
• Moderate
• Low
5. Category.
6. Affected file and code location.
7. Evidence.
8. Why it matters.
9. Failure or exploitation scenario.
10. Recommended remediation.
11. Example corrected code when useful.
12. Recommended test.
Requirements:
• Do not invent defects.
• Do not report style preferences as bugs.
• Do not repeat the same issue in multiple categories.
• Prioritize behavior over formatting.
• Distinguish confirmed defects from questions.
• Identify strengths as well as weaknesses.
• Do not approve code merely because tests pass.
• Do not reject code merely because it differs from your preferred style.
• Preserve the author's intended design where reasonable.
• Consider the surrounding architecture.
• Avoid recommending large refactors unless justified by the change.
• Clearly identify findings that block approval.
• Keep comments concise and actionable.
• Do not expose secrets or sensitive data.
• Do not recommend weakening security controls.
• Do not claim runtime behavior that cannot be confirmed statically.
After the findings, provide:
1. Executive review summary.
2. Requirement-to-implementation assessment.
3. Positive observations.
4. Blocking findings.
5. Nonblocking findings.
6. Missing tests.
7. Security assessment.
8. Performance assessment.
9. Operational-readiness assessment.
10. Open questions.
11. Final recommendation:
• Approve
• Approve with minor changes
• Request changes
• Block pending clarificationReview Only the Diff
When you want the review scoped tightly to the changed lines.Review only the changed lines, but use the surrounding code to understand behavior. Do not comment on unrelated legacy issues unless the change makes them worse or depends on them.
Review for Confirmed Defects Only
When you want to cut speculative and stylistic noise.Return only findings that are directly supported by the code. Exclude style comments, broad refactoring suggestions, and speculative concerns. For every finding, provide a concrete failure scenario.
Review for Security
For authentication, authorization, or untrusted-input paths.Perform a security-focused review. Trace all untrusted inputs through validation, authorization, data access, command execution, file access, network calls, logging, and output. Prioritize exploitable paths and clearly distinguish confirmed vulnerabilities from defense-in-depth improvements.
Review for Reliability
For production reliability and failure behavior.Review the change for production reliability. Focus on: • Failure paths • Timeouts • Retries • Idempotency • Cleanup • Partial completion • Race conditions • Transaction boundaries • Resource exhaustion • Recovery • Rollback
Review for Performance
For measurable performance and scalability concerns.Review the change for measurable performance and scalability concerns. Identify: • N+1 queries • Repeated external calls • Blocking work • Large allocations • Unbounded collections • Unbounded concurrency • Missing pagination • Missing batching • Expensive serialization • Lock contention • Inefficient algorithms Do not report micro-optimizations unless they are likely to matter.
Review Test Coverage
To map existing tests against the changed behavior.Review the existing tests against the changed behavior. Identify missing: • Success cases • Failure cases • Boundary cases • Null cases • Permission cases • Concurrency cases • Compatibility cases • Regression cases • Rollback cases Provide test names and expected outcomes.
Review API Compatibility
For any change to public interfaces.Review all public interfaces for backward compatibility. Check: • Method signatures • Parameters • Defaults • Response schemas • Status codes • Exceptions • Events • Configuration • Serialization • Database fields • Ordering • Null behavior • Deprecated behavior Identify any breaking change, even if it appears minor.
Review Database Changes
When code and schema changes ship together.Review the code and database changes together. Assess: • Schema compatibility • Data migration • Locking • Indexes • Nullability • Defaults • Rollback • Deployment order • Old and new application-version coexistence • Large-table impact • Transaction behavior
Review Infrastructure-as-Code
For infrastructure change reviews.Review the infrastructure change for: • Security exposure • Excessive permissions • Public access • Network boundaries • Encryption • State handling • Destructive replacement • Dependency ordering • Drift • Cost impact • Availability • Rollback • Observability
Convert Findings into Pull-Request Comments
To turn the review into concise inline comments.Convert only actionable findings into concise pull-request comments. Each comment should: • Refer to the exact code location • Explain the issue • Describe the impact • Suggest a correction • Avoid repeating the full review • Avoid vague language
Create a Fix Checklist
To hand the developer a prioritized, verifiable task list.Convert the review into a developer checklist grouped by: • Must fix • Should fix • Consider later • Questions to resolve Keep each item specific and verifiable.
Re-Review After Changes
After the developer submits remediations.Compare the revised code with the previous review. For each prior finding, mark: • Resolved • Partially resolved • Not resolved • No longer applicable Then identify any new issue introduced by the remediation.
Replace Broad Prompts
Reference — the anti-pattern this pack replaces.Do not ask "Is this code good?" — broad prompts produce broad, low-value feedback. Provide explicit review dimensions and output requirements using the primary prompt above.
Test Coverage Matrix
- Map each acceptance criterion and finding to a required test
- Confirm boundary, failure, and security cases are covered
- Identify test gaps before requesting human review
| Area | Example Test |
|---|---|
| Core requirement | Valid update succeeds |
| Authentication | Unauthenticated caller is rejected |
| Authorization | Caller cannot update another user |
| Validation | Invalid display name is rejected |
| Boundary | 1 and 100 characters succeed |
| Boundary | 101 characters fails |
| Normalization | Whitespace is trimmed |
| Persistence failure | Error is returned and no audit success is recorded |
| Audit | Successful change creates one audit event |
| Response | Sensitive fields are excluded |
| Concurrency | Simultaneous updates behave consistently |
| Regression | Existing profile reads remain unchanged |
Review Output Template
- Structure the review into a consistent, prioritized report
- Separate blocking from nonblocking findings
- Force an explicit final recommendation
Executive Summary
Blocking Findings
Nonblocking Findings
Missing Tests
Questions
Recommendation
Validation Checklist
- Confirm the review had sufficient context to be valid
- Verify findings cite evidence and are properly classified
- Confirm secrets were never submitted and human review remains required
Before accepting the AI review:
Finding Verification & Test Plan
- Reproduce and add a failing test for every material finding
- Compare old and new behavior across inputs and permission levels
- Layer static and runtime analysis on top of the AI review
Verify findings and validate fixes across these passes:
Finding Verification — for every Critical, High, or Medium finding
Differential Testing — compare old and new behavior for
Static Analysis — use language-appropriate tools alongside AI review
Runtime Testing — validate assumptions involving
🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.
Unlock Full BlueprintFull Playbook
Overviewpublic
Code review is one of the most important controls in software development. It helps teams identify defects, security weaknesses, maintainability problems, architectural drift, unclear logic, missing tests, and operational risks before code reaches production.
Traditional code review, however, is constrained by time and reviewer availability. Human reviewers may focus on style while missing behavioral defects, overlook edge cases in unfamiliar code, or spend large amounts of time reconstructing the purpose of a change before evaluating it.
This workflow uses AI as a structured first-pass or supplemental code reviewer.
The AI reviews a proposed change in the context of:
- The business requirement
- The surrounding code
- The intended architecture
- The supported platforms
- Existing tests
- Security expectations
- Performance constraints
- Operational requirements
- Team coding standards
The goal is not to replace human review. The goal is to make human review faster, more consistent, and more focused on the decisions that require engineering judgment.
A high-quality AI-assisted review should distinguish between:
- Confirmed defects
- Likely defects
- Maintainability concerns
- Security findings
- Performance risks
- Test gaps
- Documentation gaps
- Style preferences
- Questions requiring additional context
The final output should prioritize actionable findings and avoid overwhelming the developer with low-value commentary.
Business Problempublic
Engineering teams often struggle with code-review quality because:
- Senior reviewers are overloaded.
- Pull requests are too large.
- Reviewers lack context about the requirement.
- Review depth varies significantly by reviewer.
- Familiar code receives less scrutiny.
- Unfamiliar code takes too long to understand.
- Testing gaps are discovered late.
- Security concerns are reviewed inconsistently.
- Comments focus on formatting instead of behavior.
- Architectural drift accumulates incrementally.
- Important edge cases are missed.
- Reviewers approve changes under deadline pressure.
- Similar defects recur across projects.
- Review feedback lacks prioritization.
- Developers receive vague comments without clear remediation.
Inconsistent code review increases the likelihood of:
- Production defects
- Security incidents
- Emergency patches
- Support escalations
- Rework
- Technical debt
- Unstable releases
- Difficult maintenance
- Undocumented behavior
- Breaking API changes
AI can improve coverage, but only when it is given sufficient context and instructed to produce evidence-based findings.
Typical Use Casespublic
Use this workflow when:
- Reviewing a pull request
- Reviewing a merge request
- Reviewing a patch or diff
- Reviewing code before opening a pull request
- Reviewing a high-risk production change
- Reviewing unfamiliar code
- Reviewing legacy code modifications
- Reviewing API changes
- Reviewing database-access code
- Reviewing authentication or authorization logic
- Reviewing infrastructure-as-code changes
- Reviewing automation scripts
- Reviewing test coverage
- Reviewing error-handling behavior
- Reviewing observability changes
- Reviewing dependency updates
- Preparing for a formal human review
Do NOT Use This Workflow Whenpublic
This workflow is not intended to:
- Automatically approve code
- Replace required human reviewers
- Certify code as secure
- Replace penetration testing
- Replace runtime testing
- Replace architecture review
- Replace compliance review
- Review code without understanding its purpose
- Judge correctness from a partial snippet when surrounding behavior is required
- Invent defects to make the review appear thorough
- Enforce personal style preferences as defects
- Expose proprietary code to an unapproved AI system
- Submit credentials, secrets, keys, or sensitive customer data to an AI system
- Evaluate malware by executing it
- Guarantee production readiness
AI-generated findings should be validated against the code, tests, and runtime environment.
Expected Outcomepublic
After completing this workflow, you should have:
- A concise summary of the proposed change
- A review of whether the implementation matches the stated requirement
- Findings grouped by severity and category
- Evidence for each finding
- Suggested remediations
- Missing test scenarios
- Security and privacy considerations
- Performance and scalability considerations
- Maintainability observations
- API and compatibility risks
- Operational-readiness observations
- Questions requiring human judgment
- A clear recommendation: Approve / Approve with minor changes / Request changes / Block pending clarification
🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.
Unlock Full BlueprintReview Objectivesprotected
A complete review should answer:
- What is the change intended to accomplish?
- Does the implementation match the requirement?
- What behavior changed?
- What behavior may have changed unintentionally?
- Are error conditions handled correctly?
- Are inputs validated?
- Are permissions and authorization enforced?
- Are sensitive values protected?
- Are outputs and public interfaces stable?
- Are concurrency and state changes safe?
- Are dependencies used appropriately?
- Are tests sufficient?
- Is the code maintainable?
- Is the change observable in production?
- Can the change be rolled back safely?
- Are there edge cases not covered?
- Is the change appropriately scoped?
- Is the code ready for human approval?
Review Severity Modelprotected
Critical
- Arbitrary code execution
- Authentication bypass
- Authorization bypass
- Credential disclosure
- Data corruption
- Destructive production behavior
- Severe privacy exposure
- Unrecoverable state
- System-wide outage
- Cross-tenant data access
High
- Incorrect core behavior
- Security exposure
- Production failure
- Breaking API behavior
- Data loss under realistic conditions
- Major scalability problems
- Incorrect permission handling
- Unsafe state transitions
- Persistent operational instability
Medium
- Edge-case defects
- Weak error handling
- Reduced maintainability
- Incomplete validation
- Operational confusion
- Performance degradation at scale
- Insufficient logging
- Difficult troubleshooting
- Partial test coverage
Low
- Clarity
- Naming
- Documentation
- Small duplication
- Minor maintainability concerns
- Small test enhancements
- Nonessential refactoring
Informational
- Requires context
- Documents a tradeoff
- Notes an assumption
- Identifies a future improvement
- Highlights a nonblocking design choice
Confidence Modelprotected
Confirmed
High Confidence
Moderate Confidence
Low Confidence
Review Categoriesprotected
Functional Correctness
- The code performs the stated requirement
- Conditions are correct
- Loops terminate
- Null values are handled
- Defaults are appropriate
- Boundary values are handled
- State transitions are valid
- Return values are correct
- Data transformations preserve meaning
- Failure behavior is intentional
Security
- Authentication bypass
- Authorization failures
- Injection
- Unsafe deserialization
- Secret exposure
- Sensitive logging
- Insecure cryptography
- Weak randomness
- Path traversal
- Untrusted file handling
- Cross-tenant access
- Insecure network behavior
- Excessive privilege
- Missing input validation
- Unsafe dynamic execution
- Dependency risk
Reliability
- Error handling
- Retry behavior
- Timeout behavior
- Cleanup
- Partial failure
- Idempotency
- Transaction boundaries
- Race conditions
- Resource disposal
- Cancellation
- Recovery
- Rollback
Performance
- Repeated remote calls
- N+1 queries
- Unbounded loops
- Excessive memory allocation
- Inefficient collection handling
- Blocking operations
- Unbounded concurrency
- Large object retention
- Expensive serialization
- Missing pagination
- Missing batching
- Repeated computation
Maintainability
- Readability
- Naming
- Function size
- Responsibility boundaries
- Duplication
- Hidden side effects
- Unclear abstractions
- Tight coupling
- Magic values
- Configuration handling
- Comment accuracy
- Error-message quality
- Testability
Architecture
- Matches existing architecture
- Introduces new coupling
- Violates dependency direction
- Duplicates an existing capability
- Exposes internal implementation
- Creates an unstable interface
- Adds unnecessary infrastructure
- Changes trust boundaries
- Alters data ownership
- Creates deployment dependencies
Testing
- Unit tests
- Integration tests
- Negative tests
- Boundary tests
- Permission tests
- Failure-path tests
- Concurrency tests
- Regression tests
- Compatibility tests
- Migration tests
- Rollback tests
Operations
- Logging
- Metrics
- Tracing
- Alerts
- Health checks
- Configuration
- Feature flags
- Deployment
- Rollback
- Runbooks
- Supportability
- Rate limiting
- Resource limits
Documentation
- Public API documentation
- Changed behavior
- New configuration
- New dependencies
- Migration notes
- Changelog
- Operational guidance
- Security implications
- Examples
- Deprecation notices
Example Inputprotected
Requirement
Add an endpoint that allows an authenticated user to update their display name.
Requirements:
- User must be authenticated.
- User may update only their own profile.
- Display name must be between 1 and 100 characters.
- Leading and trailing whitespace should be removed.
- The endpoint should return the updated profile.
- Changes should be audited.
Example Code
app.put('/api/users/:id', async (req, res) => {
const user = await db.users.findById(req.params.id);
if (!user) {
return res.status(404).json({
error: 'User not found'
});
}
user.displayName = req.body.displayName;
await db.users.save(user);
return res.json(user);
});Example Review Summaryprotected
The implementation updates a user record identified by a route parameter and returns the saved object.
It does not fully satisfy the requirement because:
- Authentication is not enforced in the shown handler.
- Authorization does not restrict updates to the current user.
- Input validation is missing.
- Whitespace normalization is missing.
- Audit logging is missing.
- The full user object may expose fields not intended for API output.
Example Findingsprotected
AI-CR-001 — Missing Ownership Authorization
Severity: Critical
Confidence: Confirmed
Category: Security
Affected Code:
const user = await db.users.findById(req.params.id);Evidence: The handler selects the target account using a caller-controlled route parameter and does not compare it with the authenticated user's identifier.
Why It Matters: Any caller who can reach this endpoint may be able to update another user's profile by changing the route parameter.
Failure Scenario: A user sends:
PUT /api/users/another-user-idand changes another account's display name.
Recommended Remediation: Use the authenticated identity as the target identifier or explicitly compare the requested identifier with the authenticated user.
Example:
if (req.params.id !== req.auth.userId) {
return res.status(403).json({
error: 'Forbidden'
});
}A stronger design may remove the route identifier entirely:
PUT /api/users/meRecommended Test: Verify that an authenticated user receives 403 when attempting to update another user's record.
AI-CR-002 — Missing Input Validation
Severity: High
Confidence: Confirmed
Category: Functional Correctness
Affected Code:
user.displayName = req.body.displayName;Evidence: The value is assigned without verifying its type, length, or normalized content.
Why It Matters: The endpoint may store:
- Null values
- Empty strings
- Strings longer than 100 characters
- Non-string values
- Whitespace-only values
Recommended Remediation: Validate the type, trim the value, and enforce the length requirement after trimming.
if (typeof req.body.displayName !== 'string') {
return res.status(400).json({
error: 'displayName must be a string'
});
}
const displayName = req.body.displayName.trim();
if (displayName.length < 1 || displayName.length > 100) {
return res.status(400).json({
error: 'displayName must contain 1 to 100 characters'
});
}Recommended Tests:
- Empty string
- Whitespace-only string
- 1-character string
- 100-character string
- 101-character string
- Null
- Number
- Missing property
AI-CR-003 — Missing Audit Event
Severity: High
Confidence: Confirmed
Category: Operations
Evidence: The requirement states that changes must be audited, but the handler does not create an audit event.
Why It Matters: The organization cannot reliably determine:
- Who made the change
- Which account changed
- When the change occurred
- What the previous value was
- What the new value is
Recommended Remediation: Record an audit event containing:
- Acting user identifier
- Target user identifier
- Operation
- Previous value
- New value
- Timestamp
- Request or correlation identifier
Sensitive values should be minimized according to audit policy.
Recommended Test: Verify that one audit event is created after a successful update and no success audit event is written when persistence fails.
AI-CR-004 — Raw Persistence Object Returned
Severity: Medium
Confidence: High
Category: Security
Affected Code:
return res.json(user);Evidence: The handler returns the full database object.
Why It Matters: The object may contain fields not intended for external disclosure, such as:
- Internal identifiers
- Permission data
- Account status
- Authentication metadata
- Audit fields
- Password hashes
- Recovery settings
Recommended Remediation: Return an explicit API response model.
return res.json({
id: user.id,
displayName: user.displayName
});Recommended Test: Verify that the response contains only the documented profile fields.
Example Revised Codeprotected
app.put(
'/api/users/me',
requireAuthentication,
async (req, res, next) => {
try {
if (typeof req.body.displayName !== 'string') {
return res.status(400).json({
error: 'displayName must be a string'
});
}
const displayName = req.body.displayName.trim();
if (displayName.length < 1 || displayName.length > 100) {
return res.status(400).json({
error: 'displayName must contain 1 to 100 characters'
});
}
const user = await db.users.findById(req.auth.userId);
if (!user) {
return res.status(404).json({
error: 'User not found'
});
}
const previousDisplayName = user.displayName;
user.displayName = displayName;
await db.transaction(async transaction => {
await db.users.save(user, {
transaction
});
await db.auditEvents.create(
{
actorUserId: req.auth.userId,
targetUserId: user.id,
action: 'UserDisplayNameUpdated',
previousValue: previousDisplayName,
newValue: displayName,
requestId: req.id,
occurredAt: new Date()
},
{
transaction
}
);
});
return res.json({
id: user.id,
displayName: user.displayName
});
} catch (error) {
next(error);
}
});The exact transaction, authentication, audit, and error-handling patterns should follow the application's established architecture.
Review Processprotected
Step 1 — Understand the Requirement
Before evaluating implementation details, determine:
- User need
- Business rule
- Acceptance criteria
- Security expectation
- Performance expectation
- Data impact
- Compatibility expectation
- Deployment constraint
A reviewer cannot determine correctness without knowing the intended behavior.
Step 2 — Map the Change
Identify:
- Files changed
- Functions changed
- Interfaces changed
- Dependencies added
- Data changed
- Configuration changed
- Infrastructure changed
- Tests changed
This creates the review boundary.
Step 3 — Trace Inputs and Outputs
Trace:
- Where inputs originate
- How inputs are validated
- How data is transformed
- Which systems receive data
- What is returned
- What is logged
- What state changes
Step 4 — Review Failure Paths
For every external or state-changing operation, ask:
- What can fail?
- Is the failure visible?
- Is cleanup required?
- Is retry safe?
- Can the operation partially succeed?
- Can it be repeated?
- Is rollback possible?
Step 5 — Review Tests
Map tests to:
- Acceptance criteria
- Findings
- Boundary conditions
- Security requirements
- Failure behavior
- Compatibility
Step 6 — Prioritize Findings
The review should focus the developer on the most important work.
Use:
- Must fix
- Should fix
- Optional improvement
- Question
Do not bury a critical authorization defect beneath dozens of naming comments.
Writing Good Review Commentsprotected
Good Review Comment Characteristics
A useful review comment is:
- Specific
- Evidence-based
- Scoped
- Actionable
- Respectful
- Prioritized
- Clear about impact
- Clear about confidence
Weak:
This looks wrong.Better:
This endpoint uses the route ID without comparing it to the authenticated user. A caller could update another account by changing the URL. Please use the authenticated user ID as the target or return 403 when the IDs differ.Questions Versus Findings
Use a question when context is missing.
Example:
Is this callback guaranteed to run on one thread? If multiple requests can invoke it concurrently, the shared dictionary update may race.Use a finding when evidence is sufficient.
Example:
The shared dictionary is modified concurrently without synchronization in both request handlers. This can result in lost updates.AI should not convert uncertainty into false certainty.
Positive Observations
A balanced review should identify strong decisions where useful.
Examples:
- Input validation is centralized.
- The change uses an existing abstraction.
- The implementation preserves API compatibility.
- Errors are mapped consistently.
- The tests cover major failure paths.
- The migration is backward compatible.
- Logging avoids sensitive data.
- The change supports rollback.
- The code is appropriately scoped.
Positive observations should be meaningful, not filler.
Review Noise to Avoid
Avoid comments about:
- Personal formatting preferences
- Equivalent syntax with no meaningful benefit
- Renaming every local variable
- Refactoring unrelated code
- Theoretical issues without realistic impact
- Existing problems outside the change
- Repeating automated linter output
- Minor optimizations in noncritical paths
- Adding comments that restate obvious code
The review should improve software quality without creating unnecessary work.
Specialized Review Guidanceprotected
Large Pull Requests
AI review quality decreases when a change is too large or combines unrelated work.
For large changes:
- Review the requirement and architecture first.
- Divide the change by component.
- Review public interfaces.
- Review security-sensitive paths.
- Review data and migrations.
- Review tests.
- Review operational behavior.
- Consolidate duplicate findings.
Recommend splitting a pull request when:
- It contains multiple unrelated features.
- It combines refactoring with behavior changes.
- It includes generated files obscuring logic.
- It changes application and infrastructure behavior without clear sequencing.
- Reviewers cannot isolate risk.
Generated Code Review
AI-generated code requires the same or greater scrutiny as human-written code.
Review for:
- Invented APIs
- Incorrect library usage
- Missing edge cases
- Hallucinated configuration
- Insecure defaults
- Overly broad exception handling
- Unnecessary abstractions
- Unsupported version assumptions
- Fake test coverage
- Comments that do not match behavior
- Dependencies that do not exist
- Code that compiles but does not satisfy the requirement
The origin of code does not change the approval standard.
Dependency Review
When a change adds or updates a dependency, review:
- Purpose
- Necessity
- License
- Maintenance status
- Security history
- Version
- Transitive dependencies
- Package integrity
- Runtime impact
- Bundle size
- Platform support
- Update policy
- Removal plan
A dependency should not be added for functionality the platform already provides adequately without justification.
Error-Handling Review
Review whether errors are:
- Detected
- Classified
- Logged
- Sanitized
- Returned appropriately
- Retried safely
- Associated with the correct operation
- Preserved for diagnostics
- Converted into correct status codes
- Prevented from leaking sensitive data
Weak:
try:
process()
except Exception:
passWeak:
catch (error) {
return res.status(200).json({
success: false
});
}The second example may cause monitoring and callers to interpret failure as success.
Concurrency Review
Review shared state involving:
- Static variables
- Global variables
- Caches
- Files
- Database records
- Queues
- Counters
- Locks
- Sessions
- Temporary resources
Ask:
- Can two operations run at once?
- Is the operation atomic?
- Can updates be lost?
- Can the same job be processed twice?
- Is lock scope correct?
- Can deadlock occur?
- Is ordering required?
- Is cancellation handled?
API Review
For API changes, review:
- Authentication
- Authorization
- Request validation
- Response schema
- Status codes
- Error schema
- Pagination
- Rate limiting
- Idempotency
- Versioning
- Backward compatibility
- Sensitive fields
- Caching
- Logging
- Documentation
Data-Access Review
Review:
- Query correctness
- Parameterization
- Transaction boundaries
- Index usage
- N+1 behavior
- Pagination
- Null behavior
- Locking
- Concurrency
- Connection disposal
- Timeout
- Data filtering
- Tenant isolation
- Access control
Unsafe:
SELECT * FROM users WHERE name = '${name}'Prefer parameterized queries.
Operational-Readiness Review
A change may be functionally correct but operationally incomplete.
Review:
- What is logged?
- What is measured?
- How is failure detected?
- What alerts exist?
- How is configuration supplied?
- How is the feature disabled?
- How is the deployment rolled back?
- Is a database migration required?
- Is release ordering important?
- What happens during partial deployment?
- What support guidance is needed?
Review Metricsprotected
Teams may track:
- Defects found before merge
- Defects escaped to production
- Review turnaround time
- Average pull-request size
- Findings by severity
- False-positive rate
- Repeated defect categories
- Test gaps identified
- Security findings identified
- AI comments accepted
- AI comments rejected
- Review coverage by repository
Metrics should improve the process, not rank individual developers.
Governance Recommendationsprotected
Define:
- Approved AI platforms
- Code-classification rules
- Prohibited data
- Required human reviewers
- Repositories eligible for AI review
- Logging and retention requirements
- Whether AI comments may be posted automatically
- Severity thresholds
- False-positive handling
- Escalation process
- Audit requirements
- Model-change review
- Prompt ownership
- Periodic quality evaluation
Automation Opportunitiesprotected
- Pull-request templates
- GitHub Actions
- GitLab CI
- Azure DevOps pipelines
- Pre-commit review
- IDE workflows
- Secure development lifecycle gates
- Release readiness reviews
- Dependency-update workflows
- Infrastructure change reviews
- AI-generated code validation
- Technical debt programs
- A mature pipeline could: collect the requirement; collect the diff and surrounding code; run linters and analyzers; run tests; run secret and dependency scans; generate an AI review; post only high-confidence actionable comments; require human validation; track recurring findings; improve coding standards and test templates.
Pro Tipsprotected
- Include the requirement before the code.
- Review changed behavior, not only changed lines.
- Include relevant tests and surrounding code.
- Ask for evidence with every finding.
- Require severity and confidence.
- Separate defects from questions.
- Separate required changes from optional refactoring.
- Use linters for style and AI for reasoning.
- Trace untrusted inputs through the complete execution path.
- Review failure behavior as carefully as success behavior.
- Review public interfaces for subtle breaking changes.
- Verify all Critical and High findings manually.
- Convert confirmed findings into tests.
- Re-review fixes for newly introduced defects.
- Keep AI comments concise when posting them to a pull request.
- Measure false positives and improve the review prompt.
- Never treat AI approval as final approval.
- Never submit active secrets to the review system.
Common Mistakesprotected
- Providing only the diff — a diff may not show existing validation, existing authorization, calling behavior, shared state, output contracts, or dependency configuration; include relevant surrounding code.
- Omitting the requirement — without it, AI reviews whether code appears reasonable rather than whether it is correct.
- Asking "Is this code good?" — broad prompts produce broad, low-value feedback; provide explicit review dimensions and output requirements.
- Treating every suggestion as required — AI often proposes optional refactoring; separate defects from preferences.
- Accepting invented findings — validate API behavior, framework behavior, language semantics, dependency capabilities, and runtime assumptions.
- Overloading the review with style comments — linters and formatters should handle routine style enforcement; use AI for reasoning-intensive review.
- Ignoring existing tests — tests often explain intended behavior and reveal assumptions.
- Reviewing only happy paths — most production defects occur in invalid input, timeouts, partial failure, permission failures, concurrency, dependency outages, and unexpected state.
- Using AI approval as a control — an AI recommendation is not an accountable approval; human reviewers remain responsible for merge decisions.
- Submitting secrets — never include passwords, API keys, session tokens, private keys, connection strings containing secrets, or production authentication headers.
Security Considerationsprotected
- Before submitting code to an AI system: confirm the platform is approved.
- Confirm data-retention settings.
- Confirm whether prompts are used for training.
- Remove active secrets.
- Remove private keys.
- Remove production tokens.
- Remove customer data.
- Remove regulated data.
- Remove confidential internal endpoints where unnecessary.
- Follow source-code handling policy.
- Use enterprise controls where required.
- A secret should be considered exposed if it was included in a prompt to an unapproved service.
- If sensitive data is required to understand the code, replace it with realistic placeholders while preserving structure.
Related Blueprints
⚠ Normalization Warnings — 15 for review
- RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (12 follow-up H2s) combined into one prompt_pack tool with 14 prompts; prompt text is verbatim, 'when' guidance lines are editorial additions. NOTE: the extraction ran prompt lines together without line breaks (bullets and numbered steps collapsed); I re-inserted line breaks to restore readable structure but did NOT change any wording — confirm the reconstructed line breaks against the source docx.
- ADDED PROMPT: A 14th prompt 'Replace Broad Prompts' was synthesized from the 'Asking Is This Code Good?' common-mistake to keep the anti-pattern discoverable in the pack. This is an editorial addition, not a source prompt — confirm or remove; the same content also appears in playbook.common_mistakes.
- CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
- CLASSIFICATION TO CONFIRM: 'Testing Recommendations' classified as a checklist TOOL named 'Finding Verification & Test Plan' (all items are verifiable/executable steps). Alternative: body/reference. Display name changed from source heading — confirm. The 'Pseudo-Test Example' code block under this section was NOT included in the tool; it is a worked example — see next warning.
- DROPPED-TO-CONFIRM: The 'Pseudo-Test Example' JavaScript block (describe('PUT /api/users/me'...)) under Testing Recommendations was not placed. It is a worked example; consider adding as a body/example section. Currently omitted — restore as an example if desired.
- CLASSIFICATION: 'Review Severity Model' and 'Confidence Model' classified as body/reference (consulted tiered models, block-approval semantics). 'Review Categories' also reference (consulted checklists of what-to-review, not completed by the practitioner).
- CLASSIFICATION: 'Test Coverage Matrix' from a real 2-column table -> matrix tool; rubric left empty (doc defines no scoring scheme); example_rows verbatim, skeleton_rows 0.
- CLASSIFICATION: 'Review Output Template' -> template tool; labels and guidance taken from the H2s and their instruction lines verbatim.
- GROUPING: Review Process (6 steps), comment-quality sections (Good Comment / Questions vs Findings / Positive Observations / Review Noise), and specialized reviews (Large PRs, Generated Code, Dependency, Error-Handling, Concurrency, API, Data-Access, Operational-Readiness) grouped into three body GROUPS to avoid a flat 20+ section list. Group titles 'Writing Good Review Comments', 'Specialized Review Guidance', and 'Assemble Context and Set the Bar' (phase title) are editorial — confirm.
- PLAYBOOK: 'Common Mistakes' had subsection H2s with some code examples; flattened into playbook.common_mistakes as one-line summaries (code examples from cm sections not preserved). Confirm whether error-handling/other code snippets should be retained — the standalone 'Error-Handling Review' body section retains its code, so loss is limited.
- PLAYBOOK: 'Security Considerations' and 'Automation Opportunities' mapped to playbook (flat lists, no subsections) rather than body groups. The automation 10-step mature-pipeline list was compressed into one trailing item — confirm.
- SECTIONS 'Review Metrics' and 'Governance Recommendations' have no standard playbook home; kept as body/prose (protected). Confirm placement.
- STATS: prompts=14 counts the 13 source prompts plus the 1 synthesized anti-pattern prompt; deliverables=5 counts distinct tools (prerequisites-checklist, code-review-prompt-pack, test-coverage-matrix, review-output-template, validation-checklist, testing-recommendations = actually 6). Set deliverables to 6 if counting all tools; left at 5 counting non-checklist primary artifacts — CONFIRM and reconcile.
- AI-CR-003 in Example Findings had no 'Affected Code' line in source (finding is about an omission); preserved as-is with no code block.
- seo.noindex set true per instruction (overlay not yet reviewed).
SEO Block
- Title tag: AI-Assisted Code Review That Cites Evidence | ABME (50 chars)
- Meta: Turn AI into a structured first-pass code reviewer: evidence-based findings, severity and confidence on every one, secrets kept out — human approval still required. (164 chars)
- Schema: HowTo · noindex: false
- Related: ai-002, ai-003, ai-004, ai-005, ai-006, ai-007, ai-008, ai-009, ai-010, ps-003, ps-004, ps-005, ps-007, ps-008, ps-009
- Keywords: ai code review, ai-assisted code review, pull request review ai, chatgpt code review, claude code review, code review severity model, evidence-based code review, ai security code review, review test coverage ai, code review prompt
