I published a new Ask Good Questions guide and companion field note that may be useful to anyone using AI on larger programming projects.
Guide:
https://askgoodquestions.dev/guides/do-not-let-ai-build-the-elephant-in-the-room
Field note:
https://askgoodquestions.dev/field-notes/the-elephant-does-not-walk-into-the-room
This one is about a very ordinary problem that AI can make worse if we’re not careful.
A project starts with a reasonable structure. The files make sense. The responsibilities are mostly clear. Then you ask the AI to add a feature, fix a panel, add a mode, handle one special case, and then another.
Each change may be reasonable.
Each change may even work.
But over time, one file can become the unofficial center of the application. It starts out as a component, then becomes a component plus state manager, then a component plus state manager plus parser, plus export logic, plus platform-specific behavior.
That is the elephant in the room.
The guide looks at this from the practical side: file size, design drift, full-file replacement, living architecture notes, and scheduled structural reviews.
There is also a review prompt in the guide that can be adapted for your own projects. The point of the prompt is to make the AI stop and analyze the structure before it starts changing code.
The field note is the more personal version. It is about the moment when you realize the file did not become unmanageable because of one terrible decision. It got there one small, reasonable shortcut at a time.
One line from the article sums it up:
The elephant doesn’t appear by magic. You build it.
If you’re using AI in your own development work, I would be interested in whether you are doing any deliberate codebase structure reviews, or whether you mostly review the immediate changes the AI makes.