François argues for scientific rigor in AI safety discussions and warns that media accounts can overstate incidents. He says the Hugging Face agent episode involved a prompt and about 1,200 agents, and that safeguards were disabled because the system was not in production. He also notes that a widely cited survey asked about risks over 100 years or all time, not specifically the next decade.
AI Safety Fact vs. Fiction
Speakers
Y Combinator host François and Stanford professors Clark Barrett and Michael Koken Derfer discuss AI safety, formal verification, and system validation at YC AI Safety Club.
Clark Barrett explains how AI can help generate code while automated reasoning tools check whether it meets formal specifications. His team’s CS-lib project aims to translate programs into Lean theorems, and a prototype verifies Rust code from the Dalek cryptography library. Barrett also describes a crypto prover agent that reportedly verified a 30,000-line Rust library in 11 hours, work that had taken experts months.
Michael Koken Derfer describes methods including falsification, importance sampling, neural network verification, and POMDP planning. For aircraft collision avoidance, the target discussed is a catastrophic failure probability near 10⁻⁹ per flight hour, which makes direct simulation impractical. For language models, his group adapts stress testing to search for likely toxic outputs, while noting that failure definitions and models shape the results.
In the discussion, Barrett and Koken Derfer support independent evaluation, postmortems, and aviation-inspired safety reporting. They emphasize that proofs depend on assumptions, and that formal methods can guarantee properties such as memory safety without proving every real-world behavior safe. They also describe layered defenses, including runtime monitoring, human safeguards, and ongoing benchmark checks.
Takeaways
- Treat AI risk estimates as uncertain; check what time horizon a survey actually asked about.
- Use formal verification for properties that can be specified clearly, and document the assumptions behind each proof.
- Combine testing, statistical validation, formal methods, and runtime monitoring; no single method covers every failure mode.
- Create independent evaluation and non-punitive incident reporting so failures can improve shared safety practices.
- Keep benchmarks under review: definitions and data can drift, and flawed evaluations need versioning and correction.
Mentioned in this talk
Search inside this talk
What was claimed 8
- uses
“We're using Lean”
YouTube Unverified1 source· Talk
- featureVerisforge: Generates code and a formal proof from an English specification
“it will build the code and do the formal proof”
YouTube Unverified1 source· Talk
- metriccrypto prover agent: Verified a 30,000-line Rust crypto library fully automatically in 11 hours
“We were able to do it in 11 hours fully automatically”
YouTube Unverified1 source· Talk
- featureAnd Truth: Building a universal code reasoning engine
“We're trying to build a universal code reasoning engine”
YouTube Unverified1 source· Talk
- role atClark Barrett is co-CEO at And Truth
“I'm co-CEO of a new company called And Truth”
YouTube Unverified1 source· Talk
- uses
“We used it in part to help validate different versions of the ACAS X system”
YouTube Unverified1 source· Talk
- featureBetterBench: Provides benchmark data, lessons learned, and best practices
“you can find data about a number of different benchmarks, lessons learned, and best practices”
YouTube Unverified1 source· Talk
- metricNTSB: Established in 1967
“The NTSB was set up as an independent agency in 1967”
YouTube Unverified1 source· Talk












