Markus Schirp's wroclove.rb 2019 conference talk, held the day after his mutation-testing workshop. Frames mutation testing as a 'derived check' that mechanically applies transformations to code to surface unspecified semantics, which a human must then remove or cover with an additional test. Walks through Mutant's nomenclature: subject (instance/class method that has tests and can be mutated), match expression (recursive enumeration, class scope, specific instance/singleton method), selection (process of picking the corresponding tests using RSpec describe/context metadata or explicit coverage declarations in minitest), mutation operator (semantic-reduction operators and auto-color replacements), and mutation (alive = red flag; dead = covered). Lists preconditions for any test suite: green tests, idempotent tests, random-order-runnable, concurrency-hard, carrying selection metadata, and discoverable subjects — all of which Rails challenges (auto-loading hides subjects, shared DB state breaks idempotency and ordering, etc.). Advocates incremental mutation testing as the pragmatic way to introduce Mutant on a large existing codebase, only analyzing subjects touched in the current PR. Q&A covers: whether to use it on every project (yes, human time is the most expensive resource), CI integration via a top-level namespace match expression in incremental mode, using Mutant as a complexity metric and a refactoring guide, equivalent mutations (rare; often reveal weak library semantics that can be upstreamed), and experience with mutation testing in other ecosystems (originated for Schirp with the Haskell Heckle tool while working on DataMapper 2's axiom relational-algebra engine).