GitHub Universe day one done! If you’re here, come by tomorrow to chat to all the @GitHubNext folks at the Speakeasy section. We’re in white lab coats. Also demoing some stuff in the final keynote.

First time attending #GitHubUniverse#, any tips to make the most of it? I’ll be the guy in the blue tie-dye shirt. I’m demoing Proof-Driven Development Kit (PDD Kit) from @MSFTResearch and @GitHubNext. Come ask me about code verification at the GitHub Next booth. Stop by the Speakeasy and ask for GitHub Next.

Top 9 Formal Methods/Verification predictions: 1. Formal methods alone will not eliminate all kinds of bugs. What I’m calling “Empirical Verification” via sophisticated simulation testing, CUA, etc. will become more important than ever. 2. Languages won’t matter but barriers to adoption will still be relevant especially for startups with customers that they’d need to migrate codebases for, enterprises, etc. 3. For cost and pricing, the economics are improving but there is still high cost demands for infrastructure that are to be figured out. See more in point 7 below. 4. Models will significantly improve and intent alignment will take center stage. Even the best models today prove the wrong thing many times without sophisticated tooling, etc. The model by itself will not be enough here. 5. Engineering workflows are going to drastically change. Engineers will move into long running tasks in parallel that run for overnight to weeks, meaning we will work faster in higher quantity. But fast, iterative work that you push and get back instant results for will not be the norm anymore. Coding agents have tricked us into thinking we’re getting high quality, verified results instantly but that is not the case. This too will improve over time. 6. Vibe coding, consumer/indie development overall, and gaming will have very interesting windfalls as a result of formal methods scaling (at least in terms of applications end users will notice in their day to day). Not including crypto, finance, cloud, hardware, etc. that are already seeing and have been seeing strong results. 7. Languages are only one piece of this. Hardware, and compute are another but there will be an entire class of infrastructure that we’ll need in addition to great work on languages and across the board software. Honestly this is where one of the biggest risks lies. For this to work at scale, the infrastructure doesn’t exist and will require significant innovations and languages are not even there yet. As an engineering community if we want to win we need diversity of choice and we need to avoid lock in. That means helping contribute to different formal languages and you can start with the ones that are tied to your use case. Here’s a brief selection map I wrote: - Agents writing production code today (especially Rust): Verus - Checking a distributed design: TLA+ - Math: Lean - Bend 2, Vera, Vow and Kōdo: worth watching, still very early though. There’s others so feel free to fill them in, we can have an interesting conversation about them. Just get started for what works for you. Also you help the engineers working on building products around these to accelerate work that comes back for you to use. For example, I’m committing a lot of work to Verus which is OSS to give back. Join me. It’s pretty obvious the big guys are betting on Lean, Verus, TLA+, Dafny. Which, if you think about the unit economics of this and future vision, makes a lot of sense. Also if you read “FV X”, many of the engineers and researchers that are formal methods experts are pushing these too. There’s a reason. Also, there is less risk of having to rip out your work and start over if you want to get started now. And you can benefit from a rich engineering community already contributing to these languages with large amounts of funding. I like spreading out your contributions so no singular method is locked in and also because each is attuned for specific type of work. The most important thing is to have conviction and just contribute. I’m currently bullish on Rust so I’ve been pushing Verus. 8. Hiring will be impacted. As I mentioned this space is ripe for direct innovation and in tangential research areas, such as intent alignment. Understanding Verification Engineering and I mean understanding it for both Formal and Empirical Verification will help you a lot. This is another reason to look into the above languages as ways for working with the frontier AI labs, neo labs, and big tech companies. There’s a very limited number of formal methods experts today and even less that can combine Formal Verification, Empirical Verification, and Agentic Engineering. 9. “Vibe Verification” via just natural language skills or plugins, etc. will take the market by storm because it’s satisfying to have instant feedback. At times they will maybe even prove valuable, meaningful things and perhaps are good enough for some cases. But they are definitely not good enough for actual commercial or enterprise products or real security today. Be wary of and do not pay for Vibe Verification. Just like with all the test bloat that we had to rip out, if you vibe verify your codebase then it will be filled with slop you’ll have to pull out in the future. As model capabilities improve the last thing you want is poor formal spec examples that are incorrect for these models to reference inside of your codebase. Save yourself the trouble. I could be wrong about everything and also right about a thing or two, but I think for collective success and transparency we should share our predictions and work together. Follow me for more on Verification and Agentic Engineering.

Best way to formally verify Rust code for real programs. I use Verus because it just works with Rust repos already, no runtime cost, and fully OSS. You keep Rust’s good memory management, tooling support and performance. The spec is just Rust: fn octuple(x: i8) -> (r: i8) requires -16 <= x < 16, ensures r == 8 * x, `requires` is what every caller must promise. `ensures` is what you get back. Verus proves the body of the function keeps that promise for every input that adheres to `requires`. That formal spec is then removed when compiling so the runtime is not impacted. There’s a Verus playground you can use in your browser and multiple guides that come alongside the OSS repo. I highly recommend you invest time to play with this with your coding agent because it will open your mind to some insane possibilities that work with distributed systems, concurrency, memory constraints, etc. today. Reminder to not vibe verify, check your formal specs. Literally just go and explore, it’s available now. This doesn’t promise ‘bug free’ overall, it promises hardening. I’ll talk more about how to further harden in the future. Follow me for more on verification and agentic engineering.

New talk! About the divided human & agent worlds, boundary objects, and building thicker interfaces I've been exploring how to improve "planning", aka. deciding what agents should build, how you want it built, & making the whole team part of that process

Don't learn formal methods. Writing proofs by hand is what kept formal methods niche for over 75 years. seL4 took about 20 person-years to prove 8,700 lines of C. Agents take that part now. What's left for you is the spec, and knowing which language fits the job. That's why the history matters. Formal methods means stating what a program or system must do in precise math, then using a tool to check that the code or design meets it. Here's how we got here, what each language is good for, and where I'd start. FOUNDATIONS (1947 to 1979) 1947: Goldstine and von Neumann annotate program flow diagrams with "assertion boxes" stating what holds at each point. 1949: Alan Turing's "Checking a Large Routine" proves a short program correct using assertions. The idea mostly sits unused for over a decade. 1962: Carl Adam Petri's dissertation introduces Petri nets for modeling concurrent systems. 1963: John McCarthy, "A Basis for a Mathematical Theory of Computation". 1966-67: Peter Naur and Robert Floyd independently show how to prove programs with assertions attached to points in the code. 1967: N. G. de Bruijn starts Automath, the first language for computer-checked mathematical proofs. 1969: Tony Hoare publishes Hoare logic, {P} C {Q}. Nearly every contract language since builds on it. 1972: Robin Milner's Stanford LCF. Its Edinburgh successor (1979) introduces ML as its scripting language, the ancestor of Standard ML, OCaml and F#. 1973: Mizar starts in Poland. Formalized math that reads close to a textbook. 1975: Dijkstra's guarded commands and weakest preconditions. 1977: Amir Pnueli brings temporal logic to programs. Patrick and Radhia Cousot publish abstract interpretation, the theory behind sound static analyzers. 1978: Hoare's CSP for concurrent processes. Milner's CCS (1980) and the pi-calculus (1992) follow. 1970s: VDM at IBM's Vienna lab. Jean-Raymond Abrial proposes Z, later developed at Oxford. Boyer and Moore build their theorem prover. TOOLS PEOPLE USED (1980 to 1999) 1981-82: Model checking, invented independently by Clarke and Emerson and by Queille and Sifakis. Turing Award in 2007. 1980s: Synchronous languages Esterel and Lustre in France. Lustre becomes SCADE, which Airbus uses to design flight control software. 1984: Nuprl at Cornell. 1985: Coquand and Huet's Calculus of Constructions, the logic under Coq. 1986: Isabelle (Larry Paulson). Late 1980s: SPARK, a provable subset of Ada. 1988: HOL (Mike Gordon). 1989: Coq's first public release. Renamed Rocq in 2025. 1990: Symbolic model checking with BDDs handles 10^20 states. McMillan's SMV follows. 1991: SPIN model checker goes public (Gerard Holzmann, Bell Labs). 1992: PVS at SRI. Oxford and IBM win the Queen's Award for using Z on IBM's CICS transaction system. 1993: Metamath, a proof language simple enough to check with a few hundred lines of code. 1994: Lamport's TLA. TLA+ follows in 1999. 1994-95: Intel's Pentium division bug costs it $475 million. AMD uses ACL2, Kaufmann and Moore's successor to the Boyer-Moore prover, to prove its K5 floating-point division correct. Intel hires John Harrison in 1998 and uses his HOL Light to verify floating-point algorithms. 1996: Abrial's B-Book. 1997: Alloy (Daniel Jackson, MIT). 1998: Paris Metro line 14 opens driverless, with safety software built in the B method. The KeY project for Java verification starts. 1999: Agda (Catarina Coquand). JML, a contract language for Java. VERIFIERS MEET REAL CODE (2000 to 2019) 2000: Microsoft's SLAM project starts. It ships as the Static Driver Verifier in the Windows driver kit. 2001-02: Separation logic (Reynolds, O'Hearn, Yang) makes pointer-heavy code provable. 2002: ESC/Java. Spec# (2004) and the Boogie verifier (2005) follow at Microsoft Research. 2003: Astrée proves the Airbus A340's primary flight control software free of run-time errors. 2004: CBMC, bounded model checking for C. 2005: Georges Gonthier finishes a Coq proof of the four color theorem. 2006: CompCert, a C compiler proved correct in Coq (Xavier Leroy). Event-B gets its Rodin toolset around the same time. 2007: Agda 2. Idris first appears (Edwin Brady). 2008: Z3 SMT solver (Microsoft Research). Frama-C. VeriFast. 2009: Dafny (Rustan Leino). seL4, the first general-purpose OS kernel with a machine-checked proof that its C code matches its spec. 2010: Why3. 2011: F*. 2012: A Coq proof of the Feit-Thompson odd order theorem is completed. 2013: Lean (Leonardo de Moura, Microsoft Research). P language at Microsoft. 2014: CakeML, a verified ML compiler. Liquid Haskell. Flyspeck finishes a formal proof of the Kepler conjecture. 2014-15: AWS reports TLA+ found bugs in S3 and DynamoDB that testing missed. IronFleet proves distributed systems correct in Dafny. 2015: Iris, a separation logic framework in Coq. Facebook open-sources Infer. 2016: Project Everest starts, aiming for a verified HTTPS stack. Viper. 2017: HACL*, verified crypto written in F*, ships in Firefox 57. Lean's mathlib starts. 2018: AWS Zelkova checks IAM and S3 policies with SMT solvers. 2019: Fiat Cryptography's Coq-generated code lands in BoringSSL, used by Chrome. Prusti for Rust. LLMS MEET PROOF CHECKERS (2020 to 2025) 2020: OpenAI's GPT-f finds shorter Metamath proofs that get accepted into the main library, a first for deep learning. 2021: Lean 4. 2022: Kani (AWS) and Creusot for Rust. Aeneas translates Rust into Lean. The Liquid Tensor Experiment finishes the Lean proof Peter Scholze asked for. 2023: Verus for Rust. AWS releases Cedar, a policy language built with proofs in Dafny and later Lean. LeanDojo gives models a programmatic interface to Lean. Terence Tao's team formalizes the PFR conjecture proof in Lean in three weeks. July 2024: DeepMind's AlphaProof reaches IMO silver-medal standard with proofs in Lean. Sept 2024: Quint 1.0, TLA+ ideas with ordinary programming syntax. Mar 2025: Imandra launches CodeLogician, an agent that turns code into its IML logic and checks it. Apr 2025: AWS publishes how it rewrote its authorization engine, called a billion times per second, in Dafny with proofs. July 2025: Harmonic's Aristotle reaches IMO gold-medal level with formal Lean proofs. Sept 2025: The vericoding benchmark tests LLMs writing verified code from 12,504 specs. Off-the-shelf models pass 82% in Dafny, 44% in Verus, 27% in Lean. LANGUAGES BUILT FOR AGENTS (2026) Feb 22, 2026: Vera. "A programming language designed for LLMs to write, not humans." Feb 25, 2026: Vow. "A Programming Language for Agentic Coding." Mar 9, 2026: Kōdo. "Designed for AI agents to write." Z3-checked contracts, JSON errors with patches. Sept 17, 2026: Bend 2. Dependent types and Lean-style proofs, C-like speed, CPU and GPU parallelism, Python-like syntax. WHAT EACH LANGUAGE IS GOOD FOR Specs and models Z: precise requirements docs. Little tooling today. VDM, B, Event-B: refining a spec step by step into code. Railways and safety-critical control. CSP (with the FDR checker): concurrent protocols. Petri nets: workflows and concurrent processes. TLA+ and Quint: distributed system designs, consensus, race conditions before you write code. Checks the design, not the code. Alloy: fast counterexamples in data models and access rules. Bounded, so finding no counterexample isn't a proof. P: modeling and testing event-driven distributed services at AWS and Microsoft. Model checkers SPIN: concurrency protocols, as abstract models. NuSMV and other SMV descendants: hardware and finite-state control logic. CBMC: bounded checking of C code. Kani: bounded checking of Rust, including unsafe code. Static analysis Astrée: proving embedded C has no run-time errors. Avionics. Static Driver Verifier: Windows drivers using kernel APIs correctly. Infer: memory and null bugs across large codebases. Proof assistants ACL2: hardware and microcode. HOL4, HOL Light: hardware and floating-point proofs. Isabelle/HOL: seL4-scale systems proofs, strong automation. Rocq: verified compilers (CompCert), crypto (Fiat), big math proofs. Slow and hard to learn. PVS: aerospace, much of NASA's formal methods work. Agda: type theory research and teaching. Lean 4: math (mathlib) and AI theorem proving. Hardest of the big three for LLMs off the shelf (27%). Mizar, Metamath: large formal math libraries with simple checkers. Verifying real code SPARK: avionics, defense, rail. Dafny: verified business logic, compiles to C#, Java, Go, Python, JS. AWS uses it for its authorization engine. Easiest for LLMs off the shelf (82%). F*: verified crypto (HACL*, in Firefox and the Linux kernel). Frama-C, Why3: C in safety-critical settings. KeY, JML: Java. VeriFast, Viper: separation-logic proofs about heap-heavy code. Liquid Haskell: proofs added to existing Haskell. Idris: general-purpose programming with dependent types. Verus, Prusti, Creusot, Aeneas: proofs about Rust code. WHY IT NEVER SCALED Formal methods worked. They didn't scale, because a person had to write every proof. Back to seL4. Its 8,700 lines of C needed roughly 200,000 lines of Isabelle proof, more than 20 lines of proof per line of code. IronFleet's verified distributed systems took 3.7 person-years, including inventing the method. So formal methods stayed where a bug costs more than the proof: flight control, railways, crypto, kernels, cloud authorization. Agents change that math. The proof is the tedious part, and an agent will grind on it all night. You also don't have to trust the agent, because the verifier accepts the proof or rejects it. What stays human is the spec. A green proof of the wrong spec is still wrong, so that's where your review time goes. WHERE I'D START I would start with the Verus formal language. The agent is the new part, so I'd pair it with a verifier that isn't. For agents writing verified code. It checks ordinary Rust against specs and proofs written in Rust, then erases them before compiling, so what you prove is what ships. It has peer-reviewed results since 2023, real systems built on it (Kubernetes controllers, OS kernel, etc), and use at Microsoft and Amazon. For other jobs: - Checking a distributed design: TLA+ - Math: Lean - Bend 2, Vera, Vow and Kōdo: worth watching, still very early though. Follow me for more on verification and agentic engineering.

Getting in on the formal verification hype in the only way I know how... building a UI framework 😁 Meet Cairn: apps are in Lean, and every action is a claim, a durable id with a proof of what it does. A thin Swift + Metal host draws it on the Mac.

We spent fifty years making proofs impossible to fake. Then we let the coding agent pick what to prove. A research paper this month put a number on it.* AI wrote the formal spec, AI wrote the proof, the verifier accepted both. Then humans read the specs. Close to 60% proved something other than what the author meant. Not wrong proofs. Wrong specs. The verifier was right every time. That's the problem. Left to choose, the agent picks properties that are easy to prove and say nothing about the program, and the checker can't tell a useless theorem from a useful one. I'm calling it vibe verification: the agent writes the spec and the proof, the checker goes green, nobody reads the spec. This applies to Verus, Lean, Bend, TLA+, Dafny, [insert favorite formal language here]. Here's an example of an agent failing at something that feels too simple to fail: Ask for a verified sort. It writes a spec that says "the output is sorted" and proves it. What the spec never says is that the output has the same elements as the input, so a function that returns an empty list satisfies it, and the verifier accepts the proof. Trivially satisfiable specs are the default failure, not an edge case. Here's a formula that actually works. Don't say "formally verify the codebase." Say "show that [property] holds in [component]." A property is a precondition (true going in), a postcondition (true coming out), or an invariant (stays true the whole time). For example, "A session token is never accepted after the logout that revoked it" is a good invariant. The bottleneck is moving from code review to intent review, and the spec is where intent lives. So: read the spec before the code. Write 3 inputs it must accept and 3 it must reject. Treat a model-written spec with utmost paranoia and rely on your judgement as an engineer. Formal verification for software doesn't automatically create trust, it moves it, from the code to the spec. If a human didn't read the spec, you didn't verify anything. You vibe-verified it. Follow me for more on verification and agentic engineering. * Wang, Jiang, Liu et al., "VerusEval: Evaluating LLM-Generated Verus Specifications Beyond Verifier Acceptance", Shenzhen University, arXiv 2610.26464, October 2026

PDD Kit is in limited research preview, but here’s how you can get started now. For all engineers to benefit from verified code faster, we need to contribute to an ecosystem of formal languages. In addition to Lean, I encourage you to contribute to the formal languages Verus and F*/Pulse. There may be a learning curve but it’s worth it and you can ask for help. They're open source. To be transparent I know some of these researchers, but they’ve spent years developing these languages and building an incredibly strong foundation that scales verified code. They also advocate for open intelligence and consistently give back to the engineering community with their knowledge. This is the direction I would highly encourage exploration given what we know.

Code review does not scale to how much code agents can write in a day, and a test suite only proves the specific cases somebody remembered to write. Microsoft Research and GitHub Next shipped something this week that closes that gap with proof instead of sampling. Proof-Driven Development Kit takes a plan written in Chopin, GitHub Next's planning prototype, and translates it into Verus contracts in Rust: preconditions, postconditions, invariants. An agent writes the implementation and the verification annotations side by side. Verus generates proof obligations from that and hands them to an SMT solver. Code ships only once every required obligation is discharged, not once it happens to pass whatever tests existed. This builds directly on GitHub's own Spec Kit, which has spent the last year pushing spec-driven development as mostly a prompting discipline, written requirements steering what Copilot does. PDD Kit's actual contribution is enforcement. The spec stops being guidance a model can quietly ignore and becomes something a theorem prover checks mechanically, every time. It's not a universal fix and the team is upfront about that. The method only verifies what the specification states, and an LLM can still write a spec that drops a requirement or misreads the plan entirely. Unsafe Rust, foreign interfaces, and anything outside the formal model sit outside the proof. Architecture and security boundaries still need a person looking at them. Formal verification has lived in a small, expensive corner of software for decades, aerospace, crypto, medical devices, places where a bug was unacceptable rather than merely annoying. Agents writing most of the code may be what finally drags it into everyone else's stack.

AI agents are writing more code. How can developers ensure that code is correct? Microsoft Research’s Proof-Driven Development (PDD) Kit explores a more rigorous approach: it translates a developer’s intent into a formal specification, then uses formal verification to prove that generated code meets it. PDD Kit works with Verus for Rust and is integrated with @GitHubNext’s Chopin, bringing formal methods into an AI-assisted development workflow for teams. See the work in action at @github Universe, Oct. 28–29, 2026.

Chopin + Proof-Driven Development Kit from @GitHubNext and @MSFTResearch enable teams to ship AI-generated code to production without reviewing it line by line, with stronger assurance than code review and testing alone. Now in research preview ⬇️

PDD Kit is in limited research preview, but here’s how you can get started now. For all engineers to benefit from verified code faster, we need to contribute to an ecosystem of formal languages. In addition to Lean, I encourage you to contribute to the formal languages Verus and F*/Pulse. There may be a learning curve but it’s worth it and you can ask for help. They're open source. To be transparent I know some of these researchers, but they’ve spent years developing these languages and building an incredibly strong foundation that scales verified code. They also advocate for open intelligence and consistently give back to the engineering community with their knowledge. This is the direction I would highly encourage exploration given what we know.

I’ll be going live on @theneurondaily tomorrow at 10 AM PT to talk about verification and test engineering for AI-generated code to improve assurance at scale. I’ll be covering empirical verification techniques that can be applied in practice and should be adopted as a baseline for every codebase. Link below, make sure to hit “notify me” button on the video to not miss it.

Long-running coding agents fail in boring ways. They disappear for hours, burn past the budget, call work done without checking the requirements, or hang forever on a bad provider stream. Atomic 0.9.14 and 0.9.15 put those jobs under runtime control. Run it without babysitting it. Workflows now send configurable heartbeats to the parent chat. You can see that a run is alive, inspect its status, and steer it before a missed constraint spreads. Set a budget before the run starts. Give each workflow a budget for elapsed time, charged tokens, and provider-reported cost. Atomic warns the parent chat as the run approaches its limit. If the budget is exhausted, an active stage gets one wrap-up turn before the run stops resumably at an execution boundary. Verify every requirement, not just the tests. Verification now scores each criterion-verifier pair from 1 to 20, requires a passing mean with no veto, re-asks invalid reports, and writes an auditable comparison ledger. A model saying “done” is not proof. Stop provider failures from wedging the job. Stalled streams now settle as retryable transport errors. Workflows can retry or fail over instead of sitting in “running” forever. We also made it easier to keep the transcript visible while answering workflow questions, choose the right skill when names collide, and return typed workflow data without replacing the human-readable artifact. Stay in the main parent chat while workflows run as graphs of coding agent sessions in the background. Attach to sessions, steer, and remain in control as the engineer. Thank you to our contributors and issue reporters for building Atomic with us for these releases: morgan-coded Lingwcy Shreyas Devadiga @makgunay @RayFernando1337 tyler-utah Release notes:

“A rose by any other name would smell as sweet.” We use buzzwords like orchestration, graphs, loops, runtimes, verification to be able to convey our thoughts but we don’t want to get hypnotized by the vocabulary. Shakespeare got it right. We need to ask ourselves if the system’s effects matches the promise behind the vocabulary. Ultimately, the intrinsic qualities of an object are more important than what it’s called. Building something that has reduced stress for someone working in a 10M+ LoC repo when no other tool was working, that’s the quality that as a fellow engineer I care about the most.

Thanks for the shoutout! For those who are looking to check out Atomic, here’s the link: It innovates at the runtime level by introducing the idea of recursive state machines (RSMs) over RLMs and verifier primitives.

In this clip I explain why the hypothetical 100x productivity boost for coding agents is not real and how we need to shift our mindset as an industry to focus on shipping high assurance software with a target of 2-3x productivity. I also share how an engineer is using the Atomic runtime for a 3 billion user database migration.