O modo ENGINEER oficial da Claude: o loop que um engenheiro da Anthropic usa!

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude’s OFFICIAL ENGINEER Mode: The Loop Anthropic Engineer Uses Themselves! · Canal: AICodeKing · 11:21 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Claude, Engenharia de software com IA

Resumo

O vídeo analisa como a Anthropic acelerou a experiência web e desktop da Claude em um sprint de duas semanas, destacando medições reproduzíveis, otimizações de interface e acompanhamento em produção. A ideia central é dar ao agent uma tarefa com critérios de sucesso verificáveis, permitir iterações e definir limites para interromper o trabalho. O apresentador também ressalta que benchmarks precisam representar o uso real e que melhorias devem ser equilibradas com custos de manutenção. A supervisão humana, testes e liberações graduais são apresentados como partes essenciais do processo.

Pontos-chave

A prontidão para digitar após um carregamento web caiu de 3,1 segundos para 0,55 segundo no percentil 75; essa medida não é o tempo de resposta do modelo.
Um bom loop de trabalho define o sucesso, permite que o agent repita o trabalho e a verificação e inclui uma condição para parar.
Contar instruções com Callgrind pode oferecer comparações mais repetíveis do que medições com cronômetro, mas menos instruções não garantem uma experiência geral mais rápida.
Limites de performance na integração contínua ajudam a preservar melhorias e detectar regressões.
As otimizações incluíram exibir um campo de texto antes da inicialização do React, reduzir re-renderizações da barra lateral, reutilizar blocos de resposta e mover a tokenização para um worker.
Métricas como CLS não capturam todos os problemas percebidos pelas pessoas; gravações, interações reais e testes específicos complementam os dashboards.
Os testes devem refletir o trabalho real e incluir exemplos diferentes dos usados durante a otimização.
A Anthropic relata mais de 150 threads, mais de 3.000 mudanças integradas e nenhuma ocorrência voltada a clientes nem rollback; todas as mudanças exigiram aprovação humana.
O agent deve começar por um problema reproduzível, registrar uma medida de referência, propor uma mudança pequena e verificar tanto o resultado quanto o comportamento existente.
A complexidade e o custo de manutenção podem não justificar ganhos pequenos; por isso, o agent deve explicar os trade-offs antes de continuar.

Capítulos

Início	Capítulo	Resumo
00:00	Resultados e o loop de trabalho	O vídeo apresenta os ganhos de velocidade relatados e explica por que agents precisam de objetivos verificáveis, iteração e condições de parada.
03:33	Medições, regressões e otimizações de interface	A discussão aborda limites de performance, dados de produção e mudanças no React, incluindo a reutilização de blocos de resposta e o uso de workers.
07:10	Métricas, testes e liberações graduais	O apresentador explica limitações do CLS, a importância de evals representativos, a coordenação entre agents e o uso de liberações por etapas com aprovação humana.
09:46	Custos, limites e aplicação do workflow	O vídeo recomenda começar com um problema reproduzível, comparar medições antes e depois, verificar o comportamento existente e limitar tentativas que tragam ganhos insignificantes.

Citações

Dê ao agent um trabalho com uma forma de verificar o próprio progresso. — 00:31

A melhoria precisa ser maior do que o ruído da sua avaliação. — 02:02

Otimizar cada componente individualmente não garante que o aplicativo inteiro pareça coerente. — 09:15

Mais atividade não torna automaticamente o projeto mais valioso. — 10:17

A qualidade do feedback merece tanta atenção quanto o prompt. — 10:47

Conceitos e entidades

Anthropic (empresa): Empresa cujo sprint de otimização e orientações de trabalho com agents são discutidos no vídeo.
Claude (modelo): Produto de IA cuja experiência web e desktop foi otimizada durante o sprint relatado.
Claude Tag (ferramenta): Experiência compartilhada de agent da Anthropic no Slack, capaz de usar o contexto de uma conversa, ferramentas conectadas e instruções contínuas.
Opus 5.5 (modelo): Modelo citado como referência aproximada para o modelo interno de pesquisa usado pela equipe.
Slack (ferramenta): Plataforma onde a equipe usou o Claude tag para investigar problemas em threads compartilhadas.
hill climbing (conceito): Processo iterativo de fazer uma mudança, avaliar o resultado e usar essa avaliação para escolher a próxima tentativa.
Valgrind Callgrind (ferramenta): Ferramenta de profiling que conta instruções de máquina executadas e atribui o trabalho a funções.
continuous integration (conceito): Processo de executar verificações automatizadas quando o código muda, incluindo testes que podem sinalizar regressões de performance.
React (ferramenta): Biblioteca para construir interfaces, mencionada nas explicações sobre inicialização, hydration e re-renderizações.
CLS (conceito): Métrica de mudanças cumulativas de layout que ajuda a detectar conteúdo visualmente instável, mas não descreve por completo a experiência de cada pessoa.

Tradução completa (pt-BR)

00:00 [música] >> Oi. Boas-vindas a mais um vídeo. A Anthropic diz que a experiência do Claude na web e no desktop ficou cerca de três vezes mais rápida durante uma sprint de duas semanas. E eu queria dedicar um tempo a como eles abordam isso, porque as ideias de engenharia são úteis mesmo que você não use o Claude. Quando você pede a uma ferramenta de programação com IA para melhorar um aplicativo, ainda precisa de alguma forma de saber se as mudanças ajudaram. Uma explicação confiante e uma grande mudança no código não dão essa resposta. No percentil 75, a prontidão para digitar

00:31 em um carregamento novo da web melhorou de 3,1 segundos para 0,55. Esse percentil significa que cerca de três quartos dos carregamentos medidos foram tão rápidos quanto esse valor ou mais rápidos. Não é uma média e não descreve os usuários mais lentos. Além disso, estar pronto para aceitar o que você digita é uma medição diferente da rapidez com que um modelo gera a resposta. Minha interpretação do que a Anthropic está defendendo aqui é que você deve dar ao agent uma tarefa e uma forma de verificar o próprio progresso. As orientações mais amplas deles sobre ciclos de agent deixam isso explícito. Defina o que significa ter sucesso, deixe o agent repetir o trabalho e a

01:02 verificação, e dê a ele uma condição de parada. Acho que essa é uma discussão muito mais útil do que contar quantas linhas uma IA escreveu. Se estou esperando um documento abrir, quero saber se ele abre mais rápido e continua funcionando corretamente. Então, vamos entrar no lado técnico disso e depois falar sobre o que tiro dessa experiência. A equipe deles usou o Claude tag no Slack com um modelo interno de pesquisa aproximadamente comparável ao Opus 5.5. O Claude tag é a experiência compartilhada de agent deles dentro do Slack. Ele pode usar a conversa em um thread, trabalhar com ferramentas conectadas e seguir instruções permanentes. Assim, você pode atribuir a um agent uma

01:32 responsabilidade contínua, como acompanhar as issues recebidas, em vez de ter que explicar todo o trabalho de novo sempre que algo acontece. Para uma equipe, consigo entender o apelo. A pessoa que relata um problema e a pessoa que analisa a correção podem discutir as mesmas evidências em um só lugar. Mas colocar um agent no Slack não torna a investigação boa por si só. Você ainda precisa dar a ele acesso útil e decidir o que ele pode alterar. Agora, a expressão hill climbing aparece nessa discussão. Ela significa fazer uma mudança, avaliar o resultado

02:02 e usar esse resultado para decidir qual mudança tentar em seguida. Você precisa de um objetivo específico o bastante para ser medido, e a melhora precisa ser maior do que o ruído da sua avaliação. Imagine que você está tentando fazer uma caixa de pesquisa responder mais rápido. Você poderia mudar a forma como ela filtra os resultados, executar a mesma pesquisa de novo e comparar. Se também tiver mudado o conjunto de dados, o navegador e a conexão de rede, você não saberá quanto mérito atribuir à mudança no código. O experimento precisa ser compreensível. Eles mediram a contagem de instruções, relacionaram esses valores a melhorias no tempo decorrido e impuseram limites mais baixos na integração contínua.

02:32 Então, vamos destrinchar isso. O tempo de relógio é o tempo que passa no relógio enquanto uma operação é executada. Isso é útil porque a espera é o que o usuário sente, mas os tempos podem variar quando a máquina está fazendo outras tarefas. Um profiler ajuda você a olhar dentro da operação e descobrir onde o trabalho acontece. A ferramenta Callgrind do Valgrind pode contar as instruções de máquina executadas e atribuir o trabalho às funções e às funções que elas chamam. Isso permite investigar se uma determinada operação está repetindo trabalho desnecessário. A contagem de instruções é uma medição diferente de milissegundos, e menos

03:02 instruções não significa automaticamente que o aplicativo inteiro pareça mais rápido. Para um programa e uma entrada fixos, contar instruções pode produzir resultados muito mais repetíveis do que usar um cronômetro. Isso facilita a comparação de pequenas mudanças. Você está contando o trabalho executado pela máquina, não o número de linhas em um arquivo de código-fonte. Pense em um serviço de entregas. Você poderia fazer a papelada duas vezes mais rápido, mas, se o pacote passar um dia esperando uma van, o cliente talvez não perceba diferença. Em software, eu gostaria de saber se a função que estamos otimizando é realmente responsável por uma parte significativa do peso.

03:33 Integração contínua, ou CI, é onde verificações automatizadas são executadas quando o código muda. Uma verificação de desempenho pode comparar uma nova medição com uma linha de base aceita e sinalizar uma regressão. Regressão simplesmente significa que uma mudança piorou algo em relação a como era antes. A ideia do ratchet é que uma melhoria se torne o novo padrão. Como exemplo inventado, suponha que uma tarefa repetível exija mil operações e você reduza esse número para 700; então, atualiza o limite para 700. Assim, uma mudança posterior que aumente a contagem de novo será percebida. Eles verificaram os dados de produção depois do deploy e continuaram procurando o próximo gargalo.

04:03 Dados de produção são aquilo que você mede com pessoas usando o aplicativo lançado. Testes de laboratório oferecem condições controladas, enquanto usuários reais trazem diferentes dispositivos, velocidades de rede e padrões de uso. Ambos são úteis. Uma mudança pode parecer boa na sua máquina de teste e ainda assim ter pouco efeito sobre as pessoas que enfrentam o problema. Gosto disso porque a correção passa a vir acompanhada de uma forma de lembrar por que ela era importante. Caso contrário, alguém pode desfazer sua otimização sem querer seis semanas depois, enquanto trabalha em um recurso completamente diferente. Você não deveria depender de todo mundo se lembrar de cada decisão de desempenho. Eles usaram uma caixa de entrada HTML inicial enquanto o React era inicializado e reduziram as novas renderizações da barra lateral.

04:35 React é uma biblioteca para criar interfaces. Em um aplicativo que envia HTML primeiro, você pode exibir conteúdo antes de todo o JavaScript estar pronto. Para contextualizar, hidratação é o processo normal do React de conectar a lógica dos componentes ao HTML existente. O HTML inicial e a saída do React precisam estar de acordo, ou a transição pode causar um problema. A caixa de texto inicial do Claude tinha sua própria transição para a interface completa em React. Eu me preocuparia com mais do que apenas ela aparecer cedo. Se eu digitar a primeira metade de um prompt enquanto o aplicativo está iniciando, esses caracteres precisam

05:06 sobreviver à transição. A caixa deve manter o foco e o texto não deve pular. Uma melhoria no carregamento que interrompe a digitação seria bem irritante. Agora, uma nova renderização do React significa que o React chama os componentes para determinar como a interface deve aparecer. Isso não significa necessariamente que o navegador redesenhe tudo. Em seguida, o React determina quais mudanças precisam ser aplicadas. Mas executar a lógica dos componentes ainda pode custar tempo, especialmente quando um trabalho caro é repetido. Memoization significa reutilizar um resultado anterior quando as entradas relevantes não mudaram. Em uma interface, isso pode ajudar a evitar a repetição de

05:37 trabalho para um componente cujo conteúdo continua igual. Mas você precisa verificar corretamente as entradas, porque reutilizar um resultado desatualizado faz com que a interface deixe de atualizar quando deveria. Imagine digitar em uma caixa de mensagem enquanto uma lista completamente sem relação com ela é recalculada a cada tecla. Eu gostaria que o agent me mostrasse por que a lista está envolvida. Essa é uma investigação específica. E você pode testar se o comportamento muda depois da correção. Eles também reutilizaram blocos de resposta concluídos e moveram a tokenização do código para um worker, chegando a 120 quadros por segundo em um MacBook de 120 hertz. Tokenização, nesse caso, significa

06:09 dividir o código em partes para que um realçador de sintaxe possa reconhecer coisas como palavras-chave e strings. Esse é um trabalho que a interface executa para exibir o código. Um web worker pode executar um trabalho JavaScript adequado em uma thread separada e comunicar os resultados de volta por meio de mensagens. Ele não pode manipular diretamente o documento da página como a thread principal pode. >> A thread principal do navegador cuida de boa parte do trabalho envolvido na execução do JavaScript da página e na atualização da interface. Quando uma tarefa ocupa essa thread por tempo demais, outros trabalhos precisam esperar. Isso pode aparecer como uma resposta atrasada à entrada do usuário ou uma animação que

06:40 engasga. A 120 quadros por segundo, há apenas cerca de 8,3 milissegundos entre os quadros. Esse é o tempo disponível para o quadro inteiro. Portanto, um trecho individual de JavaScript não pode usar tudo isso sem mais nem menos. Uma alta taxa de atualização torna o trabalho desnecessário mais fácil de notar, porque o próximo quadro precisa ser exibido muito em breve. Em uma resposta transmitida aos poucos, imagine receber a última frase de uma página e, depois, formatar novamente todos os parágrafos anteriores. À medida que a resposta cresce, essa abordagem continua aumentando o trabalho. Reutilizar as partes concluídas faz sentido, desde que você saiba que elas realmente

07:10 estão concluídas. Caso contrário, você pode trocar um problema de desempenho por uma formatação incorreta. Os saltos na barra lateral ficaram dentro do limite normalmente considerado bom para CLS, apesar de incomodarem os usuários. Uma mudança de layout ocorre quando o conteúdo visível se desloca inesperadamente. Cumulative layout shift, ou CLS, mede esses deslocamentos usando fatores como a parte da tela afetada e a distância que os elementos se movem. Isso é útil para detectar páginas instáveis, mas uma pontuação não descreve todos os detalhes da experiência de alguém. Suponha que um botão pequeno se mova bem quando você está prestes a clicar nele. A área envolvida pode ser minúscula, mas, ainda assim, você clica no lugar errado

07:40 coisa. Por isso, eu usaria gravações e interações reais junto com um dashboard. Também gostaria de um teste que reproduzisse o movimento específico de que as pessoas reclamaram. As orientações separadas da Anthropic sobre avaliações destacam um ponto relacionado: as tarefas que você testa devem refletir o trabalho que realmente importa para você. Um agent pode melhorar em um benchmark sem melhorar o uso real, se o benchmark for estreito demais. Testar com exemplos diferentes daqueles usados na otimização ajuda a revelar isso. Essa é a parte à qual eu voltaria sempre se estivesse gerenciando esse trabalho. Você pode fazer um dashboard parecer mais saudável mudando o que é medido ou evitando um caso difícil.

08:11 Eu gostaria que a equipe conseguisse explicar o que uma pontuação melhor significa para quem usa o produto. Eles executaram mais de 150 threads com responsáveis humanos, testes e lançamentos graduais. Entendo por que o trabalho em paralelo ajuda quando as investigações são separadas. Um agent pode estudar a inicialização enquanto outro analisa a rolagem, mas, se os dois alterarem o mesmo componente compartilhado, alguém precisa resolver a sobreposição. Eu esperaria que revisão e coordenação se tornassem uma parte maior do trabalho à medida que o número de agents aumenta. Um feature flag permite que uma equipe ative ou desative um comportamento sem necessariamente remover o código. Um lançamento gradual

08:42 introduz uma mudança primeiro para um grupo limitado e, depois, amplia o alcance após a equipe verificar os resultados. Isso dá a você a oportunidade de detectar problemas em condições reais antes que a mudança chegue a todo mundo. Toda mudança precisava de aprovação humana. A Anthropic relata mais de 3.000 mudanças integradas, sem incidentes que afetassem clientes nem reversões. É um resultado animador para este sprint. Ainda assim, eu teria cuidado para não tratar isso como uma promessa para outra equipe, com testes diferentes e outra base de código. O nível de suporte dado ao agent faz parte do que você está avaliando aqui. Os engenheiros deles forneceram ambição, critério e direção,

09:15 insistindo em melhorias adicionais, avaliando mudanças visíveis e mantendo as investigações focadas. Acho que isso dá à pessoa uma função exigente. É preciso entender o suficiente para contestar um resultado fraco e ter moderação suficiente para interromper uma reescrita desnecessária. Também gostaria que alguém acompanhasse a experiência como um todo. Otimizar cada componente individualmente não garante que o aplicativo inteiro pareça coerente. Eles rejeitaram uma proposta de 900 linhas que economizava 2 milissegundos por centavo. Pessoalmente, gosto muito desse detalhe. Uma melhoria de desempenho ainda tem um custo de manutenção. Alguém precisa entender o novo

09:46 código quando ele falha, atualizá-lo quando as dependências mudam e decidir se ainda vale a pena mantê-lo. Eu precisaria de uma justificativa mais forte para aceitar tanta complexidade em troca de uma economia tão pequena. Então, o workflow que a Anthropic está incentivando dá ao agent mais espaço para iterar e, ao mesmo tempo, torna a verificação explícita. As orientações deles sobre o loop também recomendam testar uma pequena parte do trabalho antes de ampliar a escala, definir limites claros e verificar o uso de tokens. Esses detalhes importam se você está pagando por tentativas repetidas. Para seu próprio aplicativo, eu começaria com um problema que você consiga reproduzir. Peça ao agent que registre uma linha de base e investigue a causa

10:17 antes de fazer alterações. Depois, peça uma correção pequena, a mesma medição após a mudança e uma verificação de que o comportamento existente continua funcionando. Eu também definiria um orçamento para esse primeiro experimento. Dá para gastar muito tempo melhorando algo que ninguém percebe se o agent já tentou várias abordagens e a melhoria restante é mínima. Eu gostaria que ele explicasse a troca envolvida antes de continuar. Mais atividade não torna o projeto automaticamente mais valioso. No geral, o que tiro disso é que a qualidade do feedback merece tanta atenção quanto o prompt. Eu preferiria dedicar algum esforço a criar um teste útil a continuar perguntando a um agent se tem certeza de que o

10:47 aplicativo está mais rápido. Quando ele consegue mostrar a diferença, tenho algo concreto para analisar e posso decidir se vale a pena manter a melhoria. No geral, é bem legal. Enfim, contem nos comentários o que vocês acharam. Se gostaram deste vídeo, considerem fazer uma doação pela opção Super [música] Thanks ou se tornar membro clicando no botão de adesão. Além disso, deixem um gostei neste vídeo e inscrevam-se [música] no meu canal. Vejo vocês no próximo. Até lá, tchau.

11:21 >> [música]

Transcrição original

[00:00] [music] >> Hi. Welcome to another video. So, Anthropic [music] says Claude’s web and desktop experience became about three times faster during a two-week sprint. And I wanted to spend some time on how they approach this because the engineering ideas are useful even if you don’t use Claude. When you ask an AI coding tool to improve an application, you still need some way to tell whether its changes helped. A confident explanation and a big code change don’t give you that answer. At the 75th percentile, typing

[00:31] readiness on a fresh web load improved from 3.1 seconds to 0.55. That percentile means roughly three quarters of the measured loads were that fast or faster. It isn’t an average and it doesn’t describe the slowest users. Also, being ready to accept your typing is a different measurement from how quickly a model generates its response. My reading of what Anthropic is preaching here is that you should give the agent a job with a way to check its own progress. Their broader guidance on agent loops makes this explicit. Define what success means, let the agent repeat the work and

[01:02] verification, and give it a stopping condition. I think that’s a much more useful discussion than counting how many lines an AI wrote. If I’m waiting for a document to open, I care about whether the document opens sooner and still works properly. So, let’s get into the technical side of this and then talk about what I take from it. Their team used Claude tag in Slack with an internal research model roughly comparable to Opus 5.5. Claude tag is their shared agent experience inside Slack. It can use the conversation in a thread, work with connected tools, and follow standing instructions. So, you can give an agent an ongoing

[01:32] responsibility such as watching incoming issues instead of having to explain the whole job again whenever something happens. For a team, I can see the appeal. The person reporting a problem and the person reviewing the fix can discuss the same evidence in one place. But putting an agent in Slack doesn’t make the investigation good by itself. You still have to give it useful access and decide what it should be allowed to change. Now, the phrase hill climbing comes up in this discussion. It means making a change, evaluating the result,

[02:02] and using that result to decide which change to try next. You need an objective that’s specific enough to measure, and the improvement needs to be larger than the noise in your evaluation. Imagine you’re trying to make a search box respond faster. You could change the way it filters results, run the same search again, and compare. If you’ve also changed the data set, the browser, and the network connection, then you don’t know how much credit the code change deserves. The experiment needs to be understandable. They measured instruction counts, tied those to elapsed time improvements, and enforced lower ceilings in continuous

[02:32] integration. So, let’s unpack that. Wall clock time is the time that passes on a clock while an operation runs. That’s useful because waiting is what a user experiences, but timings can move around when the machine is doing other work. A profiler helps you look inside the operation and find where the work happens. Valgrind’s Callgrind tool can count executed machine instructions and attribute work to functions and the functions they call. That lets you investigate whether a particular operation is repeatedly doing unnecessary work. An instruction count is a different measurement from milliseconds, and fewer

[03:02] instructions won’t automatically mean the entire application feels faster. For a fixed program and input, instruction counting can give you much more repeatable results than a stopwatch. That makes small changes easier to compare. You’re counting the machine’s executed work, not the number of lines in a source file. Think of a delivery service. You could make the paperwork twice as fast, but if the package spends a day waiting for a van, the customer might see no difference. In software, I’d want to know whether the function we’re optimizing is actually responsible for a meaningful part of the weight.

[03:33] Continuous integration, or CI, is where automated checks run when code changes. A performance check can compare a new measurement against an accepted baseline and flag a regression. A regression just means that a change made something worse than it was before. The ratchet idea is that an improvement becomes the new standard. For a made-up example, suppose a repeatable task a thousand operations and you reduce that to 700, you update the limit to 700. So, a later change that pushes the count back up gets noticed. They checked production data after deployment and kept looking for the next bottleneck.

[04:03] Production data is what you measure from people using the released application. Lab tests give you controlled conditions, while real users bring different devices, network speeds, and usage patterns. Both are useful. A change can look good on your test machine and still have little effect on the people experiencing the problem. I like this because the fix now comes with a way to remember why it mattered. Otherwise, someone can accidentally undo your optimization six weeks later while working on a completely different feature. You shouldn’t have to depend on everybody remembering every performance decision. They used an early HTML input box while React initialized and reduced

[04:35] sidebar re-renders. React is a library for building interfaces. With an application that sends HTML first, you can show content before all the JavaScript is ready. For background, hydration is the usual React process of connecting component logic to existing HTML. The initial HTML and the React output need to agree or the handoff can cause problem. Claude’s early text box had its own handoff to the full React interface. I’d care about more than whether it appears early. If I type the first half of a prompt while the application is starting, those characters need to

[05:06] survive the handoff. The box should keep focus and the text shouldn’t jump. A loading improvement that interrupts typing would be pretty annoying. Now, a React re-render means React calls components to work out what the interface should look like. It doesn’t necessarily mean the browser redraws everything. React then determines which changes need to be applied. But running that component logic can still cost time, especially when expensive work happens repeatedly. Memoization means reusing a previous result when the relevant inputs haven’t changed. For an interface, this can help avoid repeating

[05:37] work for a component whose content is still the same. You have to check the inputs correctly, though, because reusing an outdated result gives you an interface that fails to update when it should. Imagine typing in a message box while a completely unrelated list recalculates itself on every key press. I’d want the agent to show me why the list is involved at all. That’s a specific investigation. And you can test whether the behavior changes after the fix. They also reused finished reply blocks and moved code tokenization to a worker, reaching 120 frames per second on a 120 hertz MacBook. Tokenization here means

[06:09] breaking code into pieces so a syntax highlighter can recognize things like keywords and strings. This is work the interface does to display code. A web worker can run suitable JavaScript work on a separate thread, communicating results back through messages. It can’t directly manipulate the page’s document the way the main thread can. >> The browser’s main thread handles a lot of the work involved in running page JavaScript and updating the interface. When one task occupies it for too long, other work has to wait. That can show up as delayed input or an animation that

[06:40] stutters. At 120 frames per second, there are only about 8.3 milliseconds between frames. That’s the time available for the whole frame. So an individual piece of JavaScript can’t casually use all of it. A high refresh rate makes unnecessary work easier to notice because the next frame is due so soon. For a streaming answer, imagine receiving the last sentence of a page and then formatting every earlier paragraph again. As the answer grows, that approach keeps giving you more work. Reusing the completed parts is sensible as long as you know they really

[07:10] are complete. Otherwise, you can trade a performance problem for incorrect formatting. The sidebar jumps stayed within the usual good CLS threshold despite bothering users. A layout shift is when visible content unexpectedly moves. Cumulative layout shift or CLS scores these movements using factors such as how much of the screen is affected and how far things move. It’s useful for detecting unstable pages, but a score doesn’t describe every detail of someone’s experience. Suppose a small button moves just as you’re about to click it. The area involved might be tiny, but you still click the wrong

[07:40] thing. That’s why I’d use recordings and real interactions alongside a dashboard. I’d also want a test that reproduces the particular movement people complained about. Anthropic’s separate guidance on evaluations makes a related point. The tasks you test should reflect the work you actually care about. An agent can improve a benchmark without improving real use if the benchmark is too narrow. Testing on examples outside the ones used for optimization helps expose that. That’s the part I’d keep coming back to if I were managing this work. You can make a dashboard look healthier by changing what gets measured or by avoiding a difficult case.

[08:11] I’d want the team to be able to explain what a better score means for the person using the product. They ran over 150 threads with human owners, tests, and staged rollouts. I can see why parallel work helps when the investigations are separate. One agent might study startup while another looks at scrolling, but if they both change the same shared component, somebody needs to resolve the overlap. I’d expect review and coordination to become a bigger part of the job as the number of agents increases. A feature flag lets a team enable or disable a behavior without necessarily removing the code. A staged rollout

[08:42] introduces a change to a limited group first, then expands it after the team checks the results. That gives you an opportunity to catch problems under real conditions before the change reaches everybody. Every change needed human approval. Anthropic reports over 3,000 merged changes with no customer-facing incidents or rollbacks. That’s an encouraging result for this sprint. I’d still be careful about treating it as a promise for another team with different tests and a different code base. The amount of support around the agent is part of what you’re evaluating here. Their engineers supplied ambition, taste, and direction,

[09:15] pushing for further improvements, judging visible changes, and keeping investigations focused. I think that gives the human a demanding role. You need enough understanding to challenge a weak result and enough restraint to stop an unnecessary rewrite. I’d also want somebody watching the experience as a whole. Optimizing each individual component doesn’t guarantee that the entire application feels coherent. They rejected a 900-line proposal saving 2 milliseconds per cent. Personally, I like that detail a lot. A performance improvement still has a maintenance cost. Somebody has to understand the new

[09:46] code when it breaks, update it when dependencies change, and decide whether it still belongs there. I’d want a stronger reason to accept that much complexity for such a small saving. So, the workflow Anthropic is encouraging gives the agent more room to iterate while making verification explicit. Their loop guidance also recommends testing on a small slice of work before scaling up, setting clear limits, and checking token usage. Those details matter if you’re paying for repeated attempts. For your own app, I’d begin with one problem you can reproduce. Ask the agent to capture a baseline and investigate the cause

[10:17] before changing things. Then ask for a small fix, the same measurement afterward, and a check that the existing behavior still works. I’d also give that first experiment a budget. You can spend a lot of time improving something nobody notices if the agent has tried several approaches and the remaining improvement is tiny. I’d want it to explain the trade-off before continuing. More activity doesn’t automatically make the project more valuable. Overall, what I take from this is that the quality of the feedback deserves as much attention as the prompt. I would rather spend some effort making a useful test than keep asking an agent whether it’s sure the

[10:47] app is faster. Once it can show the difference, I have something concrete to review, and I can decide whether the improvement is worth keeping. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the Super [music] Thanks option, or becoming a member by clicking the join button. Also, give this video a thumbs up and subscribe [music] to my channel. I’ll see you in the next one. Until then, bye.

[11:21] >> [music]