The Pulse
Anthropic afferma che Claude ha contribuito a rendere le sue app 3× più veloci
Anthropic afferma che uno sprint di due settimane con Claude ha contribuito ad accelerare claude.ai e l’app desktop di Claude, con miglioramenti misurati in quattro percorsi d’uso comuni.
AI.info Team ·
Anthropic afferma che Claude ha aiutato i suoi ingegneri a rendere claude.ai e l’app desktop di Claude circa tre volte più veloci in uno sprint di due settimane. L’azienda ha pubblicato il resoconto il 23 settembre, descrivendo un flusso di lavoro in cui Claude individuava problemi di prestazioni, creava benchmark, proponeva modifiche al codice e monitorava i rilasci, mentre le persone stabilivano le priorità e approvavano il lavoro. Anthropic afferma che i miglioramenti hanno riguardato quattro percorsi d’uso comuni, che rappresentano il 95% dell’attività.
Tre tempi di caricamento ridotti nettamente
Al 75° percentile, Anthropic afferma che il tempo necessario, dal caricamento iniziale di claude.ai fino alla comparsa di una pagina in cui l’utente potesse digitare, è sceso da 3,1 secondi a 0,55 secondi. L’avvio di una nuova sessione di Claude Code è passato da 0,8 secondi a 0,3 secondi, mentre il caricamento di una sessione cloud di Claude Cowork è sceso da 2,6 secondi a 0,73 secondi. I dati riguardano percorsi d’uso selezionati e non significano che ogni operazione in una delle due app sia diventata tre volte più veloce.
Anthropic stima che le modifiche facciano risparmiare agli utenti decine di migliaia di ore di attesa al giorno. Il post non fornisce misurazioni indipendenti né un’analisi dettagliata di questa stima, quindi l’aumento complessivo della velocità e il tempo risparmiato restano risultati riportati dall’azienda. Il team afferma di aver monitorato tredici misurazioni tra web e desktop, ciascuna con inizio all’interazione dell’utente e termine alla comparsa del risultato.
«[Questo modello] è un demonio dei numeri.»
— Shelley Vohr, un’ingegnera del canale
Il team afferma di aver raggiunto dodici dei tredici obiettivi entro il terzo giorno. Il piano iniziale dello sprint comprendeva circa venti progetti, mentre sono emerse altre opportunità quando Claude ha esaminato le misurazioni e suggerito ulteriori interventi.
Claude ha proposto le soluzioni; le persone hanno stabilito i limiti
Alcune modifiche puntavano a migliorare ciò che gli utenti vedevano per primo. Anthropic ha inserito nell’HTML della pagina una versione statica del compositore dei messaggi, così che i visitatori potessero iniziare a digitare mentre React si inizializzava. Altri interventi hanno mantenuto il compositore montato durante la navigazione, precaricato le sessioni quando gli utenti ci passavano sopra con il puntatore e ridotto del 90% i nuovi rendering della barra laterale.
Il team ha usato Claude anche per analizzare i percorsi di codice più lenti. In un esempio, ha profilato la routine che assembla l’albero dei messaggi di una conversazione e uno scanner che cerca le righe di stato nell’output di Claude Code. Anthropic afferma che il numero di istruzioni è diminuito del 48% e del 31% in questi percorsi, mentre i rispettivi tempi effettivi di esecuzione sono calati del 78% e del 44%.
Claude è stato eseguito come modello di ricerca interno, descritto dall’azienda come più o meno paragonabile a Opus 5.5, utilizzando il prodotto Claude Tag in versione beta. Gli ingegneri hanno definito gli obiettivi, valutato i compromessi e approvato le modifiche; Anthropic afferma che sono state integrate oltre 3.000 modifiche senza incidenti visibili ai clienti né ripristini. Il post descrive un lavoro supervisionato, non una revisione delle prestazioni autonoma.
I benchmark sono diventati strumenti di controllo
Poiché i millisecondi possono variare da un’esecuzione all’altra, il team ha cercato misurazioni ripetibili, eseguibili in laboratorio e in grado di rilevare regressioni nell’integrazione continua. Ha testato misure come il numero di istruzioni, i commit di React, le chiamate di funzione, i ricalcoli degli stili e le mutazioni del DOM, scartando i benchmark che non corrispondevano a miglioramenti della latenza percepita dagli utenti.
Quando un’ottimizzazione migliorava un benchmark, Anthropic afferma di aver aggiunto una soglia che le successive modifiche al codice non avrebbero potuto superare. L’azienda ha inoltre usato feature flag e rilasci graduali: le modifiche più rischiose sono state distribuite prima ai dipendenti, poi all’1% degli utenti e infine a una platea più ampia. Queste precauzioni si sono rivelate importanti quando, dopo il rilascio interno del compositore statico, si è verificato uno spostamento del layout. La causa era il ridimensionamento della pagina da parte di Chrome, non il passaggio al compositore: il piè di pagina della nuova scheda gestita di Chrome accorciava la pagina, per poi scomparire dopo il primo rendering e spostare i contenuti mentre la pagina si espandeva. Anthropic afferma che il problema era latente e non si era manifestato prima che la pagina iniziasse a essere visualizzata così presto; il team ha bloccato il layout durante il ridimensionamento e aggiunto un test per il flusso di prerendering.
Il lavoro che resta va oltre il dato in evidenza
Anthropic afferma che restano da migliorare il 95° percentile, altri percorsi d’uso e le conversazioni molto lunghe. I miglioramenti riportati segnano quindi progressi nelle attività comuni sottoposte a misurazione, ma non rappresentano il raggiungimento di un obiettivo prestazionale definitivo per ogni uso delle app di Claude.
Il resoconto dell’azienda presenta la misurazione come il motore dello sprint: una volta definito un benchmark da migliorare, Claude poteva testare le modifiche e ripetere il ciclo. I revisori umani continuavano a scegliere quali problemi fossero importanti e se un aumento di velocità giustificasse la complessità. Il post degli ingegneri di Anthropic afferma che il team intende descrivere separatamente il lavoro che ha portato a contributi a Electron, Chromium e Node.js.