Ecco la traduzione in italiano, seguendo fedelmente tutte le regole stabilite (marchi, struttura Markdown, tag, blocco note, sostantivi propri e terminologia tecnica):
All'inizio di quest'anno, il nostro team in 8090 ha smontato il motore di fatturazione di una grande entità. Era composto da 18 milioni di righe di COBOL e Assembly che si accumulavano da prima che alcuni dei nostri ingegneri fossero nati. Nessuno lo capiva più nella sua interezza, ma utilizzando la nostra Software Factory, lo abbiamo reverse-engineered in più di 100.000 regole in inglese semplice in 40 giorni. Completando quel lavoro, ho capito perché l'espressione "software factory" veniva improvvisamente usata anche da tutti gli altri.
Il concetto viene appropriato perché implica un certo livello di affidabilità industriale che le aziende desiderano ma non ottengono. Le software factory hanno cinquant'anni di storia alle spalle, e la loro caratteristica distintiva è qualcosa di cui le aziende hanno più bisogno che mai: un sistema di produzione che garantisce l'output. Questo è in netto contrasto con una frustrazione crescente verso un insieme eterogeneo di strumenti che potenziano gli individui ma stanno rendendo l'intero sistema più caotico.
Il termine è più antico di quanto molti pensino
Hitachi ha aperto "Software Works" nel 1969 come una vera e propria fabbrica: un edificio dove il software veniva prodotto sotto controllo statistico di qualità, con tassi di difetti misurati per mille righe di codice, processi standardizzati e un team di gestione responsabile della qualità dell'output. Toshiba, NEC e Fujitsu hanno seguito l'esempio, e attraverso gli anni '70 e '80 queste software factory giapponesi hanno prodotto alcuni dei codici più affidabili mai scritti. I sistemi che hanno realizzato hanno fatto funzionare l'infrastruttura bancaria, ferroviaria ed elettrica per decenni.
Nel 2004, due architetti Microsoft hanno pubblicato un libro intitolato "Software Factories", sostenendo che il software dovrebbe essere costruito come si costruiscono le automobili: a partire da componenti provati, su linee di produzione ripetibili, con variazioni controllate dal design a monte piuttosto che risolte da interventi eroici a valle. L'US Air Force gestisce software factory oggi. Kessel Run costruisce e gestisce software mission-critical per il Dipartimento della Difesa, e quando quel software si rompe, ne risponde.
In sessant'anni, una cosa è rimasta costante fino a questa ondata di AI. Una fabbrica non è mai stato uno strumento o un trucco per aumentare la produttività, per quanto buono potesse essere. Una fabbrica era un sistema di produzione che prendeva input, produceva beni finiti e si assumeva la responsabilità della qualità di quei beni. In altre parole, Ford non ti ha mai venduto una chiave inglese, dei pezzi di ricambio e ti ha augurato buona fortuna. Ford ti ha venduto un'auto, e se l'auto si guastava, Ford la richiamava, perché era la sua fabbrica a produrla.
Questo è lo standard, e sostengo che le software factory moderne debbano conformarsi anch'esse a questo standard.
I cinque test
Una software factory deve superare cinque test. Se ne manca uno solo, si ha qualcos'altro. Quel qualcos'altro è molto probabilmente uno strumento per sviluppatori, che può essere utile, ma è un prodotto diverso con un obbligo diverso.
Test uno: una fabbrica parte dall'intento del business. L'input di una fabbrica è ciò di cui il business ha bisogno, espresso nel linguaggio del business: requisiti, regole, vincoli normativi, risultati desiderati. Se l'input, invece, è un ticket Jira scritto da un ingegnere per un altro ingegnere, si ha a che fare con un utensile elettrico avvitato su un processo esistente. L'intero scopo di una fabbrica è che il cliente descriva il prodotto e la fabbrica si occupi della produzione.
Test due: una fabbrica mantiene la coerenza sotto cambiamento continuo. Questo è il test più difficile, ed è quello di cui quasi nessuno nel mercato degli strumenti AI parla, perché i loro prodotti lo peggiorano.
Scrivere nuovo codice non è mai stato il collo di bottiglia nel software enterprise. Il collo di bottiglia è che un sistema reale viene cambiato ogni settimana da dozzine di persone. Ogni cambiamento è un'opportunità per il sistema di disgregarsi. I requisiti si allontanano dalla documentazione. La documentazione si allontana dal codice. Il codice si allontana dai test. Date a questa deriva vent'anni per accumularsi e si ottiene il motore di fatturazione che ho descritto all'inizio: 18 milioni di righe che nessuno capisce nella loro interezza, un contratto di manutenzione con fornitori che aumenta del 5-8% all'anno e un'organizzazione che non può più cambiare il proprio software senza paura.
La realtà è che la generazione di codice accelera la deriva. Se i tuoi agenti producono dieci volte più codice in base a specifiche che non vengono mantenute sincronizzate, stai inducendo una deriva a una velocità senza precedenti. Il problema delle 18 milioni di righe è stato costruito a mano in quattro decenni, ma flotte di agenti senza governance lo costruiranno in pochi anni.
Una software factory funzionante mantiene intento, specifica, codice, test e comportamento di produzione sincronizzati come un unico oggetto governato. Cambia il requisito e il codice cambia. Correggi il codice e il requisito si aggiorna. Chiedi a un fornitore di mostrarti questo ciclo chiuso, dal vivo, su un sistema reale. Se non può, sta vendendo generazione di codice. E sebbene utile, è una cosa diversa.
Test tre: una fabbrica opera indipendentemente da qualsiasi persona specifica. Uno strumento è valido tanto quanto la persona che lo impugna. Dai lo stesso agente di codifica a due ingegneri e otterrai output radicalmente diversi a seconda di chi scrive i prompt, chi rivede le differenze e chi coglie gli errori. Quella varianza è accettabile in uno strumento. È squalificante in un sistema di produzione. Una fabbrica dovrebbe produrre a velocità e qualità prevedibili indipendentemente da chi è in turno, che è esattamente ciò che i controlli statistici di Hitachi erano progettati per garantire: la qualità come proprietà della linea, non dell'operatore.
Il modo in cui una fabbrica raggiunge questo obiettivo è che la conoscenza si accumula nel sistema invece che negli individui. Quando una persona si unisce, la fabbrica le fornisce tutto ciò che ha già imparato. Quando una persona se ne va, nulla esce dalla porta. La maggior parte del software enterprise fallisce questo test in modo catastrofico. Il motivo per cui un motore di fatturazione diventa illeggibile non è il cattivo codice. È che la comprensione del codice risiede nelle persone, e nel corso di molti anni le persone cambiano. Se la loro conoscenza non viene mai catturata da un sistema, il sistema diventerà lentamente una scatola nera.
Per essere chiari, questo non significa che le persone non contino o che una fabbrica non richieda responsabilità. Una fabbrica ha sempre qualcuno di specifico che risponde per l'output. Semplicemente non dipende mai dal fatto che uno di loro sia insostituibile. Un sistema che ha bisogno di un eroe per funzionare non ha né responsabilità né una fabbrica. Ha un eroe, e gli eroi prima o poi trovano nuove avventure.
Test quattro: ogni unità di output è tracciabile. In una vera fabbrica, ogni parte ha un "numero di lotto". Quando qualcosa si guasta, lo si traccia attraverso la linea di produzione fino al lotto, alla macchina e al turno. Le industrie regolamentate richiedono esattamente questo dal software, ed è per questo che sono state le più lente ad adottare gli strumenti di codifica AI. "L'ha scritto il modello" non è una risposta che un revisore accetta. Una software factory produce la traccia di audit come sottoprodotto della produzione stessa: questa regola esiste a causa di questo requisito, approvato da questa persona, implementato in questa modifica, verificato da questo test, distribuito a questo orario. La provenienza deve essere integrata nella linea di produzione, il che significa che la documentazione scritta dopo i fatti non conta.
Test cinque: qualcuno è responsabile del prodotto finito. Questo è il test che separa una software factory da uno strumento per sviluppatori, perché è quello che la maggior parte dei venditori di strumenti non è disposta a soddisfare.
Una fabbrica spedisce un prodotto di cui si assume la responsabilità. Quando il motore di fatturazione calcola male un rimborso, quando il sistema di trading produce un numero sbagliato, quando la convalida della produzione approva un pezzo difettoso, qualcuno di specifico ne risponde, lo corregge e si fa carico dei costi. Ho letto molti contratti di strumenti AI e le sezioni sulla proprietà intellettuale si estendono per pagine, ma la sezione sulla responsabilità è di solito una frase, e quella frase dice che l'output è fornito così com'è e la verifica è un problema vostro. Questo è del tutto squalificante per una fabbrica.
Uno dei nostri clienti, un'assicurazione sanitaria quotata in borsa, ha trasformato le sue regole di pagamento dei sinistri in un pre-filtro deterministico e ha ridotto di oltre l'80% i sinistri instradati a un fornitore a pagamento per cattura, evitando più di 20 milioni di dollari in quattro anni. Numeri del genere si verificano solo quando la parte che esegue il lavoro è direttamente responsabile del risultato.
Cosa non è una fabbrica
Applica i test e molti che si definiscono una fabbrica sono, invece, qualcos'altro.
Gli agenti di codifica, per quanto bravi, sono strumenti. Prendono come input compiti di ingegneria, producono codice come output e trasferiscono tutta la verifica e la responsabilità agli ingegneri del cliente. Chiamare una flotta di essi una fabbrica non cambia questo.
I dashboard di orchestrazione degli agenti sono strumenti di supervisione. Rende più facile guardare gli agenti lavorare.
I benchmark sono strumenti di misurazione per gli strumenti. Un punteggio alto ti dice che uno strumento è bravo nei compiti di benchmark. Non può dirti se il tuo sistema rimane coerente dopo due anni di cambiamento continuo da parte di team misti di umani e agenti.
Perché la definizione conta adesso
Il costo di produzione del software sta crollando. E quando i costi di produzione crollano, il valore migrerà verso chiunque possa garantire l'output. Questo è successo in ogni processo di industrializzazione prima di questo e succederà di nuovo ora con l'AI.
Le startup che si aggrappano alla parola "fabbrica" lo capiscono istintivamente. Ma molte stanno cercando la credibilità della produzione industriale senza accettare l'obbligo che ha creato quella credibilità in primo luogo.
Quindi ignora demo e benchmark, e fai a ogni software factory una domanda: quando il sistema si rompe in produzione, chi risponde al telefono?
Nel caso di una software factory, la risposta deve essere "lo facciamo noi".
