Design by Contract == Design for Minds With Memory
A follow-up to Contract-Style Comments for the AI Coding Agent
Bertrand Meyer gave us Design by Contract in the 1980s. Preconditions. Postconditions. Invariants. The idea was elegant: software components should commit to what they expect and what they guarantee, so that violations fail hard and fast at the right boundary.
It worked. It still works.
But there was an assumption baked in that nobody had to say out loud, because it was so obviously true: the collaborator has memory.
The developer who writes the contract carries it forward. The compiler tracks types across files. The runtime enforces assertions in the context of state it has been accumulating since the process started. Even the junior engineer reading the code has yesterday's standup, last month's code review, and a vague memory of the conversation where someone said "never change that sort order."
Everyone in the room has context. The contract fills gaps. It does not have to fill everything.
Then came the stateless agent.
A stateless AI coding agent opens a session with nothing. No memory of what was built last week. No recollection of the bug that broke production. No accumulated understanding of why the string indexing goes from thin to thick instead of the other way around.
Every session is the first session.
This changes what a contract is for. Classical DbC contracts are correctness specifications — they catch deviations from a baseline the reader already understands. A contract written for a stateless agent must be something different: a complete reconstruction of intent, sufficient to work safely with zero prior context.
If the invariant is not written down, the agent does not know it exists. It will make a change that "works" — compiles, runs, produces output — and silently violates something that took three debugging sessions to figure out. Not because it is careless. Because it genuinely had no way to know.
The tweak is one sentence.
DbC assumes memory. Stateless agents require that the contract itself be the memory.
That is the missing axiom. It does not invalidate the original theory. Preconditions, postconditions, invariants — those are still the right vocabulary. But the completeness requirement changes fundamentally.
A human-facing contract can be terse. The reader fills in gaps from experience.
An agent-facing contract must be self-contained. Every invariant that matters. Every ID that must not be renamed. Every shape that callers depend on. The reason why, not just the what. The consequence of violation, not just the rule.
This is why the LAST REVIEWED timestamp matters. Why REVIEW TRIGGER lists the exact conditions that require an update. Why the document explicitly says this is law before the agent reads a single line of code. These are not stylistic choices. They are the mechanism that keeps the contract trustworthy as a cold-start document — the only handoff that survives a stateless boundary.
What this means in practice
You are not just writing documentation. You are writing the working memory of every future agent that touches this codebase.
If you write it well, the agent inherits your understanding. If you let it drift, the agent inherits your gaps.
The contract is not a safety net. It is the entire floor.
The original insight belongs to Jeffrey Sabarese (@ajaxStardust) and the collaborators documented at whatsonyourbrain.com. This is a natural extension of that work, surfaced in practice while building Finga Studio.