AI-assisted refactoring without losing product intent | Rizwan Saleem

AI-assisted refactoring without losing product intent

Refactoring is not only a code-cleanliness exercise. In frontend engineering, refactoring can change how people experience a product: how quickly a screen becomes useful, how a form explains failure, how a loading state reduces uncertainty, and how accessible the interface remains when something unexpected happens.

That is why AI-assisted refactoring needs more than a prompt that says “make this cleaner”.

Cleaner code is useful, but not if the new version silently removes product intent.

A component usually contains more context than its syntax shows. Some of that context is obvious: props, state, validation, API calls, and rendering branches. Some of it is hidden in the history of the product: a condition added because real users got confused, a loading state added because a financial action felt risky, an error message added because support saw the same issue repeatedly.

AI can help with structure, naming, simplification, test ideas, and alternative implementations. But the engineer still has to protect the things the model cannot fully know.

Before asking AI to refactor frontend code, I like to make the intent explicit:

• What user problem does this component or flow solve?
• Which states are business-critical?
• What can fail?
• What should be visible to screen readers?
• What should happen while data is loading?
• Which behaviours are relied on by users, support, or compliance-heavy product flows?

This is especially important in fintech and open banking interfaces, where frontend decisions are often trust decisions. Consent screens, transaction states, permissions, error recovery, and account-connection flows should not be treated as visual details. They are part of the product contract.

A safer AI-assisted workflow looks like this:

1. Document the current intent.
   
   Write a short summary of what the code is supposed to protect before asking for changes.

2. Ask for options, not one rewrite.
   
   A few alternatives make trade-offs easier to compare.

3. Review the diff against behaviour.
   
   Do not only ask whether the code is shorter. Ask whether loading, error, empty, disabled, and accessibility states survived.

4. Add or update tests around user outcomes.
   
   TypeScript can catch many mistakes, but product trust also needs behavioural tests.

5. Keep the final decision human-owned.
   
   AI can accelerate mechanical work, but the engineer owns the context, risk, and release decision.

Used well, AI can make frontend refactoring faster and more deliberate. Used carelessly, it can make teams overconfident while removing the small behaviours that made a product reliable.

The goal is not to avoid AI. The goal is to use it with engineering judgement.

I am Rizwan Saleem, a UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder. My core line is: “I was not born with a way out, so I built one.”

More about my work: https://rizwansaleem.co