Two Principles to Make AI‑Generated Code Easy to Maintain

Even as AI accelerates code production, developers still need code that is easy to understand, review, and hand over; maintainability, not just functional correctness, determines long‑term cost.

Why AI‑generated code is hard to read

Four common problems appear in AI output: the entry method loses its narrative role, multiple abstraction levels are mixed inside a single method, useless helper abstractions (Helper, Manager, Processor) are introduced, and defensive exception logic drowns the main flow. The code may run correctly, but maintenance effort skyrockets.

CMP – Composed Method Pattern

CMP (originating from Kent Beck’s *Smalltalk Best Practice Patterns*) requires the public entry method to contain only high‑level business steps, delegating details to private methods. Kent Beck likens the entry method to a book’s table of contents, with each private method representing a paragraph.

Example: AbstractApplicationContext.refresh() in Spring organizes the container startup into a clear sequence of steps (prepareRefresh, obtainFreshBeanFactory, registerBeanPostProcessors, etc.). The entry method shows the whole lifecycle at a glance, while each step’s implementation lives in its own method.

Extraction should be based on semantic independence: a method is worth extracting if it has a single business verb, a clear reason to change, and can be tested or reused independently.

SLAP – Single Level of Abstraction Principle

SLAP (described in Robert C. Martin’s *Clean Code*) demands that all statements inside a method stay on the same abstraction level. Mixing high‑level business flow with low‑level field checks or logging makes the code noisy and hard to follow.

Counter‑example: an AI‑generated registerUser method mixes validation, duplicate checks, entity creation, encryption, and logging in one 40‑line block, spanning four abstraction layers (business flow, rule checks, technical implementation, infrastructure calls). Readers must constantly switch cognitive granularity.

Refactoring with CMP + SLAP

Applying CMP to split the steps and SLAP to keep each private method at a single level yields a concise entry method of five lines and clearly separated private methods for validation, duplicate checks, user creation, persistence, and email sending.

Entry method: 5 lines, pure business steps.

Code review: structure visible at a glance instead of line‑by‑line.

Change location: directly jump to the relevant private method.

Why the principles matter more with AI

AI models naturally try to “complete” code, favoring longer, fuller implementations. Without explicit constraints, they replicate existing bad structures and amplify technical debt at generation speed. CMP and SLAP become the minimal structural guardrails needed to keep AI output maintainable.

Making AI follow CMP + SLAP

Embed structural constraints in the prompt (e.g., public methods only list business steps, keep a single abstraction level).

Generate a skeleton first (class responsibilities and method signatures), confirm it, then flesh out private methods.

During review, check structure before implementation details (entry method as a checklist, no abstraction jumps, no useless helper classes, exception handling does not break the main flow).

Codify the principles in team assets: coding standards, service‑layer templates, review checklists, SonarQube thresholds for cognitive complexity and method length, and automated ArchUnit checks for layer violations.

Conclusion

AI speeds up code creation but does not eliminate the need for human‑centric engineering fundamentals. CMP makes the main flow clear like a table of contents; SLAP keeps each method focused on a single level of abstraction. Together they form a practical structural guardrail that ensures AI‑generated code remains understandable, modifiable, and maintainable over time.