AI makes over-engineering look cheap.
Ask it to clean up one conditional and, five minutes later, you have an interface, three implementations, a factory, dependency injection and a diagram nobody requested.
The generated code can compile, pass tests and still add an abstraction the system doesn't need.
I hit the same problem building Hermes workflows. One research job might pull a transcript from YouTube. Another might need a browser, cached text or speech-to-text. The tempting move is to invent a grand "source strategy" framework before the second path is stable.
That usually creates a framework for variations I imagined, not variations the system actually has.
So I use a smaller rule: keep the caller stable, but don't promote every branch into an abstraction.
Before I approve an AI refactor, I run the Variation-Seam Check:
What variation exists in production today?
Can that variation change without the others changing?
What seam keeps the caller unchanged?
What test proves the behaviour survived?
What would make me remove this abstraction?
If the first two answers are vague, I leave the conditional alone.
If the branch is local, I keep it local.
If the same decision starts leaking into several callers, I contain construction behind one seam. Only when the behaviours start changing independently do I consider separate strategies.
The model doesn't have your production history. It can generate ten clean implementations before lunch, but it can't tell whether those behaviours actually change independently in your system.
The useful prompt isn't "Refactor this using the Strategy pattern."
Use this instead:
Show me the current variation, the callers it affects, and the smallest seam that keeps those callers stable. Do not introduce a pattern unless two behaviours already change independently.
You can add the hierarchy when the code gives you evidence for it. Removing one after it has spread through the codebase is considerably less entertaining.
If your AI coding tool invented an abstraction you later removed, reply with what it built and what the code actually needed.