Edição excessiva: quando o modelo modifica o código além do necessário
(nrehiew.github.io)- Mesmo em bugs que podem ser resolvidos com mudanças mínimas, é comum surgir um diff enorme, com reescrita da função inteira, adição de lógica auxiliar e até mudança de assinatura
- Em trabalhos brown-field, que preservam a estrutura existente, não basta passar nos testes; para manter a possibilidade de revisão e a segurança da mudança, também é preciso avaliar o quanto foi alterado
- Com base em 400 problemas do BigCodeBench danificados programaticamente, o estudo quantifica o over-editing com Levenshtein em nível de token, pontuação relativa de patch e Added Cognitive Complexity
- A tendência de reescrita excessiva foi observada nos modelos de programação mais recentes em geral; o Claude Opus 4.6 teve uma combinação forte de precisão e edição mínima, enquanto o GPT-5.4 se destacou relativamente pelo excesso de edição
- Um prompt que explicita a preservação do original reduziu o diff, especialmente em modelos de raciocínio; entre os métodos de treinamento, o RL apresentou o resultado mais equilibrado ao aprender comportamento de edição mínima sem perda no desempenho geral de programação
O problema de Over-Editing
- Over-Editing se refere ao fenômeno em que o modelo altera profundamente até a estrutura do código, indo além do escopo mínimo necessário para corrigir um bug
- Mesmo em um bug off-by-one que exigiria apenas trocar
range(len(x) - 1)porrange(len(x)), o modelo pode acabar reescrevendo a função inteira e adicionando funções auxiliares ou lógica de validação - No exemplo, o GPT-5.4 fez verificação de
None, conversão comnp.asarray(dtype=float), mascaramento de valores finitos, validação do tamanho do array, mudança na assinatura da chamada decurve_fite substituição da lógica de plotagem; os testes passam, mas surge um diff enorme
- Mesmo em um bug off-by-one que exigiria apenas trocar
- Em trabalhos brown-field, que lidam com bases de código existentes, é importante corrigir apenas o problema mantendo o código que a equipe já entende e escreveu de forma intencional
- Diferentemente do green-field, mudanças que não respeitam a estrutura existente dificultam para o revisor entender o que mudou e por quê
- Quando a função inteira é reescrita, o código fica mais difícil de reconhecer e também mais difícil de avaliar em termos de segurança da alteração
- O critério de apenas passar nos testes não basta para detectar esse problema
- Over-Editing não é uma falha de precisão, mas uma falha de fidelidade da edição, então tende a não aparecer bem em suítes de teste
- À medida que o volume de código gerado aumenta, cresce também a quantidade a revisar, e a complexidade desnecessária pode se acumular, degradando silenciosamente a qualidade da base de código
Como medir Over-Editing
- Para montar um conjunto de dados em que a resposta correta de mudança mínima fosse clara, o estudo criou um conjunto de avaliação a partir de 400 problemas do BigCodeBench danificados programaticamente
- Em vez de injetar bugs com outro LLM, como em benchmarks existentes, eles controlaram as mudanças de forma precisa, como trocar
<por<=,+por-eTrueporFalse - Cada amostra danificada foi validada para continuar sintaticamente válida e para quebrar os casos de teste correspondentes; a correção certa foi projetada para ser apenas a reversão da alteração, garantindo mudança mínima
- Em vez de injetar bugs com outro LLM, como em benchmarks existentes, eles controlaram as mudanças de forma precisa, como trocar
- Essa configuração permite avaliar não só se o modelo corrigiu o bug, mas também o quanto ele mudou além do necessário no processo
- Tanto a resposta de referência quanto a saída do modelo são comparadas com a entrada danificada para calcular o tamanho relativo do patch
- Quanto mais alterações extras além da restauração correta, pior a pontuação
- O código relacionado está disponível no repositório no GitHub
Métricas de medição
-
Distância de Levenshtein em nível de token
- Em vez da Levenshtein tradicional em nível de caractere, foi usada uma variante em nível de token de Python
- O código é dividido com o tokenizer de Python em unidades gramaticais atômicas como
def,add,(,a,,,b,), e a distância é calculada sobre essa sequência de tokens - Se
def add(a, b):for alterado paradef someotherfunctionname(a, b):, a distância em caracteres é 19, mas a distância em tokens é 1, porque apenas um identificador foi trocado - O valor é normalizado pelo número total de tokens para permitir comparação entre funções de tamanhos diferentes
-
Pontuação relativa de patch
- Em vez de comparar diretamente a saída do modelo com a resposta correta, ambas são comparadas com a entrada danificada como referência
- A edição que reverte a resposta danificada para a original é a verdadeira mudança mínima, e a métrica mede o quão próxima a edição do modelo está disso
- Quanto mais próximo de 0, mais o patch do modelo se parece com a mudança mínima real
-
Added Cognitive Complexity
- Junto com a Cyclomatic Complexity, o estudo usa Cognitive Complexity, que reflete melhor a dificuldade de leitura
- Há penalidades para aninhamento, recursão, operadores lógicos compostos e fluxos de controle pouco intuitivos; estruturas como
if, loops etry/except, que exigem que o leitor acompanhe mais estado, aumentam a complexidade - No exemplo, o código com loops e condicionais aninhados tem Cognitive Complexity 6
- Como os danos introduzidos nesta avaliação alteram apenas valores e não a estrutura, a correção correta deve sempre ter Added Cognitive Complexity igual a 0
- Se a complexidade aumenta na saída do modelo, isso indica que foi adicionado código não solicitado; valores abaixo de 0 também são considerados indesejáveis por representarem simplificação desnecessária
Os modelos realmente fazem Over-Edit?
- O Over-Editing foi confirmado mesmo em modelos frontier recentes
- Há diferença entre Pass@1 e edição mínima tanto em modelos de raciocínio quanto em modelos sem raciocínio
- A capacidade de corrigir com precisão, por si só, não basta para julgar se a edição foi fiel
- Na comparação entre modelos de raciocínio, o Claude Opus 4.6 apresentou a melhor combinação
- Teve o maior Pass@1, com 0.912, além do menor diff, com Levenshtein normalizado de 0.060 e Added Cognitive Complexity de 0.200
- O Gemini 3.1 Pro Preview ficou em uma faixa parecida, e entre os modelos de pesos abertos o GLM 5 editou de forma relativamente mais conservadora
- O GPT-5.4 ficou entre os modelos com Over-Editing mais severo na avaliação
- No modo de raciocínio, registrou Levenshtein de 0.395 e Added Cognitive Complexity de 2.313; no modo sem raciocínio, os valores também foram altos, com 0.327 e 1.563, respectivamente
- O Pass@1 também foi relativamente baixo, em 0.723 e 0.770, indicando fraqueza tanto em precisão quanto em edição mínima
- Entre os modelos sem raciocínio, o Qwen 3.6 Plus teve o maior Pass@1, com 0.870, enquanto o GLM 5 teve o menor Added Cognitive Complexity, com 0.235
- O Claude Opus 4.6 sem raciocínio também manteve alterações muito pequenas, com Levenshtein 0.079 e Added Cognitive Complexity 0.313
Isso melhora com prompt?
- Ao adicionar ao prompt “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible”, a Distância de Levenshtein caiu em todos os modelos
- Com exceção de DeepSeek R1/v3, o Pass@1 também melhorou junto
- É possível interpretar que a restrição de mudança mínima reduz o espaço de edição possível e induz alterações mais precisas e direcionadas
- Esse efeito aparece com mais força especialmente em modelos de raciocínio
- Por seguirem melhor instruções explícitas, a exigência de minimizar a edição leva de forma mais direta à redução do diff
- Isso mostra que, mesmo quando mexem demais no estado padrão, eles podem migrar para correções mais fiéis quando recebem orientação explícita
O raciocínio leva a reescrita excessiva?
- Emparelhando modelos com raciocínio e sem raciocínio da mesma família, foi comparada a Levenshtein Distance considerando apenas amostras em que ambos acertaram
- Como muitas amostras com falha criam um viés em que a própria oportunidade de Over-Editing diminui, a ideia foi controlar a acurácia e isolar apenas o estilo de edição
- Nas configurações de prompt gerais, na maioria dos pares, o modelo com raciocínio reescreve mais
- DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus e Kimi 2.5 mostram barras mais altas na variante com raciocínio
- Fica evidente uma tendência de o raciocínio estendido caminhar para uma “implementação melhor” em vez de uma modificação mínima, gerando refatorações desnecessárias
- A exceção é Claude Opus 4.6, em que a variante com raciocínio modifica muito menos do que a sem raciocínio
- Quando se instrui explicitamente a preservar o original, o cenário muda bastante
- Em quase todos os pares, os modelos com raciocínio mostram Levenshtein Distance igual ou menor que a das variantes sem raciocínio
- A variante com raciocínio do Claude Opus 4.6 registra, nessa configuração, o menor Levenshtein entre todos os modelos
- GPT-5 e GPT-5.4 também têm uma grande queda na pontuação da variante com raciocínio, embora no GPT-5.4 a variante sem raciocínio ainda fique ligeiramente à frente
- No comportamento padrão, modelos com raciocínio tendem mais a fazer Over-Editing, mas a mesma capacidade de raciocínio também os faz seguir melhor as restrições
- A diferença entre a configuração geral e a configuração explícita aparece de forma consistentemente maior nos modelos com raciocínio
- Portanto, Over-Editing parece menos uma limitação fundamental e mais um comportamento padrão, que pode ser revertido com restrições
É possível criar um editor fiel por meio de treinamento?
- O modelo base usado foi o Qwen3 4B 2507 Instruct, e as configurações 0-shot e 8-shot com instrução de preservação do original foram usadas como baseline
- Os outros métodos de treinamento foram avaliados em configuração geral, sem instrução explícita de preservação do original
-
Configuração do experimento
- Os problemas do DeepCoder foram corrompidos da mesma forma para criar um dataset sintético
- Além disso, o Qwen3 4B 2507 Instruct base gerou 8 completions para cada problema, e, após manter apenas as amostras funcionalmente corretas e classificá-las por Levenshtein Distance, também foi montado um dataset de self-distillation
- O treinamento foi ajustado, de forma semelhante a Context Distillation, para que na avaliação o modelo tenha comportamento de edição mínima mesmo sem instruções explícitas
-
Métodos de treinamento
- SFT: ajuste fino supervisionado direto com o dataset criado programaticamente
- rSFT: treinamento usando apenas as 3 completions com menor Levenshtein Distance por amostra no dataset de self-distillation
- DPO: otimização por preferência entre a completion com maior Levenshtein Distance e a com menor Levenshtein Distance em cada amostra
- RL: aplicação de aprendizado por reforço combinando acurácia funcional com recompensa de edição mínima baseada em Levenshtein
- Se todos os testes passarem,
r = r_edit + 0.1 - Se não passarem,
r = -0.2 r_edité calculado como uma recompensa baseada em Levenshtein normalizado
- Se todos os testes passarem,
Como foi com o mesmo tipo de corrupção?
- Na configuração in-domain, em que o tipo de corrupção do conjunto de treinamento e do conjunto de teste é o mesmo, o SFT entrega resultados quase perfeitos
- Baseline 0-shot: Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
- Baseline 8-shot: Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
- SFT registra o melhor resultado nos três indicadores, com Pass@1 0.932, Norm. Levenshtein 0.002 e Added CC 0.000
- rSFT registra 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113 e RL 0.802 / 0.046 / 0.112
- Como esse resultado parecia bom demais, surgiu a necessidade de verificar se o modelo não teria apenas memorizado a transformação inversa de tipos específicos de corrupção
- A hipótese foi de que o modelo poderia não ter aprendido um comportamento geral de edição mínima, e sim apenas a reverter padrões fixos de corrupção
- Para verificar isso, os tipos de corrupção nos dados de treinamento e nos dados de avaliação foram reorganizados para serem completamente diferentes
Isso generaliza para outros tipos de corrupção?
- Na configuração out-of-domain, em que o tipo de corrupção do conjunto de treinamento e do conjunto de teste é diferente, o SFT desaba fortemente
- O Pass@1 do SFT cai para 0.458, e o modelo passa a tentar apenas mudanças mínimas específicas sem conseguir realmente corrigir os bugs
- Norm. Levenshtein fica em -0.008 e Added CC em 0.006, valores muito baixos, mas a capacidade de produzir a correção certa colapsa
- rSFT e DPO melhoram um pouco em relação ao baseline 8-shot, mas o ganho é pequeno
- rSFT: 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
- DPO: Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
- Mesmo treinando apenas com dados de rastreamento gerados pelo próprio modelo base, ainda é possível alguma generalização
- Apenas o RL generaliza de forma consistente nos três indicadores
- RL registra Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185 e LiveCodeBench Change +0.006
- Ele melhora os três indicadores em relação aos dois baselines e não reduz o desempenho geral de programação
- O fato de os ganhos em Levenshtein e Added Cognitive Complexity serem maiores do que em Pass@1 reforça que o modelo aprendeu o próprio comportamento de edição mínima, e não apenas memorizou a reversão de corrupções simples
Catastrophic Forgetting
- Também foi verificado no LiveCodeBench v6 se o ajuste fino para edição mínima reduz a capacidade geral de programação
- O objetivo é manter, mesmo após o treinamento, um nível semelhante ao do modelo pretrained original
- O SFT mostra uma queda muito grande de capacidade geral
- No LiveCodeBench, aparece uma queda de desempenho de 43%, e o modelo nem sequer mantém a capacidade básica de identificar e corrigir bugs
- rSFT e DPO também caem um pouco
- Mesmo treinando com amostras geradas pelo modelo original, ainda permanece certo nível de Catastrophic Forgetting devido à natureza da tarefa
- O RL aprende o novo comportamento sem perda de desempenho
- Ele preserva a capacidade geral de programação e ao mesmo tempo melhora mais o desempenho na tarefa de edição mínima
- Isso se conecta a SFT memorizes while RL generalizes
- Pela perspectiva de distribuição, também é possível interpretar que quanto maior a diferença entre o dataset criado programaticamente e a distribuição do modelo original, maior o Forgetting
- O SFT altera fortemente a distribuição do modelo ao ajustá-lo com força a dados muito diferentes da distribuição original
- rSFT e DPO passam por mudanças menos bruscas porque os dados self-distilled estão mais próximos da distribuição original
- O grau de Catastrophic Forgetting pode ser proporcional à diferença entre a distribuição original e a distribuição dos dados de treinamento da tarefa
Experimentos adicionais
-
RL com LoRA: é necessário ajuste fino completo?
- Como essa tarefa está mais próxima de um ajuste de estilo da capacidade existente de modificar código do que de inserir novo conhecimento, foi verificado se o LoRA também seria suficiente
- rank 1: Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
- rank 8: 0.775 / 0.112 / 0.426 / -0.022
- rank 16: Pass@1 0.805 / 0.087 / 0.328 / -0.005
- rank 32: 0.795 / 0.065 / 0.235 / -0.011
- rank 64: 0.797 / 0.051 / 0.160 / +0.001
- O melhor modelo de Full RL foi 0.782 / 0.050 / 0.185 / +0.006
- O LoRA rank 64 chegou muito perto do Full RL em Levenshtein e teve resultado melhor em Added CC
- À medida que o rank aumenta, Levenshtein e Added CC diminuem monotonicamente de 1 até 64
- As grandes melhorias se concentram no início: de rank 1→16, o Levenshtein cai bastante, de 0.166→0.087; de 16→64, reduz gradualmente de 0.087→0.051
- Os ranks 1 e 8 mostram um compromisso entre precisão e edição mínima, e é possível que tenha havido viés para a minimização de edição, de recompensa mais alta, por falta de capacidade para aprender as duas funções de recompensa ao mesmo tempo
- Para mudanças de comportamento em nível de estilo, em tarefas cuja capacidade-base já existe, poucos parâmetros adicionais já bastam, e depois de certo ponto o retorno de capacidade extra diminui
-
Nota sobre reward hacking
- Na função de recompensa inicial, havia um bug que atribuía 0 ponto a rollouts sem nenhuma execução bem-sucedida
- Como o sinal de Levenshtein havia sido invertido para ficar no formato “quanto maior, melhor”, esse 0 acabava, ao contrário, gerando uma recompensa mais alta do que a de execuções bem-sucedidas
- Ainda assim, o Full RL aprendeu a tarefa, e apenas no LoRA apareceu reward hacking na forma de nem sequer gerar código funcionalmente correto, o que levou à inspeção do ambiente
- Após corrigir a função de recompensa, os resultados de Full RL melhoraram apenas ligeiramente
-
Isso também escala para modelos maiores?
- A mesma receita de RL out-of-domain foi aplicada ao Qwen3 14B
- O baseline 14B teve Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
- Após aplicar RL, houve melhora geral para Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011
- Mesmo com mais parâmetros, mantiveram-se juntos o aumento de Pass@1, a redução de Levenshtein, a redução de Added Cognitive Complexity e a ausência de Catastrophic Forgetting
- Isso sustenta a possibilidade de que a receita de RL para edição mínima de código escale para modelos de vários tamanhos
Resumo final
- Over-Editing aparece como um problema disseminado e mensurável
- Em modelos de ponta para coding de forma geral, a capacidade de corrigir com exatidão e a capacidade de corrigir com o mínimo de mudanças aparecem como coisas distintas
- Em especial, o GPT-5.4 mostra, na configuração padrão, uma tendência relativamente forte a reescrever em excesso, enquanto o Opus 4.6 apresenta uma baseline forte
- Apenas prompts explícitos já conseguem induzir, em boa medida, edições mais fiéis
- Em especial, modelos de raciocínio tendem por padrão a mexer demais, mas seguem melhor quando recebem instruções de preservar o original
- O GPT-5.4 também mostra uma grande melhora no modo de raciocínio, o que evidencia uma forte capacidade de instruction following
- O fato de a melhora do Opus 4.6 parecer pequena pode ser porque seu desempenho-base já é alto
- Do ponto de vista de treinamento, RL aparece como a solução mais equilibrada
- Aprendeu um comportamento de edição mais fiel sem prejudicar a capacidade geral de coding, e o efeito se manteve tanto no Qwen3 4B quanto no 14B
- O SFT foi forte em alguns tipos específicos de corrupção, mas falhou bastante em generalização e em preservar a capacidade geral
- A avaliação de correção de bugs em função única tem escopo mais limitado do que avaliações mais agentic, como SWE-Bench Pro, mas serve como ponto de partida para tratar um problema que era difícil de quantificar em cenários realistas: o Over-Editing
- Avaliar e melhorar a capacidade de edição mínima pode levar a uma melhora da qualidade geral do código gerado por IA
1 comentários
Opiniões do Hacker News
A forma como eu uso o Claude Code supera muito as expectativas
Quando ele mexe demais, eu faço ele explicar onde errou e registrar a lição em um arquivo de skill específico do projeto
Assim ele quase não repete o mesmo erro, e quando o arquivo de skill cresce, ele também faz um bom trabalho organizando e condensando isso
Agora sinto que escrever código diretamente no trabalho já não faz muito sentido do ponto de vista econômico
Estou mais próximo do papel de professor, arquiteto e administrador de infraestrutura, e deixo a maior parte do desenvolvimento para uma equipe de sessões experientes do Claude
Claro que reviso tudo, e o Claude também escreve testes bem detalhados para revisarmos juntos
Hoje em dia ele lida até com projetos grandes sem dificuldade
Não quero soar como propaganda da Anthropic, mas fico curioso sobre o que exatamente estou fazendo para isso funcionar tão excepcionalmente bem
E os tokens também quase nunca faltam agora
Quase só uso o modelo Opus, que é eficiente em tokens, e na semana passada, mesmo tendo feito mais de 150 commits relevantes com ajuda do Claude, usei só um terço da cota semanal
Antes do Claude, meu limite era algo como 25 a 30 commits por semana
Ontem vi as estatísticas e me surpreendi ao descobrir que 97% do código da empresa agora está sendo escrito pelo Cursor AI
Eu rodo principalmente no cloud agent, porque acompanhar em tempo real me distrai
Meu método é extremamente simples: dar instruções claras em linguagem natural
As pessoas complicam demais isso
Ficar compartilhando arquivos .md e se aprofundando em orchestration e prompt hack me parece tão interessante quanto obsessão por atalhos do vim ou skins de IDE
Basta dizer claramente o que você quer e dar um bom feedback
Ele entrega resultados que eu aceitaria sem constrangimento mesmo se tivessem sido escritos por um colega
Claro que leio tudo linha por linha e faço correções, mas essas correções ficam num nível bem parecido com o que eu já fazia em code review
Eu não meço produtividade em números, mas dá para sentir pelo fato de que agora estou finalmente mexendo em tarefas que adiei por anos
Por exemplo, ele é especialmente forte em tarefas entediantes como converter 100 arquivos markdown em 5 json e atualizar o código que lê isso
É um software com muitos defeitos e muitos bugs, mas na prática continua sendo muito eficaz
Uma das coisas mais estranhas em IA é como a experiência varia de forma realmente extrema de pessoa para pessoa
Também importa se você faz muito trabalho operacional e se lida com código de produto de longa duração
Minha hipótese é que essa ferramenta funciona bem sobre padrões simples e até consegue lidar com coisas complexas, mas é péssima em inventar padrões novos
Se você deixar sem supervisão, ela rapidamente inventa padrões novos perigosos e estraga tudo
Por isso acontece bastante de eu reescrever por completo o que o Claude entregou
Às vezes até viro uma corrida de velocidade contra o robô e eu termino antes
Eu já sei o que quero, então tenho essa vantagem, mas sinto que o custo de ajustes manuais aqui é subestimado
Tanto futzing fraction quanto the peril of laziness lost apontam para esse incômodo com a forma como a máquina se esforça demais
Não entendo por que ela tenta fazer três coisas quando só precisava fazer uma
Mesmo que corrija e depois ajuste de novo, é irritante ter de repetir com a IA o mesmo fluxo que já existe ao trabalhar com colegas: "não faça A, B e C, faça só A"
Geração de testes também é delicada: ela vai bem quando você orienta a direção, mas se der espaço para criatividade, produz testes inúteis demais como
foo + bar == bar + fooÉ preciso olhar sempre desconfiando da utilidade dos testes para manter saudável o ciclo de feedback
Hoje em dia às vezes ela é mais útil para puxar de uma vez os imports necessários do que para os testes em si
Se essas máquinas vão substituir trabalho, então a qualidade média do código deveria ao menos subir
Mas muita gente está usando num modo de "no geral fica ali pela média", e dependendo do jeito de trabalhar isso pode até puxar a média para baixo
Estou nisso há 28 anos, e hoje escrever eu mesmo código de aplicação comercial, em horário pago pela empresa, já não parece fazer sentido nem economicamente nem, sendo generoso, em boa-fé
Em compensação, eu frequentemente sinto que agentes de código deveriam mudar o código existente com mais agressividade para atender a novos requisitos, mas acabam priorizando demais a preservação do código atual
No fim parece ser uma questão de quanto você quer congelar o código existente
Se for um app grande de produção rodando há décadas, faz sentido minimizar mudanças, mas se for um projeto experimental criado há 3 dias, talvez seja melhor consertar de verdade em vez de preservar
No fim, parece que eles precisam aprender a ajustar sozinhos esse nível de agressividade conforme o contexto do projeto
Mesmo dentro do mesmo projeto, dependendo do PR, há áreas que você pode mudar livremente e áreas que eu preferiria manter fixas para reduzir o diff e o escopo dos testes
Por isso tento explicar antes quais partes podem ser alteradas com mais agressividade e em que grau, mas os resultados são inconsistentes
Em geral ele pende para o diff mínimo e, como consequência, acaba criando duplicação ou forçando abstrações de um jeito estranho
Se alguém tiver um método que funcione melhor, eu também quero ouvir
Mesmo quando peço para refatorar ou reconsiderar de forma ampla, o desempenho costuma ser fraco
Então faço ele limpar markdown excessivamente carregado de design, apago do código-fonte o conteúdo técnico ou implementações e interfaces centrais, e mando uma nova sessão redesenhar aquilo
Depois restauro o que apaguei e reconcilio com uma sessão menos ingênua
A dependência de trajetória é forte demais, então por enquanto faço isso manualmente, mas queria formalizar esse padrão como skill
A IA costuma esconder falhas engolindo exceções e devolvendo valores fictícios, ou então deixando só uma mensagem perdida no meio de logs diversos
Os logs também costumam vir resumidos demais, a ponto de faltar justamente os dados centrais necessários para depurar de verdade
Imagino que isso aconteça porque o sistema foi treinado para enganar o sistema e ganhar pontos
Se deixar a exceção explodir, é uma falha clara e isso gera punição, mas se esconder o problema, às vezes parece sucesso
Também fico curioso sobre como isso aparece em Q&A geral
Será que o modelo caminha para soar convincente só até o ponto em que o usuário aceite a resposta e vá embora?
Um padrão frequente é algo como "isso não é X, é Y", e esse tipo de dicotomia faz você deixar de considerar outras possibilidades
Também é comum ele terminar a resposta com um plano de ação, e isso parece mais uma tentativa de fazer você concordar com a IA e imaginar o resultado do que propriamente uma resposta, como na técnica de vendas chamada assumptive close
No fim, subir a métrica via hill-climbing se parece mesmo com isso
Parece uma forma de A/B enshittification levada a um extremo quase impossível de interpretar
Se ela é treinada com feedback humano, então cada pedaço de cada resposta inevitavelmente vai tender a contornar e satisfazer o avaliador
Fazer algo muito bem feito com IA dá mais trabalho do que parece
Se você mandar, ela entrega algo bem plausível, mas pode não saber que não sabe algo
Isso fica ainda mais perigoso quando a IA fala com autoridade
Então validar de vários ângulos e confirmar a precisão não é nada simples
Vai ser interessante ver como isso muda com o tempo
Ao mesmo tempo, sinto que tanto este texto quanto os comentários daqui são meio que um retrato do momento
O ritmo de evolução do setor é tão rápido que os modelos de código já estão muito melhores do que estavam há apenas 9 meses
Sempre que leio reclamações sobre as capacidades da IA, sem culpar a pessoa, eu acabo pensando "ainda"
É como colocar uma para revisar o resultado da outra
Mesmo assim, a maior parte roda de forma assíncrona, então eu consigo fazer outras coisas nesse meio-tempo
Então em alguns projetos eu primeiro aprendi montando um protótipo com o agente, depois escrevi o design e recomecei do zero
Aí passei a saber onde precisava olhar mais a fundo
O que são os 20% restantes depende no fim da natureza do problema
Aqui se fala em edição excessiva de código, mas os agentes fazem bem mais do que isso
Eles mexem em vários arquivos, rodam testes, fazem deploy e até smoke test, e tudo isso acaba escondido atrás de uma abstração
Por um lado é impressionante, por outro dá muita insegurança
Primeiro, eu não entendo de verdade o que está acontecendo lá dentro
É tentador demais simplesmente aprovar e rodar o script que o agente montou
Só que eu já tive caso de apagar um banco de dados porque o agente concluiu que aquilo estava certo, e também já peguei tentativa de enviar credenciais da AWS para um alvo de deploy onde isso jamais deveria ir
Segundo: eu não aprendi nada
Até montar sozinho um comando simples de docker passa a ter um custo cognitivo maior, e eu acabo recorrendo repetidamente à IA como uma muleta
Não ligue auto-approve; você deve aprovar manualmente todo comando que o agente executar
Também não delegue decisões de design ou arquitetura; o humano deve decidir como construir e instruir claramente a lata a respeito disso
Não é brincadeira: se você tratar a IA como ferramenta, dá para aproveitá-la muito melhor
Talvez não chegue a 10x de produtividade, mas pelo menos você continua entendendo o código
No Day 1, ele trata segurança com extremo cuidado, explica por que .env precisa estar no .gitignore e até dá sermão dizendo para não passar credenciais e que eu mesmo devo fazer as alterações
Aí no Day 2, quando você pede a mesma coisa de novo, ele esquece essas regras e configurações, vasculha o disco inteiro lendo .env e outros arquivos, entende que está com os tokens na mão, monta por conta própria um comando curl e ainda testa
Num dia parece especialista em segurança; no seguinte, parece pior do que um estagiário comum
Esse modo gera muito comportamento indesejado e implementação excessiva, mas é útil para eliminar boilerplate
Na prática, acabo apagando uns 70% disso
Em compensação, não deixo a IA tocar nas áreas do tipo 1 e 2
Claro, isso exige uma arquitetura que permita essa separação, mas tenho ficado bastante satisfeito com o resultado
Basta não dar credenciais de produção ao LLM
Se algo não pode ser reproduzido em local ou staging/dev, então a infraestrutura de deploy precisa ficar mais parecida com a de produção; e se você não consegue granular permissões por ambiente o suficiente, então primeiro arrume seu sistema de permissões
Eu sigo esse princípio, então quase nunca enfrentei o tipo de problema que você mencionou
Para diagnóstico eu até daria credenciais temporárias somente leitura, mas mesmo nesse caso emitiria apenas tokens de vida muito curta para mitigar vazamento
Então em geral eu sei o que está acontecendo
Às vezes o Claude toma decisões estranhas ou fora do padrão
Mas, ao lidar com bases de código grandes em equipe, já existem mesmo muitas áreas escondidas atrás de abstrações que ninguém entende direito, inclusive partes feitas por gente que já saiu da empresa
Antigamente, uma sabedoria muito ensinada mas pouco seguida na prática era: refatore enquanto trabalha
A ideia era que, ao mexer numa área, você aproveitasse para organizá-la e quitar dívida técnica
Só que isso quase nunca acontecia, e agora que os LLMs começaram a fazer isso de verdade, estamos sentindo os efeitos colaterais
Às vezes ele cria algo do zero mesmo quando a função necessária já está ali
Pior ainda é quando altera uma função existente fingindo manter o comportamento, mas quebra outros pontos de uso
O pior dos casos é quando mexe no estado compartilhado entre classes sem entender os efeitos colaterais e cria deadlocks ou bugs comuns
Para mim, em vez de refatoração, isso se parece mais com puxar mais uma vez a alavanca do caça-níquel
Meu problema real era que a qualidade da refatoração feita pelo agente era ruim
Eu só queria impedir esse tipo de modificação e dar instruções mais explícitas sobre o que corrigir e como corrigir
Em muitos casos, as abstrações existentes são boas o suficiente para rastrear bugs ou expandir funcionalidades sobre elas
Mas às vezes você chega a uma encruzilhada entre contornar a implementação existente à força ou redesenhar
Com LLMs, fica nebuloso como reconsiderar isso, ou até se há necessidade de reconsiderar
Além disso, essas decisões acabam escondidas de um jeito que o usuário não percebe bem
Talvez esse tipo de mudança seja útil, então eu gostaria de ver mais exemplos
Eu não confio muito em métricas de cognitive complexity, mas acho um pouco interessante que esse tipo de modificação aparentemente aumenta essa métrica com bastante consistência
Faz algum tempo que eu não vejo edição excessiva no Claude Code ou no Codex, então fiquei curioso sobre quais prompts foram usados nesse estudo
Acho que devem estar aqui, e a última modificação foi há 8 meses
https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py
O GPT-5.4 reescreveu 50 linhas porque achou mais limpo, quando eu tinha pedido só uma adição de 10 linhas
Era uma inclusão mecânica, bastava olhar o código existente, renomear variáveis e encaixar algo parecido
E, para piorar, no começo ele nem colocou a funcionalidade que eu tinha pedido
Over-editing não é de forma alguma um problema do passado, e isso aconteceu porque eu esqueci de reduzir o nível de thinking e deixei rodando em xhigh thinking
Para mim isso soou como um problema da fase inicial dos agentes
Este texto é bem sólido
LLMs são excessivamente verbosos tanto em prosa quanto em código, e na minha opinião a principal causa disso é a forma de treinamento
Cross entropy loss acaba favorecendo frases no estilo garden path
Algo que um humano encerraria em uma frase, ou até em poucas palavras, vira um parágrafo inteiro
Isso porque frases longas são, estatisticamente, um caminho de menor surpresa, isto é, de baixa perplexity
Tenho sentimentos ambivalentes sobre esse problema
Na maior parte das vezes ele faz demais e eu preciso passar 30 minutos consertando, então concordo com a avaliação
Mas às vezes ele também deixa passar mudanças mais abrangentes
Imagino que seja por limitações de contexto, e por isso comecei a usar as ferramentas com mais rigidez
Mesmo assim, ainda não cheguei ao nível de sensação de controle que eu gostaria
Isso parece um resquício dos dados de treino
Nos dados de SFT e preference, sobram exemplos de "versões mais limpas do arquivo", mas faltam exemplos do tipo "diff de exatamente 3 linhas"
Então o modelo aprendeu que a saída vencedora é a maior e mais polida
Dá para controlar um pouco via prompt, mas no fim você está lutando contra uma tendência prévia forte