Automated code refactoring: shrinking technical debt with verified fixes

Technical debt consumes a large share of the time an engineering team already has. Developers spend more than 17 hours per week on maintenance work such as debugging, refactoring, and modifying bad code, according to Stripe's Developer Coefficient research. That breaks down to 42% of the average work week spent on debt and bad code, with 13.5 hours on technical debt alone. A separate Swedish longitudinal study by Beskow, Martini, and Bosch measured 23% of working time wasted on debt, roughly one full day per week.

The same drain shows up in budgets. Around 40% of the average IT department's spend goes to maintaining technical debt, per the Software Improvement Group. McKinsey research cited in the same analysis found that 10 to 20% of budgets meant for new product development get redirected to handling debt instead. Enterprises fare worse than smaller shops, dedicating 41% of IT funds to debt versus 27% at small companies.

Those numbers explain why backlogs grow rather than shrink when nobody touches them. A bug that costs roughly $100 to fix during planning can cost about 100 times more once it becomes embedded technical debt, per a Forbes-cited example in the Software Improvement Group analysis. Cost compounds because each unfixed issue attracts more code built on top of it, and every layer added makes the eventual fix touch more of the codebase.

The compounding effect turns a small deferral into a structural problem. A duplicated function copied twice becomes three places to change when the logic shifts. An oversized function nobody split grows another branch each sprint until reading it takes an hour. The debt that looked cheap to ignore at the point of writing becomes the most expensive line item to remediate later, which is exactly why manual fixing struggles to keep pace with the work being added.

Why manual refactoring backlogs never shrink#

Refactoring backlogs never shrink because refactoring and feature work draw from the same pool of developer hours, and feature work has a shipping date attached. A maintainability issue can sit untouched for months with no visible consequence, so it loses every prioritization contest to work that has a deadline and a stakeholder. Better backlog grooming does not change the outcome. The competition itself is the problem, not the discipline of the people running it.

The volume of code that needs attention keeps growing while the effort spent cleaning it falls. GitClear's analysis found copy-pasted lines rose from 8.3% in 2020 to 12.3% in 2024, a 48% relative increase, while moved and refactored lines dropped from 24.1% to 9.5% over the same period (Rockstar Developer University). Within a single commit, copy-pasted code exceeded moved code for the first time on record, and churn climbed to 7.1% from 3.3% in 2020. More duplication enters the codebase each year, and less of it gets consolidated.

AI-assisted coding widens the gap because it accelerates the side of the equation that produces debt. Google Cloud's 2024 DORA report found that as AI adoption increased, delivery throughput declined an estimated 1.5% and delivery stability dropped an estimated 7.2%, even though more than a third of respondents reported real productivity gains (Rockstar Developer University). More than 75% of respondents said they rely on AI for at least one daily task, and 39% reported little to no trust in AI-generated code. Teams ship more code faster and clean up less of it, which is the exact condition that grows a backlog.

Manual grooming cannot close a gap that widens every sprint, because the fix and the feature always compete for the same hours and the feature wins. The remedy has to remove refactoring from that contest entirely. Automation that verifies a fix before proposing it lets remediation run continuously in the background, independent of the hours a team spends shipping features.

What safe automated refactoring requires#

An automated refactoring tool has to clear two separate bars before a fix reaches a human reviewer. The first bar is detection, which means finding a real issue in the code rather than a stylistic preference. The second bar is remediation, which means proposing a fix that provably preserves behavior against the existing tests. A tool that finds real problems but proposes broken fixes fails the same way as one that never finds anything.

Unverified language models clear the first bar far more often than the second. In the ACE benchmarking study across more than 100,000 real-world code health issues in OSS repositories, the best-performing out-of-the-box model produced functionally correct refactorings only 37% of the time (arXiv). A refactoring that changes behavior is not a refactoring. It is a defect wearing the clothing of a cleanup, and it costs more to catch in review than the original debt cost to carry.

Validation closes that gap. After ACE discarded outputs that failed its checks, 98% of the remaining refactorings improved code health while preserving behavior, raising precision from 37% to 98% at a recall of 52% (arXiv). The tool proposes fewer fixes and keeps the ones that hold. Recall drops because the guardrails throw away roughly half the candidates. That trade favors the reviewer, who now reads fixes that already survived a behavior check instead of triaging a pile of plausible-looking breakage.

Independent studies report the same failure rate under different names. EM-Assist found that 76.3% of model-generated extract-method suggestions were hallucinations, even while 24% of attempts yielded valid, useful ones (arXiv). Liu et al. reported that GPT-4 detected 86.7% of real refactoring opportunities across 20 Java projects, yet 7.7% of its proposed refactorings introduced errors. Shirafuji et al. showed that a validated few-shot approach produced at least one test-passing solution in 95.68% of attempts, cutting cyclomatic complexity by 17.35%.

The pattern holds across every study. Detection is strong. Remediation is unreliable without a validation step that runs the tests and discards anything that changes behavior. Any tool that proposes a refactor a developer will merge has to run that check first, not leave it to the reviewer to find the break after the fact.

How Hyrax verifies and ships refactors: the Improve workflow#

Hyrax's Improve workflow verifies every fix against the codebase's tests before proposing it, which meets the verification bar that unvalidated LLM refactoring fails to clear. CodeScene's ACE benchmarking found the best out-of-the-box model produced correct refactorings only 37% of the time, rising to 98% precision after validation guardrails discarded incorrect outputs (arXiv). Improve applies the same principle. A fix that cannot demonstrate preserved behavior against the existing test suite is discarded, not surfaced.

Improve runs one review pass across six domains rather than six separate scans. Security, correctness, maintainability, performance, architecture, and operations each carry their own class of issues, and a single pass covers all of them. Dead code and duplication sit under maintainability. Oversized functions and unclear control flow surface there too. Layering violations register under architecture. A team reviewing the results reads one coherent set of proposed changes instead of stitching findings from disconnected tools.

Verified before proposed, never auto-merged#

Every fix Improve produces ships as a pull request, and none of them merge automatically. The workflow verifies a change against tests first, then submits it for human review like any other contribution. An engineer reads the diff, checks the reasoning, and decides. Hyrax closes the gap between finding an issue and proposing a provably safe fix, and it stops there by design. The merge decision stays with the reviewer.

The never-auto-merged stance answers the core risk of automated refactoring. Liu et al. found GPT-4 detected 86.7% of real refactoring opportunities across 20 Java projects, yet 7.7% of its proposed refactorings introduced errors (arXiv). Detection without verification puts broken changes in front of reviewers. Improve verifies against tests before a fix reaches the pull request stage, so the proposals an engineer reviews already carry evidence that behavior held.

Reviews all code, not just AI-written code#

Hyrax reviews all code in the repository, regardless of who or what wrote it. AI-written code needs review, and GitClear's churn data shows why, but legacy code carries the deepest debt and the oldest layering violations. A workflow that inspected only recent AI output would miss the functions written years ago that now consume the most maintenance time. Improve reads the whole codebase and proposes fixes wherever a domain check finds a real issue with a verifiable remediation.

That combination defines the stance. Improve finds issues across six domains in one pass, verifies each proposed fix against tests, ships the result as a pull request, and leaves the merge to a human. The verification bar established earlier becomes the mechanism, not an aspiration.

Where Sonar fits alongside automated fixing#

Sonar and Hyrax do different jobs, and a team running both gets full coverage. Sonar measures technical debt. It scans the codebase, quantifies what exists, and reports how much of it there is, which matters because only 7% of organizations systematically track technical debt at all (arXiv). A measurement tool answers the question of where debt lives and how bad it is.

Hyrax remediates what measurement finds. It runs autonomous code review and fixing, and it submits verified refactors as pull requests. Measurement points at a problem. Remediation closes it. A dashboard showing 5,500 estimated remediation hours per million lines of code (Rockstar Developer University) tells a team the size of the backlog, not how to shrink it.

The two functions sit next to each other, not in competition. A falling debt score means nothing if the underlying code still fails its tests, so the measurement should stay independent of the fixing. Hyrax reviews all code and verifies every proposed fix against tests before submitting the pull request, so the fix that reaches a reviewer already preserves behavior.

Hyrax runs its own review across all six domains and produces its own fixes. A team keeps Sonar for the count and adds Hyrax for the close.

Getting started: rolling out automated refactoring on an existing codebase#

Start where the debt is already measured and worst. If a tool like SonarQube reports the highest concentration of duplication, oversized functions, or dead code in a specific module, point automated refactoring at that module first. A 2023 study by Lenarduzzi et al. comparing six measurement tools across 47 Java projects found low agreement between them and many false positives (arXiv), so treat measurement as a map of candidates, not a final verdict. Verified fixes settle which candidates were real.

Review the proposed pull requests like any other contribution. Hyrax runs the Improve workflow, verifies each fix against the tests, and submits it as a PR. No fix reaches the branch without a human approving the merge. The first batch teaches the team what verified refactors look like in practice, and the review load stays familiar because the format matches every other PR the team already handles.

Expand domain coverage as trust builds. A first rollout might stay inside maintainability, closing duplication and dead code where the risk of surprise is lowest. Once the team has merged a run of clean PRs there, correctness, performance, security, architecture, and operations become sensible next steps. Each domain adds a class of issues Hyrax finds and fixes across all code in the repository, not only AI-written code.

Access starts with the Free plan, which runs on credits and lets a team point the Improve workflow at one problem area before committing more of the codebase. The Paid plan adds credits for wider, ongoing coverage as the backlog shrinks. Both give engineering leads a way to introduce verified automated refactoring alongside active feature work, without pulling developers off the roadmap to grind through the backlog by hand.

FAQ#

Does automated refactoring risk breaking behavior? Unverified LLM refactorings break code often, with the best out-of-the-box model producing functionally correct results only 37% of the time in ACE's benchmarking study. Hyrax verifies every fix against the existing tests before proposing it, so a change that alters behavior never reaches a reviewer. Behavior preservation is a precondition for a fix to become a PR, not an outcome the reviewer checks afterward.

How is a fix verified before it's proposed? Hyrax runs the codebase's tests against the proposed change and discards any refactor that fails or alters behavior. Validation guardrails in the same ACE research raised precision from 37% to 98% by rejecting incorrect outputs. Only verified fixes are submitted as PRs.

Does Hyrax replace or duplicate Sonar? No. Sonar measures debt and reports what exists and how much. Hyrax remediates it by submitting verified fixes as PRs, so the two functions run side by side.

Does Hyrax only review AI-generated code? No. Hyrax reviews all code in the repository, whether written by a person or generated by an AI coding assistant. The Improve workflow covers security, correctness, maintainability, performance, architecture, and operations in one pass.

Who merges the resulting PRs? A human reviewer does. Hyrax submits pre-verified fixes as PRs and never auto-merges them, so every change clears the same review any contribution receives before it reaches the main branch.

Verification changes the economics#

A fix that passes the tests before it reaches a reviewer stops competing with feature work for the same hours. Hyrax reviews all code across six domains, verifies each proposed change, and submits it as a PR for a human to merge. The backlog shrinks with every pass instead of growing between sprints.

Hyrax makes your code better. Ship clean code.