Engineering

Legacy Code Review Prompt

Mentoring-style maintainability review: what makes the next change expensive, explained with corrected examples — teach, don't just judge.

Overview

Legacy code review has a different goal: not gatekeeping a merge, but building a map for gradual cleanup — and teaching the developer doing it. This setup runs the maintainability focus (duplication that drifts, intent-hiding names, cohesion, coupling, dead code, test coverage of what changes) under Mentoring style: every finding explains WHY it matters, CRITICAL and MAJOR findings come with short corrected examples, and the review ends with the three most important things to learn — not a verdict to fear.

Workflow

Review before you change anything
The maintainability map tells you where changes will be expensive — before you're mid-change and finding out.
Use the corrected examples as patterns
Mentoring style shows the fix shape for major findings — apply the pattern, not just the instance.
Hand the top-three learnings to the team
The closing learnings generalize beyond this module — that's the compounding value.

Why This Works

Maintainability focus prices the NEXT change — the metric legacy code actually fails on
Mentoring style converts findings into transferable knowledge
A map-not-gate framing makes the review usable on code that would fail any gate

Best for

Modules everyone fears and nobody owns
Onboarding developers into old codebases
Cleanup work that needs a defensible priority order

Not for

Actually performing the refactor — that's the Refactor Prompt Builder, with behavior-preserving constraints
Blocking a release — mentoring style deliberately doesn't gate

Use cases

Mapping a legacy module before touching it
Teaching newer developers what good looks like, in context
Prioritizing cleanup by what makes changes expensive

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Review this legacy module to guide its gradual cleanup — teach, don't just judge.
Primary focus: maintainability — find what makes the next change to this code expensive.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.

REVIEW CRITERIA
- Duplication that will drift apart
- Naming that hides intent
- Cohesion: modules and functions doing one job
- Coupling: reaching into other modules' internals
- Test coverage of the logic that changes

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Is there duplicated logic that will drift apart when one copy changes?
2. Do names reveal intent — could a newcomer guess what each thing does?
3. Does each function/class do one job (cohesion)?
4. Does the code reach into other modules' internals (coupling)?
5. Any magic numbers or strings that should be named constants?
6. Is there dead code that should be deleted, not kept "just in case"?
7. Do comments explain WHY, not narrate WHAT?
8. Is the changed logic covered by tests that would catch a regression?
9. Is the dependency direction sensible — stable things not depending on volatile ones?
10. Is the public surface minimal — nothing exposed that callers shouldn't touch?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Explain WHY each finding matters, not just what to change.
- For each CRITICAL or MAJOR finding, include a short corrected example.
- Frame findings as learning points for a developer growing into this codebase.

FINAL VERDICT
- End with the three most important things to learn from this review.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

Related Resources

Explore more resources that work well with this one.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Legacy Code Modernization Workflow Workflow · 4 steps

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources