Leitura de toda a base de código além da janela de contexto

Um modelo que aceita um milhão de linhas não ganha, por isso, a capacidade de entender um sistema com um milhão de linhas. A capacidade responde se o texto cabe. Ela não diz se o modelo encontrará a definição correta, ligará um chamador indireto a um efeito colateral ou perceberá que uma etapa JCL muda o sentido do programa COBOL que inicia.

Essa diferença importa sobretudo na reescrita de sistemas legados. Uma tradução local plausível pode compilar e ainda quebrar o fechamento mensal, pois o comportamento antigo vive espalhado por arquivos-fonte, copybooks, gatilhos de banco de dados, controle de jobs, validação de telas e convenções de produção. Colocar tudo em um prompt troca um problema de omissão por um problema de discriminação. O contexto contém a resposta, mas o modelo não possui uma estrutura confiável para decidir quais fatos controlam a mudança.

Ler toda a base de código é, portanto, um problema de sistemas, não um recurso de tamanho de prompt. Isso requer um modelo durável do repositório, percurso explícito das dependências, raciocínio em etapas e provas executáveis de que o sistema gerado se comporta como o original.

Uma janela de contexto mede capacidade, não compreensão

Uma janela de contexto longa informa a entrada máxima que um modelo aceita sob certas condições. Ela não promete lembrança uniforme, raciocínio estável por toda a janela nem conexões corretas entre fatos distantes. Essas capacidades são separadas, e tratá-las como uma única métrica é o primeiro erro de projeto.

Nelson Liu e seus coautores tornaram concreto o problema de posição no artigo Lost in the Middle. Em perguntas sobre vários documentos e na recuperação de pares chave-valor, o desempenho costumava ser melhor quando o material relevante aparecia no começo ou no fim da entrada. Ele caía quando o mesmo material ia para o meio. O artigo não prova que todo modelo atual falha em todo programa longo. Ele prova que receber a entrada não é uma boa medida de uso confiável.

Código torna isso mais difícil que prosa. Um repositório contém milhares de formas repetidas: getters, validadores, layouts de registros, ramos de erro, arquivos gerados e etapas batch quase idênticas. O modelo precisa distinguir fatos parecidos enquanto acompanha relações que talvez nunca estejam lado a lado no texto. Um parágrafo CALCULATE-TAX e outro CALCULATE-TAX-OLD podem compartilhar quase todos os tokens e ter chamadores diferentes. A similaridade ajuda a encontrar ambos. Ela não decide qual controla a transação.

A contagem de tokens também esconde custos de representação. O texto-fonte é apenas uma camada. Uma análise útil precisa de identidades de símbolos, arestas de chamada, fluxo de dados, metadados de build, esquemas, configuração, testes e observações do software em execução. Se um fornecedor diz que a janela comporta o repositório, pergunte o que foi excluído, como os arquivos foram ordenados, como as arestas entre linguagens foram codificadas e como o sistema testa afirmações feitas a partir da entrada. O tamanho da janela não responde a nenhuma dessas perguntas.

O teste prático de aceitação é simples: mova o arquivo decisivo para outra posição, acrescente arquivos irrelevantes mas semelhantes e repita a tarefa. Se a resposta mudar, o sistema leu uma sequência, não uma base de código.

Outro teste verifica a composição. Pergunte onde um campo nasce, onde muda e qual efeito externo depende do valor final. Depois faça as mesmas perguntas separadamente e compare o caminho montado. Um leitor que responde a cada pergunta local, mas não preserva a identidade ao longo da cadeia, sabe buscar, porém não compreende o sistema. Essa falha passa despercebida porque cada resposta isolada pode parecer correta.

A recuperação perde relações que o vocabulário não expressa

Recuperar trechos funciona para perguntas cuja resposta se parece com a consulta, mas o comportamento do programa muitas vezes depende de relações, não de palavras em comum. O chamador pode usar um nome genérico, despachar por uma tabela, montar o nome de um procedimento, publicar um evento, invocar uma stored procedure ou entregar o controle a um agendador. Uma busca vetorial pelo conceito de negócio pode recuperar a função chamada e ainda perder o chamador que fornece o sinal decisivo.

Considere uma regra de cobrança implementada em COBOL. O parágrafo visível lê uma classe de conta e calcula uma tarifa. Uma etapa JCL seleciona um conjunto alternativo de entrada no último dia útil. Um copybook sobrepõe dois campos do registro, e um gatilho PL/SQL suprime a tarifa para contas migradas. Nenhum desses artefatos precisa repetir as palavras do ticket. Recuperar só o parágrafo produz uma função TypeScript limpa e errada.

O SWE-bench captou um fato relacionado em escala menor: correções reais muitas vezes exigem mudanças coordenadas entre funções, classes e arquivos. Sua configuração original comparou recuperação com acesso aos arquivos alterados pelo patch humano. Isso traz um alerta útil. Uma geração melhor não recupera provas que a etapa de recuperação nunca forneceu, e uma migração real não tem um conjunto de arquivos oráculo.

A área também confunde recall de busca com completude comportamental. Recall pergunta se um item relevante conhecido aparece no conjunto retornado. Completude pergunta se o sistema encontrou cada artefato necessário para explicar um resultado observado. É possível medir o primeiro com trechos rotulados. Só é possível estabelecer o segundo rastreando e testando o comportamento.

Um leitor de repositório deve combinar várias rotas no mesmo depósito de provas:

• busca lexical por identificadores exatos, literais, nomes de registros e códigos de erro;
• busca semântica por conceitos expressos com outro vocabulário;
• resolução de símbolos e percurso de chamadas para a estrutura explícita;
• arestas de fluxo de dados e esquema para valores que cruzam procedimentos;
• rastros de execução para despacho dinâmico, configuração e efeitos externos.

Esses não são cinco mecanismos concorrentes. Cada um revela uma classe de falha diferente. O sistema deve guardar por que selecionou um artefato, qual aresta levou até ele e o que continua sem solução. Um saco ordenado de trechos sem procedência convida o modelo a transformar confiança de recuperação em certeza inventada.

As fronteiras dos trechos causam outra perda silenciosa. Uma declaração de procedimento pode cair em um trecho e sua pré-condição, tratador de erro ou definição de dados vizinha em outro. Aumentar os trechos preserva mais contexto local, mas reduz a precisão e ocupa mais prompt. Sobreposição copia texto sem restaurar a estrutura do programa. Trechos guiados pelo parser melhoram o equilíbrio, mas nem uma função completa revela uma condição do agendador ou o efeito de um gatilho em outro ponto. Depois do primeiro resultado, a recuperação precisa expandir o grafo. Ela deve parar com base em perguntas resolvidas, não em um top-k arbitrário.

A diluição da atenção persiste no prompt maior

Adicionar material relevante pode piorar uma resposta quando o modelo precisa escolher entre fatos plausíveis demais. Em termos de engenharia, a diluição da atenção significa que a prova decisiva compete com código repetitivo, implementações duplicadas, ramos mortos, código gerado, comentários sobre uma versão antiga e testes que registram comportamento obsoleto.

A recomendação comum é colocar o repositório inteiro no prompt e pedir ao modelo que o examine com cuidado. Ela é popular porque remove um componente visível do fluxo. Não há índice para ajustar nem mecanismo de recuperação para culpar. A simplicidade é cosmética. O modelo ainda seleciona, mas agora faz isso em uma inferência opaca na qual ninguém consegue inspecionar candidatos perdidos ou repetir um percurso.

A ordem do repositório vira uma política acidental. A ordem alfabética favorece alguns módulos. Concatenar por dependência exige um grafo antes do prompt, o que admite a necessidade de análise. Colocar arquivos prováveis nas duas pontas explora um padrão de benchmark em vez de provar compreensão. Repetir arquivos importantes desperdiça capacidade e pode dar peso excessivo a cópias antigas.

O LongBench v2 incluiu compreensão de repositório entre tarefas com entradas muito longas e mostrou que responder diretamente continuava difícil. Sua lição metodológica é mais interessante: raciocínio mais longo e esforço adicional de inferência podem importar tanto quanto o tamanho anunciado da entrada. Uma arquitetura de migração deve levar essa ideia adiante e externalizar o trabalho intermediário. Uma única geração não deve descobrir o sistema, decidir o projeto-alvo, produzir código e certificar paridade ao mesmo tempo.

Você pode expor a diluição com uma avaliação pequena. Escolha uma mudança cujos fatos controladores envolvam um chamador, um valor de configuração e um efeito colateral. Execute com o conjunto mínimo de provas e depois acrescente dez grupos de distrações plausíveis do mesmo repositório. Registre o caminho de chamadas alegado, os símbolos citados, o patch e o resultado do teste em cada execução. A finalidade não é calcular uma pontuação universal. É descobrir se mais contexto muda o relato do comportamento sem qualquer mudança no programa.

Resumos no prompt não curam isso sozinhos. Resumir toma uma decisão com perdas sobre relevância antes de conhecer a tarefa posterior. Um resumo escrito para descobrir a arquitetura pode omitir regras de arredondamento necessárias para corrigir um defeito. Mantenha resumos como auxílio de orientação, ligue-os às entidades-fonte descritas e permita que a tarefa reabra as provas originais. Um resumo nunca deve ser o único relato restante de um módulo.

O repositório precisa de um mapa tipado antes da geração

A análise de toda a base começa pela criação de uma representação tipada e consultável do sistema. Um índice vetorial plano é útil dentro dela, mas não pode ser a representação. A unidade durável é uma entidade com identidade, local, linguagem e arestas para outras entidades.

No mínimo, o mapa deve representar arquivos, símbolos, pontos de entrada, chamadas, leituras e escritas, esquemas, jobs, telas, testes, chaves de configuração e interfaces externas. As arestas precisam de tipos porque calls, loads dynamically, writes field e runs after exigem raciocínios diferentes. Confiança e origem pertencem a cada aresta. Uma aresta obtida do compilador não deve parecer igual a uma associação inferida pelo modelo.

Em repositórios legados, as fronteiras entre linguagens fazem parte da semântica. JCL seleciona programas e conjuntos de dados. Mapas CICS conectam telas e campos. Programas RPG dependem de display files. Formulários VB6 guardam conexões de eventos fora dos procedimentos comuns. Classic ASP mistura marcação, script, estado de sessão e acesso ao banco. Pacotes PL/SQL podem esconder efeitos atrás de gatilhos e sinônimos. Um parser da linguagem principal vê só uma parte do sistema executável.

O mapa também precisa de fatos negativos e não resolvidos. Se o destino de uma chamada dinâmica não puder ser resolvido estaticamente, guarde a expressão e os candidatos em vez de escolher um em silêncio. Se dois copybooks definirem o mesmo registro sob opções de build diferentes, preserve as duas variantes e a condição que seleciona cada uma. Dúvidas devem virar pedidos de rastros ou casos de paridade, nunca palpites em prosa.

Um registro compacto de provas pode ser assim:

{
  "claim": "late fee is suppressed for migrated accounts",
  "path": ["BILLJOB", "FEE-CALC", "ACCT_FEE_TRIGGER"],
  "evidence": ["jobs/bill.jcl:88", "src/fee.cbl:412", "db/account.sql:219"],
  "conditions": ["RUN_MODE=MONTH_END", "account.migrated=true"],
  "unresolved": ["dynamic dataset alias at BILLIN"]
}

Esse registro não é um truque de prompt. É uma afirmação inspecionável que outra etapa pode contestar. Quando a geração muda FEE-CALC, o sistema pode localizar os pontos de entrada afetados, pedir a ligação pendente do conjunto de dados e selecionar testes que exercitem a condição. Sem o mapa, cada prompt precisa redescobrir esses fatos e os descobrirá de modo diferente.

A representação também precisa de versões. Código gerado, commits do fonte, snapshots de esquema e rastros gravados precisam compartilhar o mesmo limite de revisão. Caso contrário, o grafo pode ligar um chamador de terça a uma função substituída na quarta e descrever um sistema que nunca existiu. A análise incremental deve invalidar arestas derivadas quando a fonte muda e recalcular afirmações dependentes. Reutilizar cache sem procedência é rápido até certificar o build errado.

A leitura de toda a base deve acontecer em etapas

Um leitor confiável separa descoberta, modelagem de comportamento, projeto-alvo, implementação e verificação. As etapas podem iterar, mas cada uma produz artefatos que restringem a próxima. Isso impede que uma geração fluente apague uma incerteza descoberta antes.

A descoberta inventaria linguagens, caminhos de build, pontos de entrada, esquemas, jobs e fronteiras externas. Ela analisa o que pode ser analisado, registra falhas e conecta artefatos entre linguagens. O resultado é um mapa do repositório e uma lista explícita de pontos cegos.

A modelagem de comportamento começa pelas operações observáveis, não pelos arquivos. Para cada ponto de entrada, o sistema rastreia condições, transições de estado, saídas e efeitos colaterais. Ele agrupa caminhos duplicados que implementam a mesma regra e separa caminhos parecidos com pré-condições diferentes. O resultado é um conjunto de afirmações de comportamento ligadas a provas.

O projeto-alvo decide onde esses comportamentos devem ficar em serviços Go, núcleos Rust, clientes TypeScript ou Postgres. É aqui que reescrita difere de transliteração. Uma conversão de parágrafo em função pode preservar o fluxo de controle enquanto carrega estado global, acoplamento a arquivos e suposições do agendador. O projeto deve preservar o comportamento na fronteira e mudar a estrutura interna de propósito.

A implementação consome pacotes de trabalho limitados derivados do mapa. Um pacote inclui comportamento-alvo, entidades-fonte relevantes, chamadores anteriores, efeitos posteriores, restrições, dúvidas e casos de paridade exigidos. O modelo pode pedir mais provas. Nunca deve preencher uma aresta ausente com um palpite confiante.

A verificação roda continuamente, não depois de um merge final heroico. Falhas atualizam o modelo de comportamento ou expõem um defeito no alvo. Esse retorno importa porque a análise do fonte, sozinha, não decide se um ramo estranho está morto, representa uma exceção regulatória ou só é alcançado por dados de produção.

Esse projeto em etapas usa a atenção do modelo onde há uma tarefa definida. Modelos continuam bons em interpretar código confuso e propor implementações. O sistema ao redor fornece identidade, memória, percurso e um juiz que não avalia prosa.

A revisão humana deve seguir os mesmos artefatos. Engenheiros devem revisar comportamento em disputa e contratos-alvo, não percorrer milhares de linhas geradas esperando reconhecer uma mudança semântica. Uma etapa pode avançar quando suas afirmações têm provas, suas dúvidas têm responsáveis e as verificações necessárias existem. Aprovar prosa bem escrita não faz parte dessa passagem.

Provas de execução capturam o que a leitura estática não vê

A análise estática descreve o comportamento possível. A execução gravada mostra o comportamento que realmente ocorreu com determinadas entradas. Uma reescrita séria precisa das duas, pois cada uma cobre os pontos cegos da outra.

A análise estática pode enumerar ramos que nenhuma gravação alcançou. Pode encontrar uma escrita escondida num caminho de erro, um job trimestral ou uma ação de tela ausente do tráfego recente. Rastros de execução resolvem chamadas dinâmicas, valores reais de configuração, aliases de conjuntos de dados, SQL produzido em execução e a ordem de efeitos externos. Nenhuma fonte deve virar toda a verdade.

Equipes costumam propor cobertura de testes como substituta. Testes existentes são provas úteis, mas sistemas antigos frequentemente têm suítes unitárias estreitas, scripts de integração dependentes do ambiente ou nenhum teste automatizado sobre os comportamentos que mantêm o negócio funcionando. Passar nesses testes prova compatibilidade com eles, não com o sistema de produção.

Um harness de paridade dá forma concreta à comparação. Capture uma entrada numa fronteira estável, reproduza-a contra as implementações antiga e nova, normalize valores não determinísticos e compare saídas e efeitos colaterais. Um resultado pode ser apresentado sem interpretação:

case: invoice/month_end/migrated_account
old: status=200 body_sha256=7c... ledger_rows=0 notices=1
new: status=200 body_sha256=7c... ledger_rows=1 notices=1
verdict: FAIL side_effect.ledger_rows expected 0 got 1

Essa falha aponta para a afirmação sobre supressão da tarifa e seu caminho de provas. A equipe pode verificar se o código novo perdeu o comportamento do gatilho, se a configuração da reprodução não marcou a conta como migrada ou se a normalização escondeu uma diferença na origem. Uma afirmação genérica como “as saídas diferem” mandaria o modelo caçar outra vez por todo o repositório.

Tráfego gravado exige cuidado. Segredos e dados pessoais precisam de tratamento adequado ao ambiente, e efeitos destrutivos devem ser isolados ou virtualizados durante a reprodução. A cobertura também exige inventário: quais pontos de entrada, períodos de negócio, classes de erro e variantes de configuração aparecem no corpus? Um milhão de requisições felizes repetidas não cobre o raro procedimento de fechamento.

Regras de comparação merecem o mesmo exame dado às entradas capturadas. Horários, identificadores gerados, linhas sem ordem e caminhos específicos do ambiente podem exigir normalização, mas cada regra retira uma possível diferença da visão. Guarde cada regra como código, explique por que é segura e teste se não mascara uma mudança relevante. Se outro batch consome registros antigos em certa ordem, ordená-los antes da comparação fabricaria paridade.

Leitura paralela exige estado compartilhado

Dividir um repositório entre agentes só economiza tempo se todos escreverem num modelo comum e consistente do sistema. Dez resumos independentes criam dez vocabulários, conclusões duplicadas e lacunas nas fronteiras que cada trabalhador supôs que outro examinaria.

Trabalhadores paralelos devem assumir regiões explícitas do grafo ou perguntas específicas. Um pode resolver arestas de job para programa enquanto outro mapeia efeitos no banco e um terceiro classifica endpoints externos. Cada um escreve entidades, arestas tipadas, provas e conflitos no mesmo depósito. A identidade das entidades deve ser estável para reconhecer que CUSTOMER-REC num copybook e o buffer passado por três programas são o mesmo layout sob a mesma condição de build.

Conflitos são resultados úteis. Se a análise estática diz que um chamador alcança um procedimento, mas os rastros mostram uma segunda rota dinâmica, o sistema deve guardar ambos e programar a resolução. Se dois agentes atribuem sentidos de negócio diferentes ao mesmo campo, um revisor vê a discordância antes que o código gerado incorpore uma interpretação.

A concorrência também exige agendamento atento às dependências. Há pouco valor em gerar o substituto de um módulo posterior enquanto seu contrato de entrada continua em disputa. O trabalho pode avançar em componentes independentes, mas mudanças que cruzam arestas não resolvidas devem esperar ou carregar interfaces provisórias explícitas.

A afirmação de um milhão de linhas só se torna crível nesse modelo. A CodeHero lê em paralelo todas as linguagens da árvore e usa uma representação compartilhada do sistema inteiro, em vez de tratar cada prompt como uma sessão isolada. Esse fato arquitetural importa. O número de agentes simultâneos, sozinho, não diz nada sobre compreensão.

A superfície de revisão deve mostrar como uma conclusão foi montada: locais do fonte, caminho no grafo, casos de rastros, interpretações concorrentes e o código posterior que a consome. Uma barra de progresso para executivos não basta ao engenheiro que precisa decidir se uma regra de pagamento sobreviveu à reescrita.

Estado compartilhado não significa um prompt enorme para todos os trabalhadores. Significa um depósito transacional de provas com identificadores estáveis e verificações de versão. Os trabalhadores podem operar em partes limitadas e unir fatos apenas quando a revisão da fonte ainda coincide. Isso evita agentes isolados que se esquecem e uma conversa global que cresce até ninguém saber qual afirmação continua atual.

Qualidade da arquitetura e paridade são portas separadas

Uma reescrita pode igualar o comportamento observado e ainda reproduzir mal a arquitetura antiga. Também pode parecer moderna enquanto muda o sistema em suas fronteiras. Essas são portas separadas, e nenhuma deve compensar a outra.

A paridade comportamental avalia requisições, arquivos, mensagens, mudanças no banco, ordem temporal quando relevante e erros. A revisão de arquitetura avalia fronteiras de módulos, propriedade do estado, expressões naturais da linguagem-alvo, tratamento de falhas, observabilidade, implantação e remoção do acoplamento antigo. Uma nota ponderada que mistura ambas pode esconder um erro fatal. Exija aprovação em cada porta.

Essa é outra distinção que demonstrações de repositório costumam borrar. Gerar Go sintaticamente correto a partir de COBOL demonstra tradução. Substituir estado acoplado ao batch por serviços explícitos enquanto preserva o fechamento demonstra modernização. A segunda exige mapa do repositório, restrições operacionais e provas de paridade. Geração de código, sozinha, não estabelece isso.

Defina critérios de revisão antes da implementação. Para uma fronteira de serviço, registre chamadores permitidos, contratos de requisição e resposta, propriedade da transação, comportamento de novas tentativas e casos de paridade. Para um núcleo numérico Rust, registre domínios de entrada, arredondamento, overflow e vetores de referência. Para um cliente TypeScript, registre a propriedade da validação e sua imposição no servidor. São decisões de engenharia, não detalhes a inferir do trecho que ficou em primeiro lugar.

Não aceite “o modelo viu o repositório inteiro” como prova de qualquer porta. Peça o caminho do ponto de entrada ao comportamento alterado, as arestas não resolvidas nele, a decisão de alvo que substituiu o acoplamento antigo e os casos de reprodução aprovados. Se o sistema não fornece essas quatro coisas, produziu código sem uma explicação defensável do sistema.

A equivalência operacional pode incluir mais que corpos de respostas. Horários de corte de batch, ordem de locks, limites de novas tentativas, modos de arredondamento, codificação de arquivos e momento das mensagens podem fazer parte do contrato quando outro sistema depende deles. O inventário deve marcar quais propriedades precisam corresponder exatamente, quais podem variar dentro de um limite e quais mudanças foram aprovadas por um responsável. Chamar toda diferença de erro bloqueia a modernização. Chamar toda diferença inconveniente de melhoria abandona a paridade.

Avalie o leitor perturbando as provas

A melhor avaliação de um leitor de repositório testa sua estabilidade sob mudanças que não deveriam afetar a resposta. Uma única demonstração bem-sucedida diz pouco porque ordem dos arquivos, palavras da consulta e trechos escolhidos podem ter favorecido o caso.

Monte um conjunto de perguntas sobre o repositório com respostas apoiadas por vários artefatos. Inclua chamadas diretas, despacho dinâmico, variantes selecionadas por configuração, efeitos no banco, ordem de batch, código morto parecido com o ativo e fronteiras entre linguagens. Para cada pergunta, registre o caminho de provas esperado, não só uma resposta em prosa.

Depois perturbe a entrada de modo controlado:

1. Reordene arquivos e resultados do percurso sem alterar o conteúdo.
2. Acrescente implementações mortas quase idênticas e comentários antigos.
3. Renomeie identificadores locais preservando estrutura e comportamento.
4. Remova um artefato necessário e confira se o sistema relata incerteza.
5. Acrescente um rastro de execução que contradiz a hipótese estática.

Pontue separadamente o recall das provas, a correção do caminho, o tratamento da incerteza, a mudança gerada e o resultado de paridade. Um leitor que chega à resposta certa pelo caminho errado é frágil. Um sistema que se recusa a concluir após remover uma prova pode ser melhor que outro que mantém a resposta original.

Custo e latência pertencem à avaliação, mas não substituem precisão. Registre tempo de parsing, custo de atualizar o índice, percurso do grafo, chamadas ao modelo, tempo de reprodução e revisão humana. Mudanças incrementais devem atualizar entidades e testes afetados, sem forçar uma releitura completa. É assim que ler toda a base vira uma arquitetura operacional em vez de uma demonstração de lançamento cara.

A pergunta de aceitação não é se uma chamada ao modelo comporta um milhão de linhas. É se o sistema explica um comportamento, resiste a contexto irrelevante, expõe provas ausentes, produz um projeto-alvo deliberado e comprova a implementação nova contra a antiga. Uma janela maior pode ajudar em vários pontos. Ela nunca elimina a necessidade da estrutura ao redor.