Chi gira per San Francisco si è ormai abituato a vedere auto senza nessuno al volante. Si fermano al semaforo, aspettano che il pedone attraversi e aggirano i cantieri sulla carreggiata. Dal marciapiede sembra che l’auto sappia semplicemente guidare.
Ciò che lo rende possibile va oltre il modello che decide ogni manovra. L’auto opera dentro un insieme di componenti che lavorano insieme: una mappa dettagliata delle strade, sensori che si confermano a vicenda, un’area operativa delimitata, regole che vietano le manovre pericolose e un team remoto che gestisce i casi difficili. Il modello è una parte del sistema, e la fiducia viene dall’insieme.
L’IA che scrive codice ha lo stesso problema
Gli agenti di IA già redigono requisiti, propongono architetture, scrivono codice e generano test. Le capacità dei modelli crescono a ogni versione. Eppure un agente lasciato libero in un repository, senza il contesto di business e senza limiti, produce un lavoro di cui è difficile fidarsi. Non sa quali regole segue l’azienda, quali decisioni sono già state prese né dove non deve mettere mano.
Per questo la domanda più utile per chi guida la tecnologia è in quale struttura lavorerà il modello: con quale contesto, entro quali limiti e con chi a rivedere il risultato.
L’harness, la struttura attorno all’IA
Nel Tog Method questa struttura si chiama harness. È l’insieme di contesto, regole, agenti, pattern di architettura e verifiche che fa lavorare l’IA secondo gli standard dell’azienda. L’IA genera, le verifiche bloccano ciò che esce dalle regole e un professionista di Tog Lab rivede prima della pubblicazione.
Tutto parte dal contesto. I modelli di IA sbagliano meno quando ricevono il contesto di business, per questo ogni progetto parte da un Domain Context: l’unica fonte con le regole, i rischi e le decisioni che orientano ogni fase. Nell’auto, questo è il ruolo della mappa dettagliata delle strade.
Componente per componente
La corrispondenza tra le due strutture è quasi diretta. Ogni componente che rende sicura l’auto ha un equivalente nel ciclo di sviluppo.
| Nell’auto senza conducente | Nel Tog Method |
|---|---|
| Mappa dettagliata di ogni strada | Domain Context |
| Telecamere, lidar e radar ridondanti | Test automatizzati e TDD |
| Area operativa delimitata | Perimetro e permessi |
| Regole che vietano le manovre pericolose | Guardrail che bloccano le azioni distruttive |
| Team remoto per i casi difficili | Revisione di un professionista di Tog Lab sul piano e sulla pull request |
| Milioni di chilometri in simulazione | Evals e test di regressione prima del merge |
I sensori dell’auto si confermano a vicenda: se la telecamera non funziona, radar e lidar continuano a vedere la strada. Nel software questa funzione la svolgono i test automatizzati. Con il TDD il test viene scritto prima del codice, e l’agente termina il compito solo quando il test passa.
L’area operativa delimitata diventa perimetro e permessi. L’agente ottiene accesso solo alla parte del repository e agli strumenti che il compito richiede. Le regole che vietano le manovre pericolose diventano guardrail: le azioni distruttive, come cancellare dati o intervenire in produzione, vengono bloccate da una regola prima dell’esecuzione.
Il team remoto che gestisce i casi difficili corrisponde alla revisione di un professionista di Tog Lab, che avviene in due momenti: sul piano, prima che l’agente inizi, e sulla pull request, prima che il codice entri. E i chilometri percorsi in simulazione diventano evals e test di regressione, che verificano il comportamento prima del merge.
Niente passa alla fase successiva senza che una persona legga e approvi il documento della fase in corso.
Una persona approva ogni fase
Con l’AI-Accelerated, il modello di sviluppo con l’IA di Tog Lab, il lavoro attraversa sette fasi: contesto, requisiti, architettura, specifica, prototipo, codice e test, e infrastruttura. Ognuna produce un documento che qualcuno legge e approva. Gli agenti fanno il lavoro pesante tra una decisione e l’altra. Le persone del team del cliente e di Tog Lab decidono cosa entra e rivedono tutto il codice prima che vada in produzione.
Il livello di autonomia dell’IA ha un limite definito per ogni tipo di compito. Come nell’auto, l’autonomia cresce man mano che la struttura dimostra di reggere. In una proposta commerciale promettiamo solo ciò che è già stato validato presso un cliente.
Dove l’analogia si ferma
Ogni analogia ha un limite. L’auto decide in frazioni di secondo, nel mezzo del traffico, e un errore ha una conseguenza fisica immediata. Nel software c’è tempo tra generare e pubblicare: il codice passa da test, verifiche e revisione prima del merge, e una modifica si può annullare. Questo permette di mettere la persona nei punti decisionali del flusso, dove la sua approvazione ha più effetto.
C’è un’altra differenza importante. Nell’auto la struttura appartiene al costruttore. Con l’AI-Accelerated può girare dentro l’account cloud del cliente, con la sua chiave e il modello di IA che sceglie. Cambiare modello è una modifica di configurazione: contesto, regole, agenti e verifiche restano gli stessi, e il progetto non va rifatto.
Cosa cambia per chi commissiona il lavoro
Per chi commissiona sviluppo con l’IA, la struttura attorno al modello conta quanto il modello. In pratica questo significa tre cose.
- Segui il progetto attraverso i documenti di ogni fase e approvi prima che inizi la successiva.
- Repository, documentazione e chiavi sono intestati alla tua azienda fin dal primo commit.
- La scelta del modello di IA resta tua, e cambiare modello non obbliga a rifare il progetto.
Quando valuti un fornitore, conviene chiedere come organizza questa struttura: dove si trova il contesto di business, cosa bloccano le verifiche, chi rivede e cosa resta registrato.