AI safety: review before copying
This course builds a four-question checklist for reviewing AI code suggestions in a Rails app before accepting them. Separate lessons cover each question: whether a suggestion does what was asked, adds a security issue, duplicates existing logic, or breaks this codebase's conventions. Examples include an unscoped uniqueness validation, a create action fixed with permit!, an inline published query, and a controller holding business logic. A worked example on an Article predicate applies all four questions by reading the code and tracing inputs by hand.
What you'll learn
- ✓Why fluent, idiomatic AI code can still enforce the wrong rule
- ✓Checking a suggestion against the exact wording of the request
- ✓Spotting mass assignment risks such as permit! in AI fixes
- ✓Keeping one definition of a rule on the model, such as a published scope
- ✓Comparing suggestions with this project's layer contract and service object pattern
- ✓Tracing edge inputs by hand, such as a draft with nil published_at
Plausible but wrong: the AI review problem
An AI assistant suggests a validation, a query or a whole controller action, and every line reads like something a competent Rails developer would write: tidy indentation, the right method names, the usual Rails idioms. None of that tells you whether the code is correct. A language model's fluency…
Read the full lesson free →Curriculum
7 lessonsPlausible but wrong: the AI review problem
Explains why fluent, idiomatic AI code can still be wrong and introduces the four review questions.
Does it do what was asked?
An unscoped uniqueness validation blocks reused titles across authors; scoping it to author_id enforces the requested rule.
Security check: mass assignment and AI suggestions
A create action passing raw params crashes, and the permit! fix lets every key through, including admin.
Duplicate logic check: single source of truth
An inline published_at query duplicates Article#published?, so naming the rule once as a scope keeps both aligned.
Matching your codebase's conventions
A publish action with a raw find and business logic breaks this project's layer contract; a service object fits.
Worked example: a subtly wrong Article check
Tracing a draft with nil published_at through all four questions exposes a crash and duplicated logic in evergreen?.
Putting it together: the four-question review
Reviews the four questions and shows how the evergreen? example failed two of them at once.