Design by Contract Gets a Second Life in the Age of Stateless AI Agents

Design by Contract is not new. Bertrand Meyer introduced it in the late 1980s with the Eiffel language, building software around a simple premise: every function makes a promise. It states what it expects from callers (preconditions), what it guarantees in return (postconditions), and what must always hold true (invariants). For decades the technique lived mostly in formal-methods textbooks and a handful of safety-critical codebases. A new essay from Rsnbl Facsimile, writing under the handle ajaxStardust, argues that AI coding agents are about to drag the idea back into the mainstream, and for a reason its original authors never anticipated.

The problem: agents have no memory

The pitch starts with a property of current coding agents that developers feel daily but rarely name. These systems are stateless. Each time an agent picks up a task, it reconstructs its understanding of a codebase from whatever happens to be in its context window. It does not remember yesterday's session. It does not carry forward the reasoning it did three files ago unless that reasoning was written down somewhere it can read again.

This is where the friction lives. A human engineer who has worked on a system for a year holds a vast amount of implicit knowledge: which functions tolerate null inputs, which ones quietly assume the database is already open, which edge cases were deliberately left unhandled because they cannot occur in practice. None of that lives in the code. It lives in the person. When a stateless agent arrives, that knowledge is simply gone, and the agent is left to infer intent from function names and surrounding code, which is exactly the kind of guessing that produces plausible-looking but wrong changes.

Contracts as working memory

The argument reframes Design by Contract not as a correctness tool but as a working-memory system for machines. If a function carries an explicit, structured statement of its preconditions and postconditions, an agent no longer has to reverse-engineer intent. It can read the promise. The contract becomes a durable artifact that survives between sessions, a place where reasoning that would otherwise evaporate gets pinned to the code it describes.

Consider a function that processes a payment. A traditional comment might say "handles payment." A contract-style comment says something an agent can act on: the caller must supply a positive amount and an authenticated session; the function guarantees that on success the ledger balance increases by exactly that amount and that no partial write occurs on failure. An agent modifying nearby code now knows the boundaries it must not violate. It is the difference between a sticky note and a signed agreement.

The essay leans on a distinction that matters here. Comments written for humans are conversational and forgiving. They assume a reader who already shares context and just needs a nudge. Contracts written for agents have to be machine-readable and complete, because the reader shares nothing. This pushes documentation toward a more formal register, closer to a specification than a note in the margin.

Why now, and what it changes

The timing is the interesting part. Design by Contract struggled to gain traction with human developers because the discipline felt like overhead. Writing precise preconditions for code you understand intuitively is tedious, and teams skipped it whenever deadlines loomed. The calculus changes when the primary consumer of those contracts is a tireless agent that genuinely cannot proceed safely without them. The cost stays roughly the same. The payoff multiplies.

There is a governance angle too. As more code gets written and modified by agents, organizations need ways to express constraints that machines will respect. A contract is enforceable in a way prose is not. You can check a postcondition automatically. You can reject a change that violates an invariant. This turns documentation from a passive description into an active boundary, a form of software governance that operates at the level of individual functions rather than policy documents nobody reads.

The skeptical question is whether this scales without becoming its own burden. Contracts that drift out of sync with code are worse than no contracts, because they actively mislead. The essay's answer is that agents themselves can help maintain the contracts they depend on, generating and updating them as part of the same workflow that changes the code. Whether that closes the loop or simply moves the trust problem one level up is the kind of thing that gets settled in practice rather than in argument.

The broader pattern

What ajaxStardust is describing fits a pattern showing up across AI infrastructure work. Techniques that were too expensive or too disciplined for humans are being reconsidered now that the labor of applying them shifts to machines. Strong typing, exhaustive tests, formal specifications, and now contracts all share this quality. They were always good ideas with poor adoption economics. Stateless agents change the economics.

For teams building with coding agents today, the practical takeaway is concrete. The documentation you write is no longer just for the next human. It is the memory your agents will operate from, and structuring it as explicit contracts rather than loose commentary gives those agents something firm to reason against. The discipline that felt like overhead for people may turn out to be the cheapest reliability investment available once machines are doing the building.