When AI Refactors Break Layering (And How to Prevent It)

In a previous post, I wrote about integrating AI into a Spring Boot system without compromising architectural boundaries: We can consider that the initial integration problem. There’s a second, more subtle problem: AI-assisted refactoring changes the risk profile of cross-cutting modifications. Not all “refactors” are created equal. Classic refactoring — in the Fowler sense — is local, behaviour-preserving, and structural, e.g. Extract method. Rename class. Move function. etc. Those are relatively safe when existing tests are solid. (In fact, I'd argue that developers are unlikely to attempt a refactor of any import on a production codebase larger than a few classes without automated tests in place. If they value their sanity, at least.) But many AI-generated “refactors” are not local or even of the Fowler variety. They are often cross-cutting changes: Add logging across the application. Introduce tracing. Add validation. Add retries. Add metrics. These can and frequently do touch mult