01 The problem of working with a model

01 · The problem of working with a model

Working on a complex problem with a large language model almost always produces the same outcome: a conversation that is long, rich, and unrecoverable.

Decisions are made in the middle of the dialogue, motivated by an exchange that no one can reconstruct a few hours later. At the next prompt the model does not remember why a certain path was discarded; nor does the human operator. What remains is the code — or the draft, or the architecture — without the reasoning that produced it. When the work has to be taken up again, it is re-argued from scratch, and it is not rare for the second decision to contradict the first without anyone noticing.

Software came to know this problem before the arrival of generative models, and offers its sharpest illustration: code shows what was built, never why it was built that way. But the phenomenon is not peculiar to software — it belongs to any work in which the finished product does not carry with it the reasons that produced it, from the text of a contract to the plan of a project. With AI the problem worsens everywhere, because the speed of production increases and with it the quantity of implicit choices that slip away in the flow of the dialogue. One obtains a great deal of output, and no durable source of truth.

There is a second aspect of the problem, less obvious and more insidious. Working on a complex problem with a language model tends to amplify the competence — and the lack of it — of whoever leads the dialogue. The model goes along with its interlocutor: it rarely adds a competence the interlocutor does not possess, because without that competence the interlocutor does not know where to steer it, what questions to ask, or how to recognise a wrong answer when it arrives. The interaction thus works almost as an echo chamber for the abilities of whoever conducts it. It is an effect that research argues for complex tasks, and that finds confirmation in the practice of working with AI in real teams: the very deference of the model to user feedback amplifies competence in those who have it and mistaken beliefs in those who lack it; the expert uses each cycle of refinement to improve quality, while whoever lacks competence steers the model, without realising it, toward a mediocrity that is ever more sure of itself. The model's speed does not close the competence gap: it can widen it.

A limit that becomes leverage

The same effect reverses on simple, well-structured tasks: there the model tends to level, bringing those with less experience to results close to an expert's. This is exactly the distinction the method leverages. Writing the specification of a complex problem is the hard phase, where amplification bites and competence is needed to guide; but once written, the specification turns the downstream work into a well-structured task — the kind the model levels. A well-made specification is therefore equally useful to a junior operator assisted by AI, to an automated agent, and to a model of modest size: all work on a task that is now bounded — no longer the open problem, even if the execution retains a difficulty of its own. By separating the drafting phase from the execution phase, the method moves competence to where it is needed and makes it reusable where it is absent.

This document describes a way of working that addresses the problem at its root, and explains why. It introduces no new terminology where established terms already exist: the method sits at the intersection of known practices — the specification as source of truth, the decision log, the document as an instrument of thought — and adds to them the dimension of digital interlocutors, distinct by role and by architecture, used to multiply the points of view on a single problem.

To this composition — and to this alone, so as not to multiply names where existing ones suffice — the document assigns a term of its own: Koòrdinated Thinking. The name is deliberate. It ties the method to the tool that embodies it (Koòrd) and declares its nature: not a new technique, but the coordination of four dimensions that, taken singly, are already common property, and that remain disconnected until something holds them together. All the rest of this document's vocabulary is borrowed, by choice, from the disciplines that ground it.

Two planes not to be confused

The method described here is not specific to software development: its principles hold in different domains — the drafting of a regulatory document, the design of an organisational architecture, the writing of a technical manual, the design of an operational process. It is proposed for structurable problems, those for which intent and constraints can be formalised before production. Toward the opposite pole, where the very definition of the problem changes as it is tackled, the method loses its grip to the extent that the problem resists structuring: it remains useful for fixing what is decided along the way, but with more mobile boundaries, more frequent iterations, and an effectiveness harder to demonstrate. The experience from which the method is drawn, by contrast, is domain-specific: the making of software. For this reason the concrete examples in this document — code, technical specifications, architecture decisions — come from there, and are stated as examples, not as the method's perimeter. Where the text speaks of "code" or "implementation", read "the product of the work, whatever it may be": software is the case the author knows best, not the only one the method can apply to.

---

The Method · 02 · The specification before the product →