Todo mundo fala sobre Aprendizado Contínuo como se significasse apenas uma coisa: atualizar os pesos do modelo. Mas há uma verdade inconveniente sobre o ecossistema de agentes — a grande maioria dos agentes em produção hoje utiliza modelos de fronteira fechados. Quando você não possui os pesos, certamente não pode ajustá-los. Para a maioria dos construtores de agentes, o aprendizado contínuo em nível de peso está fora de questão, especialmente quando se trabalha na vanguarda das capacidades (pense em Fable 5 ou GPT 5.6).
Isso não significa que os agentes não podem aprender. Sistemas de agentes podem melhorar em três camadas — modelo, arcabouço e contexto [0] — e as duas últimas estão totalmente sob seu controle. É aqui que reside uma oportunidade enorme (mas muitas vezes negligenciada): o aprendizado em nível de arcabouço permite que você explore traces de produção para melhorar sistematicamente o código, as ferramentas e as instruções que alimentam cada instância do seu agente, enquanto o aprendizado em nível de contexto permite que você personalize no nível do agente, do usuário e da organização, para que seu produto melhore a cada interação. Faça tudo isso e você estará acumulando melhorias que pode implementar diariamente.
No restante deste artigo, vou detalhar como temos aplicado o aprendizado contínuo ao Replit Agent no último ano e compartilhar todas as lições que aprendemos ao longo do caminho.
Avaliando e melhorando o Replit Agent em escala
A maioria dos usuários do Replit Agent começa com uma ideia. Eles descrevem o objetivo em linguagem natural — sem um repositório, suíte de testes ou framework escolhido — e esperam que o agente transforme isso em um aplicativo funcional. O resultado pode ser um site, uma apresentação de slides, um aplicativo móvel, vários artefatos conectados ou algo totalmente diferente.
Os "vibe coders" geralmente não estão verificando diffs ou resultados de testes. O sucesso para o Replit Agent é enganosamente simples: o aplicativo deve funcionar quando os usuários clicam nele.
Isso muda o trabalho da avaliação. Uma única pontuação pode ajudar com uma decisão específica de lançamento, mas não pode nos dizer, semana após semana, se o Replit Agent está melhorando para os usuários. Para responder a essa pergunta, a avaliação deve se tornar parte do ciclo de melhoria.
NASA Lewis Research Center, Sala de Controle Central no Edifício de Pesquisa de Motores, 1968 — A medição importa quando ela muda o que é lançado.
A avaliação precisa fazer mais agora
A avaliação de agentes costumava ser um processo unidirecional: executar a avaliação, produzir uma pontuação e tomar uma decisão de lançamento. Isso funciona quando os lançamentos são lentos e a coisa que está sendo medida raramente muda. Isso se quebra quando modelos, prompts, ferramentas e superfícies de produto estão mudando rapidamente.
O ciclo antigo fazia a avaliação parecer limitada. Mas o Replit Agent muda rápido demais para que uma única pontuação carregue toda a decisão. Uma pontuação pode comparar dois candidatos em um único conjunto de tarefas. Ela não pode explicar com o que os usuários se importam, onde a produção está quebrando ou o que melhorar em seguida.
A avaliação teve que passar de uma verificação de lançamento para um ciclo de melhoria.
O trabalho da avaliação antiga termina em uma decisão humana de lançamento; a nova alimenta um sistema contínuo que aprende com a produção e envia agentes melhorados.
O sistema tem dois pilares de medição e um ciclo de otimização. Benchmarks offline nos dizem se as mudanças candidatas podem concluir tarefas simuladas de construção de aplicativos antes de lançá-las. Testes A/B online e traces de produção mostram como os usuários reais são afetados após o lançamento das mudanças. Esses sinais então fluem de volta para as avaliações e decisões de lançamento.
Nenhuma camada é suficiente por si só. Benchmarks detectam regressões antes do lançamento. Testes A/B mostram se o comportamento da produção mudou. Clusters de traces explicam as falhas por trás das métricas agregadas. O julgamento humano mantém o ciclo de melhoria apontado para os resultados certos de produto e engenharia. A forma é análoga ao modelo do queijo suíço na engenharia de segurança: cada camada tem buracos, mas juntas elas pegam mais do que qualquer camada sozinha.
Os benchmarks existentes param antes do usuário
Benchmarks de codificação de agentes, como SWE-bench [1] e Terminal-Bench [2], avaliam código em ambientes restritos e repetíveis. Esses benchmarks são valiosos e amplamente adotados, mas perdem o sinal que um "vibe coder" se importa.
O Replit Agent geralmente cria a base de código do zero. Os usuários não trazem rotas fixas, assinaturas de funções, seletores ou testes; eles trazem uma solicitação de produto. O agente escolhe a pilha, o esquema, as rotas, os componentes e os fluxos de interação.
Isso cria uma lacuna de correção funcional. Um agente pode satisfazer as restrições locais de um benchmark de codificação e ainda falhar no que o usuário vê: se o aplicativo finalizado faz o que foi solicitado. Para "vibe coding", o alvo da avaliação é o próprio artefato: ele carrega, o fluxo de trabalho principal funciona e o resultado corresponde à solicitação?
Apresentando o ViBench
A necessidade desse estilo de avaliação ponta a ponta é precisamente por que construímos o ViBench [3], nosso benchmark público para "vibe coding", medindo um sinal simples, mas importante: o aplicativo construído pelo agente atende às especificações?
O ViBench começa com um documento de requisitos de produto (PRD) em inglês simples, extraído de traces de produção anonimizados do Replit. A partir daí, o agente recebe o PRD e constrói um aplicativo funcional do zero, sem ser restrito ao scaffolding, rotas ou referências que os benchmarks de codificação tradicionais exigem.
No entanto, a mesma flexibilidade que torna o ViBench realista exige um agente de avaliação igualmente flexível, que permaneça fundamentado no PRD. Em benchmarks do tipo SWE-bench, o projeto já existe, então a superfície de avaliação é fixa. No "vibe coding", o agente escolhe a pilha, rotas, componentes e fluxo. A avaliação tem que explorar tudo o que ele inventou.
Para esse fim, cada tarefa do ViBench emparelha o PRD com um conjunto de planos de teste em linguagem natural que descrevem as interações e asserções em nível de recurso que o aplicativo finalizado deve satisfazer. O agente de avaliação usa o Playwright como uma espinha dorsal flexível, o que permite exercitar recursos complexos como simulação offline, manipulação de arquivos e multilocação. Como ele não conhece os localizadores ou a estrutura do aplicativo a priori, ele trabalha em um ambiente de notebook, descobrindo progressivamente como o aplicativo é construído e interagindo com ele passo a passo, uma abordagem extraída da pesquisa anterior do Replit sobre autoteste automatizado [4].
Executar o ViBench, e nossas avaliações em geral, na escala do Replit também exige um forte suporte de infraestrutura [5]. Internamente, contamos com a mesma infraestrutura de produção que nos permite criar sandboxes isolados e com bons recursos para construir aplicativos e executar nossos agentes. Como podemos bifurcar rapidamente essas sandboxes [6], executamos grande parte da avaliação em paralelo, sem o risco de contaminação cruzada entre avaliações.
Além de construir aplicativos do zero, a mesma base do ViBench, um PRD em linguagem natural avaliado por planos de teste em linguagem natural, se adapta a uma variedade de cenários de "vibe coding". Para avaliar como um agente funciona dentro de um aplicativo existente, mais próximo das cargas de trabalho de trajetória intermediária do Replit, nós o iniciamos em uma base de código existente e medimos o quão bem ele implementa extensões de recursos a partir de um PRD de recurso. Essa base de código pode vir de nossas próprias implementações de referência ou de aplicativos que o próprio agente codificou com "vibe", que chamamos de Vibe-to-ref e Vibe-on-Vibe em nossa publicação. Quando lançamos novas superfícies de produto, a mesma espinha dorsal nos permite derivar rapidamente novos problemas para avaliar novos padrões de interação, como fizemos para as decomposições paralelas e de mesclagem e subagentes do Agent 4.
O ViBench mantém o avaliador comportamental fixo enquanto varia a estratégia de entrada e construção.
Os primeiros resultados do ViBench nos deram duas lições úteis. Primeiro, as pontuações de benchmarks de codificação de fronteira nem sempre se transferem para a construção completa de aplicativos, especialmente para modelos de peso aberto. Segundo, a maioria dos modelos piora ao estender seu próprio código, pois os erros geralmente se acumulam. Juntas, essas lições nos dão uma colina melhor para escalar: não apenas escrever código que passa em testes, mas construir aplicativos que podem sobreviver à próxima solicitação do usuário.
O teste A/B é como nos mantemos honestos
Confiamos profundamente nas avaliações offline, mas elas não são o único juiz. Já vimos atualizações de agentes com boa aparência em ambientes controlados, apenas para regredir o comportamento real do usuário, o suficiente para saber que a produção precisa de sua própria camada de medição.
Os usuários são não roteirizados, estão sempre ativos e operam em uma escala que nenhum benchmark offline pode reproduzir completamente. Eles abandonam projetos, mudam de ideia, combinam recursos de maneiras surpreendentes e descobrem modos de falha que não sabíamos que precisavam ser testados.
Então, fazemos teste A/B na maioria das atualizações que afetam o agente: prompts, ferramentas, revisões de arcabouço, trocas de modelo e mudanças de comportamento maiores. Múltiplos experimentos geralmente são executados simultaneamente — com atribuição mantida clara para evitar ocultar efeitos de interação. Os testes A/B revelam o comportamento do usuário, o sentimento e o sucesso: os usuários continuaram, o custo se comportou inesperadamente, o sentimento mudou e os usuários lançaram algo?
Os testes A/B nos dão uma leitura controlada do comportamento da produção, mas as métricas agregadas não se explicam. Isso é uma vitória? Qual é a mudança de comportamento raiz?
Um desafio com o teste A/B é que os resultados são difíceis de interpretar. Se a duração da execução aumentar, o agente fez mais trabalho útil ou ficou preso? Se o custo diminuir, melhoramos a eficiência ou o agente parou silenciosamente de fazer algo valioso? Se o sentimento cair, quais casos de uso regrediram, quais modos de falha são novos e quais usuários desistiram?
Telescope: o que está quebrando
O teste A/B nos diz quando o comportamento da produção mudou. O Telescope — nosso sistema para análise e clusterização de traces — ajuda a explicar o porquê.
Na escala de produção, nenhum engenheiro pode ler todos os traces. O Telescope organiza padrões repetidos em clusters de problemas sobre os quais engenheiros e agentes podem agir. Ele resume trajetórias de falha, as incorpora, agrupa casos semelhantes e classifica novas sessões à medida que a distribuição muda. O objetivo não é apenas contar falhas, mas descobrir aquelas escondidas à vista.
GIF
Agrupando o que não sabíamos que precisávamos procurar.
O Telescope usa facetas curtas e baseadas em evidências, inspiradas na mesma abordagem bottom-up do Clio [7]. Para traces, ele reconstrói a sessão a partir de mensagens do usuário, respostas visíveis do agente, chamadas de ferramenta, erros, metadados e outros contextos. A partir daí, o Telescope resume o que deu errado, incorpora esses resumos e usa clusterização baseada em densidade [8] para formar grupos de problemas emergentes.
As facetas tornam a investigação mais rápida, especialmente quando a clusterização sozinha não é suficiente. Quando relatórios de suporte apontam para um problema amplo, como falhas de porta, engenheiros e agentes podem pesquisar primeiro a camada compacta, explorar as facetas relevantes e, em seguida, detalhar as sessões representativas com o contexto de logs e observabilidade necessário para explicá-lo.
Em agregado, a mesma estrutura transforma falhas dispersas em perguntas de produto: quais fluxos de trabalho dominam, quais são abandonados, o que quebra repetidamente e se uma mitigação está reduzindo o cluster pretendido.
Para mais informações sobre essa arquitetura subjacente, veja o post detalhado sobre Topics de nossos colaboradores na Braintrust [9].
O ciclo: da evidência às melhorias do agente
Uma vez que a medição existe, o gargalo se move. ViBench, testes A/B e Telescope podem nos dizer o que falhou, onde falhou e com que frequência está acontecendo. Ainda temos que transformar essa evidência em correções plausíveis.
Recorremos a um ciclo de autoaperfeiçoamento para resolver isso. O princípio operacional é simples: se os agentes são úteis para construir software, eles também devem ser úteis para melhorar o agente. Cada passagem começa lendo logs de produção, clusters de traces e falhas recentes para encontrar uma hipótese que vale a pena perseguir. Em seguida, constrói um candidato, abre um PR de rascunho com o raciocínio anexado, mede o resultado em relação ao ViBench, resultados A/B, dados de trajetória e linhas de base recentes, e recomenda se deve lançar, iterar ou descartar.
O ciclo de otimização descobre problemas, propõe mudanças no agente, as avalia e decide se deve lançar, iterar ou descartar.
O lançamento não se torna automático. O ciclo pode preparar as evidências e a implementação de primeira passagem; os engenheiros ainda revisam o resultado e são os donos da decisão de lançamento.
Cada execução registra o que tentou e o que aconteceu, incluindo falhas. Esse registro melhora o ciclo ao longo do tempo: execuções futuras podem reutilizar o que funcionou, evitar becos sem saída conhecidos e propor mudanças que generalizam.
A iteração do agente fica mais rápida sem abrir mão do controle da engenharia. Dado um novo modelo, superfície de produto ou meta de confiabilidade, o ciclo pode encontrar proativamente edições de prompt, propostas de habilidades, correções de ferramentas e mudanças de arcabouço, enquanto os engenheiros mantêm o sistema apontado para o ótimo maior do produto.
Um exemplo concreto
Uma execução recente começou com um cluster pequeno, mas crescente, do Telescope. A configuração do ambiente estava se degradando silenciosamente em uma longa cauda de cenários de inicialização a frio. Essas sessões não eram óbvias a partir das métricas agregadas, mas o cluster mostrava um padrão que valia a pena investigar.
Depois de revelar o padrão, o ciclo leu as trajetórias afetadas, propôs um patch, adicionou um teste de regressão e executou o candidato contra o ViBench para confirmar que o caminho feliz não regrediu. Os engenheiros revisaram as evidências, aprovaram a mudança e a enviaram para produção no mesmo dia.
Após o patch ser lançado, o sentimento se recuperou e os usuários afetados foram desbloqueados. Esta é a forma que queremos — um ciclo que encontra um padrão de falha real, conecta-o aos usuários afetados, propõe o nível certo de correção e traz evidências suficientes para um humano decidir se deve lançar.
Onde o gosto humano ainda importa mais
Grande parte disso pode ser executado de forma autônoma: agrupar falhas, propor hipóteses, construir candidatos, executar avaliações e reunir evidências. Os humanos ainda definem a direção e controlam a maioria das saídas, incluindo:
- Seleção de hipóteses. Um sistema pode revelar milhares de falhas, mas os humanos decidem quais perguntas merecem o orçamento noturno do ciclo. Nem todo cluster é igualmente importante, e nem toda regressão aponta para o problema de produto certo.
- Arquitetura de implementação. Os traces podem mostrar que os usuários estão abandonando um fluxo de trabalho, mas decidir se deve suavizar esse caminho, mudar o comportamento do agente ou redesenhar a superfície é um julgamento de engenharia e produto.
- Curadoria de avaliação. Isso não é trabalho administrativo; molda a colina que o agente escala. Se a avaliação recompensar o comportamento errado, o ciclo de otimização irá otimizar fielmente na direção errada.
- Aprovação de lançamento. Lançar uma mudança no agente não é apenas ler um número. Aprovação de lançamento significa ler as evidências, entender o raio de explosão, decidir se o risco é aceitável e ser o dono da implementação.
Esse equilíbrio é importante: o ciclo pode fazer mais da busca, medição e síntese. Os engenheiros ainda escolhem a direção, tomam as decisões de produto e decidem o que é lançado.
Fechando o ciclo
A avaliação não é mais apenas uma barreira antes do lançamento. Ela ajuda a decidir o que corrigir, o que testar e o que lançar.
O trabalho não é produzir um número melhor. É transformar falhas de usuários em melhores lançamentos, para que mais ideias se tornem aplicativos que as pessoas se orgulhem de publicar.
Estamos animados para continuar avançando a fronteira dos agentes autônomos, com foco na confiabilidade para as tarefas de codificação mais complexas. Se você está interessado em trabalhar com agentes de codificação autônomos, estou sempre contratando no time de IA do Replit — entre em contato pelo [email protected]
Autores: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Referências
[0] Aprendizado contínuo para agentes de IA
[1] SWE-bench: Os Modelos de Linguagem Podem Resolver Problemas Reais do GitHub?
[2] Terminal-Bench: Avaliando Agentes em Tarefas Difíceis e Realistas em Interfaces de Linha de Comando
[3] ViBench: Um Benchmark sobre Vibe Coding
[4] Permitindo que o Agente 3 se Autoteste em Escala com Verificação Baseada em REPL
[5] Quantificando o ruído da infraestrutura em avaliações de codificação de agentes
[6] Dentro do Mecanismo de Snapshot do Replit: A Tecnologia que Torna os Agentes de IA Seguros
[7] Clio: Insights que Preservam a Privacidade sobre o Uso Real de IA
[8] Estimativas de Densidade Hierárquica para Agrupamento de Dados, Visualização e Detecção de Outliers
[9] Como tornamos a inteligência contínua de traces possível em escala
