L’ANALISI
MOLT Sinai: cosa insegnano cinque mesi di agenti coding sotto controllo
Analisi pratica del case study MOLT Sinai di Cockroach Labs: gate prima del codice, revisori indipendenti, audit, costi, limiti e checklist replicabile.
In breve: Il dato utile non è la velocità dichiarata, ma l’architettura dei controlli: ogni modifica passa da pianificazione, revisione separata, test, audit e possibilità di escalation. Il case study mostra una traccia operativa concreta, ma non prova che lo stesso rendimento si trasferisca ad altri repository e non elimina il controllo umano sulle modifiche destinate ai clienti.
Il flusso che conta più del modello
Ogni issue attraversa ruoli distinti coordinati da etichette e workflow GitHub. Il piano deve essere approvato prima di scrivere codice, mentre un cambiamento di ambito obbliga a tornare alla revisione del piano.
I gate verificabili
I nuovi test vengono eseguiti anche con la modifica disattivata, così devono fallire prima di poter provare il fix. Un agente finale non rifà la code review: controlla invece approvazione, thread risolti, CI verde e cronologia pulita.
Numeri e costi da leggere con cautela
Cockroach Labs riporta oltre un milione di righe, 1.238 pull request e sette revert in quasi cinque mesi, con circa 135.000 dollari di token. Sono misure interne e includono un carico selezionato dai responsabili umani.
Dove il sistema si è inceppato
Le revisioni potevano divergere in molti cicli e gli agenti generavano troppo lavoro per se stessi. Il team ha quindi aggiunto soglie di escalation, limiti alle proposte e revisione umana obbligatoria prima del merge in produzione.
Condizioni e limitazioni
Il resoconto è un case study Cockroach Labs, non un confronto indipendente. Il test Db2 iniziale non ebbe revisione umana e deve ancora essere confermato; costi e risultati dipendono da repository, modelli, CI e criteri di ammissione specifici.
Checklist pratica
- Scegliere una classe di issue a basso impatto e definire chi può ammetterla.
- Richiedere un piano scritto e una revisione da un’istanza distinta prima del codice.
- Provare che i nuovi test falliscano quando la modifica viene disattivata.
- Imporre un limite alla dimensione delle patch e decomporre oltre la soglia.
- Registrare modello, token, durata, costo, decisioni e motivi di escalation.
- Fissare un circuit breaker per rework ripetuti e un blocco automatico se main si rompe.
- Mantenere approvazione umana finché dati indipendenti non giustificano un perimetro autonomo.