Abstract
La progressiva integrazione dei modelli linguistici di grandi dimensioni nei sistemi software non sembra destinata a produrre soltanto un'accelerazione dei processi di sviluppo, né può essere interpretata esclusivamente come una nuova fase nell'automazione della scrittura del codice. La trasformazione più rilevante riguarda, piuttosto, la struttura stessa del software applicativo e il modo in cui vengono distribuite al suo interno le funzioni di analisi, decisione e controllo.
Il software gestionale tradizionale è stato storicamente costruito traducendo processi, regole operative e percorsi di interazione in procedure deterministiche, definite in anticipo e codificate in forma esplicita. L'introduzione di sistemi fondati sulle capacità di analisi degli LLM rende invece possibile una diversa organizzazione dell'applicazione, nella quale una parte dei comportamenti non è più rigidamente prescritta, ma viene determinata dinamicamente sulla base del contesto, dei dati disponibili e dell'obiettivo espresso dall'utente.
In tale scenario acquista centralità il concetto di harness, inteso non semplicemente come insieme di meccanismi destinati a controllare un modello linguistico, ma come infrastruttura applicativa attraverso cui le capacità generali del modello vengono trasformate in capacità operative specifiche di un dominio. Dati, strumenti, permessi, vincoli, memoria, procedure di verifica, osservabilità e gestione del fallimento costituiscono così il nuovo spazio progettuale entro cui lo sviluppatore esercita la propria competenza.
La tesi sostenuta in questo contributo è che, nella misura in cui il software applicativo evolverà da sistemi costituiti prevalentemente da funzioni predefinite verso sistemi fondati su capacità componibili, il ruolo dello sviluppatore tenderà a spostarsi dalla programmazione diretta dei singoli comportamenti alla progettazione e all'orchestrazione dell'harness che rende tali comportamenti possibili, affidabili e governabili.
1. Introduzione
Per gran parte della storia dell'informatica applicata, sviluppare software ha significato trasformare un processo in una sequenza finita di istruzioni. L'analisi di un dominio conduceva alla formalizzazione delle sue entità, delle relazioni tra esse, delle regole che ne governavano il comportamento e dei percorsi attraverso cui l'utente avrebbe potuto interagire con il sistema. Il risultato di tale processo era un'applicazione nella quale le possibilità operative erano, in larga misura, definite anticipatamente dal progettista e successivamente tradotte in codice.
Il gestionale rappresenta una delle espressioni più compiute di questo paradigma. Le attività dell'utente vengono organizzate attraverso maschere, menu, procedure, filtri, report, workflow e funzioni specifiche, ciascuna delle quali incorpora una parte della conoscenza del dominio e delle modalità attraverso cui quella conoscenza deve essere utilizzata. Il sistema, in altre parole, non si limita a conservare informazioni, ma contiene una rappresentazione esplicita dei percorsi previsti per interrogarle, modificarle e trasformarle.
Tale modello ha garantito, e continua a garantire, livelli elevati di prevedibilità e controllo. Presenta tuttavia una rigidità strutturale inevitabile: ogni nuova funzione richiede che il relativo comportamento venga analizzato, modellato e implementato; ogni nuovo percorso operativo deve essere previsto in anticipo; ogni diversa modalità di interrogare il patrimonio informativo deve trovare una corrispondenza in una funzione esplicitamente progettata.
L'emergere dei modelli linguistici di grandi dimensioni introduce, sotto questo profilo, una discontinuità significativa. L'aspetto decisivo non consiste tanto nella loro capacità di produrre codice, quanto nella possibilità di utilizzare un componente software dotato di capacità generali di comprensione linguistica, analisi di informazioni eterogenee, correlazione semantica e selezione dinamica di strumenti.
È proprio questa capacità a rendere concepibile una diversa organizzazione del software applicativo. In luogo di un sistema nel quale ogni percorso deve essere descritto anticipatamente, diventa possibile progettare applicazioni nelle quali l'utente esprime un obiettivo e il sistema determina, entro limiti definiti, quali informazioni acquisire, quali strumenti utilizzare e quale sequenza di operazioni adottare per raggiungerlo.
Non si tratta semplicemente di aggiungere una componente conversazionale a un gestionale esistente. Si tratta, almeno potenzialmente, di modificare il principio secondo cui il gestionale stesso viene costruito.
2. Dalle funzioni alle capacità
Nel software applicativo tradizionale la relazione tra intenzione dell'utente e comportamento del sistema è generalmente mediata da una funzione esplicita. Se occorre visualizzare lo stato di una pratica, confrontare due documenti, individuare una determinata anomalia o produrre un report, il sistema deve possedere una procedura progettata per realizzare quell'operazione.
L'intelligenza applicativa risiede quindi, in larga misura, nella quantità e nella qualità delle funzioni che il software mette a disposizione.
L'impiego degli LLM consente di ipotizzare un'organizzazione differente, nella quale il sistema non venga costruito esclusivamente attorno a funzioni discrete, bensì attorno a capacità generali utilizzabili e combinabili in funzione del contesto. Comprendere una richiesta, estrarre informazioni da un documento, interrogare una base dati, confrontare fonti differenti, riconoscere incongruenze, produrre una sintesi o individuare lo strumento più adeguato a completare un'operazione cessano di essere necessariamente funzioni autonome e possono diventare capacità elementari di un sistema più ampio.
La differenza non è soltanto terminologica.
Nel primo caso il progettista definisce preventivamente il percorso che conduce da una richiesta a un risultato. Nel secondo caso definisce un insieme di possibilità operative e le condizioni entro cui esse possono essere utilizzate, lasciando che la sequenza concreta delle operazioni venga determinata sulla base della situazione specifica.
Si consideri, a titolo esemplificativo, un sistema amministrativo nel quale un operatore desideri individuare le pratiche che rischiano di superare i termini previsti e comprenderne le ragioni. In un gestionale tradizionale tale esigenza dovrebbe essere soddisfatta attraverso una funzione dedicata, costruita combinando interrogazioni, filtri, regole e modalità di rappresentazione definite in anticipo. Un sistema fondato sulle capacità di un LLM può invece interpretare direttamente l'obiettivo dell'utente, interrogare le fonti necessarie, acquisire i documenti rilevanti, mettere in relazione date e stati procedimentali e restituire una valutazione motivata.
Il punto di interesse non risiede nella maggiore naturalezza dell'interfaccia. Risiede nel fatto che il percorso necessario a raggiungere il risultato non deve necessariamente coincidere con una procedura progettata preventivamente in tutti i suoi passaggi.
Da questo punto di vista, la possibilità più radicale introdotta dagli LLM consiste nel passaggio da un software nel quale vengono programmate funzioni a un software nel quale vengono rese disponibili capacità.
3. L'harness come nuova struttura applicativa
È all'interno di questa trasformazione che il concetto di harness assume un significato più ampio rispetto a quello tradizionalmente associato al collaudo o, più recentemente, ai meccanismi di controllo di un modello linguistico.
L'harness può essere inteso come l'insieme delle strutture attraverso cui le capacità generali di un modello vengono rese utilizzabili all'interno di uno specifico dominio applicativo. Esso definisce il perimetro informativo e operativo entro cui il sistema può agire e stabilisce le condizioni necessarie affinché un componente probabilistico possa partecipare a processi che devono continuare a soddisfare requisiti di affidabilità, sicurezza e verificabilità.
Il modello, considerato isolatamente, possiede capacità generali. Non conosce tuttavia, se non nella misura in cui gli vengono rese disponibili, le fonti informative corrette, le autorizzazioni dell'utente, lo stato corrente dei processi, i sistemi attraverso cui effettuare determinate operazioni, i limiti normativi del dominio o i criteri con cui un risultato deve essere considerato accettabile.
Sono precisamente tali elementi a costituire l'harness.
La gestione del contesto determina quali informazioni debbano essere recuperate, da quali fonti e con quale priorità. La definizione degli strumenti stabilisce le modalità attraverso cui il modello può interagire con database, API, repository documentali o altri servizi. I sistemi di autorizzazione circoscrivono ciò che un determinato soggetto può conoscere o modificare. I vincoli formali e le procedure di validazione riducono lo spazio delle azioni ammissibili. La memoria e la gestione dello stato garantiscono continuità ai processi che non possono esaurirsi nella singola interazione. Le procedure di verifica consentono di distinguere un risultato plausibile da un risultato utilizzabile. L'osservabilità permette, infine, di ricostruire le operazioni eseguite e le informazioni che hanno condotto a una determinata conclusione.
Considerati nel loro insieme, questi elementi non costituiscono un involucro accessorio del modello. Costituiscono una parte sostanziale dell'applicazione.
Da questo punto di vista, affermare che il valore si sposti dal modello all'harness non significa sostenere che il modello sia irrilevante, ma riconoscere che la capacità generale offerta da un LLM acquisisce valore applicativo soltanto quando viene inserita in una struttura capace di trasformarla in comportamento operativo.
4. Lo spostamento del fattore differenziante
I modelli linguistici sono destinati a essere sempre più diffusi, accessibili e, in molti casi, intercambiabili. Organizzazioni diverse possono utilizzare modelli appartenenti alla stessa classe di capacità, talvolta persino lo stesso modello, senza per questo ottenere sistemi equivalenti.
La differenza dipende da ciò che viene costruito intorno ad esso.
Un harness incorpora infatti conoscenze che non appartengono al modello generale e che difficilmente possono essere acquistate come un servizio standardizzato. Vi risiedono le fonti informative di un'organizzazione, la struttura dei suoi processi, le regole autorizzative, le modalità di interazione con i sistemi esistenti, i vincoli del dominio, le eccezioni emerse nell'esercizio reale e i criteri attraverso cui viene valutata la qualità di un risultato.
In questo senso, l'harness costituisce progressivamente una forma di conoscenza organizzativa codificata.
La circostanza assume particolare rilievo nei domini regolamentati. In sanità, nella finanza o nella pubblica amministrazione non è sufficiente disporre di un modello capace di comprendere un documento o rispondere a una domanda. È necessario stabilire quali documenti possano essere utilizzati, quali informazioni siano accessibili a un determinato soggetto, quali operazioni richiedano una conferma, quali debbano essere registrate e quali decisioni non possano in alcun caso essere lasciate alla sola valutazione probabilistica del modello.
Il vantaggio non coincide dunque semplicemente con l'intelligenza del modello, ma con la capacità di inserirla correttamente nell'organizzazione.
5. L'inversione del collo di bottiglia
L'adozione di sistemi fondati su capacità generali produce anche uno spostamento del collo di bottiglia dello sviluppo.
Nel modello tradizionale una parte significativa dello sforzo consiste nell'implementare le diverse modalità attraverso cui un utente potrà utilizzare il sistema. Poiché ogni funzione deve essere costruita in forma esplicita, la complessità del software cresce insieme al numero di comportamenti che si desidera rendere disponibili.
Nel paradigma qui descritto, almeno una parte di questa complessità può essere trasferita dal codice applicativo alla capacità del sistema di interpretare un obiettivo e di combinare dinamicamente gli strumenti necessari per raggiungerlo.
Ciò non elimina la complessità. Ne modifica la natura.
Lo sviluppatore deve decidere quali dati rendere disponibili, quali strumenti esporre, quali relazioni consentire tra essi, quali operazioni richiedano un controllo deterministico, quali risultati debbano essere verificati e quali condizioni debbano determinare l'arresto o la richiesta di intervento umano.
La programmazione dei singoli percorsi tende così a lasciare spazio alla progettazione dello spazio entro cui tali percorsi possono essere costruiti.
È precisamente in questo passaggio che l'harness acquista rilevanza come categoria progettuale. Lo sviluppatore non deve necessariamente codificare ogni sequenza possibile, ma deve progettare in modo rigoroso le condizioni che rendono alcune sequenze possibili e ne impediscono altre.
6. Il nuovo ruolo dello sviluppatore
La riduzione della centralità della scrittura diretta del codice non implica una riduzione della necessità di competenza tecnica.
È, al contrario, plausibile che la renda ancora più rilevante.
Chi progetta un sistema nel quale un LLM può analizzare dati, scegliere strumenti e determinare dinamicamente un percorso operativo deve conoscere profondamente le conseguenze delle azioni che rende disponibili. Deve comprendere i modelli dati, le interfacce tra sistemi, i meccanismi di autenticazione e autorizzazione, i problemi propri dei sistemi distribuiti, le condizioni di consistenza, i limiti delle transazioni e le modalità attraverso cui verificare la correttezza di un risultato.
Tali competenze non vengono meno perché una parte del comportamento non viene più programmata direttamente. Diventano, piuttosto, gli strumenti attraverso cui è possibile delimitare e governare un comportamento che non è più interamente espresso sotto forma di codice deterministico.
Il cambiamento professionale può dunque essere descritto come uno spostamento dalla programmazione all'orchestrazione.
Il termine non deve essere inteso in senso riduttivo, come semplice coordinamento di servizi o composizione di API. Esso designa una funzione progettuale più ampia, nella quale lo sviluppatore costruisce il contesto entro cui il sistema opera, seleziona le capacità disponibili, ne definisce i confini, stabilisce le relazioni tra componenti probabilistiche e deterministiche e introduce i meccanismi attraverso cui le decisioni del sistema vengono verificate.
Il programmatore potrebbe quindi scrivere progressivamente meno codice, pur continuando a utilizzare in modo sostanziale le competenze maturate attraverso la programmazione.
Ciò che cambia è il livello al quale tali competenze vengono esercitate.
7. Dal workflow predeterminato all'orchestrazione dinamica
La trasformazione appare particolarmente evidente se osservata dal punto di vista dei workflow.
Nel software tradizionale il processo viene generalmente rappresentato come una sequenza di stati e transizioni definite preventivamente. Il sistema conosce il percorso perché tale percorso è stato programmato.
L'introduzione di componenti dotati di capacità di analisi rende invece possibile, almeno per determinate categorie di problemi, separare la definizione dell'obiettivo dalla definizione puntuale del percorso necessario per raggiungerlo.
L'harness può stabilire quali informazioni siano disponibili, quali strumenti possano essere utilizzati, quali vincoli non debbano essere violati e quali condizioni debbano essere soddisfatte affinché un'operazione sia considerata valida. All'interno di tale spazio, il sistema può determinare dinamicamente la sequenza più appropriata.
Questo non comporta necessariamente la scomparsa dei workflow deterministici. In molti ambiti essi continueranno a essere indispensabili. La novità risiede nella possibilità di non dover rappresentare in forma esplicita ogni variazione di percorso quando il problema richiede interpretazione, adattamento al contesto o combinazione di fonti eterogenee.
Il workflow non scompare, ma può cessare di coincidere interamente con il codice.
8. La persistenza del determinismo
Qualsiasi riflessione su una nuova generazione di software basato su LLM deve evitare un equivoco: la possibilità di affidare a un modello una parte delle attività di analisi non implica che ogni funzione debba diventare probabilistica.
Una delle principali competenze progettuali consiste proprio nel distinguere ciò che può beneficiare della capacità interpretativa del modello da ciò che deve rimanere deterministico.
La comprensione di una richiesta può tollerare un margine di incertezza; una verifica autorizzativa no. L'analisi di un insieme di documenti può essere affidata a un modello; l'applicazione di una regola contabile deve produrre un risultato riproducibile. La selezione delle informazioni rilevanti può essere probabilistica; l'esecuzione di una transazione deve continuare a essere soggetta a condizioni formali precise.
Ne deriva un'architettura inevitabilmente ibrida.
Gli LLM possono essere impiegati laddove interpretazione, analisi e adattamento producono valore, mentre il software deterministico continua a governare ciò che richiede certezza, ripetibilità e controllo formale.
L'harness è precisamente il luogo nel quale questi due livelli vengono raccordati.
9. L'harness come nuova competenza centrale
Se questa trasformazione dovesse consolidarsi, una parte significativa della competenza dello sviluppatore si concentrerà sempre meno sulla capacità di implementare singole funzioni e sempre più sulla capacità di progettare sistemi all'interno dei quali funzioni non rigidamente predeterminate possano emergere dall'interazione tra modello, dati e strumenti.
Ciò richiede una forma di progettazione diversa ma non meno rigorosa.
La qualità del sistema dipenderà dalla scelta delle informazioni accessibili, dalla struttura degli strumenti, dalla chiarezza dei contratti, dalla corretta separazione dei privilegi, dalla capacità di verificare i risultati e dalla possibilità di osservare e ricostruire ciò che il sistema ha fatto.
Sotto questo profilo, l'harness svolge una funzione analoga a quella che in altre fasi della storia dell'informatica è stata svolta da nuovi livelli di astrazione.
Non elimina le competenze precedenti, ma le ricolloca.
Il programmatore non deve necessariamente conoscere meno algoritmi, meno sistemi o meno architettura. Deve essere in grado di utilizzare queste conoscenze per progettare il contesto entro cui un componente dotato di capacità generali può agire senza compromettere l'affidabilità complessiva dell'applicazione.
10. Limiti e obiezioni
Una prima obiezione riguarda l'affidabilità. Un software il cui comportamento non sia interamente codificato in anticipo appare, per definizione, meno prevedibile di un sistema deterministico. L'obiezione è fondata e costituisce uno dei principali limiti del paradigma. Ma proprio questa difficoltà attribuisce rilevanza all'harness: quanto maggiore è il grado di autonomia attribuito al sistema, tanto maggiore deve essere la qualità dei vincoli, delle verifiche e dei meccanismi di controllo che ne delimitano il comportamento.
Una seconda obiezione riguarda la complessità. I sistemi fondati su capacità dinamicamente orchestrate possono risultare più difficili da testare, osservare e mantenere rispetto a un'applicazione tradizionale. Anche questo limite è reale. Tuttavia esso non riduce il ruolo dello sviluppatore; ne rende semmai più evidente la necessità, poiché la gestione di tale complessità richiede competenze architetturali e sistemistiche più profonde di quelle necessarie per l'impiego superficiale di un modello.
Una terza obiezione consiste nell'ipotizzare che l'evoluzione stessa degli LLM possa rendere progressivamente superfluo l'harness. Modelli più capaci potrebbero certamente ridurre alcune forme di controllo esplicito, ma non eliminerebbero la necessità di stabilire quali dati siano accessibili, quali azioni siano consentite, quali responsabilità appartengano al sistema e quali debbano rimanere in capo all'organizzazione. L'aumento della capacità non elimina il problema del governo; tende, piuttosto, ad ampliarne la portata.
11. Conclusioni
L'impatto più significativo dei modelli linguistici sullo sviluppo software potrebbe non coincidere con la loro capacità di generare codice. Potrebbe riguardare un cambiamento più profondo nella struttura delle applicazioni.
Il software gestionale tradizionale è costruito programmando in anticipo le funzioni e i percorsi attraverso cui un utente può raggiungere un determinato risultato. I sistemi fondati sulle capacità degli LLM rendono invece possibile, almeno per una parte dei problemi applicativi, costruire ambienti nei quali il risultato viene raggiunto attraverso la combinazione dinamica di dati, strumenti e capacità di analisi.
In tale scenario il modello non sostituisce semplicemente il software esistente. Contribuisce a modificarne la forma.
L'harness diventa l'architettura attraverso cui la capacità generale del modello viene trasformata in comportamento applicativo, delimitata dai vincoli del dominio e integrata con componenti deterministiche.
Conseguentemente cambia anche il ruolo dello sviluppatore.
La sua attività può progressivamente allontanarsi dalla scrittura diretta di ogni singolo comportamento senza perdere, per questo, la necessità delle competenze che la programmazione ha storicamente richiesto. Tali competenze vengono esercitate a un livello differente: nella scelta delle capacità da rendere disponibili, nella progettazione dei dati e degli strumenti, nella definizione dei vincoli e nella costruzione delle condizioni che permettono al sistema di operare correttamente.
Il passaggio dall'algoritmo all'harness non coincide dunque con la fine della programmazione, ma con lo spostamento del suo centro di gravità.
Il software non viene più necessariamente costruito descrivendo ogni comportamento possibile.
Viene sempre più progettato definendo l'ambiente entro cui comportamenti differenti possono essere prodotti, verificati e governati.
È in questo spazio che potrebbe collocarsi la nuova competenza centrale dello sviluppatore.