I think we are using "autoload" to discuss different things, one of which is probably in line with what the article is about, and the other is not. And I may b

I think we are using "autoload" to discuss different things, one of which is probably in line with what the article is about, and the other is not. And I may be the one misreading here! I take "autoloading" in the Rails context to mean "Rails.application.config.autoload_paths", which is separate from a Ruby "require", and which has always had all sorts of complexity, but is supposed to be recommended against as of Rails 6. You are, I believe, referring to "require" call to load a library once (which is what Bundler does). The Rails autoloading (once homegrown, now via zeitwerk) is used to hotswap to a new version of a constant when a file has changed. It does so by searching for missing constants on the file system based on "root paths", in this case using "config.autoload_paths" plus a few defaults. This hotswap nature of autoloading is why I reference autoloading a library specifically in the context where one is "actively working on it, and autoloading allows quick feedback loops". A simple "require" does not do that. It loads the library once, ala Bundler, and unless it lives in the tree of an autoload "root path", changes will not be available until one restarts the server/console/rake task, etc. I agree that, of course, that one's libraries ought to be loaded via "require" to be used. Otherwise, they are dead code, and might as well not be part of the project source. My suggestion of an ENV var is that it should swap from a single require at application boot to live autoloading.