Estudo mapeia como agentes de código editam arquivos com diffs e snapshots
O problema: escrever no disco quebra mais que o raciocínio
Segundo o autor, Kondasamy Jayaraman (Samy), a aplicação de alterações em arquivos quebra mais fluxos de trabalho de agentes de código do que erros de raciocínio dos modelos. Um modelo de fronteira pode planejar bem uma refatoração, mas falhar ao modificar um arquivo de 1.200 linhas: alucina offsets de linha, descarta chaves de fechamento ou corrompe indentação.
A causa central é a "cegueira aritmética": transformers autoregressivos não contam linhas. Em um unified diff padrão (formato de git diff e patch), o modelo precisa calcular inteiros de cabeçalho de hunk como @@ -142,18 +142,22 @@; errar por uma linha faz utilitários rejeitarem o patch. Nos benchmarks do Aider, forçar modelos a gerar unified diffs estritos reduziu a taxa de conclusão de tarefas de 59% para 26% em arquivos complexos.
A fonte lista quatro modos de falha: truncamento por preguiça (modelos emitem placeholders como // ... existing implementation remains unchanged ..., que ao serem gravados destroem código), fragilidade de whitespace (tabs vs. espaços quebram correspondências exatas), custo de tokens e latência (reescrever 1.500 linhas para mudar três gera ~5.000 tokens, 15 a 25 segundos) e drift de estado em sistemas multiagente.
Os quatro paradigmas de edição
1. Blocos de busca-e-substituição. Aider usa blocos SEARCH/REPLACE, e o Claude Code da Anthropic usa uma ferramenta str_replace que exige que old_str corresponda a exatamente uma localização única no arquivo; se houver ambiguidade (como um genérico return null;), a chamada é rejeitada. Benchmarks do Aider mostram que em arquivos acima de 400 linhas, busca-e-substituição usa dez vezes menos tokens (200–500 contra 4.000–6.000) e executa em menos de um segundo. Curiosamente, trocar GPT-4 Turbo de search-replace para unified diffs caiu os comentários preguiçosos de 61% para 20%, ao custo de mais falhas de parsing.
2. O replacer resiliente de 9 estágios da OpenCode. Como correspondência exata falha 20% a 30% das vezes em repositórios reais, a OpenCode (agente de terminal da SST) faz um cascata do match exato até matchers relaxados: por linha, por âncora de bloco com distância de Levenshtein, whitespace normalizado, indentação flexível e escapes normalizados. Após aplicar, roda formatadores (Prettier, Black, Biome) e consulta o LSP por diagnósticos, devolvendo erros ao modelo na próxima iteração.
3. Snapshots e reescritas de AST no Oh My Pi (OMP). Para lidar com corridas de concorrência, o harness OMP usa Hashline, uma linguagem de patch ancorada em linhas e atrelada a hashes de conteúdo: toda leitura anota o arquivo com um hash de 4 dígitos hexadecimais (ex.: [src/auth.ts#A1B2]); se o arquivo mudou no disco, o patch é rejeitado. Operações como PUT N*: usam Tree-sitter para resolver o fim de blocos de sintaxe, e refatorações ampolas usam ast-grep com metavaláveis ($NAME, $$$ARGS), ignorando whitespace e comentários.
4. Fast apply especulativo de dois níveis. Cursor (Instant Apply) e Morph separam raciocínio de escrita: o modelo de fronteira emite trechos preguiçosos como // ... existing code ... e um segundo modelo faz o merge. O Cursor usa um Llama-3-70B afinado hospedado na Fireworks AI, tratando o arquivo original como stream de tokens de rascunho e validando trechos inalterados em lotes paralelos, sustentando ~1.000 tokens por segundo; antes de gravar, aplica o patch a um shadow workspace com diagnósticos TypeScript/LSP. O Morph (morph-v3-fast) reporta 98% de precisão em 6 segundos por arquivo, contra 86% e 35 segundos do str_replace padrão, com throughput de até 10.500+ tokens/s em kernels CUDA próprios.
Contexto adicional e conclusão
O DeepSeek Harness (dsh), usado nas avaliações de DeepSeek-V3 e DeepSeek-R1 no SWE-bench Verified (R1 marcou 49,2%), opera com dois modos: para V3/Coder, um str_replace_editor com âncoras persistidas em Base64; para R1, extração de unified diffs de blocos markdown dentro do stream de raciocínio. Em modo minimal, o toolset se reduz a persistent_bash e str_replace_editor.
O autor conclui que o mecanismo de edição determina confiabilidade, latência e custo: busca-e-substituição com verificação de unicidade para scripts pequenos; matchers com fallback e formatadores para agentes de terminal; hashing de snapshot e AST para concorrência; e merge neural especulativo para IDEs comerciais. Engenharia de software confiável com IA exige harnesses de qualidade de compilador conectando predição estatística de tokens a sistemas de arquivos determinísticos.