In questo articolo
- Principio 1: L’arte di dare ordini chiari (perché l’IA non capisce le sfumature)
- Principio 2: Dargli solo le informazioni che servono, altrimenti va in confusione
- Principio 3: Gli strumenti devono essere a prova di stupido (letteralmente)
- Principio 4: Creare un “recinto di sicurezza” per validare ogni sua mossa
- Principio 5: Usare un’altra IA per capire perché la prima ha fallito
- Principio 6: Se l’agente si comporta in modo strano, la colpa è del sistema (cioè nostra)
Ogni tanto, nel mondo dello sviluppo software, spunta una nuova parola magica. Oggi è il turno degli “agenti AI”: sistemi di intelligenza artificiale che non si limitano a rispondere a una domanda, ma dovrebbero essere in grado di compiere azioni complesse in autonomia. L’hype, come al solito, è alle stelle. Ma chi ci lavora davvero sa che la realtà è fatta più di sudore e frustrazione che di magia. La verità è che questi agenti non sono geni autonomi, ma esecutori potentissimi che hanno bisogno di istruzioni incredibilmente precise e di una supervisione costante.
Diciamo che, più che di “intelligenza”, si tratta di ingegneria del controllo. Arseni Kravchenko, sviluppatore di app.build, ha distillato questa fatica quotidiana in sei principi pratici. Non sono formule magiche, ma lezioni imparate sul campo che smontano il mito e ci mostrano cosa serve davvero per far funzionare questi sistemi senza farsi troppe illusioni.
Principio 1: L’arte di dare ordini chiari (perché l’IA non capisce le sfumature)
Per molto tempo, il “prompt engineering” è sembrato una sorta di rito sciamanico, un insieme di trucchi per convincere l’IA a fare ciò che volevamo. Frasi come “ti darò una mancia di 100 dollari” o “mia nonna sta morendo e ha bisogno di questa risposta” hanno funzionato per un po’, ma erano solo espedienti per sfruttare le debolezze momentanee dei modelli.
La realtà, oggi, è più semplice e più complessa: i modelli linguistici non hanno bisogno di lusinghe, ma di chiarezza assoluta. Il problema non è la loro capacità di eseguire, ma la nostra di istruire. Le istruzioni devono essere dirette, dettagliate e prive di contraddizioni. Niente giochetti, solo un manuale d’uso impeccabile. In pratica, dobbiamo investire un’enorme quantità di tempo per scrivere un “prompt di sistema” che funzioni come una legge fondamentale, un documento che l’agente non possa fraintendere.
Principio 2: Dargli solo le informazioni che servono, altrimenti va in confusione
Fornire troppe informazioni a un agente AI è controproducente. I modelli attuali soffrono di “perdita di attenzione”: se il contesto è troppo vasto, si perdono i dettagli importanti, le prestazioni calano, i costi e la latenza aumentano. È come chiedere a una persona di trovare un ago in un pagliaio enorme.
La strategia vincente è quella del “minimo indispensabile”. Si fornisce all’agente solo il contesto essenziale per iniziare, dandogli però gli strumenti per recuperare altre informazioni se e quando ne avrà bisogno. Ad esempio, invece di caricare il contenuto di tutti i file di un progetto software, si può fornire solo l’elenco dei file e uno strumento per leggere quello specifico che gli serve. Si tratta di separare le competenze e fornire a ogni pezzo del sistema solo le informazioni di cui ha strettamente bisogno. Un’idea vecchia come l’informatica, che torna prepotentemente di moda.
Gli strumenti devono essere a prova di stupido (letteralmente)
Il cuore di un agente AI è la sua capacità di usare strumenti esterni (tool calling): leggere un file, scrivere codice, eseguire un comando. Progettare questi strumenti è come creare un’API, ma molto più difficile. Un programmatore umano può leggere la documentazione, interpretare, trovare soluzioni alternative. Un’IA no. Sfrutterà ogni ambiguità, ogni “buco” nella progettazione per fare qualcosa di inaspettato e, probabilmente, sbagliato.
Gli strumenti per un agente devono essere semplici, diretti, con pochi parametri e a prova di errore. Devono portare ordine nel mondo stocastico e imprevedibile dell’IA. Pensateli come un set di attrezzi da dare a uno stagista molto intelligente ma incredibilmente distratto: ogni attrezzo deve avere un solo scopo, ben definito e sicuro.
Principio 4: Creare un “recinto di sicurezza” per validare ogni sua mossa
Qui sta il vero segreto: combinare la creatività dell’IA con la rigidità del software tradizionale. L’approccio è quello “attore-critico”: un’IA “attore” propone una soluzione (scrive del codice, suggerisce un itinerario), e un sistema “critico”, deterministico e basato su regole, la valida.
Nel mondo dello sviluppo software, questo è facile: il codice scritto dall’IA deve compilare, superare i test, rispettare gli standard di formattazione. Se non lo fa, viene bocciato. Questo ciclo di feedback (feedback loop) è il motivo per cui gli agenti AI stanno avendo tanto impatto in questo settore. Ma il principio è universale: un agente di viaggio deve proporre voli che esistono davvero, un agente contabile deve rispettare i principi della partita doppia. Questo “recinto” di validazione è essenziale per filtrare i risultati scadenti e garantire un minimo di affidabilità.
Usare un’altra IA per capire perché la prima ha fallito
Un sistema di agenti AI produce una quantità enorme di log e dati. Analizzarli manualmente per capire dove e perché qualcosa è andato storto è quasi impossibile. La soluzione, paradossalmente, è usare un’altra IA per fare questo lavoro.
Il processo è semplice: si fa girare l’agente, si raccolgono i log delle sue azioni e dei suoi fallimenti, e poi si dà tutto in pasto a un modello linguistico con una grande finestra di contesto (come Gemini 1.5 Pro) chiedendogli di analizzare gli errori comuni. Questo approccio “meta-agentico” è incredibilmente potente per scovare problemi sistemici: uno strumento mancante, un’istruzione ambigua nel prompt, un contesto insufficiente. In pratica, si usa l’IA per fare il debug dei sistemi di IA.
Principio 6: Se l’agente si comporta in modo strano, la colpa è del sistema (cioè nostra)
Quando un agente AI fa qualcosa di palesemente stupido o ignora completamente le istruzioni, la prima reazione è dare la colpa al modello. Spesso, però, il problema non è l’IA, ma il sistema che abbiamo costruito attorno ad essa. Un comportamento frustrante è quasi sempre il sintomo di un errore di progettazione.
Kravchenko racconta di un agente che si ostinava a usare dati casuali invece di quelli reali forniti tramite un’integrazione. Dopo aver imprecato contro il modello, ha scoperto di non aver fornito all’agente le chiavi API corrette. L’agente aveva provato a connettersi, aveva fallito ripetutamente, e alla fine aveva ripiegato sull’unica alternativa possibile. L’errore non era dell’IA, ma dell’umano che non gli aveva dato gli strumenti giusti. Insomma, prima di maledire la macchina, è sempre meglio controllare di aver fatto bene il nostro lavoro.
