Day-two talk at wroclove.rb 2018 by Ivan Nemytchenko, continuing 'Counterintuitive Rails pt. 1'. Opens by reviewing the audience survey collected in part 1 (82 respondents): 66% happy with Rails; 82% use additional layers/building blocks vs only ~20% using frameworks on top of Rails; services and POROs dominate 'non-BC' classes; half use callbacks; most use form objects at least a bit; 40% like Devise while 36% consider it evil. Walks through concrete techniques: (1) replace default-setting and external-service callbacks (e.g. a geocoder gem) with Active Record constructor defaults and a dedicated mutators layer handling creation/editing/deletion as atomic operations, leaving services for business logic and external calls; (2) build form objects as a concern of the model that adds delegators plus extra validations/attributes (e.g. ModerationArticleForm) — 'dirty hack' that plays nicely with nested attributes and matches the controller namespace hierarchy; (3) avoid boolean flags (e.g. flag_shih_tzu) for representing state because N flags combinatorially yield 2^N implicit states — use state machines instead (one or several per model); (4) replace view-level `if current_user` checks with null objects (Guest class responding to the same methods, returning stubs), including a small gem written during a workshop that auto-stubs undefined methods to nil or empty arrays; (5) extract scopes into a concern to keep models clean while Rails still sees them inside the class. Summarizes the layer purposes: models hold associations, business rules, state machines, defaults (no IDs); mutators handle persistence-level creation/edit/delete; services handle business logic and external-service/job orchestration; controllers handle application logic (form fields, sessions, flash, redirects). IDs cross layers only when triggering jobs. Closes with a pragmatic testing philosophy: maximum ROI comes from controller tests touching every endpoint; unit-test core services/mutators; prefer minitest over RSpec (overvalued semantics, fragile custom matchers — consider power_assert); prefer fixtures over factories (faster, support cross-references, loadable into the dev DB); prefer stubs over mocks (mocks test the structure, not the behavior). Final message: stop deferring decisions to popular libraries and 5k-star GitHub authors — develop your own reasoning. Promises practical take-home tasks (services, mutators) for email signups, and notes this talk should let him finally finish his book.