Episode Summary
Executive Summary: The episode explores whether AI-written code will make formal verification mainstream, concluding that heavyweight formal methods remain too costly for most software, but lightweight approaches like property-based testing and selective modeling can meaningfully improve correctness. Hillo Wayne explains formal methods, TLA+, Alloy, and industry use cases, argues software engineering is broadly real engineering, and says AI is useful for specs and debugging but weak at inventing good properties.
Main Topics: Software engineering as real engineering: Hillo's crossover project compared software to civil, electrical, chemical, and mining engineering, finding shared tradeoffs around planning, iteration, and error cost. He ultimately moved from doubting software as engineering to concluding it largely is engineering. Formal methods: what they are and why they matter: The discussion defines formal methods as writing explicit specifications and proving code or models satisfy them for all cases, using examples like max over a list. The core value is making implicit assumptions explicit and checking them mechanically. When formal verification is practical: Heavy formal verification is reserved for high-stakes, technically constrained domains like kernels, cryptography, databases, and distributed systems. For most business software, the cost and context explosion make full proofs impractical. TLA+, Alloy, and model checking in practice: Hillo demos TLA+ for distributed-system state exploration and Alloy for finding static-model counterexamples. TLA+ brute-forces state spaces; Alloy converts models into SAT problems, making many checks much faster. Property-based testing as the middle ground: Property-based testing is presented as a more accessible alternative that generates many inputs, shrinks failing cases, and catches bugs without full proof. It is positioned as the best entry point for most engineers. AI and formal verification: AI can help fix syntax, summarize error traces, and assist experts, but it is poor at inventing meaningful properties or writing specifications from scratch. The speakers conclude AI may increase adoption of lightweight formal methods, not fully automate verification. Engineering culture, open source, and version control: The episode highlights software's unusual openness, practitioner conferences, open-source sharing, and sophisticated version control as things other engineering disciplines often envy. Hillo also notes software engineers may be weaker at planning than traditional engineers.
Key Arguments: Software engineers and traditional engineers face the same fundamental tradeoff: the cost of mistakes versus how quickly they can iterate. Software differs because it is far more consistent and much easier to iterate on than physical systems. Open source, practitioner conferences, and ubiquitous version control are unusually strong features of software culture. Formal verification is overkill for most everyday code because specifying the full real-world context is too complex. The highest-value uses for formal methods are technical, discrete, high-stakes systems such as databases, kernels, and distributed systems. Property-based testing captures much of the benefit of formal reasoning with far less effort, making it a better default for many teams. AI is helpful as a force multiplier for experts, but it is currently bad at inventing good properties and specifications. Understanding logic and discrete math materially improves day-to-day software engineering judgment and correctness reasoning. The biggest practical gain from formal methods is not just bug-finding but training engineers to think about failure modes and concurrency. Compared with software, other engineering disciplines tend to be better at documenting domain-specific knowledge and planning up front.
Data Points: Engineers interviewed for crossover project: 15-20 people - Hillo interviewed engineers across traditional fields to compare software engineering with other engineering disciplines. Fields represented in crossover project: 6-7 different fields - The interviews spanned multiple engineering domains, including civil, electrical, chemical, mining, and industrial engineering. TLA+/Amazon paper year: 2014 - The AWS formal methods paper is cited as a key moment in popularizing TLA+ in industry. Formal methods project duration reference: 30 years since 1994 - Hillo references the long history of TLA+ and the evolution of successor tools since Leslie Lamport introduced it. Bug trace length in AWS paper: 35 high-level steps - The Amazon paper reportedly found a bug in DynamoDB/S3 replication with a short but complex counterexample trace. State space explored in TLA+ demo: 53 states - A TLA+ demo found the bug in the toy trading system after exploring 53 states. State space size mentioned for TLA+: 100 million states - Hillo notes real TLA+ model spaces can become enormous, making some runs overnight-scale. TLA+/Alloy check speed: milliseconds to a second - Alloy can often translate models into SAT and check them very quickly compared with TLA+ brute-force exploration. Property-based test sample size: 1,000 random lists - Property-based testing was described as testing many generated cases rather than proving all cases. Launch year for example tool lineage: 1994 - TLA+ was introduced in 1994 by Leslie Lamport. Probability language example: 10% / 25% - Prism is described as able to model probabilistic failure rates such as bugs happening 10% or 25% of the time. Software engineering forecast horizon: 10 years - Hillo predicts the field will survive but become more like ordinary white-collar professional work over the next decade.
Pivotal Quotes: "Everybody hates waterfall." — Hillo Wayne: Used to summarize a shared engineering preference for iterative development over rigid upfront planning. "Automation comes for all of us, even automators." — Hillo Wayne: Hillo's reflection on AI, job change, and the possibility that software engineering becomes less magical and more commoditized. "AI is a specification force multiplier." — Host summarizing Hillo's view: A recurring theme: AI helps experts work faster, but does not replace the human job of defining correct properties.
Implications: For most teams, property-based testing and selective modeling are the practical path, not full formal verification. AI will likely accelerate expert workflows and spec generation, but human judgment remains essential for writing meaningful properties and verifying complex systems.