Tomas's wroclove.rb 2026 lightning talk from everaii. Frames Rails modularity as a recurring wroclove.rb theme (aspect-oriented programming, hexagonal architecture, etc.) and reminds the audience why modularity matters: human brains hold only 4–7 items at once, so complexity has to be tamed. Traces the lineage of modularity mechanisms — macros, subroutines, structured programming, 'Go To Statements Considered Harmful', modules, ADTs, OOP, FP functions, design patterns, package managers, microservices, modern module systems. All of them share one economic assumption that held until ~two years ago: code understanding and code writing are expensive. AI has made pattern recognition (understanding) and pattern reproduction (generation) cheap — but this produces torrents of spaghetti code that interact in weird, hard-to-trace ways and fail in novel modes. What is still expensive: code reviewing by humans, shipping code (staging + production + restarts), reverting, and above all downtime (every minute of outage has a quantifiable revenue cost and a trust cost for users who may not return). Conclusion: modularity techniques need to be re-prioritized around the things that stayed expensive, not the things AI made cheap.