LLM-First o Code-First? Dove appartiene l’intelligenza nell’AI di produzione

Come decidere cosa dovrebbe gestire il modello, cosa dovrebbe gestire il tuo codice e come collegare i due.

Qualche anno fa, l’architettura di un’applicazione AI sembrava così: inviare un prompt a un grande modello linguistico -> ottenere una risposta -> mostrarla all’utente. Non è più l’intera storia al giorno d’oggi. Ai modelli viene chiesto di interpretare l’intento, recuperare informazioni, scegliere strumenti, chiamare API, fare piani e gestire flussi di lavoro multi-step.

Quel cambiamento ha diviso il campo in due – LLM-First o Code-First

In un’architettura LLM-first, il modello è al centro e decide cosa succede dopo. Legge la richiesta, sceglie uno strumento, decide l’ordine delle operazioni, verifica i risultati intermedi e cambia rotta quando è necessario.

In un’architettura code-first, il software/codice rimane responsabile del sequenziamento, delle regole di business, della validazione, dei permessi e dell’esecuzione. L’LLM in questo caso è come uno specialista che il codice chiama quando è necessario comprendere o generare linguaggio.

Le persone amano dibattere su quale sia migliore. Credo che sia l’argomento sbagliato. La domanda migliore è dove appartiene ciascun tipo di intelligenza. I sistemi di produzione più solidi che ho visto sono raramente puramente uno o l’altro. Mescolano ragionamento probabilistico con controllo deterministico, e lo fanno deliberatamente.

Perché LLM-First è così attraente

Il software tradizionale funziona alla perfezione quando è possibile specificare i requisiti. Per esempio, un utente sceglie un prodotto, inserisce un importo e invia un pagamento. Definisci gli stati consentiti, le regole di validazione, le condizioni di errore e la sequenza di transazione nel codice. Fatto.

Il linguaggio naturale non collabora così. Immagina un utente che digita: “Trova le transazioni che sembrano anomale, spiega cosa è successo e dimmi cosa dovrei investigare per primo.”

Non esiste un percorso fisso per quella richiesta. Qui il sistema deve decidere cosa significa “anomalo”, capire quali dati sono rilevanti, magari chiamare diversi strumenti, valutare la risposta e scrivere una spiegazione che una persona possa utilizzare. Nessun team di ingegneri/nessun codice potrà anticipare ogni formulazione e ogni combinazione di richieste in anticipo.

È qui che un LLM svolge un ruolo fondamentale, fungendo da strato di ragionamento flessibile tra il linguaggio umano e i tuoi servizi deterministici. È anche il motivo per cui gli agenti stanno ricevendo così tanta attenzione. Google Cloud guida sull’architettura AI agenticadescrive un agente come un’applicazione in cui un modello AI funge da motore di ragionamento, mentre gli strumenti gli consentono di accedere a sistemi e dati esterni.

Anthropic’s Costruire agenti AI efficaci guida fa una distinzione a cui continuo a tornare. In un flusso di lavoro, i modelli e gli strumenti seguono percorsi che il tuo codice definisce. In un agente, l’LLM dirige il proprio processo e decide come usare i suoi strumenti. La stessa guida raccomanda di iniziare con l’architettura più semplice che risolve il problema, invece di aggiungere complessità agentica per riflesso. Sottolineerei quel consiglio due volte.

I limiti di “Lasciare decidere al modello”

Un modello può ragionare su ciò che dovrebbe accadere. Il ragionamento non è lo stesso di far rispettare una regola.

Ad esempio, prendi un flusso di lavoro finanziario. Un LLM potrebbe essere ottimo nel comprendere “invia la stessa somma che ho inviato il mese scorso allo stesso fornitore”. Ma dovrebbe anche decidere se il trasferimento è autorizzato, calcolare i limiti normativi, verificare la proprietà del conto, sovrascrivere una politica di sicurezza ed eseguire la transazione?

Probabilmente no. Questi compiti sono deterministici, testabili, verificabili e applicabili, ed è esattamente ciò in cui il software tradizionale eccelle. Il rischio aumenta man mano che i modelli ottengono l’accesso agli strumenti. OWASP guida sulla sicurezza dell’AI generativasegnala eccessiva autonomia come un rischio significativo: concedere a un sistema basato su LLM più funzionalità, permessi o autonomia di quanto il suo compito richieda. Un output strano o manipolato del modello è una cosa quando produce solo testo. È molto più grave quando il modello può agire nel mondo reale.

Niente di tutto ciò significa che i modelli non debbano mai compiere azioni. Significa che l’autonomia del modello dovrebbe essere limitata da un’autorità deterministica.

Il Code-First è ancora importante

Con l’AI che avanza così rapidamente, è facile pensare che l’ingegneria tradizionale sia fuori moda. Io sostengo il contrario. L’AI rende i sistemi deterministici di buona qualità ancora più importanti, non meno.

Il codice è ancora la scelta giusta ogni volta che un compito richiede una ripetibilità esatta. L’autenticazione è l’esempio più semplice. Un modello non dovrebbe “ragionare” sul fatto che qualcuno abbia privilegi di amministratore. La tua applicazione dovrebbe interrogare un sistema autoritario di gestione delle identità e degli accessi. Lo stesso vale per i calcoli monetari, i controlli di diritto, la validazione dei dati, i vincoli normativi, i limiti di transazione, la validazione dello schema e qualsiasi operazione irreversibile. Questi richiedono contratti espliciti, non supposizioni.

Questo è in linea con una visione più ampia della governance. Il NIST AI Risk Management Framework chiede alle organizzazioni di gestire il rischio AI attraverso progettazione, sviluppo, distribuzione e utilizzo. Il suo compagno Generative AI Profile aggiunge che i sistemi generativi potrebbero richiedere una supervisione, documentazione, revisione e controlli aggiuntivi, a seconda del rischio coinvolto.

Quindi trovo utile suddividere ogni decisione di progettazione in due domande:

Cosa dovrebbe accadere?

e

Cosa è consentito che accada?

Un LLM può spesso aiutare con il primo. I sistemi deterministici dovrebbero solitamente gestire il secondo.

Il modello ibrido: ragionare probabilisticamente, eseguire deterministicamente

Per la maggior parte delle applicazioni aziendali, la risposta pratica è un ibrido. L’LLM funge da strato di interpretazione e ragionamento. I servizi deterministici operano come strato di esecuzione e applicazione.

Ecco un esempio. Immagina che un assistente AI aiuti gli sviluppatori a creare ambienti temporanei di test API, e uno sviluppatore scriva: “Dammi un sandbox per il flusso di lavoro di onboarding del cliente”.

L’LLM può interpretare, capire quale flusso di lavoro è probabilmente inteso, leggere la documentazione e suggerire quali API sono probabilmente rilevanti. Ma la creazione effettiva dell’ambiente non dovrebbe dipendere da testo generato liberamente. Il codice può confermare che le API richieste esistono, validarne i contratti, verificare le autorizzazioni, imporre limiti di risorse, generare una configurazione approvata ed eseguire il deployment.

La divisione approssimativa è la seguente:

• L’LLM: comprendere, ragionare, classificare, proporre, sintetizzare.
• Il codice: validare, autorizzare, calcolare, persistere, applicare, eseguire.

Ogni parte svolge il lavoro per cui è più adatta, e nessuna è chiamata a simulare i punti di forza dell’altra.

I confini contano di più man mano che gli agenti diventano più potenti

Questa separazione diventa più importante quando si passa da assistenti ad agenti. Un assistente che fornisce una risposta errata crea un disagio; un agente con accesso in scrittura alla produzione può causare un disastro molto più grande.

La soluzione non consiste necessariamente nell’eliminare l’autonomia. Si tratta di aggiungere l’autonomia gradualmente mantenendo i punti di controllo espliciti al loro posto. le linee guida di Google sui sistemi multi‑agente raccomanda di abbinare il comportamento dinamico dell’IA a controlli di sicurezza deterministici, osservabilità, autonomia chiaramente definita e supervisione umana per scenari critici per il business.

L’approvazione umana può anche essere integrata nel flusso di lavoro stesso anziché essere una rete di sicurezza informale. Microsoft’s agent framework documentation, ad esempio, supporta chiamate a strumenti che si mettono in pausa finché una persona non approva esplicitamente l’operazione richiesta.

Il principio è semplice: più alte sono le conseguenze di un’azione, più forti devono essere i controlli deterministici intorno ad essa.

Cinque domande da porsi prima di affidare un compito a un LLM

Quando decido se un componente debba essere LLM-first o code-first, passo in rassegna questi punti:

1. Il compito ha una risposta oggettivamente corretta? In tal caso, orientarsi verso codice deterministico. Calcoli fiscali, autorizzazioni e validazione di schemi non dovrebbero cambiare perché un modello li interpreta diversamente oggi.
2. Coinvolge linguaggio ambiguo o informazioni non strutturate? In tal caso, un LLM può aggiungere valore reale.
3. Cosa succede se il modello sbaglia? L’architettura corretta per un riepilogo di una riunione è molto diversa da quella adeguata per avviare un pagamento.
4. È possibile convalidare l’output in modo indipendente? I piani generati da LLM diventano molto più sicuri quando regole deterministiche possono verificare l’azione risultante prima della sua esecuzione.
5. Questo richiede davvero un agente? Se conosci già i passaggi, un flusso di lavoro regolare con qualche chiamata mirata a LLM è solitamente più semplice, più economico, più facile da testare e da gestire.

Questa ultima domanda merita un’attenzione particolare. Gli agenti sono potenti proprio perché possono gestire situazioni in cui non puoi prevedere ogni passo. Ma se tu puoi prevedere i passaggi, trasformarli in un problema di ragionamento aperto aggiunge spesso variabilità senza aggiungere intelligenza.

Affidabilità è una proprietà architetturale, non un prompt

Molti team iniziano cercando di migliorare l’affidabilità quasi esclusivamente tramite l’ingegneria dei prompt. I prompt contano, ma non possono sostenere l’intero carico.

Un sistema di produzione dovrebbe presumere che l’output del modello a volte sarà incompleto, malformato, inaspettato o semplicemente errato. L’OWASP Top 10 per le applicazioni LLM elenca rischi come iniezione di prompt e gestione impropria dell’output, il che rafforza un’abitudine fondamentale: trattare l’output del modello come input non attendibile per i sistemi a valle, non come istruzioni da eseguire automaticamente.

Questo cambia la domanda che poni. Invece di “Come scrivo un prompt che faccia sempre rispettare al modello la regola?”, chiedi “Come progetto il sistema in modo che la regola non possa essere infranta anche quando il modello commette un errore?”

Questo è un problema di architettura software, non di prompting. Un prompt può dire a un agente di non eseguire un’azione non autorizzata. Un servizio di autorizzazione può effettivamente fermarlo. Quei due controlli non sono equivalenti.

Oltre il dibattito: sistemi intent-first

Riflettendo su tutto questo, sono giunto a credere che il dibattito LLM-first contro code-first punti verso una terza idea: intent-first architettura.

In un sistema intent-first, l’applicazione inizia comprendendo cosa l’utente sta cercando di realizzare. È qui che un LLM è più prezioso, perché le persone raramente sono precise su ciò che vogliono. Da lì, il sistema converte gradualmente quella vaghezza in operazioni strutturate e deterministiche.

Una richiesta come “Aiutami a risolvere il problema di pagamento del cliente” potrebbe trasformarsi in una pipeline: comprendere l’intento, recuperare la transazione, identificare la ragione del fallimento, raccomandare una soluzione, richiedere l’approvazione, eseguire l’operazione approvata.

Alcune di queste fasi beneficiano del ragionamento dei modelli linguistici. Altre dovrebbero essere servizi fissi. L’architettura non è definita da chi, tra IA o codice, “vince”. È definita da dove l’incertezza è accettabile.

In sintesi

Man mano che i modelli migliorano, sarà allettante concedere loro il controllo su porzioni sempre più ampie dello stack. A volte sarà la scelta giusta. In altri sistemi, il design più sofisticato sarà quello che deliberatamente concede al modello meno autorità.

L’ingegneria AI di produzione, in definitiva, riguarda il posizionamento dell’intelligenza al confine giusto. Usa i modelli linguistici dove interpretazione, ragionamento, sintesi e adattamento creano valore. Usa software deterministico dove coerenza, autorizzazione, precisione e applicazione sono importanti. Quindi collega i due attraverso interfacce strette, osservabili e ben testate.

Il futuro dell’AI aziendale probabilmente non sarà puramente LLM-first o puramente code-first. È LLM dove l’incertezza richiede intelligenza, e codice dove la certezza richiede controllo.

Questa distinzione potrebbe importare molto più del modello che scegli.