No Tensile Strength to Measure

I recently read Martin Rosén-Lidholm's essay "Software Civil Engineering" and found it to be a stimulating piece on agentic engineering. The following is a response in which I play devil's advocate — not because I think the project fails, but because I believe the strongest version of the argument must survive the hardest objections.

Martin Rosén-Lidholm's essay "Software Civil Engineering" argues that agentic AI is the forcing function that will professionalize software development along the same lines that transformed building-as-craft into civil engineering. The central claim is that the difference between a 10% and a 10× productivity gain from AI coding agents lies not in better AI but in better engineering — formal specification, verification, and accountability structures that allow humans to move from "in the loop" (reviewing every agent output) to "on the loop" (governing the process). Event Modeling, made executable through the Decider pattern and extended with operational and policy constraint layers, provides the specification language for this transformation, operationalized through a Terraform-analogous lifecycle: Specify → Plan → Verify → Apply → Observe.

1. The Analogy and Its Limits

The Civil Engineering analogy is illuminating, and Rosén-Lidholm develops it with considerable care. But I see several structural disanalogies between civil engineering and software development that deserve closer examination:

The most fundamental is the physics constraint. Civil engineering operates against fixed physical laws. Steel has a known tensile strength. Gravity is constant. Concrete behaves predictably under compression. This is precisely what makes standardized material datasheets, simulation, and the entire verification apparatus possible — engineers are modeling a closed physical system with invariant properties. Software operates against human meaning. Requirements are not discovered like material properties; they are negotiated, contested, and frequently contradictory. The solution space for a bridge is constrained by physics into a relatively narrow range of viable designs. The solution space for a publishing system is constrained only by imagination, budget, and organizational politics — a combinatorially larger and fundamentally fuzzier domain. The essay's "provider profiles" (database latency characteristics, broker throughput) capture a thin slice of the substrate, but the deeper substrate of software — the human intentions, organizational processes, and domain semantics it must model — has no tensile strength to measure.

Requirements volatility compounds the problem. A bridge's requirements do not change after the foundation is poured. Software requirements change continuously — sometimes because users discover what they actually need only by using the system, sometimes because the business environment shifts, sometimes because adjacent systems evolve. The Specify → Plan → Verify → Apply → Observe lifecycle assumes a degree of specification stability that most product development does not enjoy. This is not a minor operational inconvenience; it is the reason agile methods displaced waterfall. The shift was not driven by laziness about specifications but by hard-won recognition that the feedback loop between deployment and understanding is irreducible. An Event Model is a snapshot of current understanding, but in volatile domains, the model must be revised faster than agents can implement and verify it, collapsing the lifecycle back into the iterative dialogue the framework was designed to transcend.

The verification asymmetry further strains the parallel. A bridge design can be fully verified against known physical laws before construction begins. Software verification is fundamentally harder — Rice's theorem tells us that non-trivial semantic properties of programs are undecidable in the general case. The essay's Given-When-Then contracts verify specified behavior, and the Decider pattern's purity enables simulation of that behavior at near-zero cost. This is a genuine contribution. But much of what goes wrong in software involves emergent behavior at integration boundaries, race conditions, unforeseen state combinations, and subtle interactions between components — precisely the phenomena that resist specification. Civil engineers can model a system completely because physics is finite; software state spaces are effectively infinite.1 The three verification loops the essay proposes catch violations of what has been specified, but they cannot catch what has not been imagined, and the history of software failure is overwhelmingly a history of failures of imagination rather than failures of implementation.

Finally, the legibility problem. The essay argues that Event Modeling solves the interface problem that plagued earlier formal methods — it is readable by domain experts, product managers, and engineers alike. This is a fair claim; Event Modeling is substantially more accessible than Z-notation or TLA+. But earlier specification approaches — UML, BPMN, use case diagrams, DDD context maps — made similar promises and largely failed to become a shared language between business and engineering. The question is not whether Event Modeling is better than its predecessors (it likely is) but whether any formal notation can capture business intent with sufficient fidelity that autonomous agents can implement it without the ongoing interpretive dialogue that characterizes real product development. The history of formal methods suggests a persistent gap between the richness of human intent and the precision of any notation, a gap that narrows but never fully closes.

2. The Social Substrate

These four disanalogies point toward a deeper one. Civil engineering specifications describe relationships between physical objects. Software specifications describe relationships between human intentions, organizational processes, and social conventions. A publishing system does not merely process submissions; it encodes assumptions about editorial authority, peer review norms, funder relationships, and institutional hierarchies. When the essay claims that the specification "is" the product, it treats these social structures as if they were as stable and measurable as load-bearing requirements. They are not. The same software with the same specification behaves "correctly" or "incorrectly" depending on how organizational processes evolve around it, how users reinterpret its affordances, and how power relations shift between the stakeholders it serves. A bridge either bears its load, or it does not. A compliance dashboard either reflects the organization's actual understanding of compliance, or it does not — and that understanding is a moving, contested, politically charged target that no Given-When-Then contract can fully pin down.

3. Naur's Challenge

These concerns are not new. In 1985, Peter Naur — widely known as one of the authors of the Backus-Naur Form — published "Programming as Theory Building," an essay that remains a philosophical challenge to any project that seeks to reduce software development to formal specification and mechanized implementation.2

Naur's central claim is that programming is primarily the activity of building a theory — in the sense of Gilbert Ryle's philosophy of mind — of how certain affairs of the world are mapped into a program. The theory resides in the programmers' heads, not in any artifact. Code, documentation, and specifications are secondary products of this theory-building activity, not the thing itself. A programmer who possesses the theory can do three things that someone without it cannot: explain how the program relates to the affairs of the world it handles, justify why each part of the program is the way it is rather than some alternative, and respond constructively to new demands by designing modifications that extend the program coherently. Crucially, Naur argues that this knowledge cannot be reduced to rules or formal documentation — the theory depends on a grasp of similarities between the world and the program that, like the recognition of faces or tastes of wine, cannot be captured in explicit criteria (Naur 1985, p. 231). From this follows a stark conclusion: a program lives as long as the team possessing its theory remains intact, and it dies when that team dissolves. Revival from documentation alone is essentially impossible; it is better to discard and rewrite.

Naur's discussion of program modification strikes at the heart of Rosén-Lidholm's lifecycle model. What looks like "modifying a program" is, on the Theory Building View, modifying the theory. The programmer must confront the new demand against the existing theory, assess the degree of similarity between the capabilities the program already provides and those the new demand requires, and then design a change that extends the theory coherently. Without the theory, modifications become patches — locally correct but globally incoherent, progressively destroying the structural integrity of the program. This is a precise description of what happens with AI-generated code today when agents make changes without grasping the deeper design rationale. The eval loops Rosén-Lidholm proposes can catch violations of what has been specified, but Naur's point cuts deeper: the most important kind of coherence — the kind that keeps a program alive over years of adaptation — is not the kind that can be captured in Given-When-Then contracts. It is the kind that lives in the relationship between the program and the world it models, mediated by human understanding of why the program is structured this way rather than some other way that would also pass the tests.

Naur wrote in 1985, long before LLMs. The interesting question is whether the existence of AI agents that can produce working code without possessing a theory changes his argument or confirms it. The evidence so far suggests it confirms it, in a way that is uncomfortable for both the optimists and the skeptics. Agents produce code that works locally but lacks coherence globally — exactly what Naur predicts for anyone operating without the theory. The programs agents produce are, in Naur's sense, born dead: no one possesses their theory, because no theory was ever built. They function, but they cannot be lived with, extended, or maintained in the way a theory-grounded program can.

Conclusion

None of this means that Rosén-Lidholm's project is without value. Event Modeling, the Decider pattern, and the discipline of formal verification all represent genuine advances — particularly for the subset of software development where domains are well-understood, requirements are stable, and the stakes are high enough to justify the overhead. But the essay's ambition extends beyond that subset. It claims a general disciplinary transformation analogous to the professionalization of civil engineering. Naur's challenge to that ambition remains unanswered: if the essential content of programming is a theory that resides in human minds and resists complete externalization, then no specification language — however elegant — can serve as a sufficient substrate for autonomous implementation.

This suggests that the real challenge for agentic engineering is not better specifications. It is figuring out what it means for a human-agent system to collectively possess a theory of the program — and whether such a thing is even possible, or whether theory remains irreducibly human, setting a permanent boundary on the autonomy we can safely grant to our agents.