The scope of the proof
For a program sorting a table, a mathematical proof starts with what the table must preserve. In WIRED’s example, it must contain the same items before and after sorting, with only their order changing. Formal verification checks whether a program satisfies precise behavioral specifications of this kind. AI assistance with producing proofs brings me to a measurement question: how much of the behavior that matters to a user does the accepted proposition cover? The conditions written at the start determine the scope of the proof.[1]
&Truth, which Stanford researcher Chuyue Sun joined in August, publicly launched to automate this process. Sun’s research concerns part of the code encrypting Signal conversations. That boundary matters: verifying a particular portion of encryption code does not automatically become an assessment of every behavior of the application. The rapid completion described in the report concerns the effort spent on verification work. The breadth of assurance still depends on which code was checked against which conditions. Effort and coverage measure different outcomes.[1]
Who writes the condition?
The startups plan to have AI automate much of the work of defining how a program should behave. Further automation can translate code into forms checked by mathematical tools such as Lean, Rocq and Isabelle. Two questions follow: does the code satisfy the written condition, and does that condition accurately describe the intended task? My interpretation is that automation makes the second question more deserving of attention. A positive result from the checker has meaning within the condition presented to it; coverage of behavior omitted from that condition cannot be assumed.[1]
Proofcraft’s June Andronick and Gerwin Klein raise precisely this concern: AI-written specifications could inspire unjustified trust. The possible mechanism I infer is that a successful proof can leave an omission in the specification unnoticed. A plausible alternative is that teams specify the required conditions correctly and automation simply reduces laborious proof work. In that case, faster completion would be a real methodological contribution. Distinguishing these explanations requires examining the checked behavioral specification alongside the accepted proof.[1]
Locating the remaining bug
The experts’ contrasting experiences also need to be read against the question being asked. Byron Cook of Amazon Web Services says formal verification eliminated major bugs early. Apple’s security team says it caught otherwise undetectable problems in corecrypto. Antithesis CEO Wilson says his company’s tool found additional errors in defenses it had verified. These accounts show how useful proofs and remaining bugs can coexist; they supply no common experiment measuring which approach is superior in every setting.[1]
The example I would want to examine should therefore show the specification, accepted proof and subsequently discovered bug for the same piece of code. Does the bug concern behavior outside the specification or an assumption about how the computer operates? The concerns about user error and hardware breakdowns reported by WIRED make this distinction concrete. It makes the question answered by a proof intelligible. For me, assessing automated verification begins with making that boundary as inspectable as the proof itself.[1]