In some other comments somebody wrote about method_missing and ActiveRecord callbacks. Days ago we had a post about a state machine gem.

Leave method_missing to the inner workings of gems. Do not use it in your code. Even in gems, hide them well. Rails used to have auto-generated find_by_field1_and_field2 methods, by method_missing if I remember well. They eventually moved to where(field1: value1, field2: value2) and we are fine with that.

ActiveRecord before and after filters are just callbacks like many libraries have, in any language. They need discipline because of the obvious problems we can run into if we add a ton of code to the callback system, possibly with side effects and multiple definitions of the same callbacks in classes derived from a common model. That's actually a very bad code smell (and a broken architecture?) and something that we could be tempted to do but we learn not to do. I use them very sparingly. The whole validation system is a particular case of before save callbacks. I think that every ORM for every language has got a validation system.

Another case of callbacks are the ones for the state changes of finite state machines. We can define them with function pointers in C structs or with symbol names in Ruby, they are the same thing. The triggers for state changes: same thing.

If I can choose I go with the more explicit alternative because... Finally I confess that I lose time when reading some new code bases to understand if some object.something is an attribute, a method, a state machine callback or something else auto-generated by some other gem. I think that LSP servers have a very bad time following those methods and probably none of them do. Maybe heuristic in IDEs can do something about it.

If I feel that I would be in trouble there, I add a short comment explaining the origin of the method: "this is from gem XYZ", then the docs will explain how and why to the next developers. Maybe they will thank me.