Cos’è una software factory AI? Contesto aziendale, software e agenti con Teriyaki

La software factory parte dal lavoro reale, si collega ai sistemi aziendali e trasforma il contesto in software e agenti AI che il team può verificare, usare e migliorare.

Un reparto individua un lavoro ripetitivo. Qualcuno costruisce una demo convincente. Poi arrivano le domande che decidono se software o agente verranno davvero usati: a quali sistemi possono accedere, quali regole aziendali valgono, cosa succede con le eccezioni, chi controlla le azioni e chi li mantiene dopo il rilascio? Una software factory serve a rispondere a queste domande durante la costruzione.

Cosa significa «factory» nel software

È un sistema ripetibile che trasforma un’esigenza reale in un rilascio verificato: uno strumento, un’applicazione o un agente AI. Entrano un compito, esempi, contesto aziendale e vincoli. Ne risultano software o agenti utilizzabili, test, traccia delle decisioni e un modo per migliorare la versione successiva. L’AI può accelerare più passaggi, ma un agente che scrive codice da solo non è la factory.

Uno strumento può eseguire un’operazione circoscritta; un agente può seguire un workflow a più passi, consultare il contesto e chiedere approvazione quando un’azione supera un confine. Entrambi richiedono prove del comportamento previsto. L’unità che conta è la modifica verificata che le persone possono usare, non la quantità di codice generato.

Perché scrivere codice più in fretta non basta

Quando la generazione diventa veloce, il collo di bottiglia si sposta sulla scelta del lavoro giusto, sul contesto affidabile, sulla verifica dei risultati e sull’adozione in produzione. Una factory utile deve quindi coordinare l’intero percorso di delivery, oltre a far lavorare un agente di programmazione. I risultati dipendono comunque dal compito, dal team e dai controlli adottati.

• Contesto: documenti, regole, permessi ed esempi reali devono essere disponibili e aggiornati.
• Specifica: una persona conferma il comportamento atteso e i casi che contano.
• Verifica: test e revisione devono avere indipendenza da chi ha prodotto la modifica.
• Esercizio: i rilasci richiedono responsabilità, log, costi, feedback e un percorso di correzione.

Connettori enterprise: vedere il lavoro reale

Il lavoro raramente vive in un’unica applicazione. Un ordine può stare nell’ERP, la fattura in un archivio documentale, l’eccezione in un’email e la regola di approvazione in una procedura. I connettori enterprise sono ponti controllati fra la factory e i sistemi che custodiscono questi pezzi. Consentono a software e agenti di usare le informazioni necessarie a un compito e, dove autorizzato, riportare il risultato nel sistema giusto.

Teriyaki si collega ai sistemi aziendali autorizzati tramite connettori enterprise. Ogni integrazione richiede un perimetro chiaro: quali dati legge, quali azioni può compiere, quali permessi rispetta e cosa viene registrato. Un connettore non dà all’agente il diritto di vedere tutto o modificare un record senza approvazione. Il confine va progettato con il team responsabile del processo.

Il company brain, spiegato semplice

Immagina una memoria di lavoro condivisa per l’azienda. Riunisce ciò che serve a capire un compito: documenti pertinenti, passi del processo, persone responsabili, decisioni già prese ed eccezioni imparate nel tempo. Conserva anche la provenienza delle informazioni e chi può usarle. È questo che intendiamo per company brain: contesto organizzato e aggiornato che software e agenti possono consultare secondo i permessi.

Se un agente deve capire se una fattura richiede revisione, la fattura da sola non basta. Servono anche l’ordine, lo storico del fornitore, la regola di tolleranza attuale ed eventuali eccezioni precedenti. I connettori portano questi elementi dai sistemi autorizzati; il company brain aiuta a collegarli al processo e alla fonte corretti. Se un elemento manca o è contraddittorio, l’agente deve segnalare il vuoto a una persona, non inventare una risposta.

Teriyaki: dal compito a software o agente

Teriyaki è la software factory AI di Hoplo. Il punto di partenza è volutamente quotidiano: una persona descrive un compito ripetitivo a parole e allega esempi reali. La factory chiede i dettagli mancanti, individua i sistemi e il contesto aziendale necessari, propone una specifica e i casi di test, e attende la conferma prima di costruire software o un agente.

Poi un agente di programmazione costruisce il software o l’agente. Un validatore separato lo controlla, anche su casi nascosti a chi lo ha costruito. Una persona approva il rilascio della Factory. La capacità risultante si usa come modulo, API, chat o tramite MCP, secondo il suo perimetro. Il pacchetto scaricabile contiene codice sorgente, test e specifica; esecuzioni e costi vengono registrati. Tempi ed esiti dipendono dal compito e dai suoi requisiti.

Dove il giudizio umano resta essenziale

Un validatore può rilevare errori rispetto a requisiti espliciti. Non può decidere da solo se un requisito rappresenta la policy aziendale giusta, se un dataset può essere usato o se l’azione di un agente ha conseguenze che il team accetta. Queste decisioni richiedono un responsabile. Deve confermare la specifica, stabilire quali azioni richiedono approvazione e poter fermare il workflow quando la realtà differisce dai casi di test.

Questo confine rende la factory più utile nel tempo. Quando una persona corregge un’eccezione, la correzione può diventare un nuovo test e una regola più chiara per i rilasci successivi. Quando cambiano modello o fonte dati, quei test aiutano a controllare le regressioni prima di sostituire la versione in uso. Il riuso vale solo se conserva ciò che è già stato imparato.

Un esempio pratico: controllare le fatture in arrivo

Immaginiamo un ufficio fornitori che confronta le fatture in arrivo con gli ordini. Un connettore legge l’ordine dall’ERP autorizzato; un altro porta la fattura. Il company brain fornisce la regola di tolleranza attuale e le eccezioni note. Il software può estrarre e abbinare i campi più lineari; un agente può seguire i casi incerti, spiegare la discrepanza e chiedere a una persona di decidere. Non dovrebbe approvare in silenzio un’eccezione che il team non ha definito.

Gli esempi diventano casi di test; le eccezioni definiscono la specifica e arricchiscono il contesto condiviso; chi revisiona stabilisce il confine del rilascio. Dopo l’uso, correzioni e nuovi casi migliorano la versione successiva. È un workflow illustrativo, non il racconto di un’installazione cliente o di un ritorno misurato.

Come iniziare senza creare l’ennesimo pilota isolato

• Scegli un compito frequente con un responsabile chiaro, un processo attuale noto ed esempi rappresentativi.
• Mappa sistemi, connettori e permessi necessari; individua le regole che il company brain può fornire e il contesto ancora mancante.
• Scrivi cosa significa «corretto», incluse eccezioni, azioni vietate e chi approva il risultato.
• Rilascia un software o un agente dal perimetro circoscritto, conserva codice e test, e osserva dove intervengono le persone.
• Misura l’intero workflow: tempo al rilascio utilizzabile, correzioni, adozione e costo per esecuzione. Confronta con il processo precedente.

Cosa misurare dopo il rilascio

Una demo veloce è una misura incompleta. Prima registra la situazione di partenza: quanto dura oggi il compito, quanti casi richiedono correzioni e dove le persone aspettano un passaggio di consegne. Poi osserva lo stesso workflow con il software o l’agente in uso. Il tempo risparmiato in un passo conta solo se l’intero lavoro finisce prima, senza trasferire oneri a un’altra persona.

Segui falsi positivi ed eccezioni mancate insieme ad adozione, costo per esecuzione, tempo al rilascio e sforzo necessario per aggiornare il sistema. Rivedi le misure con il team responsabile del processo. Se il risultato viene usato poco, la causa può essere l’accesso, la fiducia, un’eccezione assente o un workflow scelto male. La factory dovrebbe permettere di scoprirlo presto e cambiare rotta.

Il primo risultato dovrebbe rendere più semplice il compito successivo: software o agente riutilizzabili, test che proteggono le modifiche future e una conoscenza più chiara e governata del lavoro aziendale. È l’effetto cumulativo che una software factory dovrebbe produrre. Teriyaki dà a questo approccio un prodotto e un percorso di delivery; il team mantiene la scelta del lavoro e la decisione finale sul rilascio.