Thesis

A domain model only protects code written by agents if it is held up against the intent as much as against the code

Info

Originally written in French. Translated by AI — the meaning has been preserved, not the prose.

Angle

A written domain model only protects the code agents produce if it holds its ground between two kinds of drift: frozen, it blocks any change to the product; aligned with the code, it rubber-stamps every mistake. What lets it hold is a third element, the intent behind the request, which tells an intended change apart from drift, and a loop that works both ways: the code makes the model change when the intent justifies it, and the model frames the code before it is written.

Synthesis

Tests and compilation check the behaviour the agent has just written, not the model it should have respected. The domain model fills that gap, but it is only useful if it steps in at several points: before the code, as in TDD, to frame the request; during and after, to judge the changes in the repository; before integration, to produce a consistency report.

The loop only holds through a strict division of labour. What can be exact — the inventory of changes, invariants turned into tests — is handed to scripts and assertions. What calls for judgement — is a class change a concept change? is a gap intended? — is handed to the LLM, with the intent as arbiter and evidence as a requirement. And every change to the model is handled explicitly, versioned and linked to its decision, so that the model remains a reference and not a mirror.

The result comes down to a division of roles: the code is authoritative on the implemented behaviour, the ontology on business meaning, the intent on why that meaning can change.

Tensions / contradictions

With the thesis that the code is the source of truth: here, the code must not automatically be right. The tension is resolved by a division of roles — the code is authoritative on behaviour, not on meaning — but it remains real when the intent has been lost.

Nothing has been measured yet. The volume of false positives from the semantic judgement, the running cost and the human attention needed to sign off changes all remain to be tested on real software changes.

Questions

  • Does the gain in consistency justify the cost of running and maintaining the loop, and on which kinds of software?
  • How do you stop the ontology from filling up with technical details as the loop feeds it from the code?