Nel 2026, un team aziendale ha creato un agente che leggeva i ticket di gestione degli incidenti, ne generava autopsie e creava automaticamente elementi di riparazione. Un secondo agente dello stesso team ha cercato nuovi elementi di lavoro e ha aperto le bozze delle PR per ciascuno di essi per aiutare gli sviluppatori a iniziare. Uno sviluppatore ha esaminato uno di questi PR, lo ha trovato ragionevole, lo ha approvato e si è unito al ramo principale.

**Il problema era che il cambiamento era interamente inventato.**

L'agente aveva inventato una soluzione apparentemente plausibile per un problema che non esisteva nel modo descritto. Il cambiamento ha fatto regredire uno scenario di produzione reale. Un vero cliente se ne è accorto. Si è verificata un'interruzione.

Questo è il motivo per cui esiste la Costituzione dell’EDD.

La costituzione è un singolo file che governa ogni modifica non banale al codice base. Definisce come si presenta un cambiamento finito, quali prove deve portare, cosa deve coprire un audit mirato e come le regole stesse possono evolversi. Ogni agente e ogni essere umano che tocca il repository lo carica in ogni sessione. Il bar non fa altro che alzarsi.

Questo post illustra la Costituzione passo dopo passo: l'incidente che l'ha motivata, la domanda di progettazione a cui risponde, come è strutturata, come è stata scritta (e cosa abbiamo sbagliato all'inizio), come funzionano gli emendamenti e come il kit completo si sviluppa in un nuovo repository.

Passaggio 1: di cosa si tratta

L'incidente è l'illustrazione più chiara possibile della modalità di guasto che l'EDD è progettata per prevenire. L'agente non ha avuto allucinazioni in modo casuale. Ha prodotto un PR coerente, leggibile e formattato in modo professionale. Lo sviluppatore che lo ha esaminato ha fatto quello che fanno gli sviluppatori: ha letto l'intento, ha trovato l'intento plausibile e l'ha approvato. Il divario non era l'attenzione. La lacuna era l’assenza di prove. Niente nel processo di revisione richiedeva all'agente di dimostrare che il problema che dichiarava di risolvere esistesse effettivamente, che la correzione riguardasse un comportamento reale o che la modifica non regredisse nulla.

L'EDD risponde a questa lacuna con un unico requisito fondamentale: se l'agente non può dimostrarlo, il compito non viene svolto. La prova non è un riassunto. La prova non è un’affermazione di fiducia. La prova è un artefatto che può essere verificato in modo indipendente: un test fallito, un output dello scanner, uno screenshot prima/dopo, una differenza del piano. Il PR trasporta l'artefatto oppure il PR è incompleto.

La costituzione si trova su `docs/methodology/CONSTITUTION.md`. Ogni agente AI configurato sul progetto lo carica in ogni sessione tramite il proprio file di caricamento. Il corpo è neutrale rispetto all'agente: nessun nome di strumento, nessuna sintassi specifica della piattaforma. Definisce nove principi fondamentali, vincoli rigidi con ID slug stabili, il ciclo di implementazione in 10 passaggi, dimensioni dell'audit, criteri di accettazione delle prove per tipo di modifica, dettagli di banalità per il lavoro a basso rischio e la clausola di modifica.

Ogni vincolo rigido ha uno slug come "[HC-EVIDENCE-BEFORE]" e dichiara tre cose: la barra (cosa deve essere vero), la verifica (come viene verificata l'aderenza) e la fonte del modello (quale file di istruzioni elabora la guida all'implementazione).

Il ciclo di 10 passaggi è il cuore operativo: definire il fatto, scrivere un test che dimostri il divario, guardarlo fallire, acquisire prove prima, implementare, osservare il superamento del test, acquisire prove successive, verificare documenti, verificare le dimensioni dichiarate, quindi revisione umana. I passaggi da 1 a 4 vengono eseguiti prima di qualsiasi modifica dell'implementazione. L'ordinamento è costituzionale perché questo incidente mostra esattamente cosa succede quando non lo è.

Come ulteriore salvaguardia, l’EDD prende in prestito un principio fondamentale dal TDD: lo scenario deve essere dimostrato fallito prima che i lavori abbiano inizio. Una prova che supera la fine di una modifica non è di per sé una prova sufficiente: se il test è stato superato anche prima della modifica, l'agente potrebbe aver corretto qualcosa che non si era mai rotto. Questa è una modalità di errore specifica nei flussi di lavoro assistiti dall'intelligenza artificiale: un agente genera una soluzione apparentemente plausibile, la verifica sembra essere soddisfatta e la modifica viene fornita come se avesse risolto un problema reale. La richiesta di uno stato di errore documentato prima dell'inizio dell'implementazione colma questa lacuna. La fase precedente alla prova non è solo una base per il confronto: è la prova che il problema da risolvere era reale.

Di tutti i vincoli rigidi che sono stati introdotti attraverso la costituzione, due hanno rilevato più difetti di tutti gli altri messi insieme, e sono probabilmente l'aggiornamento più importante che EDD apporta a qualsiasi flusso di lavoro assistito dall'intelligenza artificiale: "[HC-EVIDENCE]" e "[HC-EVIDENCE-INTEGRITY]". Entrambi sono dichiarati in ".github/copilot-instructions.md" - il file caricato con entusiasmo che si trova nel contesto dell'agente in ogni sessione.

"[HC-EVIDENCE]" richiede che ogni PR contenga effettivi artefatti prima e dopo: non descrizioni di ciò che gli artefatti mostrerebbero, non riepiloghi di ciò che l'agente ritiene sia accaduto, ma l'output grezzo. "[HC-EVIDENCE-INTEGRITY]" va oltre: richiede che le prove contenute nel PR possano essere ricondotte al lavoro effettivamente svolto. Convalida che il PR contiene ciò che dice di contenere.

Insieme, questi due vincoli hanno rilevato centinaia di bug generati dall’intelligenza artificiale prima che raggiungessero la revisione. La modalità di fallimento da cui si guardano non è un'allucinazione nel senso ovvio. Si tratta di un comportamento più sottile: l'agente contrassegna un'attività come completata, scrive una descrizione PR sicura e include ciò che viene letto come prova, ma la prova è stata composta, non catturata. L'agente ha descritto come dovrebbe apparire l'output anziché eseguire il comando e includere l'output effettivo.

"[HC-EVIDENCE-INTEGRITY]" è particolarmente efficace nel catturare quello che potrebbe essere chiamato il modello "Non potrei farlo". Un agente che affronta un compito difficile o non familiare a volte affermerà che il compito è impossibile o fuori portata invece di tentarlo. L'affermazione è spesso inquadrata come una limitazione: uno strumento che non esiste, un vincolo che impedisce l'approccio, un ambiente che non supporta l'operazione. "[HC-EVIDENCE-INTEGRITY]" emerge questo: se l'agente afferma che un compito non può essere svolto, il PR deve mostrare la prova che il compito è stato effettivamente tentato e che l'ostacolo è reale. "Non ho potuto eseguire la suite di test" richiede un output del terminale che mostri l'errore, non una dichiarazione che l'errore si è verificato. Senza tale requisito, l'evitamento da parte dell'agente del lavoro difficile è invisibile al momento della revisione e l'attività risulta incompleta, come se fosse stata completata.

Passaggio 2: come siamo arrivati ​​qui

La Costituzione non è un accumulo di lezioni apprese. È la risposta a una domanda di progettazione posta all'inizio: come forzare un agente di intelligenza artificiale a dimostrare il proprio lavoro ogni volta, in un modo che non sia aggirabile e non dipenda dal fatto che un essere umano si ricordi di chiedere?

Rispondere a questa domanda ha costretto una scomposizione. La prova richiede di sapere come appare prima dell'inizio dell'implementazione, che ha prodotto la fase di documentazione. La prova richiede un test che fallisce prima della modifica e passa dopo - che ha prodotto la disciplina del test di fallimento/superamento. La prova richiede uno stato precedente che è stato catturato prima che l'implementazione toccasse qualcosa, che ha prodotto il requisito della prova precedente. La prova richiede un audit indipendente che copra ciò che l'evidenza per modifica non può - che ha prodotto le dimensioni dell'audit. E le prove devono sopravvivere al processo di revisione senza essere attenuate, il che ha prodotto il rigido vincolo secondo cui il revisore umano è l’ultimo cancello e l’unico cancello che non può essere automatizzato.

Il risultato è il ciclo di 10 passaggi. Ogni passaggio esiste perché la sua rimozione crea un buco attraverso il quale può passare il lavoro non dimostrato. Il ciclo non è una lista di controllo. È una catena causale.

Da lì la domanda è diventata: quali categorie di fallimento può produrre un agente che il ciclo non rileva per impostazione predefinita? Ciò ha prodotto vincoli rigidi. Il silenzio dei problemi di sicurezza durante il downgrade delle regole ha prodotto "[HC-SECURITY-LINT]". Un errore nella codifica dei caratteri in un artefatto distribuito ha prodotto "[HC-ASCII-PUNCT]". Ogni HC chiude una specifica classe di guasto con una specifica verifica automatizzata. Sono state rifiutate le regole che non potevano nominare una verifica: se un controllo non può essere automatizzato, la regola è aspirazionale, non costituzionale.

La domanda progettuale finale era: chi governa la costituzione stessa? La risposta è il cricchetto. La Costituzione non può che diventare più severa. Gli emendamenti devono portare la prova che il comportamento dell'agente migliora o mantiene. Il pavimento non si abbassa mai. Ciò significa che ci si può fidare della Costituzione nel tempo in un modo che una guida allo stile di vita non può fare: ogni versione è rigorosamente più forte di quella precedente.

Passaggio 3: come è strutturato

La costituzione segue un’architettura a tre strati.

**Livello 1: il corpo canonico.** Un file, `docs/methodology/CONSTITUTION.md`. Questa è la fonte della verità. È neutrale rispetto agli agenti: non fa ipotesi su quale strumento di intelligenza artificiale sia in uso. Definisce i principi, i vincoli rigidi, il ciclo, le dimensioni dell’audit, i criteri di accettazione delle prove, i limiti della banalità e la clausola di auto-miglioramento. Quando il corpo supera circa 250 righe, le regole che si applicano a uno specifico modello di percorso vengono inserite in file con ambito percorso, con un puntatore a una riga lasciato nel corpo.

**Livello 2: caricatori di agenti.** Ogni agente configurato riceve esattamente un file di caricamento nella posizione che l'agente carica con entusiasmo. Per GitHub Copilot è `.github/copilot-instructions.md`. Per Claude questo è "CLAUDE.md". Il caricatore importa o integra l'organo costitutivo a seconda di ciò che la piattaforma attualmente supporta. Il caricatore è ricavato meccanicamente dal corpo canonico; non è modificato manualmente. Se un progetto utilizza tre strumenti di intelligenza artificiale, ci sono tre file di caricamento, che restituiscono tutti lo stesso contenuto costituzionale.

**Livello 3: regole con ambito percorso.** Alcune regole si applicano solo a tipi di file specifici. Le regole di accessibilità e localizzazione si applicano ai file JSX e CSS, non ai modelli di infrastruttura. Queste regole risiedono nei file di istruzioni con un glob frontmatter:

L'agente carica questi file solo quando tocca un percorso corrispondente. Ciò mantiene limitato il budget del contesto carico di entusiasmo (regole principali sempre presenti, regole specializzate caricate su richiesta) e impedisce che le indicazioni sull'accessibilità emergano in una modifica del modello Bicep.

I file di supporto completano la struttura: corpi dei comandi `/constitute` in `.github/prompts/`, cartelle per funzionalità in `docs/methodology/features/`, scenari eval in `docs/methodology/eval/scenarios/` e `verify-sequence.yaml` nella root del repository che definisce l'ordinamento del gate CI.

Passaggio 4: come l'abbiamo scritto

**Il contesto è tutto. Ciò che non è nel contesto è morto per l'agente.**

Questa è l’intuizione più importante sulla scrittura di una costituzione per uno sviluppo governato dall’intelligenza artificiale. Una regola esistente in un file che l'agente non carica mai non esiste. Un vincolo rigido sepolto in un documento che viene caricato solo quando viene toccato un percorso di file specifico non è un vincolo rigido per nessun altro percorso. La Costituzione deve sempre essere contestualizzata e tutto ciò che deve sempre applicarsi deve vivere lì.

Ciò guida tre decisioni di creazione:

**L'ottimizzazione dei token non è negoziabile.** Il corpo canonico ha come target meno di 300 linee e 8.000 token. Ogni emendamento deve mantenere o migliorare l’efficienza simbolica: le regole prolisse che realizzano ciò che possono fare quelle concise vengono respinte solo per questi motivi. Questa non è una preferenza di stile. È un vincolo di carico. Se la costituzione supera il budget, gli agenti in finestre di contesto più piccole iniziano a troncarla e le regole troncate non sono regole.

**Caricamento condizionale tramite frontmatter.** Le regole che si applicano solo a tipi di file specifici vengono estratte dal corpo canonico e in file di istruzioni con ambito percorso con una dichiarazione glob frontmatter. Le indicazioni sull'accessibilità e sulla localizzazione vengono caricate solo quando l'agente tocca JSX o CSS. La guida dell'infrastruttura viene caricata solo quando l'agente tocca Bicep. Il corpo canonico mantiene un puntatore a una riga. L'agente carica il file con ambito percorso solo quando è rilevante. Non si tratta solo di efficienza: impedisce che le indicazioni sull'accessibilità emergano come distrazione durante una modifica dell'infrastruttura, insegnando all'agente a ignorarla.

Questo progetto non utilizza file di regole separati da frontmatter perché la costituzione è sufficientemente piccola da poter essere caricata interamente nel contesto: un singolo sviluppatore, un ambito mirato, un insieme di regole snelle. Per i team più grandi il calcolo cambia. Un progetto su scala aziendale che attualmente esegue EDD presenta 75 vincoli rigidi tra sicurezza, conformità, accessibilità e requisiti specifici della piattaforma. Integrare tutti i 75 documenti in un unico file, molto carico, spingerebbe la costituzione ben oltre il budget contestuale per la maggior parte degli agenti. La suddivisione del frontmatter mantiene il corpo canonico sotto le 250 righe - un puntatore di riepilogo per dominio - e carica in modo lento l'intero dettaglio della regola solo quando l'agente tocca i percorsi corrispondenti. La costituzione rimane veloce e snella. Le regole rimangono complete. Il costo del token rimane limitato.

**Emendamenti come unità di cambiamento.** Un emendamento costituzionale non è un cambiamento di parola in un file di ribasso. Si tratta di un pacchetto di tre artefatti: l'esatto delta della regola, il meccanismo di verifica che rileverà le violazioni future e uno scenario di valutazione comportamentale che dimostra il miglioramento del comportamento dell'agente. Tutti e tre spediscono insieme nello stesso PR. L'emendamento è atomico. Gli emendamenti parziali che promettono di aggiungere la verifica in un secondo momento vengono respinti: il dopo non arriva e la regola non verificabile è la decorazione.

**Scrivi le valutazioni e le rubriche prima di pensare di averne bisogno.** La valutazione è il cricchetto. Senza di essa, gli emendamenti vengono accettati in buona fede e la Costituzione va alla deriva. La rubrica valuta il comportamento degli agenti in scenari realistici. Ogni nuova regola produce almeno uno scenario. La rubrica produce un punteggio numerico. L'emendamento passa solo se il punteggio dell'albero di lavoro soddisfa o supera la linea di base.

**Documenta ciò che puoi e non puoi coprire. Non mentire a te stesso riguardo alla copertura.**

All'inizio, il vincolo rigido dell'accessibilità dichiarava che le nuove superfici dell'interfaccia utente interattive richiedevano una copertura e2e a11y utilizzando axe-core. Sembrava completo. In pratica è stato ingenuo. axe-core gestisce un sottoinsieme significativo di WCAG: rileva le etichette mancanti, la struttura dei punti di riferimento, l'ordine del focus e il contrasto nei casi in cui il DOM è completamente renderizzato e i colori vengono risolti. Non rileva la logica degli annunci dello screen reader, i modelli di carico cognitivo, i contratti complessi della tastiera dei widget o i problemi di contrasto che coinvolgono gradienti e nodi di immagini SVG in cui il colore calcolato non può essere risolto.

Avere "[HC-A11Y-GATE]" con axe-core nella verifica non significa che tutti i bug siano pari a zero. Significa che il set di regole specifico di axe-core viene eseguito rispetto al DOM renderizzato. La differenza conta enormemente nelle richieste di copertura PR.

La soluzione era la decomposizione. Invece di "axe-core clean", la verifica è stata riscritta per enumerare quali criteri di successo delle WCAG il set di regole axe-core copre in modo deterministico (1.1.1 per contenuto non testuale, 1.3.1 per informazioni e relazioni, 1.4.3 per contrasto dove risolvibile, 4.1.2 per nome/ruolo/valore) e che non hanno copertura automatizzata (1.3.3 caratteristiche sensoriali, 2.4.6 intestazioni ed etichette semantiche, tutti i criteri 3.x comprensibili). La sezione delle lacune note della dimensione di audit ora afferma esplicitamente: axe-core gestisce questi criteri; per questi è necessaria la scansione manuale. I revisori delle pubbliche relazioni vedono la copertura effettiva, non un riepilogo di falsa fiducia.

Il principio più ampio: per ogni verifica, documentare cosa rileva e cosa no. "Passaggi di lanugine di sicurezza" non significa che la base di codice sia sicura. "axe-core clean" non significa conforme alle WCAG 2.2 AA. Dai un nome al divario. Registrarlo nella dimensione di controllo. Richiedere la scansione manuale della superficie dello spazio vuoto. Non lasciare che il controllo automatizzato sostituisca il giudizio umano che non può sostituire.

Passaggio 5: come scriviamo gli emendamenti

Gli emendamenti non iniziano quasi mai come proposte di emendamento. Iniziano come insetti.

Un insetto emerge. La correzione viene applicata. Prima della spedizione, "/reflect" pone una domanda: si tratta di un caso isolato o manca qualcosa nella costituzione che avrebbe colto questo tipo di fallimento? Se la risposta è una tantum, la correzione viene fornita e questa è la fine. Se la risposta è che manca qualcosa, è allora che viene invocato "/constitute".

**Il percorso /reflect -> gap -> emendamento.** `/reflect` esamina la correzione e la classifica: gap di costituzione (nessuna regola copriva questa classe di errori) o gap di verifica (esisteva una regola ma nessun controllo automatico la applicava). Entrambi i percorsi portano a "/constitute". Una lacuna costituzionale produce un nuovo HC. Una lacuna di verifica produce una verifica più rigorosa su un HC esistente, in genere una nuova sottosezione della dimensione di audit, una nuova regola di scansione o un nuovo scenario di valutazione.

**I tre artefatti richiesti.** "/constitute" rifiuta di procedere senza tutti e tre nello stesso PR:

• **Delta regola.** La modifica esatta del testo, classificata: nuova regola, formulazione modificata, spostamento (sostituire e rimuovere la vecchia), sostituzione (alzare il livello con la vecchia come base) o ricollocazione. I duplicati vengono rifiutati a vista.
• **Meccanismo di verifica.** Il gate specifico che rileverà una violazione futura: un nome di test, un ID regola di lanugine, una sottosezione della dimensione di controllo, un controllo del codice di uscita dello scanner o uno scenario di valutazione comportamentale. Deve esistere al momento del commit. Le regole senza violazioni rilevabili sono decorative.
• **Scenario di valutazione.** Archiviato in `docs/methodology/eval/scenarios/<id>.md`. Descrive una situazione realistica in cui la vecchia regola produce un comportamento sbagliato dell'agente e la nuova regola produce la risposta corretta con punteggio.

**Il cricchetto.** Dopo che tutti e tre gli artefatti sono stati approvati, la modifica viene applicata a un ramo. La valutazione va contro le regole del ramo principale e le regole dell'albero di lavoro. La rubrica assegna entrambi i punteggi. Il passaggio richiede working-tree >= main in ogni scenario. La regressione blocca l'emendamento finché la formulazione non viene corretta. Il cricchetto non è facoltativo per gli emendamenti ovvi: possono comunque produrre sottili regressioni, e l’eval è l’unico meccanismo che li cattura prima che atterrino.

**L'effetto retroattivo.** Un emendamento fissa immediatamente la regola per il nuovo codice: l'ambito diff di "/audit" significa che il nuovo lavoro soddisfa i nuovi standard dal momento in cui arriva l'emendamento. Il codice preesistente che viola la nuova regola viene gestito da un PR di scansione separato messo in coda tramite "/rollout". Non è necessario che il sito di correzione corregga ogni istanza preesistente in linea. Ciò renderebbe gli emendamenti proibitivamente costosi. Invece: il nuovo codice soddisfa immediatamente la nuova barra, il vecchio codice è nella coda di implementazione e il PR di scansione porta la prova che le istanze preesistenti sono state risolte.

I quattro trigger validi per "/constitute" sono: un bug, un incidente, un'autopsia e un nuovo standard contrattuale. Le proposte con la scritta "probabilmente dovremmo..." senza nessuno dei quattro trigger vengono rifiutate e indirizzate invece a "/reflect".

Passaggio 6: come lo spieghiamo

Il Portable Methodology Kit ("EDD - Portable Methodology Kit.md") è un documento autonomo che consegni a qualsiasi agente AI con le istruzioni per eseguire "/begin". L'agente ispeziona il repository, esegue un passaggio di rilevamento, conferma con te i valori rilevati in un'unica tabella, chiede solo a cosa il rilevamento non può rispondere ed emette l'impalcatura minima praticabile per il tuo progetto. Una sessione per supportare l'intera infrastruttura EDD.

Il modo in cui lo spieghi dipende interamente dal fatto che tu stia iniziando da capo o inserendolo in una codebase esistente. I due percorsi sono abbastanza diversi da poterli trattare separatamente.

**Greenfield.** In un nuovo progetto, inserisci tutte le regole che ti vengono in mente nella costituzione fin dal primo giorno. Non hai un codice preesistente da controllare, nessuna pratica di squadra da proteggere, nessuna PR esistente per il nonno. Il costo del rigore fin dal primo giorno è quasi pari a zero. Aggiungi tutti i vincoli rigidi, tutte le dimensioni di controllo, tutte le regole con ambito percorso. Quindi esegui il ciclo. Ciò che scoprirai rapidamente è dove la costituzione crea attrito: tempi di costruzione esagerati perché ogni modifica innesca un audit completo, suite di test che sono lente perché la barra di copertura è impostata troppo alta per la complessità attuale, budget token che sono ristretti perché il corpo canonico è troppo prolisso. La severità del primo giorno fa emergere questi problemi nello sviluppo, non nella produzione. Poi si ottimizza: si stringono i cancelli della costruzione, si adeguano le regole di copertura, si riduce al minimo l’organismo costituzionale. Stabilizzi tutto in una volta, senza clienti interessati e senza interruzioni del team. Il costo a breve termine è un primo sprint leggermente più lento. Il vantaggio a lungo termine è una costituzione che è stata messa a dura prova fin dal primo impegno.

**Brownfield.** Una codebase esistente ha un team esistente, pratiche esistenti e PR esistenti che non seguono l'EDD. Lo svolgimento qui è incrementale e deve essere additivo, non distruttivo. L'obiettivo per il primo mese non è quello di aggiornare ogni decisione passata, ma di iniziare a generare le garanzie che rendono affidabile l'EDD: una dimensione di audit che coglie qualcosa di reale, un vincolo rigido che automatizza un controllo di revisione che il team stava già facendo manualmente, un ciclo di modifiche dall'inizio alla fine. Utilizzare i segnali di qualità esistenti del team come materia prima. Se il team ha già una regola lint per la sicurezza, aggiungi "[HC-SECURITY-LINT]" e puntala verso il cancello esistente: non cambia nulla per gli sviluppatori, ma ora il registro costituzionale riflette ciò che il cancello effettivamente applica.

La regola fondamentale nelle brownfield è: conquistare gli alleati prima di vincere le discussioni. Non promuovere una costituzione completa che tocchi ogni area del codice base nella prima settimana. Inizia con la dimensione a cui il team già tiene di più, solitamente sicurezza o affidabilità. Dimostrare che il processo di emendamento colma un divario reale già riscontrato in precedenza. Lascia che il composto a cricchetto venga da lì. Un team che ha visto l'EDD individuare un vero bug sfuggito al processo esistente farà spazio alla regola successiva. Una squadra che incontra l'EDD come un documento che dice loro che hanno fatto tutto di sbagliato lo aggirerà.

**Cosa sblocca.** La ragione per procedere attraverso lo sviluppo, sia greenfield che brownfield, non è il documento costituzionale. È ciò che la Costituzione consente una volta che il meccanismo di verifica è in funzione.

La qualità del codice di produzione e la velocità di consegna si combinano in un modo davvero controintuitivo se non l'hai visto. Gli ingegneri interrompono il cambio di contesto per eseguire il debug delle regressioni che il ciclo avrebbe rilevato. I cicli di revisione si accorciano perché le PR portano prove invece che spiegazioni. L'audit viene eseguito automaticamente e segnala i problemi che sarebbero stati rilevati dal revisore più esperto, consentendogli di concentrarsi sulle decisioni architetturali che richiedono effettivamente il suo giudizio.

La prova più chiara di ciò: un nuovo ingegnere che si unisce al team, con pieno accesso alla costituzione, alle specifiche delle funzionalità e al loop, può fornire un contributo a una funzionalità di qualità di produzione controllata in main entro 48 ore dal primo giorno. Non è un cambio di giocattolo. Non un aggiornamento della documentazione. Una caratteristica reale, con prove, che supera l'audit completo. Non è un colpo di fortuna e non è un ingegnere particolarmente insolito. I guardrail consentono a qualsiasi sviluppatore esperto di operare secondo lo standard di qualità del team fin dal primo giorno, perché lo standard di qualità è scritto, verificabile e applicato automaticamente piuttosto che portato come conoscenza istituzionale nella testa di chiunque sia in attività da più tempo.

Questa è la forma che raggiunge: un team in cui l'intelligenza artificiale esegue il lavoro di verifica, i guardrail rilevano le classi di errore che altrimenti sfuggirebbero alla revisione del codice e gli ingegneri dedicano il loro tempo a pensare ai problemi che richiedono effettivamente un giudizio ingegneristico.

Ciò è stato verificato su scale diverse: prima progetti individuali, poi team di medie dimensioni, quindi organizzazioni su scala aziendale. La meccanica regge su tutti e tre. Il costo di sviluppo è diverso (uno sviluppatore solista può saltare i registri dei requisiti e la revisione contraddittoria tra fornitori; un team aziendale ne ha bisogno). La cadenza delle modifiche è diversa (un progetto solista può richiedere settimane tra le invocazioni di "/constitute"; un team aziendale con più agenti che contribuiscono le esegue settimanalmente). Ma il core loop, il meccanismo e il requisito delle prove si comportano allo stesso modo indipendentemente dalle dimensioni del team. Il livello della qualità non fa altro che salire, e il meccanismo di verifica lo mantiene lì senza dipendere da chi risulta essere il revisore più esperto nella stanza quella settimana.

Ganci AI

La costituzione governa il comportamento dell'agente attraverso il contesto caricato. Gli hook lo applicano al momento dell'azione, prima che il lavoro sia già svolto e che un PR sia già aperto. Senza hook, una violazione viene rilevata durante la revisione: l'agente ha già scritto il codice, la PR esiste e risolverla significa rifare il lavoro. Con gli hook, l'intercettazione avviene prima di qualsiasi pressione di un tasto.

**Sia Claude Code che GitHub Copilot eseguono un hook al prompt di invio.** Quando arriva una nuova attività, l'hook si attiva prima che l'agente faccia qualsiasi cosa. Il suo compito: controllare se l'attività non è banale, quindi ricollegare l'elenco delle attività nel ciclo "/wow" - la sequenza EDD in 10 passaggi che l'agente deve seguire prima di spedire qualsiasi cosa.

Un agente che raggiunge il passaggio 5 senza completare i passaggi 1-4 ha violato il loop. L'hook stabilisce la sequenza all'inizio della sessione, non dopo il fatto.

**Codice Claude** inoltre attiva un hook pre-tool-call prima di qualsiasi scrittura di file, comando da terminale o operazione git. Non è possibile tentare un commit se i passaggi del ciclo non sono stati soddisfatti.

**GitHub Copilot** attiva inoltre un hook di creazione PR. Prima che la descrizione PR sia finalizzata, l'hook esegue "/audit" in modalità di auto-revisione, rilevando violazioni delle dimensioni, prove mancanti e piani di test vuoti prima che un revisore umano veda la bozza. Ciò che arriva al revisore è già preselezionato.

**Codex e altri agenti** non hanno una superficie hook nativa al momento della stesura di questo documento. Il fallback è un bot osservatore CI che commenta i PR immediatamente dopo la creazione e segnala le violazioni. È un dispositivo antiritorno, non un cancello di prima superficie: il lavoro è già svolto nel momento in cui viene attivato, quindi non impedisce la rilavorazione eliminata dai ganci.

Su un progetto con hook attivi, le violazioni vengono corrette in linea durante la sessione. L'agente coglie il divario, produce le prove e le include fin dall'inizio. Il tempo di revisione diminuisce. La rilavorazione scompare. La costituzione si sposta da un documento che l'agente legge a un vincolo all'interno del quale l'agente opera in tempo reale.

Appendice - La Costituzione completa

Quello che segue è l'effettivo `CONSTITUTION.md` di questo progetto: un singolo sviluppatore, un progetto di sviluppo assistito dall'intelligenza artificiale completamente autonomo. Governa ogni modifica non banale apportata a questa codebase. Questo non è un modello o un'illustrazione. Questo è il documento live caricato da ogni agente in ogni sessione.