Só nessas horas eles concordam.
A OpenAI, que age descaradamente mesmo tendo “Open” cravado no nome, ou
a Anthropic, que saiu dizendo que a OpenAI tinha mudado, ou
se fazem isso por dinheiro, ou se veem a IA como uma disputa por hegemonia e o governo se envolve, manipulando a diretoria à vontade.
Vender educação é o que tem o melhor custo-benefício. Não há responsabilidade, só cobrança de custos. A IA vai ficar com uma grande fatia desse negócio.
Acho que o ponto 3 (separação de responsabilidades entre agentes) é a parte mais difícil. Já examinei alguns traces de benchmarks públicos e compartilho aqui um padrão que vi por lá.
O mais comum não era uma “decisão errada”, mas a mesma tarefa ser executada duas vezes. O envio de um e-mail se repetia com os mesmos argumentos, ou o mesmo arquivo era regravado. Isso aparecia com frequência especialmente no trecho de retry após timeout: a primeira chamada só tinha sido lenta, mas era considerada falha e chamada de novo.
O motivo pelo qual isso é difícil de rastrear é que não ocorre erro. As duas retornam 200 e os logs ficam limpos, então, olhando apenas os logs depois, isso não aparece.
O método que usamos é agrupar por (ferramenta, argumentos normalizados, hash da saída) e contar mecanicamente se a mesma combinação se repete. Como é só cálculo, sem julgamento do LLM, é reproduzível. Mas a limitação é clara: dá para saber apenas que “foi chamado duas vezes”, não se “foi realmente executado duas vezes” só pelo trace. Para ferramentas que retornam um ID de entidade na resposta (como uma API de criação de documentos), dá para confirmar comparando os IDs, mas, para ferramentas como e-mail que só retornam “envio bem-sucedido”, não há como.
Também concordo com o ponto 2 que você mencionou, de “deixar passar em prol da velocidade”. Nós também avaliamos bloquear em tempo real, mas antes da execução não dá para ver o resultado, então seria preciso julgar apenas pelos argumentos, e a precisão era baixa. Acabamos desistindo porque havia casos em que até retries normais eram bloqueados.
A correção de bugs também ficou muito barata, e o custo de atualização de software tende a zero; além disso, a menos que seja algo no nível do setor financeiro, muitas vezes basta corrigir o bug quando ele aparece...
Mas, se essa percepção for se acumulando, no fim é assim que grandes acidentes acabam acontecendo.
Se ao usar você encontrar alguma conversa em que o jumpback não funcione direito, ou alguma parte que pareça "isso é meio inconveniente", fique à vontade para deixar um comentário. Como a estrutura das conversas varia de site para site, casos reais de uso ajudam muito. Em seguida estou pensando em dar suporte ao Perplexity e exportação para Notion/Obsidian, mas, se houver algo mais urgente, pretendo priorizar isso primeiro, haha.
Obrigado. Teste e, se houver alguma conversa em que o jump back não funcione, fique à vontade para me avisar~
Eu também estou usando, mas acho que seria bom poder ouvir também sobre os incômodos de outros usuários reais haha
Parece possível observar o log de diffs sempre que um agente fizer alterações e, se ele provocar shotgun surgery ou um grande volume de mudanças, tratá-lo como um mau cheiro de engenharia de software e aplicar aprendizado por reforço...
[Para facilitar a leitura, incluí uma tradução do README para o português!]
Clew
Um detector determinístico que encontra trabalho desperdiçado em traces de agentes.
O Clew lê traces de execuções concluídas de agentes de IA e identifica etapas que repetiram trabalho já realizado — rechamar a mesma ferramenta com os mesmos argumentos, tentar novamente uma chamada que falhou com os mesmos argumentos, ou consultar de novo informações que já estavam no contexto. Como funciona sem julgamento de LLM, o mesmo trace sempre produz o mesmo resultado.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
Por que isso importa
Em sessões de agentes de IA para programação, o desperdício só aparece na fatura. Todas as chamadas de ferramenta retornam 200 e nada gera erro, então o desperdício não fica visível. Mas, dentro do trace, o agente lê o mesmo arquivo duas vezes, tenta novamente uma chamada que falhou com os mesmos argumentos e chama de novo a mesma ferramenta com o mesmo payload.
Como operações de leitura (read) representam 65% a 90% dos tokens em sessões de agentes de programação, esse desperdício se acumula sem chamar atenção. Ferramentas de observabilidade mostram o trace, mas não indicam qual etapa foi duplicada.
O que ele detecta
O Clew procura três padrões de duplicação:
repeat — a mesma ferramenta/nó é chamada repetidamente
requery — a mesma ferramenta é rechamada com a mesma entrada (saída idêntica)
pingpong — dois agentes trocam conteúdo substancialmente igual (multiagente)
Cada achado é classificado em quatro categorias:
error_repeat — a saída é um erro, mas a mesma chamada é repetida
side_effect — uma ferramenta que altera estado (envio/escrita/criação etc.) é reexecutada
idempotent — repetição de uma ferramenta somente leitura/declarativa (sem efeito colateral, mas consome tokens)
unclassified — ferramenta que não está no mapeamento. Como o efeito depende do payload, não inferimos apenas pelo nome da ferramenta (Bash/PowerShell etc.)
[Como funciona]
É uma cascata em 2 etapas:
Gate estrutural — agrupa chamadas da mesma ferramenta com os mesmos argumentos (normalizados)
Gate de identidade — verifica se o sha256 da saída é exatamente igual. Se for diferente, significa que o estado mudou, então não marca
Uma verificação estrutural barata primeiro filtra os candidatos, e a verificação semântica cara (embedding + cosseno) só é executada quando necessário. Como não há julgamento de LLM, o resultado é determinístico — isso é importante se você quiser colocar no CI.
[Formatos de entrada]
Claude Code — analisa diretamente JSONL de sessão
LangGraph — detecta duplicações de cadeia no trace
LangChain·CrewAI·AutoGen·LlamaIndex etc. — faz parsing de traces instrumentados nos formatos padrão OpenTelemetry/OpenInference (suporte de formato; validação empírica por framework ainda em andamento)
Traces públicos de benchmark (Toolathlon, RedundancyBench)
Sessões do Cursor e do Codex ainda não são compatíveis — estamos analisando os formatos locais.
[Resultados de validação]
Benchmark público (Toolathlon, 6.780 traces, 176.270 tool spans):
Detectou 8.042 chamadas duplicadas. Destas, 47% são zona cinzenta (operações idempotentes, declarações de conclusão); excluindo-as, são 4.251 casos (2,41% dos tool spans). Cerca de 3 vezes mais que nas sessões do Claude Code (0,80%).
Foram detectadas 1.343 execuções duplicadas de ferramentas que alteram estado, incluindo 459 envios de e-mail repetidos com os mesmos argumentos. Porém, isso indica apenas que a mesma ferramenta foi chamada repetidamente com os mesmos argumentos; não foi confirmado se houve, de fato, efeito colateral.
Benchmark de rotulagem (RedundancyBench):
precision 0.826 (estimativa de limite inferior para duplicação dentro do arquivo). Uma parte considerável dos rótulos do RB é de duplicação entre arquivos (cross-file), fora do escopo do desenho de análise por sessão. O recall é baixo, 0.157.
[Limites honestos]
Ainda não há casos medidos de economia. É possível detectar e estimar, mas há 0 dados before/after em que um usuário real corrigiu algo e a fatura efetivamente diminuiu.
47% do que foi sinalizado no benchmark é zona cinzenta (reexecuções idempotentes). Não filtramos; apenas classificamos — porque saber se uma reexecução somente leitura foi desperdício depende de um contexto que não conseguimos ver.
Como exigimos correspondência perfeita por sha256, qualquer pequena diferença na saída faz com que não seja sinalizado. Esse é o motivo do recall baixo; o design privilegia precisão.
O Claude Code é excepcionalmente bem otimizado. Medimos seis padrões candidatos de desperdício em sessões reais do CC, e cinco deles simplesmente não existiam ali. O desperdício interessante apareceu não no CC em si, mas em ambientes MCP com múltiplas ferramentas.
A estimativa de custo (amplification) é uma estimativa, não uma medição, e só é possível no formato do Claude Code.
O que não é validado, descartamos
Criamos um detector de releitura de arquivos, mas o descartamos depois que anotações humanas em uma amostra de 30 casos ficaram muito abaixo do limiar pré-registrado de precisão (70%): 3,3% na avaliação generosa e 0% na rigorosa. As previsões e os resultados foram mantidos juntos no documento de pré-registro.
Atualização do autor. Publiquei um texto separado organizando a parte do servidor MCP que mencionei em apenas uma linha no texto principal — é uma estrutura que resolve o problema de o agente dar nomes arbitrários às colunas ao escrever migrações, trocando o nome físico de algo a ser "inserido" para algo "calculado" com base em um dicionário de termos: https://sqemo.com/blog/erd-mcp-server
(Ainda é apenas local via stdio, então MCP remoto ainda não é suportado; o app principal é fechado, e apenas o servidor MCP está aberto).
Dá para testar na hora sem cadastro (app.sqemo.com), então se houver algum ponto que incomode, deixe um comentário — como ainda está no começo, o feedback é refletido rapidamente.
Desde o primeiro post, continuei expandindo o Repolis para algo mais próximo de uma pequena vila à qual há motivos para voltar, em vez de apenas um navegador 3D de repositórios.
O traffic do GitHub e as informações de repos públicos são refletidos diariamente nos prédios e na iluminação noturna.
Adicionei a Starlight Row, com 8 moradores e suas respectivas casas, rotinas diurnas/noturnas e pequenas caminhadas e interações entre os moradores.
Com Explorer Passport, Village Chronicle e Town Gazette, é possível acompanhar registros de visitas e novos repos, releases, pushes e mudanças de métricas.
Posicionei na cidade real do Repolis a World Tree procedural criada com o plugin Copilot threejs-sculpt-dna.
Por padrão, continua sendo um app estático zero-build que não precisa de backend nem de chaves; apenas os recursos grounded AI taxi/scholar são opcionais.
Em vez de criar um novo post, vou continuar registrando as mudanças posteriores nos comentários deste post original.
No teclado coreano do Mac não dá para digitar :( No Claude, ele usa bem mais esse sinal nas respostas, mas para usuários de coreano isso não é muito familiar...
Sou o autor. Para complementar algumas coisas que não couberam no texto —
· Os vídeos de demonstração (fluxo de aprovação pelo celular, command center em 3 painéis no desktop) estão na landing page, com capturas reais: adhf.dev
· Para self-host, basta uma linha: npm i -g adhdev; o dashboard aparece em localhost:3847 (sem necessidade de conta)
· Perguntas de design são bem-vindas, como sobre o projeto de merge ff-only ou o que a validação cruzada MAGI realmente detecta
Se enviarem feedback, vou incorporar imediatamente.
Hoje em dia, não se fala em dívida técnica, mas em dívida cognitiva.
Às vezes, conversando com colegas, dá até um certo arrepio ver que eles não entendem direito o funcionamento de algo que eles mesmos criaram.
Com o passar do tempo, isso vai acabar chegando a um estado em que ninguém entende mais como funciona, mas fico pensando se talvez isso não seja um problema, já que dá para pedir para a IA analisar e perguntar a ela.
Só nessas horas eles concordam.
A OpenAI, que age descaradamente mesmo tendo “Open” cravado no nome, ou
a Anthropic, que saiu dizendo que a OpenAI tinha mudado, ou
se fazem isso por dinheiro, ou se veem a IA como uma disputa por hegemonia e o governo se envolve, manipulando a diretoria à vontade.
eca...
Vender educação é o que tem o melhor custo-benefício. Não há responsabilidade, só cobrança de custos. A IA vai ficar com uma grande fatia desse negócio.
Acho que vi isso há alguns anos.
Primeiro, fui ao site original e, como a explicação é feita com imagens, ficou fácil entender de forma intuitiva.
Melhora se você aumentar as atividades offline, como caminhar ou ler. haha
Acho que o ponto 3 (separação de responsabilidades entre agentes) é a parte mais difícil. Já examinei alguns traces de benchmarks públicos e compartilho aqui um padrão que vi por lá.
O mais comum não era uma “decisão errada”, mas a mesma tarefa ser executada duas vezes. O envio de um e-mail se repetia com os mesmos argumentos, ou o mesmo arquivo era regravado. Isso aparecia com frequência especialmente no trecho de retry após timeout: a primeira chamada só tinha sido lenta, mas era considerada falha e chamada de novo.
O motivo pelo qual isso é difícil de rastrear é que não ocorre erro. As duas retornam 200 e os logs ficam limpos, então, olhando apenas os logs depois, isso não aparece.
O método que usamos é agrupar por (ferramenta, argumentos normalizados, hash da saída) e contar mecanicamente se a mesma combinação se repete. Como é só cálculo, sem julgamento do LLM, é reproduzível. Mas a limitação é clara: dá para saber apenas que “foi chamado duas vezes”, não se “foi realmente executado duas vezes” só pelo trace. Para ferramentas que retornam um ID de entidade na resposta (como uma API de criação de documentos), dá para confirmar comparando os IDs, mas, para ferramentas como e-mail que só retornam “envio bem-sucedido”, não há como.
Também concordo com o ponto 2 que você mencionou, de “deixar passar em prol da velocidade”. Nós também avaliamos bloquear em tempo real, mas antes da execução não dá para ver o resultado, então seria preciso julgar apenas pelos argumentos, e a precisão era baixa. Acabamos desistindo porque havia casos em que até retries normais eram bloqueados.
A correção de bugs também ficou muito barata, e o custo de atualização de software tende a zero; além disso, a menos que seja algo no nível do setor financeiro, muitas vezes basta corrigir o bug quando ele aparece...
Mas, se essa percepção for se acumulando, no fim é assim que grandes acidentes acabam acontecendo.
Se ao usar você encontrar alguma conversa em que o jumpback não funcione direito, ou alguma parte que pareça "isso é meio inconveniente", fique à vontade para deixar um comentário. Como a estrutura das conversas varia de site para site, casos reais de uso ajudam muito. Em seguida estou pensando em dar suporte ao Perplexity e exportação para Notion/Obsidian, mas, se houver algo mais urgente, pretendo priorizar isso primeiro, haha.
Obrigado. Teste e, se houver alguma conversa em que o jump back não funcione, fique à vontade para me avisar~
Eu também estou usando, mas acho que seria bom poder ouvir também sobre os incômodos de outros usuários reais haha
Parece possível observar o log de diffs sempre que um agente fizer alterações e, se ele provocar shotgun surgery ou um grande volume de mudanças, tratá-lo como um mau cheiro de engenharia de software e aplicar aprendizado por reforço...
[Para facilitar a leitura, incluí uma tradução do README para o português!]
Clew
Um detector determinístico que encontra trabalho desperdiçado em traces de agentes.
O Clew lê traces de execuções concluídas de agentes de IA e identifica etapas que repetiram trabalho já realizado — rechamar a mesma ferramenta com os mesmos argumentos, tentar novamente uma chamada que falhou com os mesmos argumentos, ou consultar de novo informações que já estavam no contexto. Como funciona sem julgamento de LLM, o mesmo trace sempre produz o mesmo resultado.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Exemplo de saída real ao rodar em uma sessão pública do Claude Code:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPor que isso importa
Em sessões de agentes de IA para programação, o desperdício só aparece na fatura. Todas as chamadas de ferramenta retornam 200 e nada gera erro, então o desperdício não fica visível. Mas, dentro do trace, o agente lê o mesmo arquivo duas vezes, tenta novamente uma chamada que falhou com os mesmos argumentos e chama de novo a mesma ferramenta com o mesmo payload.
Como operações de leitura (read) representam 65% a 90% dos tokens em sessões de agentes de programação, esse desperdício se acumula sem chamar atenção. Ferramentas de observabilidade mostram o trace, mas não indicam qual etapa foi duplicada.
O que ele detecta
O Clew procura três padrões de duplicação:
repeat — a mesma ferramenta/nó é chamada repetidamente
requery — a mesma ferramenta é rechamada com a mesma entrada (saída idêntica)
pingpong — dois agentes trocam conteúdo substancialmente igual (multiagente)
Cada achado é classificado em quatro categorias:
error_repeat — a saída é um erro, mas a mesma chamada é repetida
side_effect — uma ferramenta que altera estado (envio/escrita/criação etc.) é reexecutada
idempotent — repetição de uma ferramenta somente leitura/declarativa (sem efeito colateral, mas consome tokens)
unclassified — ferramenta que não está no mapeamento. Como o efeito depende do payload, não inferimos apenas pelo nome da ferramenta (Bash/PowerShell etc.)
[Como funciona]
É uma cascata em 2 etapas:
Gate estrutural — agrupa chamadas da mesma ferramenta com os mesmos argumentos (normalizados)
Gate de identidade — verifica se o sha256 da saída é exatamente igual. Se for diferente, significa que o estado mudou, então não marca
Uma verificação estrutural barata primeiro filtra os candidatos, e a verificação semântica cara (embedding + cosseno) só é executada quando necessário. Como não há julgamento de LLM, o resultado é determinístico — isso é importante se você quiser colocar no CI.
[Formatos de entrada]
Claude Code — analisa diretamente JSONL de sessão
LangGraph — detecta duplicações de cadeia no trace
LangChain·CrewAI·AutoGen·LlamaIndex etc. — faz parsing de traces instrumentados nos formatos padrão OpenTelemetry/OpenInference (suporte de formato; validação empírica por framework ainda em andamento)
Traces públicos de benchmark (Toolathlon, RedundancyBench)
Sessões do Cursor e do Codex ainda não são compatíveis — estamos analisando os formatos locais.
[Resultados de validação]
Benchmark público (Toolathlon, 6.780 traces, 176.270 tool spans):
Detectou 8.042 chamadas duplicadas. Destas, 47% são zona cinzenta (operações idempotentes, declarações de conclusão); excluindo-as, são 4.251 casos (2,41% dos tool spans). Cerca de 3 vezes mais que nas sessões do Claude Code (0,80%).
Foram detectadas 1.343 execuções duplicadas de ferramentas que alteram estado, incluindo 459 envios de e-mail repetidos com os mesmos argumentos. Porém, isso indica apenas que a mesma ferramenta foi chamada repetidamente com os mesmos argumentos; não foi confirmado se houve, de fato, efeito colateral.
Benchmark de rotulagem (RedundancyBench):
precision 0.826 (estimativa de limite inferior para duplicação dentro do arquivo). Uma parte considerável dos rótulos do RB é de duplicação entre arquivos (cross-file), fora do escopo do desenho de análise por sessão. O recall é baixo, 0.157.
[Limites honestos]
Ainda não há casos medidos de economia. É possível detectar e estimar, mas há 0 dados before/after em que um usuário real corrigiu algo e a fatura efetivamente diminuiu.
47% do que foi sinalizado no benchmark é zona cinzenta (reexecuções idempotentes). Não filtramos; apenas classificamos — porque saber se uma reexecução somente leitura foi desperdício depende de um contexto que não conseguimos ver.
Como exigimos correspondência perfeita por sha256, qualquer pequena diferença na saída faz com que não seja sinalizado. Esse é o motivo do recall baixo; o design privilegia precisão.
O Claude Code é excepcionalmente bem otimizado. Medimos seis padrões candidatos de desperdício em sessões reais do CC, e cinco deles simplesmente não existiam ali. O desperdício interessante apareceu não no CC em si, mas em ambientes MCP com múltiplas ferramentas.
A estimativa de custo (amplification) é uma estimativa, não uma medição, e só é possível no formato do Claude Code.
O que não é validado, descartamos
Criamos um detector de releitura de arquivos, mas o descartamos depois que anotações humanas em uma amostra de 30 casos ficaram muito abaixo do limiar pré-registrado de precisão (70%): 3,3% na avaliação generosa e 0% na rigorosa. As previsões e os resultados foram mantidos juntos no documento de pré-registro.
Atualização do autor. Publiquei um texto separado organizando a parte do servidor MCP que mencionei em apenas uma linha no texto principal — é uma estrutura que resolve o problema de o agente dar nomes arbitrários às colunas ao escrever migrações, trocando o nome físico de algo a ser "inserido" para algo "calculado" com base em um dicionário de termos:
https://sqemo.com/blog/erd-mcp-server
(Ainda é apenas local via stdio, então MCP remoto ainda não é suportado; o app principal é fechado, e apenas o servidor MCP está aberto).
Dá para testar na hora sem cadastro (app.sqemo.com), então se houver algum ponto que incomode, deixe um comentário — como ainda está no começo, o feedback é refletido rapidamente.
Registro de atualizações (2026-07-25)
Desde o primeiro post, continuei expandindo o Repolis para algo mais próximo de uma pequena vila à qual há motivos para voltar, em vez de apenas um navegador 3D de repositórios.
Em vez de criar um novo post, vou continuar registrando as mudanças posteriores nos comentários deste post original.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
No teclado coreano do Mac não dá para digitar :( No Claude, ele usa bem mais esse sinal nas respostas, mas para usuários de coreano isso não é muito familiar...
Eu também testei porque já tinha sido liberado para mim... mas, poxa, o coreano ainda não está bom 😢
Sou o autor. Para complementar algumas coisas que não couberam no texto —
· Os vídeos de demonstração (fluxo de aprovação pelo celular, command center em 3 painéis no desktop) estão na landing page, com capturas reais: adhf.dev
· Para self-host, basta uma linha: npm i -g adhdev; o dashboard aparece em localhost:3847 (sem necessidade de conta)
· Perguntas de design são bem-vindas, como sobre o projeto de merge ff-only ou o que a validação cruzada MAGI realmente detecta
Se enviarem feedback, vou incorporar imediatamente.
Eu estava esperando o GPT-6... já que saiu o Opus 5, não deveria sair um modelo novo?
Hoje em dia, não se fala em dívida técnica, mas em dívida cognitiva.
Às vezes, conversando com colegas, dá até um certo arrepio ver que eles não entendem direito o funcionamento de algo que eles mesmos criaram.
Com o passar do tempo, isso vai acabar chegando a um estado em que ninguém entende mais como funciona, mas fico pensando se talvez isso não seja um problema, já que dá para pedir para a IA analisar e perguntar a ela.
Adoro textos assim.