L’AI sta diventando molto brava ad aiutarci a lavorare su sistemi software che non conosciamo fino in fondo.
Può leggere migliaia di righe di codice, trovare il punto in cui intervenire, spiegare un errore, proporre una modifica e preparare dei test.
Per chi sviluppa software è un aiuto reale. Permette di orientarsi più velocemente, esplorare progetti sconosciuti e affrontare attività che prima avrebbero richiesto molto più tempo.
Ma apre anche una domanda:
Dopo una modifica realizzata con l’aiuto dell’AI, il sistema è diventato più comprensibile anche per la prossima persona? Oppure siamo soltanto riusciti a modificarlo senza comprenderlo davvero?
L’AI entra in sistemi già complessi
Il problema non nasce con l’AI.
Da molto tempo costruiamo sistemi software composti da tanti livelli, strumenti, configurazioni e regole accumulate nel corso degli anni.
Abbiamo costruito astrazioni potenti, ma spesso fragili.
Le astrazioni ci permettono di non doverci occupare ogni volta di tutti i dettagli di ciò che c’è sotto. Ed è anche grazie a loro che siamo riusciti a costruire sistemi così sofisticati.
La fragilità emerge quando ci concentriamo su ogni nuovo livello separatamente, senza riuscire più a tenere sotto controllo ciò che nasce dalle sue interazioni con tutti gli altri. Un componente può funzionare bene da solo e produrre comunque comportamenti inattesi quando entra a far parte del sistema.
Una parte di questa complessità è inevitabile. Un’altra deriva da decisioni stratificate, documentazione incompleta, responsabilità poco chiare o parti del sistema che nessuno ha più il tempo di semplificare.
Tradizionalmente, questa complessità ha avuto almeno una conseguenza evidente: prima o poi diventava difficile intervenire.
L’AI può cambiare questa situazione. Può fare da guida dentro il labirinto, ricostruendo ogni volta le relazioni che una persona faticherebbe a vedere.
Questo è utile. Ma proprio questa capacità potrebbe portarci a sentire meno l’urgenza di mettere ordine nel labirinto.
Una dinamica che sta appena iniziando
Non stiamo dicendo che oggi tutti i progetti software dipendano dall’AI per funzionare.
Siamo ancora in una fase iniziale.
Proprio adesso, però, si stanno formando nuove abitudini di lavoro. Sempre più spesso possiamo chiedere a un modello di:
- ricostruire come funziona una parte del sistema;
- trovare una regola nascosta;
- preparare una modifica;
- spiegare perché qualcosa non funziona;
- ricordarci come eseguire una procedura complessa.
Il rischio è che questa capacità ci porti ad accettare sistemi sempre più difficili da comprendere direttamente.
Se ogni volta possiamo chiedere all’AI di ritrovare la strada, potremmo sentire meno il bisogno di lasciare indicazioni chiare per le persone.
Dovremo pagare ogni volta per capire il nostro software?
L’uso dei modelli consuma risorse e spesso viene misurato attraverso i token, cioè le unità con cui si calcola la quantità di testo elaborata e, in molti servizi, anche il costo.
Non sappiamo se in futuro ogni singolo token costerà di più o di meno. E non è necessario prevederlo per vedere il problema.
Anche con prezzi più bassi, un sistema può richiedere un uso sempre maggiore dell’AI:
- più file da analizzare;
- conversazioni più lunghe;
- più tentativi;
- più controlli;
- più agenti che lavorano insieme;
- la stessa ricostruzione ripetuta a ogni nuova modifica.
Il punto non è soltanto quanto costa una singola richiesta.
Il punto è questo:
Vogliamo che comprendere e mantenere il nostro stesso software diventi un servizio che dobbiamo acquistare ogni volta?
L’AI può essere un acceleratore molto utile. Ma non dovrebbe diventare l’unico modo pratico per capire ciò che abbiamo costruito.
Una risposta convincente non è una prova
C’è poi un secondo problema.
I modelli linguistici non sono macchine della verità. Producono risposte plausibili sulla base delle informazioni che hanno ricevuto, ma possono sbagliare, perdere un dettaglio o ragionare partendo da un’ipotesi incompleta.
Un’AI potrebbe, per esempio:
- non vedere un file importante;
- non conoscere un comportamento presente solo nell’ambiente reale;
- interpretare male una regola;
- ignorare un caso particolare;
- proporre una modifica che sembra corretta, ma cambia un comportamento necessario.
Il rischio aumenta quando la stessa interpretazione viene usata per generare tutto il resto.
L’AI formula un’ipotesi, scrive il codice seguendo quell’ipotesi, prepara la documentazione e crea anche i test. Tutto appare coerente, ma potrebbe essere coerente con un’idea sbagliata.
Una supposizione temporanea rischia così di trasformarsi in una nuova “verità” del progetto senza essere mai stata verificata davvero.
Per questo vogliamo adottare una regola semplice:
L’AI può proporre una risposta. Non può essere anche l’unica prova che quella risposta sia corretta.
Le modifiche importanti devono essere controllate attraverso elementi indipendenti dalla conversazione: il comportamento atteso, il codice reale, test significativi, dati osservabili e il giudizio delle persone responsabili.
Usare l’AI per ridurre la complessità
Esiste però un percorso diverso.
Possiamo usare l’AI non soltanto per attraversare un sistema complicato, ma per lasciarlo un po’ più semplice di come lo abbiamo trovato.
Dopo una sessione di lavoro potrebbero rimanere:
- codice più chiaro;
- meno regole duplicate;
- responsabilità più facili da individuare;
- istruzioni brevi e aggiornate;
- controlli automatici;
- test costruiti sul comportamento desiderato;
- strumenti migliori per capire un problema;
- procedure di recupero che una persona può seguire.
In questo modo l’AI non si limita a fornire temporaneamente la comprensione che manca.
Aiuta a trasferire quella comprensione nel sistema e nelle persone che dovranno occuparsene in futuro.
La prossima volta l’AI potrà ancora essere utile, ma dovrebbe essere un po’ meno necessaria.
Perché partire dallo sviluppo software
Questa dinamica può forse riguardare in futuro anche altri ambiti. Ma non vogliamo dare per scontato che sia già così.
Partiamo dallo sviluppo software perché è uno dei luoghi in cui il cambiamento è più vicino e osservabile.
Gli sviluppatori stanno adottando rapidamente questi strumenti. Inoltre, ciò che viene generato non scompare alla fine della conversazione: il nuovo codice rimane, si collega al resto del sistema e dovrà essere compreso anche negli anni successivi.
Il software ci permette anche di fare esperimenti concreti.
Possiamo confrontare:
- quanto è difficile svolgere un’attività senza AI;
- quanto l’AI aiuta a completarla;
- che cosa possiamo semplificare grazie a quell’aiuto;
- se una persona riesce poi a ripetere l’attività senza la conversazione originale.
Il vero risultato non è soltanto aver prodotto più codice o aver concluso il lavoro più velocemente.
Il risultato è aver migliorato anche la situazione di chi verrà dopo.
Human-Scale Systems
All’interno di ABC vogliamo iniziare a esplorare questa direzione. La chiamiamo provvisoriamente Human-Scale Systems, cioè sistemi a misura di persone.
Non è ancora una nuova organizzazione, una piattaforma o una soluzione pronta.
È una domanda di ricerca e un percorso di piccoli esperimenti:
Possiamo usare l’AI per lasciare il software più facile da capire, verificare, modificare e recuperare anche senza la sessione AI che ci ha aiutato?
Vogliamo partire da casi reali e osservabili, raccontando anche ciò che non funziona.
Solo in seguito potremo capire se le stesse idee sono utili in altri contesti.
Più autonomia, non più dipendenza
L’AI può permetterci di fare cose importanti e di affrontare problemi che prima sembravano fuori dalla nostra portata.
Non vogliamo rinunciare a questa possibilità.
Vogliamo però adottare un principio mentre questi nuovi modi di lavorare stanno ancora prendendo forma:
L’AI dovrebbe lasciare dietro di sé più autonomia di quanta dipendenza crei.
Dopo che l’AI ci ha aiutato, dovrebbero rimanere più conoscenza, più strumenti verificabili e una maggiore capacità delle persone di continuare il lavoro.
Non soltanto una risposta convincente.
Non soltanto altro codice.
E non la necessità di chiedere di nuovo, ogni volta, come funziona ciò che abbiamo costruito.