La Guerra degli Assistenti AI per Programmare: Come Servirli in Produzione Senza Perdere la Testa

La competizione tra gli assistenti AI per la programmazione ha raggiunto un nuovo livello. Con Claude Code, Codex e Gemini CLI ormai testati da sviluppatori in tutto il mondo, la domanda non è più se funzionano—è come farceli lavorare a pieno regime senza spendere una fortuna o introdurre latenze che fanno venire voglia di lanciare la tastiera dalla finestra.

Un paper di ricerca piuttosto interessante dal laboratorio SyFI dell'Università di Washington ha appena pubblicato numeri concreti su come sono realmente strutturati i carichi di lavoro degli agenti di programmazione. E qui le cose si fanno interessanti: probabilmente la vostra infrastruttura attuale per servire LLM non è ottimizzata per questo scenario.

La Rivoluzione Autonoma che Nessuno Aveva Previsto

C'è un aspetto degli agenti di programmazione che appare ovvio una volta che qualcuno lo enuncia: non si limitano a rispondere a domande. Eseguono piani. Quando chiedi a un assistente AI di implementare una funzionalità o correggere un bug, non stai avviando una semplice transazione domanda-risposta—stai attivando un workflow autonomo in cui il modello ragiona, esegue comandi shell, legge e modifica file, lancia test e itera fino a quando non è soddisfatto (o fino a quando non lo interrompi).

Il team di ricerca ha raccolto oltre 4.300 sessioni reali per un totale di circa 55 miliardi di token, e i pattern emersi sono significativi. Ogni richiesta utente innesca in media 8,8 cicchi di tool prima del completamento. Lasciatemi ripetere: per ogni domanda che uno sviluppatore pone, ci sono quasi nove giri di generazione del modello seguiti dall'esecuzione di strumenti. Il modello non sta semplicemente parlando—sta agendo. E l'88% di tutti i turni di inferenza LLM avviene non in risposta all'input dell'utente, ma in risposta ai risultati degli strumenti.

Questo ha implicazioni enormi per la pianificazione del throughput. I chatbot tradizionali sono essenzialmente sistemi request-response con occasionali follow-up. Gli agenti di programmazione assomigliano più a processi autonomi di lunga durata con frequenti cambi di contesto tra fasi di generazione ed esecuzione. Le vostre politiche di autoscaling, il sistema di code delle richieste, le strategie di caching—tutto questo va ripensato considerando workflow multi-step autonomi, non semplici conversazioni a turni.

L'Asimmetria Input-Output che Manderà in Crisi la Vostra Cache

Ecco un numero che dovrebbe far rabbrividire ogni ingegnere infrastrutturale: gli input superano gli output in un rapporto di 294 a 1. Nelle tracce analizzate, i modelli hanno letto 52,56 miliardi di token di input cachati e prefillato 2,34 miliardi di token nuovi, eppure hanno generato soltanto 186,9 milioni di token in output. Un giro tipico si trova con un prefisso di 32K-256K token e aggiunge solo qualche centinaio o qualche migliaio di token prima di decodificarne un paio di centinaia in uscita.

Questo crea un profilo di performance fondamentalmente diverso da quello per cui la maggior parte dei sistemi di serving LLM sono ottimizzati. L'inferenza tradizionale dei language model si concentra fortemente sul throughput di generazione—quanti token al secondo possiamo produrre? Ma per gli agenti di programmazione, il collo di bottiglia spesso non è la velocità di decoding; è il time-to-first-token (TTFT) dopo il ritorno dell'esecuzione del tool. Il team ha scoperto che il TTFT di Codex per ogni step si attesta intorno ai 3,1 secondi, che rappresenta circa il 25% del tempo totale di generazione di un round. Quando state facendo nove round per richiesta, questo overhead si somma rapidamente.

La questione del caching è anche più sfumata di quanto appaia a prima vista. Sì, il caching degli input (prefill caching) aiuta con l'enorme contesto che gli agenti di programmazione portano con sé. Ma il carico di prefill è diviso tra token cachati e token nuovi che richiedono computazione effettiva. I prefill brevi e incrementali dopo l'esecuzione di tool hanno caratteristiche di performance diverse dal carico iniziale di contesto lungo. I sistemi di serving devono gestire entrambi efficientemente, e le strategie ottimali potrebbero differire tra questi casi.

I Comandi Shell Stanno Mangionando il Mondo (Ancora)

Se pensavate che gli agenti di programmazione si dedicassero principalmente a ragionamenti sofisticati e refactoring complessi, non avevate tutti i torti—ma la realtà è più confusa. Dei 433.000 chiamate di tool catturate nelle tracce, il 76% erano esecuzioni di shell o comandi. Lanciare build, test, operazioni git, manipolazioni di file attraverso strumenti CLI—le cose meno glamour che però compongono il lavoro quotidiano reale dello sviluppo software.

Le modifiche ai file hanno totalizzato l'11%, le letture e ricerche di file il 9%, con pianificazione, delega a sub-agent e ricerche web che compongono il resto. Questa concentrazione nei comandi shell conta per diverse ragioni. Prima di tutto, si tratta di operazioni con code di latenza molto variabili: un semplice ls è veloce, ma lanciare una suite di test completa o compilare una codebase grande può richiedere minuti. La distribuzione della latenza copre quattro ordini di grandezza, il che rende la pianificazione della capacità un incubo.

In secondo luogo, il vocabolario dei tool varia significativamente tra agenti. Claude Code ha usato 54 tool diversi mentre Codex ne ha usati 31, ma entrambi hanno concentrato la strass maggioranza del volume nello stesso nucleo—shell, modifiche file, letture file. Questo suggerisce che ottimizzare per questi tool ad alto utilizzo potrebbe dare miglioramenti outsized, anche senza affrontare l'intero ecosistema di strumenti.

Cosa Significa Questo per la Vostra Infrastruttura

Se state costruendo o gestendo strumenti di sviluppo AI-powered, questa ricerca indica diversi punti concreti da cui partire.

Pensate in termini di workflow, non di richieste. La vostra infrastruttura di serving deve tenere conto della natura autonoma e multi-step degli agenti di programmazione. Questo significa contesti di richiesta più lunghi, gestione dello stato più sofisticata, e opportunità di scheduling batch che raggruppino chiamate di tool correlate insieme.

Ottimizzate per i gap di inattività. Gli utenti passano in media 46,7 minuti tra una richiesta e l'altra, nonostante un tempo di pensiero mediano di soli 1,4 minuti. La distribuzione è estremamente heavy-tailed—alcuni sviluppatori iterano rapidamente mentre altri avviano una richiesta e tornano ore dopo. Strategie smart di prefetching e re-prefill durante questi periodi di inattività potrebbero ridurre drasticamente la latenza percepita senza aumentare i costi di calcolo.

Separate i percorsi di prefill e decode. Il rapporto input-output di 294:1 significa che la vostra computazione di prefill è probabilmente il costo dominante. I prefill incrementali dopo l'esecuzione di tool richiedono ottimizzazioni diverse dal caricamento iniziale del contesto. Considerate pool di risorse separate o politiche di scheduling per questi diversi tipi di carico di lavoro.

Non dimenticate l'infrastruttura di esecuzione dei tool. Quando il 76% dell'attività dell'agente sono comandi shell, il vostro orchestrazione di container, i pattern di accesso al filesystem e il caching degli strumenti di build diventano preoccupazioni di primo livello per il serving di agenti AI. L'inferenza del modello è solo parte della pipeline.

La Strada Davanti

Il team di TraceLab ha reso open-source la loro pipeline di raccolta e analisi delle tracce, rendendo possibile per i team infrastrutturali generare le proprie tracce e ottimizzare per pattern di utilizzo reali invece che benchmark sintetici. Questo tipo di dato dal mondo reale è esattamente ciò di cui lo spazio dell'infrastruttura AI ha bisogno mentre matura da "facciamo funzionare le cose" a "facciamo funzionare le cose su larga scala."

Per la community di NomeOcean Vibe Hosting, questi insights evidenziano perché stiamo investendo in infrastruttura che va oltre la semplice allocazione di GPU. Servire agenti AI di programmazione non riguarda solo la potenza di calcolo grezza—riguarda comprendere le caratteristiche uniche dei carichi di lavoro agentici e costruire sistemi che possano gestire la realtà autonoma, multi-step e ricca di strumenti di come gli sviluppatori usano realmente questi tool.

L'era dell'agente di programmazione sta appena iniziando, e le decisioni infrastrutturali che prendiamo oggi plasmeranno l'efficienza con cui questi strumenti serviranno gli sviluppatori per gli anni a venire.