AI changes the cost of producing code. It does not remove the cost of understanding, operating, or changing that code. Established engineering principles become useful review instruments—not decorations added to a prompt.
SRP: ask who makes this change necessary
The Single Responsibility Principle is more precise than “one function does one thing.” Consider our graph index and our visual cards. A rule about valid relationships should not require editing the card layout. A typography change should not change graph membership.
Ask an assistant: which unrelated reasons to change are coupled here? Then inspect whether the proposed split reduces that coupling. Ten tiny files can be harder to maintain than one cohesive module.
SOLID: review contracts, not class counts
The rest of SOLID raises questions about extension, substitution, interfaces, and dependency direction. A provider adapter that returns similarly shaped JSON is not necessarily substitutable: privacy, failure behavior, and tool semantics can differ.
Ask for behavioral tests before a refactor. Avoid generating an abstraction hierarchy just because a prompt mentions a principle.
DDD: settle the language before generating the model
Domain-Driven Design starts with meaningful language and boundaries. In this project, Hugo Web is the personified identity; Builder is an audience role; the website is a system. Those distinctions are real modeling work. A generated folder structure cannot substitute for them.
AI can find inconsistent vocabulary and suggest candidate boundaries. The builder still decides which distinctions reflect the domain.
Patterns: name the pressure that makes one useful
An Adapter can keep Hugo storage conventions separate from portable node meaning. A Strategy can make actual algorithm variation explicit. Neither is a reason to invent future requirements.
The Gang of Four catalog is a vocabulary of recurring solutions and consequences. Ask the assistant to explain the simpler alternative and why it fails the actual requirement before adopting a pattern.
A better review prompt
Identify one concrete source of coupling in this change.
Explain the requirement that makes it a problem.
Compare the smallest fix with a pattern-based alternative.
Propose tests that preserve the existing behavioral contract.
Do not change code until the proposed scope is approved.
The goal is not to make AI-generated code look sophisticated. It is to make the result easier for a builder to understand, trust appropriately, and change.