As large language models increasingly write our production code, a subtle but critical erosion is happening within engineering teams: the loss of shared mental models. Bryn, an engineer at Mulga, argues in a recent blog post that while AI has made code generation cheap, it has degraded the feedback loop that historically forced engineers to formalize their understanding of complex systems. To combat this, Bryn is turning to TLA+, a formal specification language created by Leslie Lamport, to act as the new architectural blueprint for AI-assisted development.

The Erosion of Shared Understanding

Historically, the act of writing code was where individual reasoning was picked apart and rearranged through design discussions and PR reviews. The codebase served as an objective distribution of this distilled technical intent. However, with the release of Anthropic's Opus 4.6 in February 2026, which Bryn cites as the turning point for viable AI-assisted development, many engineers have stopped writing code by hand. This shift has disconnected developers from the rigorous translation of ideas into verifiable logic, leaving teams relying on imprecise natural language prompts that fail to capture edge cases or system constraints.

TLA+ as the New Blueprint

Bryn proposes that TLA+ fills the gap left by disappearing code literacy. Unlike programming languages, TLA+ is based on formal mathematical notation, allowing engineers to model systems as state machines and exhaustively explore logical paths using the TLC model checker. This approach allows teams to capture intent without getting bogged down in implementation details. As Bryn notes, a well-written TLA+ spec is a human-readable artifact that forces authors to reason through system design, providing LLMs with a concrete benchmark to evaluate their generated implementations against.

Case Study: AWS EBS Specification

To demonstrate this workflow, Bryn developed an open-source TLA+ specification for a subset of the AWS Elastic Block Store (EBS) API. The resulting spec, spanning roughly 400 lines across four files, captures the volume lifecycle state machine more precisely than AWSโ€™s own 13-page English documentation. This rigorous modeling even uncovered undocumented behavior, such as a volume transitioning directly from 'creating' to 'deleting' without passing through an 'error' state. By abstracting away irrelevant details like byte-level storage, the spec focuses entirely on the observable behavior of the control plane, ensuring that the AI-generated implementation of Mulgaโ€™s Spinifex project adheres to expected AWS CLI behaviors.

Key Takeaways

  • Natural language is insufficient for specs: Prompts are often too imprecise to capture system constraints, leading to AI-generated code that drifts from the original intent.
  • Formal methods are now accessible: Tools like TLA+ allow engineers to specify intent mathematically, creating a verifiable contract for AI agents to implement.
  • Documentation gaps are real: Writing a formal spec can reveal undocumented behaviors in external APIs, as seen in Brynโ€™s discovery of AWS EBS state transition anomalies.
  • Code is becoming a construction detail: The future role of the engineer may shift from writing code to creating and maintaining the formal models that guide AI code generation.

The Bottom Line

Brynโ€™s experiment at Mulga suggests that the future of software engineering isn't about prompting better, but about specifying more precisely. If we want to maintain our grip on complex systems in an AI-driven world, we need to treat formal models as the primary artifact, not the code itself.