Introduction

You inherited a codebase, or an AI coding assistant produced most of it, and now every new feature takes longer than the last one. Someone on the team is going to ask whether you should refactor or start over, and the honest answer is that most founders answer this question with their gut instead of their data. That is expensive in both directions: rewriting a codebase that only needed targeted refactoring burns months and a budget you did not need to spend, while refactoring a codebase that has structurally failed just delays the inevitable rewrite while bugs compound.

The practitioner consensus across multiple independent sources is unusually consistent: refactor when you can, rewrite when you must. The hard part is knowing which situation you are actually in. This diagnostic gives you three measurable thresholds, plus the scaling and performance signals that override them, so the decision rests on evidence instead of anxiety.

Bug density: the clearest quantitative signal you have

Of all the signals available to a founder without deep codebase archaeology, bug density is the most actionable. One source in this space sets specific bands: codebases with a bug density under roughly 15% respond well to refactoring, while codebases above roughly 40% are actively fighting the team, at which point a rewrite becomes the faster path to stability (Productera). Treat that range as a directional signal rather than a hard scientific cutoff, since no source in this research set supplies controlled study data behind it. What matters is the shape of the curve: below 15%, fixes tend to stay fixed. Above 40%, every patch tends to open a new defect somewhere else, which is the real tell that you are past the point where local repair works.

To measure this yourself, pull your last two or three months of closed tickets and calculate the ratio of bug fixes to total shipped changes. If that ratio is climbing release over release rather than holding steady, you are watching a codebase cross the threshold in real time, not looking at a one-time bad sprint.

Related Zenveus resource: Code Rescue insights.

Coupling and size: when the codebase resists change

Bug density tells you how much the codebase hurts today. Coupling tells you why it will keep hurting. A codebase that is fundamentally sound but merely messy is the classic case for refactoring: the architecture holds, and improvements to maintainability or readability compound safely over time. The danger sign is when a small change in one module forces edits in three unrelated modules, or when nobody on the team can confidently predict blast radius before touching a file.

Scale matters here too. One analysis notes that once a codebase grows into the hundreds of thousands of lines, teams typically shift from refactoring toward a full rewrite as the more practical path (TechTarget). Size alone is not disqualifying, but size combined with tight, undocumented coupling across a large surface area is what turns refactoring into an open-ended project with no visible end. A related framing puts it plainly: refactoring wins when the foundation is sound and the pain is local. If the pain is systemic and touches every subsystem, that is your signal to stop treating symptoms.

Test gaps and the AI-generated codebase problem

Test coverage is not just a quality metric, it is a decision-safety metric. Refactoring depends on the ability to make a change and immediately know whether you broke something. Without meaningful test coverage, every refactor becomes a rewrite in disguise, because you are rebuilding confidence in the code from scratch with every edit. If your test suite covers only the happy path, or does not exist at all, you do not actually have the option to refactor safely yet, regardless of how sound the underlying architecture looks.

This gap shows up constantly in codebases generated largely by AI coding assistants. The code often compiles, runs, and demos well, but was produced without the layered decision-making a human architect brings to error handling, edge cases, and long-term structure. That gap between what runs and what is production-ready is one of the most common patterns in AI-built software, and it is a major reason bug density and coupling metrics alone can understate risk in these codebases. A repository that looks clean on the surface can still fail every threshold above once you start writing tests against it. Before applying any of these thresholds to an AI-generated system, get an honest read on test coverage first.

Performance ceilings and the parallel-run safety net

Bug density and coupling describe pain you are already feeling. Performance and scalability ceilings describe pain that has not arrived yet but is guaranteed to. If the system cannot scale to support more users, or shows persistent lagging or crashing under real load, that is treated as an independent signal pushing toward a rewrite even when other metrics look tolerable (Medium/Nosrati). A codebase can pass a bug-density check and still be structurally incapable of handling the growth you are planning for, which is exactly the kind of failure that surfaces during due diligence or a product launch rather than during quiet development.

If your metrics point toward a rewrite, the safest execution path is not a hard cutover. Run the new system in parallel, keep the old one operating until the replacement is proven under real traffic, and never take the business offline chasing full feature parity on day one (Unico Connect). This is where teams doing platform engineering work earn their keep: the rewrite itself is rarely the risk, an uncontrolled transition is.