Perché “quale API devo chiamare?” è la domanda sbagliata nell’period LLM

Per decenni ci siamo adattati al software program. Abbiamo imparato i comandi della shell, memorizzato i nomi dei metodi HTTP e collegato insieme gli SDK. Ogni interfaccia presumeva che avremmo parlato suo lingua. Negli anni ’80 digitavamo “grep”, “ssh” e “ls” in una shell; verso la metà degli anni 2000 invocavamo endpoint REST come GET /customers; negli anni 2010 abbiamo importato gli SDK (consumer.orders.record()) in modo da non dover pensare all’HTTP. Ma alla base di ciascuno di questi passaggi c’period la stessa premessa: esporre le capacità in una forma strutturata in modo che altri possano invocarle.

Ma ora lo siamo entrando nel prossimo paradigma di interfaccia. I moderni LLM stanno sfidando l’concept secondo cui un utente deve scegliere una funzione o ricordare la firma di un metodo. Invece di “Quale API devo chiamare?” la domanda diventa: “Quale risultato sto cercando di ottenere?” In altre parole, l’interfaccia si sta spostando dal codice → al linguaggio. In questo cambiamento, il Mannequin Context Protocol (MCP) emerge come l’astrazione che consente ai modelli di interpretare l’intento umano, scoprire capacità ed eseguire flussi di lavoro, esponendo efficacemente le funzioni del software program non come le conoscono i programmatori, ma come richieste in linguaggio naturale.

MCP non è un termine esagerato; numerosi studi indipendenti identificano il cambiamento architetturale richiesto per l’invocazione dello strumento “LLM-consumabile”. Un weblog di Ingegneri Akamai descrive la transizione dalle API tradizionali alle “integrazioni basate sul linguaggio” per i LLM. Un altro documento accademico su “Flussi di lavoro degli agenti AI e API aziendali” parla di come l’architettura delle API aziendali deve evolversi per supportare agenti orientati agli obiettivi piuttosto che chiamate guidate dall’uomo. In breve: non ci limitiamo più a progettare API per il codice; stiamo progettando capacità per l’intento.

Perché questo è importante per le imprese? Perché le imprese stanno annegando nei sistemi interni, nell’espansione dell’integrazione e nei costi di formazione degli utenti. I lavoratori lottano non perché non abbiano strumenti, ma perché ne hanno troppi, ognuno con la propria interfaccia. Quando il linguaggio naturale diventa l’interfaccia primaria, la barriera “quale funzione chiamo?” scompare. Un recente blog aziendale ha osservato che le interfacce in linguaggio naturale (NLI) stanno consentendo l’accesso self-service ai dati per gli operatori di advertising and marketing che in precedenza dovevano attendere che gli analisti scrivessero SQL. Quando l’utente dichiara semplicemente l’intento (come “recuperare le entrate dell’ultimo trimestre per la regione X e segnalare anomalie”), il sistema sottostante può tradurlo in chiamate, orchestrazione, memoria di contesto e fornire risultati.

Il linguaggio naturale diventa non una comodità, ma l’interfaccia

Per capire come funziona questa evoluzione, consideriamo la scala dell’interfaccia:

Attraverso ogni passaggio, gli esseri umani dovevano “imparare il linguaggio della macchina”. Con MCP la macchina assorbe il linguaggio dell’uomo e fa il resto. Non si tratta solo di un miglioramento della UX, è un cambiamento architetturale.

Sotto MCP, le funzioni del codice sono ancora presenti: accesso ai dati, logica di enterprise e orchestrazione. Ma vengono scoperti anziché richiamati manualmente. Advert esempio, invece di chiamare “billingApi.fetchInvoices(customerId=…)”, dici “Mostra tutte le fatture di Acme Corp da gennaio ed evidenzia eventuali pagamenti in ritardo”. Il modello risolve le entità, chiama i sistemi giusti, filtra e restituisce informazioni strutturate. Il lavoro dello sviluppatore si sposta dal cablaggio degli endpoint alla definizione delle superfici di capacità e dei guardrail.

Questo cambiamento trasforma l’esperienza degli sviluppatori e l’integrazione aziendale. I crew spesso hanno difficoltà a integrare nuovi strumenti perché richiedono la mappatura di schemi, la scrittura di codici collanti e la formazione degli utenti. Utilizzando il linguaggio naturale, l’onboarding implica la definizione dei nomi delle entità aziendali, la dichiarazione delle capacità e la loro esposizione tramite il protocollo. L’essere umano (o l’agente AI) non ha più bisogno di conoscere i nomi dei parametri o l’ordine delle chiamate. Gli studi dimostrano che l’utilizzo degli LLM come interfacce per le API può ridurre il tempo e le risorse necessarie per sviluppare chatbot o flussi di lavoro richiamati da strumenti.

Il cambiamento comporta anche vantaggi in termini di produttività. Le aziende che adottano interfacce basate su LLM possono trasformare la latenza di accesso ai dati (ore/giorni) in latenza di conversazione (secondi). Advert esempio, se in precedenza un analista doveva esportare CSV, eseguire trasformazioni e distribuire diapositive, un’interfaccia linguistica consente di “riepilogare i cinque principali fattori di rischio di abbandono nell’ultimo trimestre” e generare narrativa e immagini in una volta sola. L’essere umano quindi rivede, adatta e agisce, passando da idraulico dei dati a decisore. Ciò conta: secondo un sondaggio di McKinsey & Companyil 63% delle organizzazioni che utilizzano la generazione AI sta già creando output di testo e più di un terzo sta generando immagini o codice. (Anche se molti sono ancora agli inizi nel tentativo di acquisire un ROI a livello aziendale, il segnale è chiaro: il linguaggio come interfaccia sblocca nuovo valore.

In termini architettonici, ciò significa che la progettazione del software program deve evolversi. MCP richiede sistemi che pubblicano metadati di capacitàsupporto instradamento semantico, mantenere memoria del contesto e applicare guardrail. Un progetto API non ha più bisogno di chiedersi “Quale funzione chiamerà l’utente?”, ma piuttosto “Quale intento potrebbe esprimere l’utente?” Un quadro pubblicato di recente per migliorare le API aziendali per LLM mostra come le API possono essere arricchite con metadati adatti al linguaggio naturale in modo che gli agenti possano selezionare gli strumenti in modo dinamico. L’implicazione: il software program diventa modulare attorno a superfici di intenti piuttosto che a superfici di funzioni.

I sistemi basati sul linguaggio comportano anche rischi e requisiti. Il linguaggio naturale è ambiguo per natura, quindi le aziende devono implementare l’autenticazione, la registrazione, la provenienza e il controllo degli accessi, proprio come hanno fatto per le API. Senza questi guardrail, un agente potrebbe chiamare il sistema sbagliato, esporre dati o interpretare erroneamente le intenzioni. Un submit su “collasso immediato” mette in guardia dal pericolo: man mano che l’interfaccia utente in linguaggio naturale diventa dominante, il software program potrebbe trasformarsi in “una funzionalità a cui si accede tramite conversazione” e l’azienda in “un’API con un frontend in linguaggio naturale”. Questa trasformazione è potente, ma sicura solo se i sistemi sono progettati per l’introspezione, l’audit e la governance.

Il cambiamento ha anche ramificazioni culturali e organizzative. Per decenni, le aziende hanno assunto ingegneri dell’integrazione per progettare API e middleware. Con i modelli guidati da MCP, le aziende assumeranno sempre più personale ingegneri dell’ontologia, architetti delle capacità E specialisti dell’abilitazione degli agenti. Questi ruoli si concentrano sulla definizione della semantica delle operazioni aziendali, sulla mappatura delle entità aziendali sulle capacità del sistema e sulla cura della memoria del contesto. Poiché l’interfaccia è ora incentrata sull’uomo, competenze come la conoscenza del settore, l’inquadramento tempestivo, la supervisione e la valutazione diventano centrali.

Cosa dovrebbero fare oggi i chief aziendali? Innanzitutto, pensa al linguaggio naturale come al livello dell’interfaccia, non come a un componente aggiuntivo di fantasia. Mappa i flussi di lavoro aziendali che possono essere richiamati in tutta sicurezza tramite il linguaggio. Quindi cataloga le funzionalità sottostanti di cui già disponi: servizi dati, analisi e API. Quindi chiedi: “Sono rilevabili? Possono essere richiamati tramite intento?” Infine, sperimenta un livello in stile MCP: crea un piccolo dominio (triage dell’assistenza clienti) in cui un utente o un agente può esprimere i risultati in linguaggio e lasciare che i sistemi facciano l’orchestrazione. Quindi itera e ridimensiona.

Il linguaggio naturale non è solo il nuovo front-end. Sta diventando il livello di interfaccia predefinito per il software program, sostituendo la CLI, quindi le API e infine gli SDK. MCP è l’astrazione che lo rende possibile. I vantaggi includono un’integrazione più rapida, sistemi modulari, maggiore produttività e nuovi ruoli. Per quelle organizzazioni ancora vincolate alla chiamata manuale degli endpoint, il cambiamento sembrerà come imparare di nuovo una nuova piattaforma. La domanda non è più “quale funzione chiamo?” ma “cosa voglio fare?”

Dhyey Mavani sta accelerando l’intelligenza artificiale e la matematica computazionale.

Benvenuto nella comunità VentureBeat!

Il nostro programma di visitor posting è il luogo in cui gli esperti tecnici condividono approfondimenti e forniscono approfondimenti neutrali e non conferiti su intelligenza artificiale, infrastruttura dati, sicurezza informatica e altre tecnologie all’avanguardia che plasmano il futuro dell’impresa.

Per saperne di più dal nostro programma di submit per gli ospiti e dai un’occhiata al nostro linee guida se sei interessato a contribuire con un tuo articolo!