Como ferramentas de programação com IA mudam código alheio

O preenchimento automático, os assistentes e os agentes conseguem produzir uma função que parece plausível. Essa semelhança superficial levou fornecedores e equipes de engenharia a usar um único nome para três modelos operacionais diferentes. O nome esconde a parte que interessa: o que a ferramenta pode observar, o que pode alterar e quais provas reúne antes de declarar o trabalho concluído.

Em uma base de código conhecida, essas diferenças afetam a velocidade. Em um sistema cujos autores já não estão presentes, elas determinam se você preserva um comportamento que ninguém lembrou de documentar. Um preenchimento prevê o texto perto do cursor. Um assistente responde com base em um contexto limitado. Um agente escolhe ações, observa seus resultados e continua. Tratar um como se fosse outro gera falsa confiança muito antes de gerar um erro do compilador.

Como o preenchimento prevê a próxima edição local

O preenchimento automático sugere texto a partir do código ao redor do cursor e do contexto adicional do repositório que seu ambiente fornece. Sua unidade natural de trabalho é o próximo token, linha ou bloco pequeno. Mesmo quando uma sugestão abrange uma função inteira, a interação continua preditiva: a ferramenta oferece texto e o desenvolvedor decide se aceita.

Esse modelo funciona muito bem quando a intenção já está no arquivo atual. Repetir um padrão de tratamento de erros, completar um switch sobre uma enum conhecida, montar uma tabela de testes com casos vizinhos ou escrever outro método que siga uma interface visível são tarefas adequadas. O desenvolvedor mantém o projeto na cabeça. A ferramenta reduz a digitação e recorda a sintaxe.

O Language Server Protocol faz uma distinção útil aqui. Sua solicitação de conclusão carrega uma posição no documento e pode carregar um caractere ou tipo de acionamento. O protocolo não define uma missão como «substitua esta camada de armazenamento» nem um ciclo de provas que demonstre a substituição. Um produto pode enriquecer a conclusão com trechos indexados do repositório, mas a interação ainda termina em uma sugestão. Buscar mais conteúdo pode melhorar a hipótese sem transformá-la em investigação.

O preenchimento deixa de ser útil quando a correção depende de fatos fora da vizinhança fornecida. Um parágrafo COBOL pode atualizar um campo cujo layout vem de um copybook, enquanto JCL seleciona outro conjunto de dados no fechamento do mês. Um tratador de eventos VB6 pode parecer sem uso até um arquivo de formulário vinculá-lo pelo nome. Um procedimento PL/SQL pode depender de uma variável de pacote inicializada por uma chamada anterior. O fato ausente costuma ter sintaxe válida e nenhum sinal visível no ponto da edição.

Observe o gesto de aceitação. Pressionar Tab significa «insira estes caracteres», não «comprovei que este comportamento é seguro». As equipes se complicam quando a facilidade física de aceitar substitui discretamente a revisão. Uma conclusão longa merece mais desconfiança, pois sua superfície bem acabada pode esconder um conjunto maior de suposições.

Como um assistente trabalha dentro da conversa fornecida

Um assistente de programação responde a uma solicitação usando o material colocado em seu contexto: código selecionado, arquivos abertos, trechos recuperados, diagnósticos, instruções e turnos anteriores. Sua unidade natural é a conversa. Ele consegue explicar uma rotina, comparar projetos, redigir um patch ou raciocinar sobre um erro com mais espaço que o preenchimento.

Esse espaço adicional muda a qualidade do trabalho. Você pode pedir ao assistente que acompanhe um valor por quatro funções, identifique uma invariante implícita ou explique por que uma refatoração proposta muda os limites da transação. Pode contestar a primeira resposta e acrescentar o arquivo que ele não viu. Isso ajuda na exploração, principalmente quando um desenvolvedor continua responsável por escolher as provas.

O limite passa despercebido porque as interfaces de chat falam com fluência sobre arquivos que nunca abriram. Se o assistente disser: «Esta função só é chamada pelo importador em lote», a afirmação pode ser uma dedução do trecho colado, não uma busca no repositório. Pergunte o que ele examinou. Uma resposta sólida deve nomear os pontos de chamada, a configuração, as ligações geradas ou as provas de execução por trás da conclusão. Se não conseguir, trate a afirmação como hipótese.

Janelas de contexto não resolvem a seleção do contexto. Um milhão de linhas pode caber mal, mesmo que o modelo aceite uma entrada enorme. Árvores de código contêm código gerado, versões duplicadas, definições de banco de dados, scripts de implantação, layouts binários e testes com graus diferentes de autoridade. Colocar mais tokens no prompt não diz ao assistente qual copybook está ativo em produção nem qual de dois cálculos quase idênticos atende à regra regulatória.

Use um assistente para transformar incerteza em perguntas explícitas. Peça que ele liste as suposições por trás de um patch, nomeie arquivos que poderiam refutá-las e descreva o teste de comportamento que espera passar. Essa saída dá ao revisor algo concreto para examinar. Não peça notas de confiança. Uma porcentagem que soa precisa não tem calibração comum e não acrescenta provas.

Como um agente altera o repositório em um ciclo de ações

Um agente de programação pode selecionar e executar ações e depois usar os resultados para escolher a ação seguinte. Ele pode pesquisar a árvore, abrir arquivos, editar vários módulos, executar um compilador, rodar testes, examinar falhas e revisar o patch. Sua unidade natural é uma tarefa com uma condição de parada, não uma única resposta.

O ciclo importa mais que a janela de chat. Um agente útil faz algo assim:

1. Identifica o estado do repositório e as instruções aplicáveis.
2. Busca definições, chamadores, configuração, testes e ligações geradas.
3. Faz uma alteração limitada em uma branch ou worktree isolado.
4. Executa as verificações capazes de refutar a mudança.
5. Examina o diff e relata a incerteza restante.

Cada observação pode redirecionar o trabalho. Um teste com falha pode revelar uma regra de arredondamento não documentada. Um erro do compilador pode expor uma build tag que seleciona outra implementação. Uma busca pode encontrar uma segunda linguagem chamando a mesma rotina de banco de dados. O agente consegue seguir essas ramificações sem esperar que uma pessoa cole o próximo arquivo.

Capacidade de agir não significa autonomia sem limites. Gravação de arquivos, comandos de shell, acesso à rede, credenciais, direitos de implantação e regras de aprovação são capacidades separadas. Uma ferramenta que edita a árvore mas não roda testes tem um ciclo de provas mais curto. Uma ferramenta que pode executar qualquer comando de produção tem um modelo de permissões perigoso. Chamar as duas de «agentes» quase nada diz a um líder de engenharia.

A condição de parada também precisa ser examinada. «Os testes passam» só basta se os testes cobrirem o comportamento em risco. «A build funciona» prova restrições de tipo e ligação, não equivalência de negócio. O agente deve parar porque cumpriu uma condição explícita de aceitação e esgotou as verificações combinadas, não porque ficou sem ações óbvias ou produziu um diff organizado.

Sistemas desconhecidos tornam o contexto ausente o maior risco

Em código desconhecido, o maior risco geralmente não está em gerar a sintaxe de substituição. Está em descobrir o contrato de comportamento que atravessa arquivos fonte, controle de jobs, dados, operações e hábitos dos usuários. Os autores originais muitas vezes codificaram esse contrato em lugares que uma busca moderna no repositório classifica mal.

Considere um job noturno de faturamento. Uma rotina de cálculo é clara isoladamente, então um assistente a reescreve em uma linguagem moderna e seus testes unitários passam. O comportamento em produção também depende de um código de condição JCL que pula uma etapa após uma entrada parcial, de um registro de largura fixa no qual um valor em branco difere de zero e de um procedimento de reexecução que preserva um arquivo intermediário. Nenhum desses fatos precisa aparecer na rotina. Uma reescrita fiel no nível local ainda pode cobrar duas vezes em uma reexecução.

É aqui que o setor confunde dois tipos de contexto. Contexto de código é o material que a ferramenta consegue ler: código, esquemas, arquivos de build, chamados e testes. Contexto operacional é a prova do que o sistema realmente faz: solicitações de produção, entradas em lote, saídas, horários, efeitos colaterais, recuperação de falhas e decisões de operadores. Mais contexto de código não recupera automaticamente o contexto operacional. A consequência é direta: compreender o repositório ajuda na migração, mas não prova sozinho a paridade de comportamento.

Sistemas legados acrescentam ligações entre linguagens. COBOL chama assembler ou procedimentos de banco de dados. Programas RPG dependem de comandos CL e arquivos descritos externamente. Uma página Classic ASP invoca componentes COM criados em VB6. Uma planilha Excel chama uma consulta Access que chama um procedimento armazenado. Uma ferramenta que indexa apenas a linguagem indicada no chamado produz um mapa limpo, mas com estradas ausentes.

Antes de alterar um sistema assim, registre o limite das provas. Quais repositórios estão incluídos? Quais agendadores, esquemas, layouts de dados e rastros de execução estão disponíveis? Quais chamadas externas serão simuladas? Quais ações dos operadores continuarão fora da observação? Isso não é burocracia de projeto. O limite mostra quais afirmações a ferramenta pode sustentar e quais ainda exigem uma pessoa que conheça a produção.

A paridade de comportamento exige um oráculo fora do novo código

Uma reescrita deve ser julgada contra o comportamento observado, não pela aparência razoável da nova implementação. O oráculo mais seguro é independente do código gerado: entradas registradas são enviadas às duas versões, e as saídas e efeitos colaterais são comparados por regras explícitas de normalização.

Um pequeno harness de paridade pode começar com um manifesto que declara o que conta como igual:

{
  "case": "month_end_partial_input",
  "input": "fixtures/partial.dat",
  "compare": ["stdout", "records", "exit_code"],
  "ignore": ["run_id", "processed_at"]
}

Depois, execute as implementações antiga e nova a partir de um estado limpo e preserve resultados legíveis por máquina:

case                         old  new  records  result
month_end_partial_input      04   04   1827     PASS
blank_amount_field           00   00   19       PASS
operator_rerun_after_step_3  00   08   641      FAIL

A linha com falha é mais útil que uma revisão de código confiante. Ela dá à equipe uma entrada reproduzível, o primeiro efeito divergente e um ponto para investigar. A comparação deve cobrir dados retornados, gravações no banco, mensagens emitidas, arquivos, códigos de saída e ordem sempre que os consumidores observarem a ordenação. Normalize apenas valores que o contrato realmente permite variar, como identificadores de execução gerados. Uma lista de exclusões ampla demais pode fazer qualquer implementação parecer correta.

O tráfego de produção registrado tem lacunas. Caminhos raros de erro podem não aparecer, campos sensíveis podem exigir tratamento controlado e jobs em lote podem depender do relógio ou do ambiente. Acrescente casos projetados para limites, entradas inválidas, novas tentativas e recuperação. Mantenha o executável antigo disponível em um harness isolado quando a licença e o acesso à plataforma permitirem. Se não houver um oráculo independente, diga isso claramente e reduza o escopo da alteração automática.

Sou contra usar testes escritos pelo modelo como única suíte de aceitação. A recomendação é popular porque o modelo consegue gerar código e testes de uma vez, e a build verde parece completa. Os dois artefatos podem compartilhar a mesma suposição errada. Testes gerados ajudam a expressar regras conhecidas; eles não descobrem de forma independente as regras que a geração deixou passar.

O trabalho de paridade falha quando as equipes comparam apenas o valor retornado pelo caminho feliz. Mudanças de estado costumam escapar por canais que o novo projeto pretende eliminar: um arquivo temporário consumido por outro job, um código de status verificado por JCL, uma linha de banco gravada antes de um erro ou um relatório classificado na ordem esperada pelos operadores. Faça um inventário dos efeitos observáveis externamente. Se um consumidor consegue distinguir duas execuções, o harness deve comparar a diferença ou documentar por que o novo contrato pode alterá-la.

O tempo merece uma fixture própria. Programas antigos frequentemente leem o relógio mais de uma vez, derivam datas comerciais de variáveis do agendador ou usam a meia-noite local como limite de processamento. Congele o tempo onde a plataforma permitir e registre os valores fornecidos pelo agendador. Faça o mesmo para valores aleatórios, geradores de sequência, localidade, codificação e variáveis de ambiente. Sem entradas controladas, o relatório de diferenças se enche de ruído, e os revisores começam a ignorar falhas que podem incluir a relevante.

A comparação de banco de dados exige mais que despejar as tabelas finais. Capture limites de transação e pontos de falha quando os chamadores puderem observá-los. Duas implementações podem terminar com linhas idênticas após o sucesso e se comportar de modo diferente quando a terceira gravação falha. Execute casos que interrompam o job em pontos controlados e compare linhas confirmadas, marcadores de repetição, bloqueios, mensagens emitidas e o resultado do procedimento documentado de reexecução. É um trabalho cansativo, mas transforma «preservar o comportamento» em provas que um engenheiro pode contestar.

As regras de normalização devem passar por revisão junto com o harness. Uma regra como «ignore todos os timestamps» costuma ser ampla demais; pode esconder uma data de liquidação movida para o período errado. Prefira regras por campo com uma justificativa, como ignorar um identificador de rastreamento gerado enquanto compara exatamente o timestamp com efeito comercial. Quando uma regra mudar, execute novamente os casos anteriores e registre quais diferenças desapareceram. A configuração de exclusões faz parte da especificação da migração, não da arrumação.

O sistema antigo também pode discordar de si mesmo. Registros de produção podem conter um defeito aceito, uma correção manual não documentada ou um comportamento que varia conforme a implantação. Não deixe o agente escolher silenciosamente a versão mais conveniente. Classifique cada divergência como comportamento a preservar, defeito a corrigir em decisão separada, diferença permitida ou observação sem resolução. O responsável pelo processo de negócio deve aprovar a segunda e a terceira categorias. Caso contrário, uma reescrita pode introduzir mudanças de política por meio de uma revisão técnica.

Um resultado de paridade deve ser reproduzível por alguém que não executou a tarefa original. Preserve a revisão do código, entradas da build, identidade das fixtures, descrição do ambiente, versão da normalização, linha de comando e artefatos de saída. Calcule o hash de fixtures grandes ou sensíveis quando não for adequado copiá-las, mas mantenha um caminho controlado até os originais. Oculte dados por um processo definido, em vez de editar fixtures casualmente, pois a máscara pode alterar comprimentos de campo, conjuntos de caracteres, checksums e caminhos de execução.

O comportamento dinâmico exige um método diferente dos grafos estáticos de chamadas. A busca encontra um nome direto de função, mas pode perder reflexão, despacho baseado em strings, callbacks de banco, registro de plugins, invocações do agendador e nomes montados pela configuração. Combine busca no código com metadados da build e observação em execução. Em um sistema que permita rastreamento, registre módulos carregados, jobs executados, endpoints chamados, arquivos abertos e rotinas de banco para casos representativos. O rastro não substitui a leitura do código; ele mostra quais partes de um mapa amplo participam do comportamento observado.

Afirmações de cobertura precisam nomear o denominador. Dizer que um agente «leu o repositório» pode significar que listou cada arquivo, incorporou texto selecionado, analisou linguagens compatíveis ou construiu um grafo de dependências entre linguagens. São ações diferentes. Peça contagens por tipo de arquivo, exclusões explícitas, falhas de análise, símbolos não resolvidos e ligações inferidas da configuração. Um relatório curto de exclusões é mais confiável que uma afirmação geral de compreensão total.

Por fim, teste o próprio harness com mutações deliberadas. Altere um campo comparado, inverta uma saída ordenada, mude um código de saída e suprima um efeito colateral. Cada mutação deve produzir uma falha clara. Se o harness continuar verde, ele não é um oráculo para esse comportamento. As equipes revisam o código da aplicação, mas tratam a infraestrutura de teste como neutra; em uma reescrita gerada, o mecanismo de comparação merece pelo menos a mesma desconfiança que o código julgado.

O preenchimento vence quando o desenvolvedor já domina a intenção

O preenchimento costuma ser a melhor ferramenta para uma alteração pequena e compreendida, pois mantém baixa a latência e o trabalho adicional. Se você conhece o contrato, vê os tipos relevantes e vai revisar cada inserção, um ciclo de ações acrescenta custo sem encontrar muitas provas novas.

Um bom trabalho de conclusão tem raio curto de revisão. Alguns exemplos são converter asserções repetitivas em tabela, acrescentar outro ramo de parser que siga os casos vizinhos, escrever uma chamada conhecida de API ou completar a serialização a partir de um esquema visível. O desenvolvedor pode rejeitar uma sugestão errada em segundos porque já sabe como deve ser o resultado correto.

Defina um limite prático. Quando precisar perguntar se outro arquivo controla o comportamento, pare de aceitar conclusões grandes e pesquise. Quando a edição atravessar um limite de persistência, permissão, linguagem ou job assíncrono, mude para um assistente na análise ou um agente na investigação. A mudança depende da incerteza e do raio de impacto, não do número de linhas. Uma alteração de uma linha no layout de um registro pode ser mais arriscada que uma fixture de teste com cem linhas.

Revise a saída como código de um colega rápido que não participou da reunião de projeto. Verifique caminhos de erro, propriedade de recursos, conversão numérica, codificação e suposições de concorrência. Não premie a ferramenta por imitar o estilo local se esse estilo carrega um erro. É justamente na repetição que o preenchimento reproduz um padrão ruim com eficiência.

Desative ou limite o preenchimento onde uma divulgação ou inserção acidental seja inaceitável. Código regulado, segredos em configurações próximas, textos jurídicos gerados e consoles de produção merecem regras explícitas. A questão não é se o fornecedor do modelo é confiável em geral. É quais dados o ambiente envia, onde a inferência roda, o que ele retém e quais controles seu ambiente pode impor.

Assistentes funcionam melhor quando a pergunta pode ser delimitada

Um assistente funciona bem quando um desenvolvedor consegue definir o conjunto de provas e avaliar a resposta sem conceder acesso de gravação. É uma boa opção para arqueologia de código, comparação de projetos, revisão de patches, explicação de consultas e conversão de uma observação de incidente em casos de teste.

Faça uma pergunta delimitada com provas nomeadas. Em vez de «explique este subsistema», peça: «Usando a definição do job, estes dois copybooks e os três chamadores, explique quando CUSTOMER-STATUS muda de H para A. Cite o arquivo e o símbolo de cada transição e liste qualquer caminho que não consiga resolver». A resposta ainda pode estar errada, mas o formato pedido torna visíveis os saltos sem suporte.

O assistente deve separar observação, inferência e proposta. A observação diz que um chamador passa um campo em branco. A inferência diz que o branco provavelmente representa um valor ausente, pois dois testes esperam esse resultado. A proposta diz que o novo parser deve mapear os brancos para um valor opcional explícito. Misturar essas afirmações transforma uma escolha plausível de projeto em suposto fato sobre o sistema antigo.

Use a conversa para uma revisão adversarial. Pergunte o que quebra se os registros chegarem fora de ordem, se o job reiniciar depois de uma gravação, se uma string contiver um caractere não ASCII ou se a chamada ao banco fizer commit de forma independente. Depois confira as respostas no código ou em provas de execução. O assistente ajuda porque enumera caminhos que pessoas cansadas ignoram, mas uma pergunta inventada não prova que o caminho existe.

Evite conversas intermináveis que acumulam suposições antigas. Quando o conjunto de provas mudar de forma relevante, comece uma nova análise com os fatos corrigidos e um registro conciso das decisões. Caso contrário, uma interpretação errada inicial pode continuar na conversa e influenciar respostas posteriores depois que a equipe pensa tê-la corrigido. Guarde descobertas duradouras em testes, notas de arquitetura ou chamados, não apenas no histórico do chat.

Agentes precisam de autoridade limitada e provas visíveis

Um agente ganha um escopo maior quando suas ações podem ser examinadas e revertidas. Dê apenas as permissões necessárias à tarefa, uma branch ou worktree isolado, instruções determinísticas de configuração e verificações de aceitação que falhem claramente. Mantenha credenciais de produção e direitos de implantação fora do ciclo, a menos que a tarefa os exija de forma explícita e exista uma aprovação humana.

Um relatório útil de execução deve responder a perguntas concretas:

• Com que estado do repositório e instruções o agente começou?
• Quais arquivos ele leu e alterou?
• Quais comandos rodaram e quais foram seus resultados de saída?
• Quais condições de aceitação passaram ou falharam?
• Que incerteza resta e qual prova poderia resolvê-la?

O diff continua necessário, mas não basta. Os revisores também precisam do caminho que o produziu. Um agente pode apagar um teste para fazer a suíte passar, atualizar um snapshot que registrava uma regressão ou escolher uma configuração alternativa que nunca roda em produção. Registros de comandos e contagens de testes antes e depois expõem alguns desses atalhos. A política do repositório deve proibir outros.

Contenha falhas mecanicamente. Limite os caminhos graváveis quando possível. Exija aprovação antes de comandos destrutivos, alterações de dependências, acesso à rede ou mudanças na configuração de implantação. Use limites de duração e número de arquivos alterados como alarmes, não como definições de correção. Se um alarme disparar, preserve o trabalho e as provas para revisão, em vez de deixar o agente ampliar sua própria autoridade.

Segurança e conformidade exigem linguagem precisa. Executar um modelo dentro do perímetro do cliente pode atender a restrições de localização de dados e rede, mas não concede uma certificação à ferramenta nem ao sistema resultante. Uma instalação isolada da rede ainda precisa de controles de acesso, registros de auditoria, procedência do modelo e das dependências e um processo para aprovar o que sai do ambiente.

Escolha a ferramenta pelas provas e pelo raio de impacto

A escolha deve seguir a afirmação que você precisa fazer. Se a afirmação for «esta linha segue o padrão que já entendo», o preenchimento pode bastar. Se for «estes arquivos indicam este comportamento», use um assistente e verifique as provas citadas. Se for «o repositório agora atende a esta condição de aceitação», um agente pode reunir as provas, desde que suas ferramentas e permissões cubram a condição.

Não compre o nome da categoria. Peça aos fornecedores que demonstrem o limite real de observação e ação. A ferramenta lê todas as linguagens da árvore? Segue ligações geradas e configuradas? Consegue rodar a build e os testes de paridade em seu ambiente? Mostra comandos e falhas? Você pode restringir gravações, rede e credenciais? O que exatamente faz o trabalho parar? Um patch bem acabado não responde a nenhuma dessas perguntas.

Para um sistema herdado, comece a escolha da ferramenta com uma tabela de risco, não uma lista de recursos. Coloque a ambiguidade do comportamento em um eixo e o raio de impacto no outro. Pouca ambiguidade e baixo impacto favorecem o preenchimento. Ambiguidade limitada com decisão humana favorece um assistente. Grande ambiguidade ou uma alteração entre sistemas exige um agente mais um oráculo independente, e às vezes exige adiar a mudança até a equipe capturar esse oráculo.

A CodeHero usa o último modelo em reescritas legadas: sua plataforma lê toda a base multilíngue, moderniza a arquitetura e verifica o comportamento contra tráfego de produção registrado com um harness de paridade. Cada projeto é entregue em menos de 30 dias, mas o prazo não reduz a exigência de provas; o ciclo de ações e o oráculo permitem discutir esse prazo em termos de engenharia.

A aquisição deve usar uma tarefa com pelo menos um padrão local enganoso, uma dependência entre linguagens e um comportamento visível apenas em execução. Dê a todos os candidatos o mesmo estado do repositório e as mesmas provas de aceitação. Compare afirmações sem suporte, arquivos excluídos, comandos, tentativas com falha e esforço de revisão com o mesmo cuidado dado ao patch final. Uma ferramenta que admite uma ligação sem resolução é mais segura que outra que preenche a lacuna com uma suposição fluente.

A responsabilidade após a execução também importa. A equipe deve conseguir reproduzir as verificações, manter o substituto e entender as exceções restantes sem acesso a uma sessão de chat desaparecida. Exija código comum, testes, instruções de execução e registros de decisões. Se um fornecedor não consegue entregar a cadeia de provas em formatos que seus engenheiros possam inspecionar, o sistema continua desconhecido após a reescrita, apenas em uma linguagem mais nova.

Uma ferramenta nunca deve receber mais autoridade do que suas provas justificam. Em código desconhecido, examine o que ela viu, o que fez e como tentou provar o resultado. Os três nomes importam porque forçam essa conversa antes que uma sugestão fluente se torne uma alteração de produção não examinada.