2026-07-08 · A Rust-to-Lean verification pipeline with AI provers: An experience report

Transcript

Transcript. Paraphrased; sources in notes.md.

HostGood morning, everyone. It is July 8th, 2026, and we are back to dig into the latest discussions from Lobsters. Victoria, thanks for joining me. We have quite the spread today, ranging from formal methods in Rust, to Apple's shift in their AI infrastructure, and finally, a critique of the embedded Linux build landscape.

GuestI am ready, Daniel. And honestly, if we start with formal methods, I am going to have a hard time not starting with my favorite question: is this actually going to stop a production outage, or are we just building a very expensive academic trophy case?

HostWell, you are in luck, because that is exactly where we are starting. The paper is an experience report on using AI provers to bridge the gap between Rust and Lean, which is a theorem prover for formal verification. Basically, they are trying to automate the process of verifying critical code, specifically in Plonky3 and RISC Zero, which are projects involved in zero-knowledge proofs. The author’s claim is that they have managed to make the formal verification process more practical by using AI to handle the heavy lifting of proof generation.

GuestPractical is a loaded word. Look, Plonky3 is doing heavy-duty math. If a bug there leaks private data or corrupts a proof, you are out of business. My issue with formal methods is always the upkeep. You ship the code, the proof is done, and then a developer changes two lines of logic six months later. Does the proof break? Does the AI auto-update the proof? Because if the answer is "no," you have just added a massive tax to every future PR, and that is how you end up with stale, ignored verification.

HostIt is a fair point. There were no comments on the Lobsters thread for this one, which is rare, but it suggests this is still very much in the "frontier research" bucket rather than something ready for a team of three at a startup.

GuestExactly. If you need a PhD to maintain your build pipeline, you are not shipping, you are researching. I want to see this used on a boring API endpoint, not just a cryptographic primitive, before I get excited.

HostLet's shift gears to something that affects users immediately. Apple is updating their privacy dialogs. The author notes that Apple’s new "AFM Cloud Pro" models, which stands for Apple Foundation Model, are being routed through Google Cloud. This flies in the face of their original "Private Cloud Compute" pitch, where the hardware was supposed to be strictly Apple-owned and managed.

GuestOh, this is delicious. Apple sold the "walled garden" as a security feature, but they ran out of compute. A Lobsters user called fazalmajid points out that the servers Apple actually built are reportedly sitting in warehouses, unused, because the demand for Apple Intelligence just is not there, or at least it isn't hitting their projections. So, they have to pivot to a provider that actually has the GPUs.

HostThe thread has some heat to it. Someone named fazalmajid argues that confidential computing, using Trusted Execution Environments, or TEEs, is standard practice for banks and government agencies, and that Apple is essentially just using Google as a generic utility player.

GuestIt is the ultimate pragmatist move. Apple realized that building a bespoke, secure server fleet is an infrastructure nightmare, and it is cheaper to rent Google's scale while slapping a "Privacy" sticker on the front door. To be blunt, the TEEs are just a band-aid. If I am the user, I have to decide if I trust the "provisioning layer" between Apple and Google. I suspect for most people, the privacy promise was always more of a marketing campaign than a technical guarantee, and this just proves it.

HostFinally, let's talk about the embedded world. A new project called Yoe is arguing that Yocto, the industry standard for building embedded Linux, is showing its age. They claim that modern development, with its reliance on language-specific package managers and cloud-based updates, has outpaced the old way of building everything from source.

GuestThis is the eternal struggle of the "Embedded Linux" category. I have spent years fighting with Yocto layers that are pinned to some specific version of a kernel from 2018 because the board support package breaks if you look at it wrong. The author claims this is because we have outgrown cross-compilation.

HostA user named mort in the thread pushes back hard on that, saying that software didn't outgrow cross-compilation at all. They think the author is just producing the kind of vague, AI-generated-sounding slop that fails to address the actual mechanical complexities of build systems. Another user, Corbin, argues that the real solution is just using Nix to manage packages, because it is more efficient than reinventing the wheel.

GuestCorbin is onto something. The problem is not the build system; it is the dependency hell. If you are building a product, you do not want to be a build-system engineer. You want a binary that boots and a way to update it without bricking the device. If a tool doesn't make my life easier by handling the "ship to customer" part, I don't care how "modern" the package manager is.

HostSounds like the consensus is that the tools might be annoying, but the core problems are still the same ones we have had for a decade.

GuestAlways. Every few years, someone thinks they can solve embedded build complexity with a new DSL, and then we all end up back in the same trap, just with a different syntax to debug. I am going to stick to the boring, stable stuff for as long as I can, Daniel.

HostFair enough. Well, that is all the time we have for today. Thank you, Victoria, for keeping it grounded. All of these stories and the lively debate around them can be found over on Lobsters. Thanks for joining us, and we will see you all back here tomorrow.