Why AI invents plausible, wrong conventions

The fat controller wasn't a mistake; it was a default

AI safety: review before copying ended with a controller action that awarded XP directly inside publish. It was valid Ruby and idiomatic Rails, and wrong for this app, which keeps business logic in service objects. Nothing about that suggestion was a bug in the AI. It was working as trained, and that's the problem this course fixes.

What "trained" means here

A language model's suggestions come from patterns across a huge number of public Rails codebases. Most of them don't use this project's service-object convention or its Identity::, Catalog:: and Enrollment:: namespaces. Most put logic wherever the tutorial they copied put it. Asked to write Rails code with no information about the app, a model reproduces the dominant shape across all of that, because that's the only signal it has.

The fix is more information, not a smarter model

A model that already knew this app's layer contract (controllers delegate to services, services return Result = Data.define(...)) wouldn't need to guess. It would have the specific answer in its context instead of an average standing in for one. That's the lever this course pulls: not making the AI reason better in the abstract, but putting this project's rules in front of it before it writes anything.

What this course covers

1. Mechanisms for giving an AI assistant a project's instructions, like CLAUDE.md and Cursor's rules.
2. Searching the codebase on demand, a different kind of context from a rules file, and how that has changed.
3. This project's MEMORY.md, a working instance of the idea in this codebase.
4. What makes a rules file something an AI follows instead of prose it skims.
5. Why a context file goes stale, and what that costs.
6. A wrap-up, and what's still needed even with perfect project context.

By the end, "the AI didn't know any better" stops being an excuse. It didn't know because nobody told it, and telling it is a specific, doable thing.