Di fronte all’aumento dei costi legati all’IA, la risposta più comune consiste nel limitarne l’uso: tetti di consumo, numero di posti e approvazioni prima del lancio degli agenti. Queste restrizioni indifferenziate possono tuttavia frenare utilizzi utili e misurare l’indicatore sbagliato, secondo l’analisi.
- Limitare l’IA con tetti indifferenziati può frenare utilizzi utili.
- Il costo per token misura il consumo, non i risultati ottenuti.
- Un indicatore più pertinente è il costo per richiesta di merge accettata, senza calo di qualità.
- Il modello più potente va riservato ai compiti complessi, mentre i modelli open-weight gestiscono il lavoro semplice.
Il costo per token (unità di testo elaborata da un modello linguistico) misura il consumo, non i risultati. Una parte delle spese corrisponde a sprechi, come i rilanci delle richieste o i loop incontrollati, mentre un’altra rappresenta il lavoro reale di consegna di un software. Un contatore non permette di distinguerli, né lo fa un tetto di spesa.
Misurare il software consegnato
Un indicatore più pertinente sarebbe il costo per richiesta di merge accettata, cioè il costo totale dello sviluppo assistito dall’IA diviso per il numero di modifiche che superano la revisione e vengono integrate nel codice, chiamate « pull requests » nel gergo. Bisogna monitorare in parallelo le modifiche e i difetti, affinché modifiche meno costose non nascondano un calo di qualità.
Se questo costo scende mentre l’uso aumenta, senza degradazione della qualità, gli sviluppatori trasformano più consumo in software utile. La domanda quindi non è il numero di token utilizzati, ma la quantità di lavoro completato che produce l’investimento. Per migliorare questo equilibrio, vengono proposte due leve: riservare l’inferenza costosa ai compiti che ne hanno bisogno, e ridurre il costo del lavoro corrente.
Adattare il modello al compito
Lo sviluppo agentico, in cui un agente scrive e modifica codice in modo autonomo, non richiede il modello più potente ad ogni passo. Un modello all’avanguardia, o un modello faro ospitato in sede quando la politica aziendale lo impone, può essere riservato alla pianificazione complessa e al ragionamento innovativo. I compiti più semplici, come la generazione di codice, la creazione di test o le refactoring ripetute, possono essere affidati a modelli a peso aperto (« open-weight »), gestiti direttamente dall’azienda.
Un gateway può orientare ogni richiesta in base alla sua complessità, alla sensibilità dei dati, al suo costo e alla sua latenza. Il primo modello viene così impiegato solo quando la situazione lo giustifica. Come riassume l’autore, « Meter the exception, not the workload », ovvero: misurare l’eccezione, e non il carico di lavoro.
I modelli a peso aperto rendono questa ripartizione sempre più praticabile. Secondo i benchmark di ingegneria software citati, i migliori tra loro possono avvicinarsi alle prestazioni di punta su alcuni compiti. Questa constatazione non garantisce l’equivalenza su tutti i repository di codice né su tutti i workflow. Si raccomanda quindi di valutare i candidati sul proprio codice, i propri test e i propri criteri di accettazione prima di affidare loro lavoro in produzione.
Cambiare l’economia degli usi ripetuti
Resta da determinare chi possiede la capacità di calcolo. Con un’inferenza in affitto, ogni chiamata si aggiunge alla fattura. Con una capacità posseduta, l’essenziale del costo è impegnato fin dall’inizio, cosicché ogni chiamata aggiuntiva diventa meno costosa man mano che l’uso aumenta.
