The real AI defect rate is unstated invariants, not bad functions

An essay on dev.to, "Shipping Assumptions: A Reliability Stack for AI-Generated Code," argues that the defining failure mode of AI-assisted development is no longer a bad function or an obvious syntax error but the space between components: boundaries, state transitions, failure modes, and invariants ^[1][2]. That should interest anyone who owns a merge gate, because the incident shape it describes is ordinary: code that linted cleanly, shallow tests that passed, an edge case that showed up in production, and then a question to QA about why they had not caught it ^[3]. The answer the piece gives is the part worth sitting with. QA never received a model of the system, only an implementation full of assumptions they were expected to reverse-engineer ^[4]. An invariant, in the essay's definition, is a condition that must remain true across every valid state of the system: an account balance cannot change without a corresponding transaction, a private object cannot become public without authorization, two successful writes cannot silently erase one another ^[5][6]. A linter reports whether code follows a set of local rules; a test reports whether selected examples produce the expected result; neither can tell you what the system must preserve unless someone states it first ^[7]. So the property that actually broke production is, by construction, outside the reach of the tooling that passed ^[8]. When invariants stay implicit, clean code can still assemble into an incoherent system, with the failure waiting in a transition, a retry, a race, or a boundary nobody thought to draw ^[9]. The argument avoids the usual nostalgia. Most teams never wrote formal specifications, and earlier software was full of hidden assumptions too ^[10]. What changed is the price of implementation: frameworks hid machinery, packages compressed years of expertise into an import, and generative AI extends the same trade by producing a plausible implementation before a team has agreed what the system is ^[11][12]. When nobody externalizes that intent, the generated code becomes the design by default, and QA receives the consequences downstream ^[13]. The missing layer, the essay says, is not more code review but a shared model between human intent and machine output ^[14]. It frames that layer as a stack answering three different questions, with no single technique covering it ^[15]. For structure it points to C4, a hierarchy of context, containers, components, and code that works like a map with zoom levels ^[16]; official guidance notes that context and container diagrams are sufficient for many teams, which is two of the four levels rather than a mandatory diagram set ^[17][18]. The reason to bother is that generated code is locally persuasive: a service can look complete while its ownership is unclear, an API can look tidy while its trust boundary is invisible ^[19]. AI can help draft the map from requirements or an existing codebase, but the essay is explicit that it should not get the final word ^[20]. Structure alone does not express behavior, so it does not say which states are valid, which transitions are permitted, or which conditions survive every interleaving ^[21]. For that it points to TLA+, which Leslie Lamport describes as a language for precise, high-level models above the code level, especially for concurrent and distributed systems, with the TLC model checker exploring behaviors and finding traces that violate the properties you claim hold ^[22][23]. The operational translation is a sequencing change rather than a new tool budget. If generated code becomes the design whenever intent goes unwritten, then the model has to exist before the merge to be a design at all; written afterwards it is documentation of whatever the generator chose ^[24]. Watch whether your written invariants get produced before merge or after the incident review, and watch whether AI-drafted maps get a human sign-off, since the essay withholds the final word from the model that drew them ^[20].