One week to verify zlib, no artifact to check: reading the Lean-plus-AI evidence

A summarized interview transcript with Lean's founder, published on dev.to, carries the strongest claim now circulating about AI-written formal verification: a project initiated by Kim Morrison had an AI translate the C-written zlib compression library into Lean, pass the original test suite, and prove the strong property that compressing then decompressing returns the original data ^[1]. The same source says the entire formalization was finished in about a week, with only performance optimization left, and that the optimization must not break the existing proofs ^[2]. That matters because it is the one data point in the material that speaks directly to cost, and the material contains no link to the artifact, no line count for the translated library, and no compute cost figures ^[18]. Set that against what adoption actually shows. AWS has an internal AI accelerator compiler of roughly 500,000 lines of Lean, but uses Lean mainly as a programming language, with some property proofs as an extra benefit ^[8]. Companies including Jane Street are investing in formal verification, with the complete verification of the seL4 microkernel cited as an example ^[7]. Neither of those is evidence that AI changed the economics; the first is language adoption with verification as a side effect, and the second is the pre-AI state of the art. The interview itself notes that major labs only began seriously putting Lean formal verification into their reinforcement learning pipelines in the last year or two ^[17]. The adoption base is real, narrow, and older than the claim it is being used to support. The load-bearing economic assertion is that before AI, manually writing and maintaining proofs often cost about ten times the cost of writing the program itself ^[3], paired with the claim that AI is very good at writing and maintaining those proofs even when the human no longer remembers why a proof was structured as it was ^[4]. Both come from the same interviewee. If the ten-times figure is close, partial automation moves verification from research budget to engineering budget. If it is a rule of thumb, the case rests on one anecdote whose artifact is not published. Volume is being used as a proxy for progress, and it does not work. OpenAI first produced an informal proof related to the unit distance conjecture, Morrison posted it as a challenge, and OpenAI's Boris Kusolovic produced a complete Lean formalization of about one million lines in under two weeks ^[13]. That averages more than roughly 71,000 lines of Lean per day ^[14], which is past any rate a team reviews by reading. The confidence there comes from the checker, not the text, which is why the kernel story is the part worth auditing: Lean's shipped kernel is not verified, but Mario Carneiro implemented a kernel called Lean for Lean and proved it consistent with Lean's semantics, and third-party kernels exist, including ones written in Rust ^[11]. A high-performance kernel is roughly 5,000 lines, small enough that in principle anyone could rewrite one ^[12]. Note who benefits from the framing. The strongest numbers come from the tool's founder, in an interview, and from labs whose systems generated the proofs. That is selection, not dishonesty: you hear about the week that worked. What is transferable regardless of the anecdote: complexity remains the enemy of verification, and automated proving only works if proofs are written modularly so they can be extended ^[5]. The specification technique is concrete and cheap to try: use a low-efficiency but correct implementation as the spec, then have AI generate an efficient version and prove it equivalent ^[6]. The payoff claimed is willingness to make aggressive performance rewrites, because the equivalence is either proved or a counterexample appears ^[16].