Il cofondatore di Databricks Patrick Wendell spiega perché i costi del coding con l'AI crescono in modo esponenziale e come i leader dell'engineering possono invertire la rotta senza rallentare i propri team
In questa conversazione, Catherine Brown parla con Patrick di cosa è successo quando Databricks ha puntato tutto sugli agenti di coding basati su AI: come i costi sono inizialmente aumentati a dismisura con il crescere dell'utilizzo, cosa ha effettivamente ridotto i costi unitari fino al 90% e perché ogni organizzazione di engineering ha bisogno di un livello di controllo tra i suoi sviluppatori e i suoi modelli. Quel livello di controllo è iniziato come una soluzione interna per le fatture AI di Databricks ed è diventato l'ispirazione per Unity Gateway.
Catherine: Gestisci i prodotti AI di Databricks e sei stato anche il sostenitore interno dell'adozione dell'AI. Perché questa è diventata una priorità così personale per te?
Patrick: Perché l'output di engineering è il principale collo di bottiglia nel nostro business. Ogni azienda ha bisogno che il proprio team di engineering proceda più velocemente e, se puoi offrire loro qualcosa che ne migliori in modo significativo la produttività, ha un grande valore. I primi prodotti di chat erano utili fino a un certo punto. Ma il ROI è davvero cambiato circa un anno fa, quando sono comparsi i primi modelli di coding davvero validi.
Catherine: Come fai a sapere se stai ottenendo dei vantaggi in termini di produttività dagli strumenti AI?
Patrick: Monitoriamo una serie di metriche di output: pull request, funzionalità rilasciate e linee di codice. Nessuna di queste è perfetta da sola. Penso all'R&D come a una grande macchina. Inserisci risorse, ottieni funzionalità e codice in uscita e puoi misurare quanto valore in più ne deriva. Complessivamente, siamo vicini al raddoppio dell'output con lo stesso team. I team che hanno riorganizzato i propri processi attorno all'AI stanno andando molto più veloci.
Catherine: Quando Databricks ha distribuito per la prima volta gli strumenti di coding basati su AI, cosa avete sbagliato?
Patrick: È divertente perché all'inizio avevamo il problema opposto. Nessuno voleva provare le novità. Andavo in giro a sollecitare le persone. Così abbiamo fatto quello che hanno fatto tutti: rimuovere ogni barriera, ovvero il modello più costoso e tutti i token desiderati. Penso che l'intenzione fosse buona. Stai cercando di far superare agli utenti l'ostacolo iniziale.
Poi le persone hanno iniziato ad usarlo davvero e abbiamo visto una curva dei costi esponenziale. Questi strumenti sono ormai tutti con prezzo a consumo, non per utente, quindi un singolo utente può, in linea di principio, spendere una quantità illimitata di denaro. Può eseguire un piccolo loop sul modello più costoso e andare a pranzo. Forse quel loop sta facendo qualcosa di molto utile, ma forse sta solo bruciando token. Se i tuoi costi crescono in modo esponenziale e le tue entrate no, a un certo punto c'è un problema. Siamo arrivati al punto in cui i costi rischiavano di annullare i guadagni di efficienza, che erano l'unico motivo per cui avevamo fatto tutto questo.
È stato allora che mi sono coinvolto in prima persona. Mi sono confrontato con i leader di altre aziende tecnologiche che sapevo stessero adottando l'AI su scala (Coinbase, Uber, Stripe e altre). Collettivamente, molti di noi stavano adottando tecniche simili. Oggi, in Databricks, la nostra spesa in token per persona è pressoché stabile, anche se l'utilizzo totale e il valore continuano ad aumentare.
Catherine: Il primo istinto della maggior parte delle aziende è un limite di spesa rigido (hard cap). Voi ci avete provato. Cos'è successo?
Patrick: È la prima mossa ovvia e quel meccanismo serve. Ma un blocco rigido è una brutta esperienza. Interrompi qualcuno a metà lavoro e perde il ritmo, magari ore di lavoro. E le persone che raggiungono il limite sono spesso i tuoi utenti migliori. Se li blocchi, alcuni di loro finiscono per usare un account personale e a quel punto perdi ogni visibilità.
Così siamo passati a una frizione graduale, e Unity Gateway gestisce tutto. Prima un avviso, poi un'approvazione, poi ti passiamo a un modello più economico in modo che tu possa continuare a lavorare. Bloccare davvero qualcuno è l'ultima spiaggia. Inviamo anche a tutti un report periodico sulle proprie spese con suggerimenti su dove risparmiare. Solo questo vale circa il 10%. Un'azienda di cui sono a conoscenza inserisce il modello e il costo direttamente in ogni pull request. Quindi si tratta di una sorta di "public shaming" se usi un modello costoso per un'attività secondaria. Lo adoro.
Catherine: Hai scritto di quattro leve per ridurre questi costi. Quale ha avuto l'impatto maggiore?
Patrick: La nostra preferita è un po' noiosa: continuano a uscire modelli migliori ed economici, e si sposta il traffico verso di essi. Vengono rilasciati probabilmente cinque modelli a settimana tra fornitori proprietari e open source. Non ognuno di essi rappresenta un passo avanti sui costi, ma magari uno ogni due settimane sì. È una marea crescente. Ottieni lo stesso output spendendo meno e nessuno deve modificare nulla. Nessun routing sofisticato, niente di niente.
Per darvi un'idea di quanto rapidamente ci si muova: uno dei recenti modelli economici equivale grosso modo a ciò che un modello frontier poteva fare circa nove mesi fa, a circa l'1% del costo per attività. Si tratta di un calo di 100 volte in meno di un anno. È un dato ancora preliminare, ma la direzione è questa.
L'inghippo è che devi effettivamente fare il passaggio. Se esce un nuovo modello e nessuno nella tua azienda lo usa, è come un albero che cade in una foresta vuota. Quindi siamo diventati bravi a valutare rapidamente i nuovi modelli e a spostare i workload quando uno è abbastanza valido. Poiché tutto passa attraverso Unity Gateway, possiamo effettuare quel cambio in un unico punto e gli sviluppatori non devono modificare nulla. È stata la cosa più d'impatto che abbiamo fatto, con un peso del 50% o più da sola. Aggiungendo il routing, la visibilità sulla spesa e la riduzione dell'overhead dei token, in alcuni casi i nostri costi unitari sono scesi fino al 90%.
Catherine: Il tuo team fa benchmark degli agenti di coding sulla codebase di vari milioni di righe di Databricks. Perché non fidarsi semplicemente dei benchmark pubblici?
Patrick: I benchmark pubblici non dicono molto sul tuo codice. I task finiscono nei dati di addestramento e non assomigliano a una grande codebase aziendale. Quindi abbiamo creato il nostro benchmark da pull request reali nel nostro repository e valutiamo eseguendo effettivamente i test. Non usiamo un LLM come giudice, perché tende a premiare ciò che sembra corretto rispetto a ciò che lo è davvero.
Alcuni risultati hanno sorpreso le persone. Un modello open source, GLM 5.2, ha pareggiato con Opus 4.8 sulla qualità a circa un terzo in meno per task. Un modello che era 1,7 volte più economico per token è costato di più per task, perché ha consumato più token. E l'harness, lo strumento di coding attorno al modello, ha contato quasi quanto il modello stesso. Stesso modello, harness diverso, oltre 2 volte di differenza di costo. Solo l'ottimizzazione dell'harness e delle impostazioni di caching ci ha fatto risparmiare quasi il 50%.
Catherine: Il divario tra i modelli più economici e quelli più costosi può essere di 100 volte. Come dovrebbero considerare questa gamma i leader dell'engineering?
Patrick: Pensa a come le auto. Ci sono la Lamborghini, la Honda e la bicicletta. Non hai bisogno della Lamborghini per ogni viaggio e la maggior parte del lavoro di coding non richiede il modello più grande.
Astra è stato un buon esempio. L'abbiamo distribuito a ogni engineer, circa 3.500 persone, e per quanto ne sappiamo, siamo la prima azienda a condividere pubblicamente un rollout di questo tipo. Era chiaramente migliore sugli aspetti difficili, come la progettazione dei sistemi. Ma la spesa è aumentata di circa il 60% e non forniva un aiuto evidente per le attività quotidiane, che i modelli esistenti gestiscono già bene. Molto di quel costo era uno spreco, con persone che usavano Astra per cose per cui avrebbero dovuto usare un altro modello. Quindi gli abbiamo assegnato un budget dedicato in Unity Gateway. Va usato per i problemi complessi.
A lungo termine, non so in che direzione andrà la cosa. I modelli economici continuano a farsi carico di una quota maggiore del lavoro di routine, ma le persone sottopongono all'AI problemi sempre più complessi. In un certo senso il punto è proprio questo. Vuoi essere in grado di orientarti nell'una o nell'altra direzione.
Catherine: Hai sostenuto che il costo dell'AI è un problema di infrastruttura, non di procurement. Perché i budget e le policy non possono risolverlo?
Patrick: I budget aiutano, ma un budget non può decidere quale modello debba gestire una determinata richiesta. Questo è il routing. La ridenominazione di un componente va a un modello economico; un problema complesso e aperto va a uno più avanzato. Il nostro Smart Router riduce il costo medio per task di oltre il 30% all'incirca con la stessa qualità del modello più costoso. Ci consente anche di smettere di chiedere agli utenti di decidere quando usare i modelli più costosi… avviene e basta.
Per fare tutto questo hai bisogno di un livello tra i tuoi sviluppatori e i modelli. Abbiamo creato il nostro perché dovevamo farlo. Tutto il traffico dei nostri strumenti di coding passa attraverso un unico gateway, che si tratti di Claude Code, Codex, Cursor o Omnigent, il nostro meta-harness. Questo ci ha permesso di vedere effettivamente dove andavano i soldi. Poi ci siamo resi conto che ogni cliente aveva lo stesso problema, quindi lo abbiamo trasformato in un prodotto come Unity Gateway. Migliaia di clienti lo usano ora.
Catherine: Il routing finirà per essere competitivo quanto i modelli stessi?
Patrick: È la nostra visione. Man mano che i margini sui modelli si riducono, capire quale modello usare e per cosa diventa una sfida davvero interessante. I modelli di routing devono essere piccolissimi e veloci. Inoltre, è un compito difficile da eseguire bene. Ci sono ancora molti problemi di ricerca aperti sul lato pratico dell'uso di questi modelli, e credo che ci sia una vera e propria IP nel farlo nel modo giusto.
Catherine: Se potessi dare un consiglio a un CTO che si trova di fronte a una fattura per l'IA in continua crescita, quale sarebbe?
Patrick: Capire dove vanno a finire le risorse. La maggior parte delle aziende non sa dire quanto sta spendendo per l'IA per team o per modello, per non parlare del fatto che stia fruttando o meno. Inserisci un gateway davanti ai tuoi modelli in modo che tutto il traffico passi da un unico punto e tu possa vederlo. Da lì in poi, tutto diventa più semplice. E non rallentare. I guadagni di produttività sono reali. Ma queste cose si sommano e, se aspetti, il conto finale sarà molto più alto di quanto pensi.
Il messaggio di Patrick ai leader dell'engineering è che non occorre scegliere tra la produttività dell'IA e il controllo dei costi. Le aziende che fanno la cosa giusta mantengono un ampio accesso ai modelli migliori, testano i nuovi modelli sul proprio codice, passano a quelli più economici non appena risultano sufficientemente validi e offrono agli sviluppatori visibilità invece di ostacoli. Alla base di tutto c'è un unico livello di controllo, un gateway, che rende la spesa per l'IA qualcosa che si può vedere e gestire. In Databricks, quel livello è diventato Unity Gateway.
Per saperne di più su come Databricks gestisce la propria spesa per la codifica con l'IA, leggi il blog di Patrick "Managing AI Coding Costs at Scale" e prova Databricks Unity Gateway.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.