The Case for 'Boring' Languages and Formal Methods in the Age of Agentic Coding
The rapid rise of AI coding agents has ignited a profound shift in how we think about programming language design and verification. While developers have traditionally optimized languages for human expressiveness and developer ergonomics, the "verification bottleneck" of agentic coding is forcing a pivot toward highly structured, "boring" languages and mathematical formal methods.
This paradigm shift is highlighted by Jane Street's strategic pivot to AI-assisted formal methods. Historically, Jane Street rejected formal verification because of its astronomical cost (e.g., seL4 took 25 person-years to verify 8,700 lines of C). However, the emergence of agentic coding has inverted this calculus: AI agents are excellent at generating code and writing boilerplate proofs, but they tend toward "slop"—producing overly complex code full of subtle edge cases.1 By shifting human effort from writing code to writing formal specifications, engineers can let AI agents generate the implementation and the proofs, which are then statically verified by a rigorous compiler or proof assistant.
The Verification Bottleneck and 'Slop' Prevention
As discussed in The 'Vibe-Coding' Hangover: AI Codebases, Maintenance Debt, and the Codex SSD-Burning Bug, "vibe-coding" (generating code via natural language prompts without deep engineering rigor) creates massive maintenance debt. Humans cannot realistically review or verify the thousands of lines of code that agents produce. Furthermore, as shown in LLM Coding Agents Suffer 'Constraint Decay' as Backend Complexity Scales, LLMs suffer from "constraint decay" as codebase complexity scales.
To combat this, the engineering community is splitting into two camps:
- The 'Boring' Language Advocates: Proponents of languages with extremely simple, rigid syntax (like Go, Elm, or Rust's borrow checker) that drastically limit the state space of possible code. This makes it easier for LLM agents to produce consistent, bug-free implementations because the language itself acts as a strict sandbox.
- The Formal Specification Pioneers: Organizations like Jane Street leveraging advanced type systems (such as OxCaml) and formal proof systems (such as Lean, Dafny, or Rocq). Here, the language provides universal guarantees (the $\forall$ quantifier), allowing developers to prove mathematical consistency between specification and implementation.
The Specification Problem: The New Frontier of Bugs
The ultimate limitation of formal methods is that the verifier only checks the consistency between the specification and the implementation—it does not check whether the specification matches reality. If the formal specification itself is "sloppy" or contains logical errors, the AI will perfectly verify a fundamentally broken system. Thus, as AI takes over code generation, the role of the software engineer is transitioning from a "coder" to a "specifier" and "translator" of real-world business requirements into mathematical axioms.
-
An instance of AI capabilities are no longer evaluated on code generation alone — they must prove their spatial reasoning on multi-dimensional datasets. — Generating raw, unconstrained code is trivial for LLMs, but verifying its architectural and spatial validity requires human-driven formal specifications. ↩︎