A Anthropic afirma que um sprint de duas semanas, em agosto, tornou cerca de três vezes mais rápidas as tarefas principais no claude.ai e na aplicação de ambiente de trabalho Claude. O seu relato técnico, publicado a 23 de setembro, é mais esclarecedor do que o número da manchete, por si só: mostra quais as ações que aceleraram, como a equipa verificou as medições e em que decisões e lançamentos os engenheiros mantiveram a responsabilidade.

A grande mudança

  • O que mudou: A Anthropic reporta esperas mais curtas em 13 medições de ações comuns na Web e no ambiente de trabalho. O valor de 3,1 vezes é a média geométrica dessas melhorias, medida no percentil 75 a 13 e 27 de agosto. É um resultado da empresa relativo a um conjunto selecionado de percursos.
  • Porque é importante: Para quem usa o Claude, uma página nova da Web ficar pronta para escrever em 550 milissegundos, em vez de 3 085, altera uma parte frequente da utilização do produto. Para as equipas de engenharia, este caso mostra um assistente de IA a trabalhar sobre problemas de desempenho medidos, enquanto as pessoas definem prioridades e aprovam alterações.
  • O que importa acompanhar: A Anthropic afirma que ainda é preciso melhorar o percentil 95, outros percursos e conversas muito longas. Estas medições mostrarão se os ganhos reportados se estendem para além das ações selecionadas e da comparação de agosto.

O que os utilizadores ganharam

A Anthropic identificou quatro percursos que, segundo a empresa, representam 95% da atividade dos utilizadores: abrir a aplicação, iniciar uma conversa, carregar uma conversa e enviar uma mensagem. Na Web, no ambiente de trabalho e nos seus produtos, estes deram origem a 13 medições. Cada medição começava com uma ação do utilizador e terminava quando o resultado era apresentado; o trabalho no cliente e no servidor foi medido separadamente.

Numa nova sessão do claude.ai na Web, o tempo até a página estar pronta para escrever, no percentil 75, diminuiu de 3 085 para 550 milissegundos: uma aceleração de 5,6 vezes. O arranque a frio da aplicação de ambiente de trabalho passou de 6 310 para 3 328 milissegundos, ou 1,9 vezes mais rápido. Carregar uma sessão na nuvem do Claude Cowork no ambiente de trabalho passou de 2 566 para 728 milissegundos, ou 3,5 vezes mais rápido. A parte executada no cliente ao enviar uma mensagem de chat na Web diminuiu de 180 para 59 milissegundos, ou 3,1 vezes mais rápido. São ações e plataformas diferentes; o valor global de 3,1 vezes é a média geométrica das 13 proporções, não o resultado de uma única tarefa.

A comparação usa a monitorização de utilizadores reais da Anthropic no percentil 75, a 13 e 27 de agosto. A publicação não inclui uma auditoria independente, resultados no percentil 95 para estes percursos ou uma estimativa controlada da contribuição da assistência do Claude para os ganhos. A Anthropic estima que as ações mais rápidas poupam dezenas de milhares de horas diárias de espera aos utilizadores, mas não apresenta o cálculo dessa estimativa.

O ciclo de medição por detrás das alterações

A equipa começou com cerca de 20 projetos escolhidos por engenheiros. Segundo a Anthropic, utilizou o Claude Tag, um agente beta que executa um modelo interno de investigação aproximadamente comparável ao Opus 5.5, para detetar estrangulamentos, criar testes de referência e propor alterações. A equipa afirma que atingiu 12 dos 13 objetivos iniciais até ao terceiro dia; depois definiu novos objetivos e procurou problemas que os monitores existentes não detetavam.

Um exemplo começou com uma gravação de linhas da barra lateral que se deslocavam depois de uma página carregar. A medida existente de Cumulative Layout Shift não destacava o problema. Um engenheiro propôs utilizar a API subjacente de Layout Instability. Em seguida, o Claude acrescentou telemetria para identificar a zona afetada da página e um teste de integração que atrasava os dados da barra lateral. A Anthropic indica que o teste falhou nas 20 execuções do código original e passou nas 20 execuções da correção proposta. Depois de implementar a telemetria, a empresa afirma ter detetado deslocações após a página se tornar utilizável em 31% dos carregamentos na Web. É um exemplo documentado do sprint da Anthropic, não uma medição reproduzida pela BIG CHANGE.

A equipa também recorreu a medições de laboratório para acelerar o ciclo entre lançamentos. Em dois percursos JavaScript de execução intensiva, comparou contagens determinísticas de instruções com o tempo decorrido nos mesmos testes de referência. A Anthropic indica que reduções de 48% e 31% no número de instruções acompanharam reduções do tempo decorrido de 78% e 44%. A equipa transformou essas contagens em limites na integração contínua e reduziu-os à medida que o desempenho melhorava. Afirma ter descartado testes de referência pouco fiáveis ou que não refletiam a latência para os utilizadores. A distinção é importante: um contador de laboratório orientou as alterações; medições de utilizadores reais verificaram se o trabalho lançado trouxe benefícios.

Onde as pessoas mantiveram o controlo

A Anthropic descreve um canal Slack com muitos tópicos específicos, cada um dedicado a um percurso ou teste de referência. O Claude rastreava um problema, propunha um teste de referência e pedidos de alteração, acompanhava as implementações e lia dados de campo. Os engenheiros definiam os objetivos, decidiam quais os compromissos aceitáveis para os utilizadores e aprovavam cada alteração. Cada tópico tinha um responsável humano identificado. Uma alteração proposta, com 900 linhas, foi rejeitada porque os engenheiros consideraram que poupar dois milissegundos por mensagem não compensava o custo de manutenção.

O processo de lançamento incluía várias verificações. A Anthropic afirma que cada pedido de alteração recebeu uma revisão automatizada e, pelo menos, uma aprovação humana, e que foram executados testes unitários antes das otimizações. As alterações visíveis para os utilizadores ficaram protegidas por indicadores de funcionalidade temporários. As alterações de maior risco foram disponibilizadas primeiro aos funcionários, depois a 1% dos utilizadores e, por fim, a todos. Durante o sprint, a equipa introduziu quase 200 indicadores e afirma ter removido mais de metade até ao seu final. A Anthropic reporta a integração de mais de 3 000 alterações sem incidentes para os clientes nem reversões. Este resultado corresponde ao relato da empresa sobre o sprint; não demonstra que outra equipa ou base de código obtenha o mesmo resultado.

O compositor estático mostra a importância destes controlos. A Anthropic incluiu no HTML inicial um compositor pronto para escrever, enquanto o React carregava. Para verificar a transição, os testes compararam as versões estática e React em 14 tamanhos de ecrã, confirmaram um alinhamento com uma margem de um píxel e simularam a escrita durante a transição para detetar teclas perdidas ou reordenadas. A telemetria de campo mediu os deslocamentos durante essa passagem. Mais tarde, um funcionário detetou um deslocamento no esquema ao abrir um novo separador que as medições não tinham apanhado; a Anthropic associou-o ao redimensionamento do navegador durante o carregamento especulativo e acrescentou um teste para esse cenário.

O relatório da Anthropic sustenta uma conclusão específica: os engenheiros usaram o Claude para procurar e melhorar estrangulamentos medidos, num processo de lançamento dirigido por pessoas, e alguns percursos selecionados dos utilizadores eram mais rápidos no final de agosto. Fica por esclarecer o desempenho na cauda mais lenta, a duração dos ganhos e quanto do resultado um observador independente atribuiria ao agente, em vez da instrumentação, engenharia e decisões de lançamento da equipa.