04 The iterative dialogue and its open points

04 · The iterative dialogue and its open points

A specification could be written entirely up front, alone, and then handed to the model to execute. The method does something else: it builds the specification in dialogue with the model, through iterations.

Once an aim has been clarified, at each step the model returns a small set of consolidation questions oriented toward reaching the objectives, each with a reasoned recommendation. The human operator then answers on that basis, frequently in a concise way, at times elaborating on the proposals. Once a satisfactory stage is reached, the specification is updated.

Iteration, however, generates more than it closes, and here lies the second aspect of the same process. Some steps of the reasoning bring up questions that are not yet decidable — because they depend on an upstream choice not yet made, because they require information that is missing, or simply because it is not the moment to settle them. The method neither forces them to a premature answer nor lets them drop: it records them as open points, explicit and tracked entries in the document alongside the closed decisions. Iterating the reasoning and noting the open questions the iteration produces are not two separate activities: they are the same movement. One advances where the path is clear, writes down what remains open, and returns to it when a later decision makes it resolvable.

The discipline governing an open point is simple: do not block work on the rest. This avoids the failure mode opposite to haste — the indefinite wait for an answer before proceeding — which in work with AI is particularly costly: suspending work while waiting for an answer, only to proceed anyway when it does not arrive, combines the drawbacks of both options with the benefits of neither. Tracking the open point, instead, lets one proceed without feigning a certainty that is not there, and without forgetting the question. For this reason open points are not a flaw of the document but a function of it, and at the same time an indicator of its adequacy: an old rule of design documents says that if the part devoted to the consequences of a choice is shorter than the choice itself, one has probably not finished thinking. The register of open points is where this incompleteness is declared rather than hidden.

This form is not a procedural affectation. It has a documented cognitive function. Research on "cognitive forcing functions" in AI-assisted work suggests that obliging the worker to engage explicitly with the plan — instead of scrolling straight to the result — leads them to examine steps they would otherwise have skipped and to reconsider what the plan took for granted. The question–answer–consolidation cycle is exactly a forcing function of this kind: it prevents the operator from passively accepting the output and shifts attention onto the reasoning.

There is a second, simpler reason. Writing forces thinking. Those with long familiarity with design documents put it this way: the act of writing a specification adds rigour to what otherwise remains vague intuition, and reveals the gaps in the underlying reasoning. The dialogue with the model accelerates this revelation, because the consolidation questions expose the ambiguities while they are still cheap to resolve.

---

← 03 · Declaring the boundaries, accepting good enough · The Method · 05 · The decision log →