AI code refactoring: automation, security, speed

Legacy codebase: where AI code refactoring gets stuck

The most expensive breakage in legacy code looks mundane: a change to one condition in a calculation module triggers rebuilding reporting, exchange with external systems, and an overnight recalculation of balances.

The change itself takes hours, while verification takes the entire release cycle, because no one keeps the complete list of affected places in their head.

The root cause is module coupling and hidden dependencies. Tax logic is duplicated in three places, state changes from event handlers bypassing the data access layer, and some calls go directly across layers.

Static analysis at the SonarQube level will show duplicates and long methods, but it will not show that removing a “dead” branch breaks calculations with clients — that knowledge lives with two engineers and leaves with them.

Technical debt here is measured not in lines, but in the cost of change: the share of edits affecting more than five files grows, and the share of edits with a predictable result falls.

This is exactly where AI code refactoring gets stuck — the model confidently rewrites an individual file but does not see the system: without a dependency map, any “improvement” either changes nothing or reproduces the same coupling in new syntax.

We break down how this is closed: first a map of connections and duplicates across the repository is built, then the change is sliced into steps, each of which is verified by tests and can be rolled back.

Build speed, class of eliminated failures, rework time

The effect of refactoring is measured not by “it became cleaner,” but by four numbers: build time, time to run checks, the number of echo edits per hundred changes, and the share of releases with rollback.

We take these values before the start and repeat them after — otherwise the conversation about code quality remains a matter of taste and cannot be defended at the planning meeting.

The first class of failures that goes away is null dereferences, races during concurrent writes to a shared cache, and unhandled exceptions in async calls.

We build analysis rules for the project manually: default rulesets in SonarQube produce a lot of noise, and the team gets used to skimming the report without reading it. A configured ruleset cuts off these defects before branch merge, not during incident triage.

Build time and check time fall by removing duplicate logic and dead branches: the build is reduced from 18 to 7 minutes, and the test run from 40 to 15, because the suite stops running unused paths.

We raise test coverage for changed code from one third to two thirds — regression is caught before release, not on rollout day.

Rework time is consumed by echo edits: the same bug lives in five copies of a function and is fixed five times in different places. After extracting shared modules, the fix is made once, not in four places.

Release stability grows as a consequence: the rollback rate falls threefold, hotfixes in prod cease to be a regular practice, and planning of the next iteration does not fall apart.

Automation modes: batch analysis, chunked, hybrid

The choice of mode is determined by two properties of the codebase: size and coupling. If modules exchange data through shared structures and dozens of call sites, edits cannot be made in isolation — first we fix the boundaries of changes and the order of their application.

Below is a comparison by the criterion “when suitable / limitations,” which we use at the assessment stage.

In practice, we most often start with batch analysis on peripheral modules: it quickly shows where coupling is higher than expected and refines the dependency map. Then the tightly coupled core goes into chunked processing, and the rest is picked up by incremental edits.

Such a hybrid mode gives a predictable chunk size for review — the reviewer sees one logically coherent block, not a hundred scattered lines.

How work is structured: from repository analysis to handover

Model-assisted refactoring starts not with edits, but with inventory: while there is no dependency map and module boundaries, any automatic change affects adjacent code.

Therefore work proceeds in stages, and each ends with an artifact that can be checked before moving to the next.

1. Repository audit. We look at the structure, change history, duplicate areas, and what tests cover. The output is a list of risk zones: where edits will have an effect and where touching the code is more expensive than leaving it.
2. Dependency map. We build a graph of connections between modules and external libraries, mark cycles and implicit connections through shared state. The map sets the order: isolated modules first, then the periphery, core last.
3. Check rules. We fix what counts as a correct change — style, error handling, ban on certain constructs. Rules are placed into linters and the build so that an edit is rejected automatically, not at review.
4. Chunked edits. Changes are made in small batches, each chunk has one goal. Review remains manageable, and a failed chunk can be rolled back without analyzing the entire scope.
5. Acceptance checks. We run tests and compare behavior before and after on control scenarios. If coverage is insufficient, we first add tests for the affected paths.
6. Handover. We hand over the scheme, check rules, chunk log, and list of what was intentionally left out of refactoring.

After that, your team works by the same rules on its own — without depending on us.

What remains in the repository and documentation after handover

Automated refactoring delivers results only when the team continues to change code without the original authors of the edits.

Therefore handover is not a set of changed files, but a working environment: rules for bringing code to a uniform style, module boundaries, and procedure for failure. What exactly remains in your hands:

• Rule configuration — settings files for static analysis and auto-fixes with an explanation of why a rule is enabled or disabled and what exceptions are made for legacy code.
• Module scheme — map of connections between components: where boundaries are drawn, which dependencies are allowed, which are considered violations and fail the check.
• Review regulations — what the author of a change checks, what automation checks, which discrepancies block merging, and who makes decisions on disputed cases.
• Rollback instructions — step-by-step return of a branch to previous state with compatibility check of data schema changes and without losing accumulated edits.
• Interface documentation — behavior of public functions on errors and list of places where automation was intentionally not applied so they are not rewritten blindly.
• Coverage report — which paths are covered by checks, which remain without them and why.

All this lies in the repository next to the code and is updated by the same checks — otherwise instructions become outdated faster than they can be read.

Case study: refactoring a payment module without stopping the product

The payment module is the place where an edit costs the most: charges, refunds, and reconciliation with providers go through it, and an error is immediately visible to the client.

Before the start, we took baseline measurements: response time for typical operations, failure rate from logs, complexity of key functions, and what part of the code is covered by tests. These numbers became the reference point — the result was compared against them.

Before: where exactly it hurt

The main scenarios lived in one long function with branches for each payment method and refund type.

An edit in one place affected neighboring ones, any change required a manual run of the entire module, and measurements showed that about one third of the logic was not covered by automated checks.

After: measurements and absence of regressions

We edited in chunks: first payment, then refund, then provider notifications. Each chunk was enabled with a toggle on live traffic — the new and old branches calculated the same operations in parallel, and results were compared line by line.

After delivery, the complexity of key functions dropped by about half, response time decreased almost threefold, and test coverage grew from one third to almost complete.

There were no regressions: they were caught by a set of checks on historical operations, a parallel run of two branches, and gradual switching by traffic shares.

Checksums for the payment log were reconciled line by line — a discrepancy in one record returned the previous version. Measurements were taken with the same tools as before the start: SonarQube — complexity and coverage, internal monitoring charts — latency and failure rate.

What to do if the project has no tests and no clear documentation?

Edits in a project without tests run into one thing: it's unclear what counts as working. Formally the task is solved, but whether something broke on an adjacent path, no one can say.

Therefore the first step is not rewriting code, but capturing the behavior that the system currently produces.

Capture proceeds from the observable, not the desired.

We run real scenarios on a copy of the data, capture inputs and outputs of public modules, and write characterization checks that describe the current behavior as is — including strange branches, rounding, and handling of empty values. Such checks do not claim correctness of the result; their task is to notice that it has changed.

In parallel, a description of the system is assembled: module map, call directions, places where data changes, external dependencies and side effects. The model speeds up this work — it reads the code and the draft map, while the engineer checks each branch on a live call.

The document turns out short and to the point: not a retelling of the code, but module boundaries and agreements between them.

Next is the order of edits. We change one area at a time, from periphery to core, and after each step we run the accumulated set of checks. Control points are placed where the change is visible externally: response to a request, write to storage, sent event. If a check turns red, rollback to the previous state takes minutes, not hours of analysis.

By the end of the stage, the project stops being a black box: there is a set of checks for the current behavior, a brief description of the system, and control points.

This is the safety net after which AI refactoring and edit automation cease to be a risk — any change is visible and can be rolled back.

Technical doubts: security, privacy, rollback of changes

Engineers rightly ask what happens to the repository when automatic refactoring is connected to it. The agent does not touch the production branch: it works in an isolated environment on a copy of the code, access is granted by short-lived tokens scoped to one repository. Requests and commands are logged the same as for a regular engineer.

Edits come as separate change sets, not as a commit to the main branch.

Each set passes automated tests and static analysis, changes are split into small steps with a clear description — both an individual edit and the entire series can be rolled back, without rebuilding the release. Below are three doubts most often voiced at the start.

Can a series of edits be rolled back?

Yes. Refactoring is broken down into atomic steps, so both an individual edit and the entire series can be canceled. Tests and build at each step show the point where the system's behavior diverged from the expected.

Who is responsible for regressions?

We fix the boundaries before the start: which modules we touch, which contracts we consider unchanged, and which checks we use to confirm behavior. We close an uncovered area with a test before the edit — the change does not proceed further if behavior is broken.

Let's discuss the task: what to send to get an estimate and plan

To come back with a work estimate and work plan, full access to the code is not needed — at the first step, the input data usually at hand is enough. They show the scope, the class of tasks, and where automation will pay off and where you will have to go manually.

It is important to discuss access restrictions in advance: both the work scheme and timelines depend on them.

• Code structure: directory tree, largest modules, where the main logic is concentrated and where dependencies converge.
• Scope and state: number of files, areas that have not been touched for a long time, share of code not covered by checks.
• Frequent edit locations: files that change most often — there refactoring pays off fastest.
• Project rules: accepted style, linters, change review regulations, what must not be changed under any circumstances.
• Access restrictions: whether work can be done on a copy of the repository, whether there is an isolated environment, what data is prohibited from being taken outside it.
• Two or three typical tasks: examples of edits you would like to speed up — we use them to align expectations.
• Goal: speed up release of changes, reduce the number of defects, or prepare migration to another development branch.

Then discussion of the task takes one conversation: we ask clarifying questions, check restrictions, and come back with a timeline estimate, breakdown by stages, and a clear readiness criterion. Describe the task and send the input data — that is enough to start.