Models name things by resemblance. You get Manager, Helper, Utils, and Data, sometimes twice in one change. Those names do not say what is allowed to call what. A week later the next prompt treats every file as public, because nothing in the names suggested a boundary.
Before you accept the change, rename the pieces you intend to keep. A function name should say the result. A type name should say the concept the rest of the program already uses, not a synonym the model preferred. If the project says “order”, do not accept “purchase entity”. Consistency is what lets the next prompt land in the right file.
Then mark the boundary in the ordinary way your language already has: what is exported, what is private, which package other code may import. Tell the model that boundary in the next prompt. “Call this function. Do not import the file beside it.” An unstated boundary will not survive the next generation.
If a module needs a paragraph to explain who may use it, the module is too large or the name is still wrong. Fix that before you ask for the next feature. Generated code is cheap to replace and expensive to grow in the wrong direction.