Skip to main content

Refactor code

Use this scenario when you need to improve the structure of existing code without changing its behavior: rename entities, split a large function or class, remove duplication, simplify dependencies, or prepare the code for the next change.

What to prepare​

  • name the code or module you want to improve;
  • explain which behavior must be preserved;
  • list the compatibility constraints, especially for the public API;
  • name the tests, the build, or the user scenario that will verify the work;
  • set an Edit Scope if the changes must stay within a specific part of the project.

If there are not enough tests, first ask the agent to identify the risky scenarios. For a large refactoring it helps to add tests that lock in the current behavior before you change the implementation.

Build a plan​

  1. Ask the agent to study the target code, its usages, and the related tests.
  2. State the structure you expect and what must not change.
  3. For a large change, start in Plan mode: break the work into small steps with a separate check for each step.
  4. Agree on whether changes to the public API, data formats, and configuration are allowed.

Example prompt:

Prepare a refactoring of this service without changing its behavior.
First find its usages and the related tests. Propose small steps, and for each
one state the risk and how to verify it. The public API must not change.

Make the changes​

Carry out the refactoring in small, coherent steps. After each step, run the narrowest check that confirms the behavior is preserved.

If a step involves renaming a class, method, field, or another symbol, ask Explyt to use the IDE refactoring rather than a text replacement:

Explyt can rename a symbol through the IDE refactoring and update the related declarations, usages, and imports.

Do not combine a structural change with unrelated formatting, dependency updates, or new functionality: such a diff is harder to review and to roll back.

Verify the result​

Open Agent Changes and make sure that:

  • the external behavior of the code has not changed;
  • the edits belong to the agreed goal;
  • declarations, usages, and imports remain consistent;
  • no duplicate or temporary implementations have appeared in the project;
  • the related tests and the build pass.

After a large refactoring, run a broader test suite and Auto Review. If the change touches the public API, check external consumers and backward compatibility requirements separately.

Definition of done​

The refactoring is complete when the structure of the code is closer to the agreed goal, the behavior is confirmed by tests or another reproducible scenario, the public contracts are preserved or changed deliberately, and the diff contains no unrelated edits.

The features in detail​

How Explyt performs safe renames through the IDE is described on the Symbol refactoring page. To find related places, use project search, and to verify the work, use IDE run configurations.

Related pages: