Reescrita de código com IA: como avaliar desempenho e controles
Um benchmark rápido não demonstra que uma aplicação preservou suas regras de acesso. Veja como avaliar uma migração produzida com auxílio de IA.
Read in EnglishPor Pentesty
O que a comparação entre linguagens permite concluir
O CyberSec Brazil noticiou uma comparação de versões do Campfire em diferentes linguagens. Os repositórios públicos da Basecamp mostram implementações e procedimentos de verificação distintos. Este artigo não reproduz os números da notícia: uma medição depende da versão e da configuração testadas. O caso motiva uma pergunta de engenharia: quais evidências justificam trocar uma aplicação em produção?
Defina a equivalência antes de medir velocidade
Comece com uma lista de comportamentos observáveis que a versão atual precisa preservar. Inclua criação de conta, recuperação de acesso, permissões, anexos, buscas e operações administrativas relevantes ao produto. Para cada comportamento, registre entrada, resultado esperado e efeitos persistidos. Uma resposta HTTP correta pode esconder uma gravação incorreta ou a ausência de uma verificação de acesso.
Escolha exemplos de negócio que exercitem limites. Uma pessoa pode ler a conversa de outro grupo? Uma conta suspensa mantém uma sessão válida? O mesmo evento chega duas vezes e duplica uma operação? Transforme essas perguntas em critérios de aceitação acordados com quem mantém o produto. A proposta é uma avaliação da migração, não uma afirmação de falhas nos projetos citados.
Compare os controles com identidades diferentes
Execute os mesmos cenários nas duas versões com contas de teste que tenham funções diferentes. Use dados sintéticos reconhecíveis para identificar uma resposta indevida. Registre o estado anterior, a requisição autorizada e o resultado efetivo. O teste deve comprovar tanto a operação permitida quanto a recusa da operação fora do escopo.
- Autorização: mantenha a separação entre organizações, grupos e funções.
- Sessão: confira expiração, encerramento e revogação nos fluxos acordados.
- Dados: compare validação, persistência e exposição em respostas e registros.
- Integrações: verifique identidade, permissões e tratamento de falhas de cada serviço conectado.
Torne o benchmark reproduzível
Fixe a revisão do código, a versão do runtime, os recursos disponíveis e a configuração de armazenamento. Documente o volume e a forma dos dados sintéticos. Se uma versão usa cache aquecido e outra começa vazia, registre essa diferença e rode cenários equivalentes antes de atribuir o resultado à linguagem.
Descreva a carga como um conjunto de jornadas, com proporção de leitura, escrita e conexões persistentes compatível com a hipótese estudada. Observe latência, erros e uso de recursos juntos. Uma execução que retorna mais respostas por segundo pode estar rejeitando trabalho, omitindo verificações ou medindo uma operação diferente. Investigue essas possibilidades antes de aceitar o ganho.
Aceite a migração com evidências e caminho de retorno
O NIST SSDF oferece práticas para integrar segurança ao desenvolvimento. Na aplicação proposta aqui, a equipe mantém um registro que liga requisitos, testes e resultados à revisão candidata. Esse registro deve permitir a outro responsável repetir o cenário e entender por que a mudança foi aceita, sem depender da explicação gerada pela ferramenta de IA.
Separe a aprovação técnica da decisão de entrada em produção. Confirme compatibilidade dos dados e a viabilidade do retorno antes de mudar o tráfego. Uma alteração de esquema pode impedir restaurar apenas a versão anterior do código. Faça o ensaio de recuperação com uma cópia autorizada e protegida, definindo quem pode interromper a migração e como validar o serviço depois.
A Pentesty pode avaliar caminhos de acesso e controles dentro do escopo combinado. Combine essa avaliação com os testes funcionais e de desempenho mantidos pela equipe do produto. A decisão deve reunir evidências complementares: preservar regras de negócio, respeitar limites de acesso e atender ao objetivo operacional que motivou a reescrita.
Quem define o teste quando a IA também ajuda a avaliar o código?
Atualização editorial: 16 de outubro de 2026
No relatório de riscos de agosto de 2026, a Anthropic afirmou que seus modelos não haviam atingido nenhum dos dois critérios de sua política para automação de pesquisa e desenvolvimento, mas registrou menor confiança nessa avaliação. Em When AI builds itself, o laboratório distingue avanços na execução de tarefas da capacidade de escolher objetivos de pesquisa. São avaliações do fornecedor em escopos definidos, sem demonstrar autoaperfeiçoamento recursivo completo nem segurança universal.
Para a revisão de uma reescrita, separe a implementação candidata do contrato que decide seu aceite. Uma IA pode sugerir testes, mas a equipe responsável precisa aprovar os requisitos e as mudanças nesses critérios. Mantenha os casos essenciais de autorização, persistência e comportamento fora do conjunto que o agente pode alterar livremente. Um teste modificado junto com o código pode passar e ainda deixar sem resposta a pergunta original da migração.
Em um exercício autorizado com aplicação fictícia, fixe os comportamentos esperados e guarde a revisão da suíte de aceitação. Peça a alteração dentro das permissões combinadas e execute os casos aprovados a partir de um ambiente controlado. Se surgir necessidade legítima de mudar um critério, registre a justificativa e uma aprovação separada antes de atualizar a referência. Compare resultados e limitações, sem transformar a avaliação gerada pelo próprio modelo na única evidência de sucesso.
Perguntas frequentes
Um benchmark prova que Rust é sempre mais rápido?
Não. O resultado descreve uma implementação sob condições específicas. Compare revisões, configurações, operações realizadas, erros e recursos antes de tirar conclusões para a sua aplicação.
O código produzido com IA precisa de testes diferentes?
Ele precisa satisfazer os mesmos requisitos do produto. A migração também exige evidências de equivalência com a versão anterior, incluindo limites de autorização e efeitos persistidos.
Qual controle deve entrar primeiro na avaliação?
Escolha os limites de acesso com maior impacto para o produto. Use identidades com permissões diferentes e confirme tanto os resultados autorizados quanto a recusa dos acessos indevidos.
Quando uma reescrita pode ser aceita?
Quando atende aos critérios funcionais, de segurança e de operação acordados, com resultados reproduzíveis e um retorno viável. Um ganho isolado de velocidade não resolve essas outras condições.
Fontes e referências
- Cyber Security Brazil: referência editorial da notícia
- Basecamp: implementação do Campfire em Rust
- Basecamp: implementação e verificação do Campfire em Elixir
- NIST SP 800-218: desenvolvimento seguro de software
Análise original da Pentesty, publicada em 15 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.