Every team that runs a code review or audit ends up with a list of findings. Security vulnerabilities, architectural inconsistencies, dead code, performance bottlenecks, missing tests. The list can be long – dozens or hundreds of items. And the immediate question is always the same: where do we start?
Starting at the top of the list and working down is tempting but wrong. Not all findings are equal. Some are urgent. Some are important but not urgent. Some are easy to fix. Some require weeks of refactoring. Treating them all the same wastes effort and misses the opportunity to make strategic progress.
What you need is a framework for prioritisation. The technical debt prioritisation matrix provides one.
The two axes: impact and effort
The matrix uses two dimensions to evaluate each finding.
Impact measures how much damage this issue causes or how much risk it represents. A security vulnerability in an authentication module has high impact because the blast radius is large – it affects every user. A naming inconsistency in an internal utility has low impact because it causes confusion but not harm.
Impact is not the same as severity in the traditional sense. A critical-severity finding in a module that nobody uses has lower practical impact than a medium-severity finding in your most active endpoint. Impact considers the blast radius: how many users, systems, or processes are affected if this issue causes a problem.
Effort measures how much work it takes to fix the issue. Renaming a variable for consistency is low effort. Refactoring a data access layer to use a consistent pattern across 40 files is high effort. Effort includes not just the coding time but the testing, review, and deployment risk.
With these two axes, every finding falls into one of four quadrants.
Quadrant 1: Quick wins (high impact, low effort)
These are the findings you should fix immediately. They represent high-value improvements that can be completed quickly. Examples include:
A missing rate limiter on a public API endpoint. The fix is adding a few lines of middleware. The impact is preventing abuse that could take down the service.
Hardcoded credentials in a configuration file. The fix is moving them to environment variables. The impact is eliminating a credential leak vector.
A SQL query without parameterisation in a user-facing endpoint. The fix is straightforward. The impact is closing an injection vulnerability.
Quick wins build momentum. They demonstrate visible progress, reduce immediate risk, and create credibility for the larger effort. Start here.
Quadrant 2: Strategic investments (high impact, high effort)
These are the findings that matter most but cannot be fixed in a sprint. They require planning, coordination, and sustained effort. Examples include:
An inconsistent error handling strategy across the entire codebase. Some modules throw exceptions, some return error codes, some swallow errors. Fixing this means choosing a pattern, migrating every module, and testing thoroughly. The impact is significant – consistent error handling reduces production incidents and debugging time – but the effort is weeks, not hours.
A fragmented configuration system with three different approaches across the project. Consolidating configuration is a substantial refactoring effort, but the payoff is reduced complexity for every developer working on the system.
Strategic investments should be scheduled as planned work, not squeezed into spare cycles. They need dedicated time, a clear scope, and incremental milestones. The mistake teams make is acknowledging these issues but never allocating time to address them. Put them on the roadmap with a target quarter.
Quadrant 3: Thankless tasks (low impact, low effort)
These are minor improvements that are easy to make but do not move the needle on risk or quality. Examples include:
Inconsistent whitespace in a file that nobody edits. A deprecated import that still works fine. A TODO comment from 2019 that references a completed ticket.
Thankless tasks are safe to batch and address opportunistically – fix them when you are already editing that file for another reason. They do not deserve dedicated sprints, but they should not be ignored entirely. Over time, the accumulation of these small inconsistencies creates cognitive load for developers reading the code.
The key is not to let thankless tasks crowd out strategic investments. It is satisfying to clear a dozen low-effort items from the list, but if none of them materially improve the system, the satisfaction is misleading.
Quadrant 4: Major projects (low impact, high effort)
These are the findings that are expensive to fix and do not offer proportional returns. Examples include:
Rewriting a legacy module that works correctly but uses an older coding style. The module is stable, well-tested, and rarely modified. Rewriting it would bring it up to modern standards, but the practical benefit is marginal.
Migrating from one ORM to another because the current one is no longer the team's preferred choice. If the existing ORM works, the migration effort is rarely justified by the benefit.
Major projects should generally be deferred. They are the items that sit on the backlog indefinitely, and that is often the right outcome. Revisit them periodically – sometimes the impact increases as the system evolves, moving them into the strategic investment quadrant.
How AI findings map to the matrix
When an AI code review tool generates findings, each finding typically includes a severity level and a category. These map to the matrix, but not directly.
A finding categorised as “critical severity, security” in a public-facing module is high impact. The effort depends on the specific fix. If it is a missing input validation, the effort is low – quick win. If it requires restructuring the authentication flow, the effort is high – strategic investment.
A finding categorised as “low severity, maintainability” in a module with high change frequency is higher impact than it appears, because every developer who touches that code is affected by the issue. Conversely, a “medium severity” finding in a module that has not been modified in two years has lower practical impact.
The matrix is a human judgement overlay on top of the AI's analysis. The AI provides the findings. Your team provides the context about blast radius, change frequency, and fix complexity. Together, they produce a prioritised action plan.
Working the matrix in practice
Here is how to apply the matrix to a set of code review findings.
Step 1: Categorise every finding. For each item, estimate impact (high or low) and effort (high or low). Do not overthink this. A rough categorisation is better than a precise one that takes days to produce.
Step 2: Start with quick wins. Create tickets for high-impact, low-effort items and address them in the current sprint. These are your immediate wins.
Step 3: Plan strategic investments. For high-impact, high-effort items, scope the work and place it on the roadmap. Define milestones so progress is visible.
Step 4: Batch thankless tasks. Group low-impact, low-effort items and address them opportunistically. Some teams dedicate one day per sprint to this work.
Step 5: Defer major projects. Document low-impact, high-effort items but do not schedule them. Review quarterly to see if conditions have changed.
The matrix does not eliminate the need for judgement. It organises judgement into a structure that prevents the two most common failure modes: trying to fix everything at once, and fixing the easy things while ignoring the important ones.