Loop de Autocorreção

1. Visão geral da conceção e problema sistémico

Uma das maiores ilusões no trabalho com IA é a expectativa de que um modelo de linguagem escreva código complexo e funcional à primeira tentativa. Na realidade, até os desenvolvedores experientes dependem constantemente do diagnóstico via ferramentas: executam o compilador, observam o realce de erros na IDE e analisam as mensagens dos testes.

Se privarmos o agente do ciclo de feedback:

1. Alucinações sintáticas cegas: O modelo usa confiantemente métodos obsoletos de bibliotecas ou acessa propriedades inexistentes de objetos.
2. Incapacidade de resolver bugs complexos: Sem a análise do stack trace, o agente não conhece o ponto real de falha do programa em runtime.
3. Sobrecarga rotineira para o desenvolvedor: A pessoa precisa copiar manualmente as mensagens do terminal para o chat e solicitar a correção do erro.

O Self-Correction Loop (Ciclo de autocorreção fundamentada) transforma a geração de código em um pipeline de engenharia controlado: o agente aplica alterações, executa ferramentas de verificação, analisa a saída do ambiente e repete tentativas por conta própria até que os testes fiquem "verdes".

2. Taxonomia arquitetural e modelo mental

Um ciclo robusto de autocorreção baseia-se em três níveis de Oráculos de Feedback Determinísticos:

• 1. Oráculos Sintáticos e Estáticos (Static Oracles): Ferramentas de compilação e verificação de tipos (tsc --noEmit, mypy, cargo check). Elas operam em milissegundos e fornecem coordenadas precisas do erro (arquivo, linha, coluna, tipo esperado vs. tipo atual).
• 2. Oráculos Dinâmicos Comportamentais (Dynamic Test Oracles): Runners de testes (vitest, pytest, jest). Verificam a lógica real de execução, a reação às condições de contorno (Boundary Conditions) e a ausência de regressões.
• 3. Linters Estilísticos e Arquiteturais (Linters): eslint, biome, ruff. Controlam a conformidade com o code style da empresa, a proibição do uso de any e vazamentos de variáveis não utilizadas.
• 4. Estratégias de Aplicação de Correções:
  • Surgical Diff (Patch Cirúrgico): Substituição apenas de algumas linhas-alvo dentro de uma função.
  • Full File Rewrite (Reescrita Completa do Arquivo): Método arriscado que frequentemente introduz bugs colaterais.

3. Pipeline técnico e mecânica interna

O ciclo de vida da correção iterativa de erros:

1. Geração e Aplicação de Patch (Aplicação de Alterações): O agente gera um patch para o arquivo original e grava as mudanças no sistema de arquivos.
2. Execução do Oráculo (Disparo da Verificação): O runtime executa automaticamente o comando de validação em um processo isolado (por exemplo, npm test).
3. Extração do Exit Code & Stacktrace (Avaliação do Resultado):
   • Se o código de saída for 0 — a tarefa é considerada concluída, o ciclo termina com sucesso.
   • Se o código de saída for != 0 — o runtime faz o parse do stderr/stdout, remove o ruído visual excessivo e formula uma mensagem de erro estruturada.
4. Injeção de Contexto & Re-prompting (Transmissão do Feedback): O agente recebe a mensagem: «O teste user-auth.test.ts falhou na linha 42 com o erro: Expected status 200, received 401. Aqui está o trecho do arquivo ao redor da linha 42. Identifique a causa e proponha uma correção». O processo se repete com um contador de tentativas.

4. Cenários práticos de engenharia em produção

01. Resolução autônoma de erros TypeScript

O agente atualiza a assinatura de um método em uma biblioteca compartilhada. A execução do tsc identifica 8 arquivos com contratos violados. O agente percorre sequencialmente cada arquivo, corrige os tipos dos parâmetros e só para quando o compilador retorna zero erros.

02. Desenvolvimento Orientado a Testes (TDD)

O engenheiro escreve um conjunto rigoroso de testes unitários que descrevem os requisitos de negócio para uma nova API. O agente recebe a tarefa de escrever o código de implementação. Trabalhando no ciclo de autocorreção, o modelo escreve o código, roda os testes, analisa as discrepâncias e leva todos os testes ao status verde sem intervenção humana.

03. Migração automática de dependências obsoletas

Durante a transição para uma nova versão majoritária do framework, o agente executa a suíte de testes e, com base nas mensagens de métodos obsoletos (Deprecation Warning), atualiza automaticamente o código da aplicação para as APIs modernas.

5. Armadilhas, erros comuns e segurança

• Remoção ou suavização de testes (Test Cheating): Ao enfrentar um teste difícil, o modelo pode tentar "resolver" o problema adicionando it.skip() ou comentando o expect(). Bloqueie sempre a capacidade de editar arquivos de teste ou valide o Git Diff para detectar modificações na pasta de testes.
• Oscilação e "loop suave" (Flip-Flop Edits): O agente corrige um erro no arquivo A, quebrando o arquivo B; depois corrige o arquivo B, quebrando novamente o A. Se o sistema detectar a repetição de um estado idêntico do código, o ciclo deve parar imediatamente.
• Reescrita em vez de cura (Over-Fixing): Em vez de corrigir um único argumento incorreto, o agente reescreve toda uma função de 300 linhas, perdendo otimizações e detalhes críticos. Exija que o agente utilize patches diff localizados.