A high-traffic post went up this week on a Chinese tech community on evaluating code before AI refactoring. It's framed for programmers, but our read is that this methodology is worth borrowing for any manager weighing an AI-driven legacy system overhaul. The thesis in one line: "ugly code" doesn't mean "worth changing."

What this is

The post sorts code earmarked for overhaul into four buckets by call frequency and risk:

  • High-frequency zone: Called constantly, problems keep surfacing — prioritize refactor evaluation
  • Core zone: Touches money, permissions, data consistency — small-step refactor, write tests first
  • Low-frequency legacy zone: Rarely called, no near-term need — usually don't touch
  • Sunset zone: Already has a replacement or a defined retirement plan — don't sink major effort

The author's prescribed engineering flow: first have AI run a blast-radius analysis (callers, dependencies, side effects); then score seven-axis upside (comprehension cost, modification cost, test feasibility, etc.); then score seven-axis risk (behavior change, data consistency, rollback difficulty, etc.); only then decide whether to proceed. His specific warning: core code without stable test coverage is not a candidate for a big-bang rewrite — AI can't tell whether those weird branches are artifacts of historical compatibility.

Industry view

Supporters say the framework turns the itch to refactor from an emotional reflex into a verifiable, controllable engineering task. One architect in the comments put it bluntly: in the last decade he's watched too many projects die from "while-we're-at-it optimization."

But the pushback is real. First critique: over-evaluation is itself a cost. If every small change has to run through seven-axis upside plus seven-axis risk, early-stage teams can't move. The sharper second critique: the framework assumes enterprises already have stable test coverage as infrastructure, yet plenty of Chinese companies' core codebases have zero test coverage — apply the standard literally and almost no refactor is allowed, which means no refactor ever happens.

We also flag a quiet worry: the framework presumes behavior-preserving structural cleanup, but most refactors enterprises actually need in the AI era are precisely the ones that change business behavior — and the framework fits that case less well.

Impact on regular people

  • For enterprise IT: When a business unit pitches "use AI to refactor System X," step one is not project initiation — it's asking which of the four buckets the system falls into, how big the blast radius is, and whether test coverage is adequate. Skip those three questions and the budget is likely wasted.
  • For individual careers: The "evaluate first, then act" engineering culture is spreading into product and operations roles. The judgment call — being able to write with AI doesn't mean it's worth writing with AI — is becoming more valuable in itself.
  • For the consumer market: There's a clear gap between "AI one-click enterprise refactor" product marketing and what frontline engineers actually experience on the ground — a signal procurement teams should heed.