DIALOGUE PRODUCES DECISIONS · DECISIONS PRODUCE STRUCTURE · STRUCTURE PERSISTS
Koòrdinated Thinking: una proposta di metodo per lavorare a un problema complesso con un modello linguistico senza che il ragionamento svanisca nel flusso della conversazione. Questo documento ne espone i principi, i limiti, e il razionale che lo sostiene.
Lavorare a un problema complesso con un modello linguistico di grandi dimensioni produce, quasi sempre, lo stesso esito: una conversazione lunga, ricca, e irrecuperabile.
Le decisioni vengono prese in mezzo al dialogo, motivate da uno scambio che poche ore dopo nessuno ricostruisce più. Il modello, alla richiesta successiva, non ricorda perché una certa strada era stata scartata; l'operatore umano nemmeno. Ciò che resta è il codice — o la bozza, o l'architettura — senza il ragionamento che lo ha generato. Quando serve rimettere mano al lavoro, si ridiscute da capo, e non è raro che la seconda decisione contraddica la prima senza che nessuno se ne accorga.
Il software ha imparato a conoscere questo problema prima dell'arrivo dei modelli generativi, e offre l'illustrazione più netta: il codice mostra cosa è stato costruito, mai perché in quel modo. Ma il fenomeno non è del software — è di qualunque lavoro in cui il prodotto finito non porta con sé le ragioni che lo hanno generato, dal testo di un contratto al piano di un progetto. Con l'IA il problema si aggrava ovunque, perché la velocità di produzione aumenta e con essa la quantità di scelte implicite che scorrono via nel flusso del dialogo. Si ottiene molto output, e nessuna fonte di verità durevole.
C'è un secondo aspetto del problema, meno evidente e più insidioso. Lavorare a un problema complesso con un modello linguistico tende ad amplificare la competenza — e la sua assenza — di chi guida il dialogo. Il modello asseconda l'interlocutore: raramente aggiunge una competenza che questi non possiede, perché senza quella competenza l'interlocutore non sa dove indirizzarlo, quali domande porre, né riconoscere una risposta sbagliata quando arriva. L'interazione funziona così quasi da cassa di risonanza delle abilità proprie di chi la conduce. È un effetto che la ricerca argomenta per i compiti complessi, e che trova riscontro nella pratica di lavoro con l'IA in team reali: la stessa deferenza del modello al feedback dell'utente amplifica la competenza in chi la possiede e le convinzioni errate in chi ne è privo; l'esperto usa ogni ciclo di raffinamento per migliorare la qualità, mentre chi è privo di competenza guida il modello, senza accorgersene, verso una mediocrità sempre più sicura di sé. La velocità del modello non colma il divario di competenza: lo può allargare.
Questo documento descrive un modo di lavorare che affronta il problema alla radice, e ne spiega le ragioni. Non introduce terminologia nuova dove ne esiste già di consolidata: il metodo si colloca all'incrocio di pratiche note — la specifica come fonte di verità, il registro delle decisioni, il documento come strumento di pensiero — e vi aggiunge la dimensione degli interlocutori digitali, distinti per ruolo e per architettura, impiegati per moltiplicare i punti di vista su un medesimo problema.
A questa composizione — e solo a questa, per non moltiplicare i nomi dove bastano quelli esistenti — il documento assegna un termine proprio: Koòrdinated Thinking. Il nome è deliberato. Lega il metodo allo strumento che lo incorpora (Koòrd) e ne dichiara la natura: non una tecnica nuova, ma il coordinamento di quattro dimensioni che, prese singolarmente, sono già patrimonio comune, e che restano scollegate finché qualcosa non le tiene insieme. Tutto il resto del vocabolario di questo documento è preso in prestito, per scelta, dalle discipline che lo fondano.
Il primo principio del metodo è che l'artefatto primario del lavoro non è il prodotto finito, ma un documento di specifica. Il prodotto — un programma, un documento, un piano, una decisione strategica — è un artefatto derivato: generato o verificato a partire dalla specifica, non viceversa. Negli esempi di questo documento il prodotto derivato a cui si pensa è prevalentemente codice software, perché è il dominio da cui proviene l'esperienza; ma il principio è generale in quegli ambiti in cui un artefatto si costruisce a partire da un intento.
Nel software questo principio ha un nome consolidato — spec-driven development: la specifica è la fonte di verità, il codice è ciò che ne discende. La ragione per cui l'idea, di per sé non nuova, è tornata attuale vale però oltre il codice. Quando un modello genera un artefatto a partire da istruzioni sparse in una conversazione, ogni ambiguità non risolta a monte si ripresenta a valle — sotto forma di un prodotto che funziona ma non fa la cosa giusta, di riscritture, di divergenza fra ciò che era inteso e ciò che è stato prodotto. Vale per un programma come per una relazione, una policy, un piano. Fissare l'intento in modo esplicito, prima di produrre, riduce questo costo: la letteratura sul software lo definisce "tassa sull'ambiguità", ma l'effetto è osservabile in svariati ambiti.
Nel metodo qui descritto la specifica è un documento di testo semplice, versionato, che cresce per iterazioni successive. Mentre si redige, vale una proprietà non negoziabile: l'additività. Una versione nuova non cancella il contenuto della precedente; lo integra. Questo vincolo protegge da un modo di fallire tipico e insidioso — la perdita silenziosa di contenuto fra due revisioni, dove un dettaglio deciso settimane prima sparisce senza che nessuno lo scelga.
Una specifica dichiara anche la propria portata: lo scopo generale che la inquadra e gli obiettivi, enunciati come elementi atomici e verificabili. Non è formalismo. Un modello linguistico, lasciato senza confini espliciti, tende a strafare — ad aggiungere struttura, casi, generalizzazioni che nessuno ha chiesto, nella direzione di ciò che sembra completo anziché di ciò che serve. È la versione, propria della macchina, di una tendenza che la gestione dei progetti conosce da tempo sotto i nomi di gold plating (aggiungere pregi non richiesti) e over-engineering: sintomi che si pagano in tempo, costo e complessità, e che le discipline gestionali indicano come causa ricorrente di ritardi e di risorse spese in funzioni che nessuno userà. La portata dichiarata è il confine contro cui questa tendenza si misura; è anche ciò che rende possibile all'operatore umano competente riconoscere lo strafare e correggerlo, perché fornisce il metro — questo era nello scopo? questo obiettivo era dichiarato?
A questo confine si affianca un criterio esplicito: sufficientemente buono. La disciplina del good-enough, formalizzata da Herbert Simon come satisficing, sostiene che sotto vincoli reali di tempo e informazione la scelta razionale non è la migliore in assoluto ma la prima che supera una soglia di adeguatezza dichiarata. Nella gestione d'impresa è un principio riconosciuto: rilasciare un prodotto "sufficientemente buono" consente di entrare sul mercato prima, e l'inseguimento della perfezione è documentato come causa di occasioni mancate. Il metodo adotta questo criterio come vincolo di progetto: la complessità va giustificata caso per caso, e "sufficientemente buono" è una decisione legittima, non un compromesso al ribasso.
Vale una precisazione, che è anche il punto di flessibilità del metodo: il good-enough non è universalmente superiore all'ottimizzazione — esistono contesti, e la letteratura li documenta, in cui spingere verso il massimo paga. Il metodo lo adotta come default perché il modo di fallire che deve correggere è l'eccesso, non il difetto, di struttura; ma il comportamento resta configurabile. La portata è il luogo dove si dichiara dove mettere l'asticella: "sufficientemente buono" ferma la ricerca al primo risultato valido; alzarla su una dimensione critica — chiedere non una soluzione accettabile ma la migliore raggiungibile su quell'asse — impegna tutti gli attori a un criterio più esigente, con i costi che ne conseguono. Si può modificare l'altezza della soglia, non il fatto che una soglia, sotto il vincolo di tempo e risorse, ci sia sempre. Il metodo non impone un determinato criterio; impone che il criterio, qualunque sia, sia dichiarato ed esplicito.
Una specifica si potrebbe scrivere tutta a monte, da soli, e poi passarla al modello perché la esegua. Il metodo fa un'altra cosa: costruisce la specifica in dialogo con il modello, per iterazioni.
Una volta chiarito uno scopo, a ogni passo il modello restituirà un piccolo insieme di domande di consolidamento orientate a raggiungere gli obiettivi, ciascuna con una raccomandazione motivata. L'operatore umano risponde quindi su questa base, frequentemente in modo conciso, a volte elaborando le proposte. Raggiunto uno stadio soddisfacente, la specifica viene aggiornata.
L'iterazione, però, genera più di quanto chiuda, e qui sta il secondo aspetto dello stesso processo. Alcuni passi del ragionamento fanno emergere questioni che non sono ancora decidibili — perché dipendono da una scelta a monte non ancora presa, perché richiedono un'informazione che manca, o semplicemente perché non è il momento per prenderle. Il metodo non le forza a una risposta prematura né le lascia cadere: le registra come punti aperti, voci esplicite e tracciate nel documento accanto alle decisioni chiuse. Iterare il ragionamento e annotare i sospesi che l'iterazione produce non sono due attività separate: sono lo stesso movimento. Si avanza dove il cammino è chiaro, si mette per iscritto ciò che resta aperto, e vi si torna quando una decisione successiva lo rende risolvibile.
La disciplina che governa un punto aperto è semplice: non bloccare il lavoro sul resto. Questo evita il modo di fallire opposto alla fretta — l'attesa indefinita di una risposta prima di procedere — che nel lavoro con l'IA è particolarmente costoso: sospendere il lavoro in attesa di una risposta, per poi procedere comunque quando questa non arriva, unisce gli svantaggi di entrambe le opzioni senza i vantaggi di nessuna. Tracciare il sospeso, invece, permette di procedere senza fingere una certezza che non c'è, e senza dimenticare la questione. Per questo i punti aperti non sono un difetto del documento ma una sua funzione, e insieme un indicatore della sua adeguatezza: una vecchia regola dei documenti di progettazione dice che se la parte dedicata alle conseguenze di una scelta è più corta della scelta stessa, probabilmente non si è finito di pensare. Il registro dei punti aperti è il luogo dove questa incompletezza è dichiarata invece che nascosta.
Questa forma non è un vezzo procedurale. Ha una funzione cognitiva documentata. La ricerca sulle "funzioni di forzatura cognitiva" nel lavoro assistito da IA suggerisce che obbligare chi lavora a impegnarsi esplicitamente con il piano — invece di scorrere direttamente al risultato — porti a esaminare passaggi che altrimenti si sarebbero saltati e a rimettere in discussione ciò che il piano dava per scontato. Il ciclo domanda–risposta–consolidamento è esattamente una funzione di forzatura di questo tipo: impedisce che l'operatore accetti passivamente l'output e sposta l'attenzione sul ragionamento.
C'è una seconda ragione, più semplice. Scrivere costringe a pensare. Chi ha una lunga consuetudine con i documenti di progettazione lo formula così: l'atto di scrivere una specifica aggiunge rigore a ciò che altrimenti resta intuizione vaga, e rivela le lacune del ragionamento sottostante. Il dialogo con il modello accelera questa rivelazione, perché le domande di consolidamento mettono a nudo le ambiguità mentre sono ancora economiche da risolvere.
Ogni scelta di sostanza presa durante il processo iterativo entra nella specifica come una decisione numerata: un identificatore stabile, l'enunciato della scelta, e la sua motivazione. Le decisioni si possono citare per numero, nelle conversazioni successive e nei documenti collegati, senza riaprire la discussione.
È la pratica che il software conosce come architecture decision records, in uso da oltre un decennio in organizzazioni di ogni scala; ma registrare le decisioni con la loro motivazione non è specifico del software — è ciò che ogni verbale di delibera, ogni nota di indirizzo, ogni registro di progetto tenta di fare. Il valore non sta nel registrare la scelta, ma nel registrarne il perché e i compromessi accettati. Una decisione senza motivazione perde valore col tempo: chi la incontra mesi dopo ha solo due opzioni, accettarla alla cieca o ribaltarla alla cieca, entrambe pericolose se il contesto nel frattempo è cambiato. Il numero serve proprio a chiudere le discussioni già chiuse — "è già stato deciso, si veda la decisione tale" — e a rendere visibile, a chiunque arrivi dopo, la ragione di ciò che vede. Questo vale in egual misura per un team umano, dove il registro previene che si rimetta in discussione ciò che era già stato risolto, che per un modello linguistico di grandi dimensioni.
C'è infatti un secondo beneficiario del registro, oltre a chi lo leggerà in futuro: il modello linguistico di grandi dimensioni stesso, durante il lavoro. Riproporre a ogni passo le decisioni già prese con la loro motivazione arricchisce il contesto del modello e ne guida il ragionamento, tenendolo lontano da un modo di fallire ben documentato nel lavoro iterativo con un modello — la state revisitation: il modello ritorna a soluzioni già esplorate e scartate senza riconoscere il ciclo, riproponendole con minimi slittamenti e nessun progresso reale. La causa nota è la mancanza di una memoria strutturata di ciò che è già stato percorso: il modello rileva la ripetizione solo fra i passi recenti e trascura quelli più lontani, e il fenomeno non è solo lessicale ma semantico — lo stesso territorio concettuale riattraversato con parole diverse. Un registro esplicito delle decisioni, tenuto nel contesto, è precisamente la memoria degli stati già visitati che al modello manca durante il dialogo: rende presente e citabile ciò che è già stato deciso e scartato, e sostituisce una traccia implicita e volatile con una esplicita e persistente. È lo stesso servizio che il registro rende al team umano — non rideliberare ciò che è chiuso — offerto qui alla macchina.
Il registro non è immutabile nel senso rigido del termine. Il metodo adotta la variante "documento vivente": una decisione superata non si cancella, si aggiorna in modo tracciato, così che la storia resti leggibile. Rivedere una scelta alla luce di nuove informazioni è salute del processo di redazione, non un fallimento da nascondere.
La specifica porta con sé alcuni ancoraggi ulteriori, minori nella forma ma funzionali nella sostanza. Il primo è un glossario: la fissazione esplicita del significato dei termini nel contesto del lavoro. Un modello linguistico, di fronte a una parola che ammette più sensi legittimi, tende a scivolare tra questi da un passo all'altro — usando "attore", "registro" o "sessione" ora in un'accezione ora in un'altra, tutte lecite in astratto ma non tutte corrette nel contesto. La letteratura riconosce questo scivolamento come semantic drift e ne indica una causa: in assenza di un ancoraggio esplicito, il modello inferisce il senso dei termini da pattern statistici di co-occorrenza anziché da una definizione autorevole. Dichiarare una volta che, qui, un termine significa questo e non altro elimina l'ambiguità alla radice e vincola tutti gli attori — esseri umani e modelli — allo stesso vocabolario.
Il secondo ancoraggio è un registro di riferimenti: i link a fonti, materiali e documenti esterni, fissati nella specifica una volta recuperati. Serve a un problema pratico e ricorrente: ciò che il modello ha trovato una volta non resta disponibile al passo successivo, e senza un ancoraggio esplicito verrebbe ricercato daccapo — con il costo, e il rischio di esiti diversi, di ogni nuovo recupero. Annotare la fonte nel documento la rende un punto fermo, citabile e ritrovabile, invece di un recupero da ripetere. È lo stesso principio che la ricerca chiama provenance: ogni affermazione risale alla fonte da cui proviene, così che possa essere verificata invece che indovinata di nuovo. Questi due ancoraggi, insieme al riscontro pragmatico da cui il metodo li ha derivati, trovano conferma in una letteratura che documenta il glossario di dominio e il registro delle fonti come correttivi efficaci di derive reali dei modelli.
Un terzo ancoraggio riguarda non ciò che la specifica dice, ma come cambia: il tracciamento delle modifiche fra versioni. Il documento non registra solo lo stato corrente, ma cosa è cambiato da una versione all'altra e perché. È l'estensione naturale del principio del documento vivente: come la decisione conserva la propria motivazione, così la specifica conserva la storia delle proprie trasformazioni. E risponde alla stessa tendenza del modello a ritornare involontariamente sui propri passi — un cambiamento tracciato è un cambiamento che non verrà rifatto all'indietro senza accorgersene.
Glossario, riferimenti e tracciamento completano un quadro che, a questo punto, ha una forma riconoscibile. Obiettivi e portata, punti aperti, decisioni, glossario, fonti, storia delle versioni: sono tutti artefatti dallo scopo affine — ricordare — ma di natura diversa dalla memoria implicita di un modello o di una persona. Sono una memoria funzionale esplicita: scritta, versionata, e soprattutto leggibile e verificabile tanto dagli esseri umani quanto dai modelli linguistici che vi operano. Là dove la memoria di un modello è volatile e opaca, e quella di una persona è limitata e privata, questi artefatti sono persistenti, condivisi e ispezionabili. Il metodo, in fondo, non fa che costruire deliberatamente questa memoria comune, un artefatto alla volta.
Una specifica additiva ha un rovescio: cresce. Versione dopo versione, decisioni, punti aperti, glossario, riferimenti e storia delle modifiche si accumulano, e un documento che non perde nulla diventa, col tempo, voluminoso. Se l'intero documento va tenuto nel contesto del modello a ogni passo, la sua stessa completezza rischia di lavorare contro il ragionamento — saturando l'attenzione con materiale che, in quel momento, non serve. Il metodo affronta questa tensione con due accorgimenti.
Il primo accorgimento è la distillazione: la produzione, su richiesta, di una versione condensata che presenta lo stato attuale del lavoro come specifica leggibile, ripulita della cronaca del processo — le versioni precedenti e le alternative valutate e scartate. Resta lo stato corrente con le sue decisioni motivate, il glossario, i vincoli e le fonti, quale memoria funzionale nella sua forma applicabile dall'esecutore. Non sostituisce il documento completo — lo affianca, per gli usi in cui serve la fotografia del presente e non il percorso che vi ha condotto. È lo strumento della fase di applicazione: chi realizza il prodotto lavora sullo stato corrente, non sulla storia di come è maturato. Distillare significa scegliere deliberatamente di non saturare il contesto quando la storia completa non è necessaria, mantenendo però intatto il documento sorgente — con tutta la sua storia tracciata — per quando lo è.
Quando la distillazione ometta qualcosa che sarebbe servito, e quanto ciò pesi rispetto al lavorare sul documento completo, è una valutazione difficile: ricade sul giudizio dell'operatore esperto, ed è ancora da indagare a fondo. Nell'uso pratico del metodo per lo sviluppo software si è rivelata discretamente affidabile: i casi in cui la sintesi avrebbe indotto errori si sono rivelati per lo più riconoscibili in anticipo, e una specifica ben formulata in questo ambito attenua il problema alla radice — la fotografia del presente si auto-sostiene perché poggia su fondamenta note che non richiedono di essere riformulate ogni volta. È lo stesso principio che, nei domini tecnici, fa emergere best practice, pattern e soluzioni consolidate a problemi ricorrenti.
Il secondo accorgimento agisce sulla stessa tensione da un'altra direzione: la partizione in sotto-specifiche. Una specifica principale che cresce oltre una certa soglia si divide in sotto-specifiche tematiche — il disegno dell'interfaccia, la progettazione del lato server, i dettagli operativi di ciò che è già in produzione — ciascuna coerente al proprio interno e collegata alla principale. La partizione tiene ogni documento entro una dimensione in cui resta leggibile e ogni contesto di lavoro focalizzato sul proprio tema, senza che chi lavora a un aspetto debba portare con sé il peso di tutti gli altri. È la stessa logica della distillazione applicata allo spazio anziché al tempo: mostrare, di volta in volta, solo ciò che serve.
Questi accorgimenti hanno una conseguenza che va oltre la leggibilità, e tocca il costo. Una specifica ampia tenuta interamente nel contesto è ciò che mette più facilmente in crisi un modello con finestra ridotta — tipicamente un modello locale, eseguito su hardware proprio. Distillazione e partizione riducono ciò che serve avere sotto gli occhi in un dato momento, e con esso il carico sul contesto; e poiché, come si è visto, una specifica ben fatta trasforma il lavoro a valle in un compito strutturato, quel compito diventa alla portata di un modello di dimensioni modeste. Qui il limite si rovescia di nuovo in fine: minimizzare la porzione di lavoro che richiede modelli grandi e costosi in produzione, e affidare a modelli locali — economici, eseguibili in casa, rispettosi dei dati — i compiti chiari e ben specificati che il metodo produce. La stessa disciplina che rischia di saturare il contesto è quella che, gestita, rende sostenibile lavorare con modelli piccoli dove prima servivano i grandi.
Fin qui il metodo descrive un lavoro fra un operatore umano e un modello. La dimensione che resta riguarda quanti interlocutori, e di che tipo. Il metodo agisce su due livelli distinti, che affrontano due problemi diversi e non vanno confusi.
Un problema complesso ha più di un punto di vista legittimo. Chi lavora da solo, o in un gruppo a cui manchino competenze specifiche, tende a esaminarlo da una prospettiva sola — quella che gli è più naturale. È il rischio che le scienze della decisione conoscono da mezzo secolo sotto il nome di pensiero di gruppo, e il cui antidoto storico è la diversità cognitiva: la presenza deliberata di prospettive, stili di ragionamento e ruoli differenti. Gli strumenti classici sono l'avvocato del diavolo — qualcuno incaricato di contestare la posizione prevalente — e l'indagine dialettica, dove team distinti generano e valutano alternative contrapposte. La motivazione di fondo è esplicita nella letteratura: si ricorre alla decisione collettiva proprio perché i problemi reali, complessi e ambigui, sono molto difficili da risolvere per un individuo solo.
Il primo livello del metodo dà agli interlocutori digitali personalità distinte — ruoli, competenze, atteggiamenti differenti — così che il singolo operatore, o il team incompleto, disponga di un tavolo di prospettive che altrimenti non avrebbe. Un interlocutore che scrutina i dettagli, uno che verifica i fatti, uno che pianifica, uno che contesta. È la trasposizione degli antidoti classici: prospettive assegnate deliberatamente per contrastare l'appiattimento su un unico punto di vista. Questo livello colma così le lacune di ruolo: le prospettive che mancano al tavolo.
Il secondo livello affronta un problema più profondo, e diverso. Un singolo modello linguistico, per quanto gli si assegnino personalità diverse, porta con sé i propri bias, i propri punti ciechi, la propria tendenza a cristallizzare il ragionamento lungo i binari appresi in addestramento. Cambiare la maschera non cambia la mente sottostante.
Per questo il metodo impiega, quando la posta lo giustifica — tipicamente nelle fasi di revisione — modelli di fornitori e architetture differenti sullo stesso problema. La ragione è documentata: modelli diversi, anche addestrati su dati simili, mostrano punti di forza, bias e modi di fallire distinti. Un gruppo di interlocutori costruiti sullo stesso modello resta correlato ai priori di quel modello — è una camera dell'eco; mettere al tavolo modelli eterogenei introduce bias induttivi complementari e fa emergere ipotesi e obiezioni che un singolo modello, da solo, non produrrebbe. Il primo livello moltiplica i ruoli; il secondo rompe la cristallizzazione idiosincratica del singolo modello. Entrambi rispondono all'effetto descritto in apertura: se il dialogo con un modello amplifica la prospettiva di chi lo conduce, mettere al tavolo più interlocutori — per ruolo e per architettura — è il correttivo strutturale, perché introduce prospettive che l'operatore, da solo, non saprebbe sollecitare.
Su entrambi i livelli il metodo è deliberatamente esplicito, perché la letteratura lo impone. Né le personalità né la diversità di modello garantiscono, da sole, un risultato migliore.
La conseguenza pratica è che né le personalità né i modelli sono un ornamento: sono oggetti di progettazione, il cui valore si misura sulla diversità dei ragionamenti che producono. È questa la ragione per cui il metodo separa nettamente il ruolo dell'operatore umano — che decide — da quello degli interlocutori digitali, che propongono, contestano e verificano: la decisione resta un gesto umano esplicito, informato da un ventaglio di posizioni più ampio di quanto un singolo punto di vista, o un singolo modello, potrebbe sostenere.
Alla base del metodo stanno quindi quattro principi — la specifica come fonte di verità, la decisione motivata e tracciata, il dialogo iterativo che apre e registra i propri sospesi, la molteplicità di interlocutori; si considerano poi portata e criterio del sufficiente, glossario e riferimenti come attributi che li rendono operativi in modo efficace. Tutti questi non sono indipendenti: funzionano perché si rinforzano a vicenda, come suggerisce l'esperienza accumulata nel loro impiego.
La specifica come fonte di verità dà al dialogo un luogo dove depositarsi: senza di essa, il dialogo evapora. Le decisioni numerate danno alla specifica una struttura di memoria: senza di esse, la specifica è un testo che si rilegge da capo ogni volta. I punti aperti danno al processo un modo di procedere senza mentire sulla propria incompletezza: senza di essi, o ci si blocca o si finge una certezza che non c'è. Gli interlocutori distinti danno al ragionamento un ventaglio di prospettive: senza di essi, la qualità del pensiero è limitata da quella di un solo punto di vista.
Ciascuno di questi pilastri viene da una pratica consolidata, nata per il lavoro fra esseri umani. Ciò che il metodo aggiunge è la loro ricontestualizzazione nel lavoro uomo–IA, dove ognuno agisce su due fronti insieme: disciplina un modo di fallire proprio del modello e, nello stesso gesto, struttura il ragionamento di chi lo guida.
| Pilastro | Origine | Guadagno sul lato umano | Modo di fallire del modello a cui risponde |
|---|---|---|---|
| Specifica come fonte di verità | spec-driven development | un luogo unico dove il ragionamento del gruppo si deposita e si ritrova | il ragionamento del modello evapora nel flusso |
| Decisione motivata e tracciata | architecture decision records | il team non rimette in discussione ciò che era già stato risolto | state revisitation: il modello ricicla soluzioni già scartate |
| Dialogo iterativo con sospesi | design doc, punti aperti | costringe l'operatore a esplicitare e a non fingere certezze | accettazione passiva dell'output, false certezze |
| Molteplicità di interlocutori | groupthink, indagine dialettica | apre la prospettiva dell'operatore oltre il proprio punto di vista | camera dell'eco, cristallizzazione del singolo modello |
Il registro delle decisioni tiene il modello lontano dal riciclare soluzioni scartate, e insieme evita al team umano di rideliberare ciò che è chiuso; la molteplicità di interlocutori rompe la cristallizzazione del singolo modello, e insieme apre la prospettiva dell'operatore oltre la propria. Nessun pilastro, da solo, copre tutti i fronti; è il loro funzionare insieme, sullo stesso artefatto persistente, a produrre ciò che la somma dei pezzi non dà: un ragionamento a più voci — umane e artificiali — che non si perde, e che resta eseguibile da chi verrà dopo. L'effetto osservato nell'uso è un salto di resa: poche persone assistite da modelli producono, con questo telaio, risultati che prima avrebbero richiesto team più grandi e tempi più lunghi. È una constatazione d'uso, non una misura; ed è in questa composizione, non nei singoli mattoni, che il metodo trova la propria ragione e il proprio nome.
Il risultato osservato è duplice. Da un lato, il lavoro diventa ripristinabile: una sessione interrotta si riprende dal documento, non dalla memoria; una persona nuova entra nel progetto leggendo il registro delle decisioni. Dall'altro, la qualità del ragionamento aumenta, perché il metodo forza a esplicitare ciò che altrimenti resterebbe intuizione, e perché espone il problema a più prospettive di quante un singolo operatore ne porti.
C'è un terzo effetto, che risponde direttamente alla cassa di risonanza descritta in apertura. Concentrando la competenza nella fase di redazione della specifica — e moltiplicando lì gli interlocutori — il metodo argina l'amplificazione dei limiti dell'operatore proprio dove sarebbe più dannosa. E il prodotto di quella fase, la specifica, resta come artefatto strutturato che chi viene dopo può eseguire senza dover riaffrontare il problema aperto: la competenza spesa una volta è riutilizzabile da chi non ce l'ha, umano o agente che sia.
Il metodo ha limiti, e alcuni sono già emersi nell'uso.
| Limite | Implicazione |
|---|---|
| Sovraccarico iniziale | Scrivere e mantenere la specifica ha un costo che non si giustifica per compiti brevi o usa-e-getta. Il metodo rende su lavori di durata e complessità, non sulla richiesta singola. |
| Saturazione del contesto | Il carattere additivo fa crescere la specifica, e una specifica ampia tenuta interamente nel contesto satura l'attenzione del modello. Distillazione e partizione (capitolo 7) mitigano il problema ma non lo eliminano; è il limite più tangibile del metodo, e mette in crisi prima di tutto i modelli con finestra di contesto ridotta. |
| Rischio di sovra-strutturazione | La disciplina può degenerare in apparato: decisioni dove basterebbe un'ovvietà, struttura dove serve prosa. È il rovescio della tendenza a strafare trattata al capitolo 3; il correttivo — portata dichiarata e criterio del sufficiente — riduce il rischio ma non lo elimina, e richiede il giudizio di un operatore competente. |
| Personalità non sufficienti | Come dichiarato, interlocutori distinti non garantiscono ragionamenti distinti. Il beneficio dipende dal disegno dei ruoli, non dalla loro semplice presenza. |
| Dipendenza dal giudizio umano | La decisione resta un gesto umano. Il metodo migliora l'informazione su cui la decisione si fonda; non la sostituisce, né supplisce alla mancanza di un criterio. |
| Evidenza di un solo dominio | L'esperienza che sostiene il metodo proviene dallo sviluppo di software, dove l'intento è formalizzabile in anticipo e l'errore si verifica presto. Che renda allo stesso modo dove manca un test di correttezza rapido, o dove intento e prodotto co-evolvono, è un'attesa ragionevole, non un fatto dimostrato. Va verificato dominio per dominio. |
C'è infine ciò che questo documento non afferma. Non sostiene che il metodo produca risultati migliori in senso misurabile su un compito arbitrario: sostiene che rende il lavoro tracciabile, ripristinabile e aperto a più prospettive, e che questi sono vantaggi di processo, distinti dalla qualità del singolo output. La generalizzazione oltre l'esperienza da cui è tratto va verificata caso per caso.
Un metodo di lavoro può restare una disciplina individuale, affidata alla costanza di chi lo pratica, oppure può essere incorporato in uno strumento che lo rende naturale invece che faticoso.
La ragione per costruire uno strumento dedicato è che ciascuno dei quattro principi, oggi, si sostiene a fatica sopra interfacce pensate per la conversazione singola. Il registro delle decisioni vive in un file mantenuto a mano; i punti aperti si perdono se l'operatore non è disciplinato; distillare la specifica, tracciarne le modifiche e partizionarla in sotto-specifiche sono operazioni interamente manuali; il tavolo di interlocutori — distinti per ruolo e, dove serve, per modello — richiede di orchestrare a mano più conversazioni e di tenerne separati i ruoli. È stata proprio questa fatica di gestione — sostenibile su un lavoro, insidiosa su molti — a far maturare l'idea di uno strumento dedicato. Uno strumento che assuma il metodo come propria forma nativa — con la specifica versionata al centro, il registro delle decisioni come struttura di prima classe, e più interlocutori digitali distinti che convergono su un unico documento condiviso sotto la guida di un operatore umano — trasforma una pratica esigente in un modo di lavorare ordinario.
È questa la giustificazione dello strumento di cui questo documento è il fondamento: non un ulteriore contenitore di conversazioni, ma la traduzione operativa di un principio — che il lavoro fra un operatore umano e un modello richiede un luogo dove depositarsi, una memoria delle proprie ragioni, e più di una prospettiva.
Il metodo poggia su quattro principi presi da tradizioni consolidate e composti in una forma unica. La specifica precede il prodotto ed è la fonte di verità. Le decisioni si numerano e si motivano, così che non si ridiscutano. I punti aperti si tracciano invece di bloccare o di essere nascosti. Gli interlocutori digitali si distinguono per moltiplicare le prospettive su un problema, con la consapevolezza dichiarata che la distinzione è necessaria ma non sufficiente.
Ciò che tiene insieme i quattro principi è una sola convinzione, verificata dall'uso: il lavoro con un modello linguistico produce valore duraturo solo se il ragionamento che lo genera viene fissato, strutturato e aperto a più voci — invece di scorrere via nel flusso di una conversazione che nessuno rilegge. A questa convinzione, e alla forma che le dà corpo, il documento ha dato un nome: Koòrdinated Thinking.
I riferimenti sono raggruppati per natura della fonte. La distinzione è deliberata: non tutte le fonti hanno lo stesso peso probatorio, e trattarle come equivalenti sarebbe scorretto. I paper accademici e le pratiche consolidate reggono le affermazioni di fondo; i position paper e le fonti osservazionali sono citati per ciò che sono — inquadramenti e osservazioni sul campo, non prove sperimentali controllate.
Piskala, D. B. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv:2602.00180. arxiv.org/abs/2602.00180 — Guida sistematica allo spec-driven development e ai suoi livelli di rigore. Paper divulgativo per professionisti, ampiamente citato nella letteratura successiva.
Nygard, M. (2011). Documenting Architecture Decisions. Cognitect. cognitect.com — Saggio originale che ha reso popolare l'Architecture Decision Record; radicato nel lavoro di Kruchten sulla decision view. Standard di fatto, adottato da GDS UK, AWS, ThoughtWorks.
Architectural Decision Records. Raccolta di modelli e pratiche (organizzazione ADR). adr.github.io — Punto di riferimento corrente per formati (Nygard, MADR, Y-Statement) e processo.
Sulla state revisitation e sull'assenza di una memoria strutturata degli stati visitati come sua causa: la letteratura recente sui modelli di ragionamento e sugli agenti documenta il ritorno ciclico a soluzioni già scartate, la natura semantica (non solo lessicale) del fenomeno, e la sua origine nella localizzazione della finestra di contesto e nell'assenza di un visited-set esplicito (studi su reasoning LLMs e degradazione del ragionamento negli agenti, 2025–2026). Paper accademici e osservazioni di pratica agentica; il fenomeno è ampiamente riscontrato nei loop agentici, la sua mitigazione tramite contesto strutturato è oggetto di lavoro corrente.
Sul semantic drift (lo scivolamento tra sensi legittimi) e sulla sua origine nell'inferenza da co-occorrenze statistiche in assenza di grounding esplicito, e sul glossario di dominio come correttivo: la letteratura recente sui modelli linguistici di grandi dimensioni in contesti industriali e sulla generazione strutturata documenta il fenomeno e misura l'efficacia dell'iniezione di un glossario di dominio e di un registro dati come metodi di riduzione delle derive (studi su riduzione delle allucinazioni e coerenza semantica, 2025–2026). Sul registro delle fonti: la nozione di provenance (ogni affermazione risale alla fonte da cui proviene, verificabile invece che rigenerata) è consolidata nella letteratura su grounding e memoria degli agenti. Paper accademici e resoconti di pratica; le misure quantitative provengono da singoli studi e vanno lette come indicative.
Slatton, G. (2025). Writing a good design document. grantslatton.com — Trattazione pratica del documento di progettazione come strumento che aggiunge rigore al ragionamento. Fonte professionale, non accademica.
Sulla funzione di forzatura cognitiva nel lavoro assistito da IA: studi sperimentali recenti mostrano che obbligare all'ingaggio esplicito con il piano riduce l'accettazione passiva dell'output (letteratura su cognitive forcing functions, arXiv 2026). Evidenza sperimentale iniziale, ancora in consolidamento.
Sul dibattito multi-agente e le personalità: la letteratura mostra che assegnare ruoli distinti diversifica le prospettive ma non aumenta le prestazioni in modo consistente, e che ragionamenti omogenei producono una "fissazione mentale" nonostante personalità diverse (Diverse Multi-Agent Debate e lavori correlati, 2024–2026). Paper accademici; risultati dipendenti dal disegno dei ruoli.
Sui modelli eterogenei: la ricerca su ensemble e dibattito fra modelli di fornitori diversi documenta bias e modi di fallire complementari, e la rottura della "camera dell'eco" dei team monomodello; con l'avvertenza che dove i modi di fallire convergono la diversità non aiuta (letteratura su heterogeneous LLM ensembles e mixed-vendor multi-agent, 2024–2026). Paper accademici, alcuni di dominio specifico.
Janis, I. L. (1972). Victims of Groupthink. Houghton Mifflin — formulazione originale del pensiero di gruppo e dell'avvocato del diavolo come correttivo.
Mason, R. O. (1969). A Dialectical Approach to Strategic Planning. Management Science, 15(8) — l'indagine dialettica come struttura decisionale. Fonti classiche, consolidate.
An, T. (2026). AI as Equalizer or Amplifier? Task Complexity as the Moderating Factor for Human Expertise in Hybrid Intelligence Systems. arXiv:2512.10961. arxiv.org/abs/2512.10961 — Sostiene che l'IA amplifica la competenza sui compiti complessi e la livella su quelli semplici e ben strutturati. Position paper basato su osservazioni strutturate di un piccolo team, non su uno studio controllato: da leggere come inquadramento, non come prova. Si àncora al "jagged frontier" di Dell'Acqua et al. (2023).
Evidenza empirica convergente sul divario esperto–novizio nell'uso di modelli linguistici di grandi dimensioni per compiti complessi (studi su cybersecurity, biologia di laboratorio, problem reframing, 2024–2026); ed evidenza contraria di livellamento su compiti strutturati (es. scoring assistito). Paper accademici; il quadro complessivo dipende dal tipo di compito.
Simon, H. A. (1955). A Behavioral Model of Rational Choice. Quarterly Journal of Economics, 69(1) — formulazione originale del satisficing e della razionalità limitata, per cui sotto vincoli di tempo e informazione si sceglie la prima opzione che supera una soglia di adeguatezza. Fonte classica (Simon, Nobel 1978).
Rittel, H. W. J. & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4(2), 155–169 — introduce la distinzione fra problemi "addomesticati" (tame, ben strutturati, con obiettivi e criteri di soluzione definiti) e problemi "malvagi" (wicked, la cui stessa formulazione muta mentre li si affronta). La classe dei problemi strutturabili a cui il metodo si rivolge corrisponde al primo polo di questa distinzione. Fonte classica.
Sul gold plating, l'over-engineering e lo scope creep come cause documentate di ritardi e costi in gestione dei progetti e sviluppo software: nomenclatura consolidata nella letteratura di project management; le stime quantitative sul costo di funzioni non utilizzate provengono da singole indagini di settore e vanno lette come tali, non come dati consolidati. Sul rovescio — contesti in cui la ricerca dell'ottimo (maximizing) paga più del sufficiente — esiste evidenza in ambito imprenditoriale (studi su stili decisionali e performance, 2017–2026): il quadro dipende dal contesto.