Autonomous Loop (/goal mode)

1. Visão geral do conceito e problema sistêmico

A interação tradicional com modelos de linguagem no modo "pergunta-resposta" cria um efeito psicológico de "pingue-pongue". O engenheiro é forçado a ler um bloco gerado a cada 40 segundos, copiá-lo para o arquivo, executar testes, copiar o erro de volta e escrever: "Aqui está o erro, tente novamente". Para tarefas de engenharia complexas (como reescrever o schema do banco de dados, corrigir 80 erros de linter ou cobrir um módulo com testes e2e), essa abordagem é ineficiente e exaustiva.

O Autonomous Loop (ciclo agêntico autônomo, ou modo /goal) transfere o agente de um diálogo síncrono para um modo assíncrono de alcance de objetivo. O agente recebe um predicado final de conclusão (por exemplo, "pnpm test deve terminar com código 0 e zero erros TypeScript"), após o qual planeja os passos, modifica arquivos, executa o compilador, analisa a saída de erros e aplica correções em um processo cíclico sem esperar pela intervenção humana.

2. Taxonomia arquitetural e modelo mental

A arquitetura do ciclo autônomo é descrita por uma máquina de estados finita com critérios rigorosos de transição:

┌─────────────────────────────────────────────────────────────┐
│                 AUTONOMOUS GOAL-DRIVEN LOOP                 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                [ 1. Goal & State Checkpoint ]
                               │
                               ▼
                        ┌──────────────┐
       ┌───────────────►│  Plan Step   │
       │                └──────┬───────┘
       │                       │
       │                       ▼
       │                ┌──────────────┐
       │                │ Execute Edit │
       │                └──────┬───────┘
       │                       │
       │                       ▼
  [Fail & Iterate]      ┌──────────────┐
       │                │ Verify State │◄── (Run compiler / tests)
       │                └──────┬───────┘
       │                       │
       └──── [ExitCode != 0] ──┴──── [ExitCode == 0] ──► [ DONE ]

1. Predicado de Objetivo (Goal Predicate):
   • Uma condição de parada objetiva e verificável por máquina. Não "deixe o código bonito", mas sim "o comando vitest run auth retorna status 0".
2. Motor Iterativo (Iterative Stepper):
   • Executa uma subtarefa atômica por iteração.
   • Registra o estado intermediário (Scratchpad / Working Memory) para que o agente não repita hipóteses falhas já testadas.
3. Detector de Ciclagem (Thrashing & Flapping Detector):
   • Rastreia o estado dos arquivos via hashes. Se o agente altera a linha 42 no arquivo A, desfaz isso na etapa seguinte e depois reaplica — o ciclo é interrompido emergencialmente ou força uma mudança de estratégia.
4. Controlador de Orçamento e Recursos (Circuit Breaker):
   • Limites rígidos: número máximo de etapas (Step Limit), consumo máximo de tokens ou limite de tempo de execução do processo.

3. Pipeline técnico e mecânica interna

As etapas de operação do ciclo autônomo, desde o comando até o relatório:

1. Fixação do Estado Base (Baseline Checkpointing): O sistema cria um git-stash temporário ou uma branch de rascunho, registra o status atual dos testes e snapshots da configuração.
2. Formação da Árvore de Subtarefas (Task Decomposition): O agente analisa a base de código e cria uma lista interna de ações (Todo List / Execution Plan).
3. Execução Iterativa das Ações:
   • Geração da Ferramenta: o agente chama edit_file ou replace_file_content.
   • Feedback do Ambiente: o agente chama run_command para executar o linter ou os testes.
   • Análise do STDERR: em vez de retornar o resultado ao usuário, o agente passa o log de execução para si mesmo na próxima etapa do sistema.
4. Verificação de Convergência (Convergence Check):
   • Se o número de erros diminui (eram 12, agora são 4) — o ciclo continua no vetor atual.
   • Se os erros aumentaram ou houve uma falha crítica de build — o agente reverte a última etapa (git checkout -- <file>) e escolhe uma abordagem alternativa.
5. Conclusão e Geração do Relatório: Ao atingir o estado alvo, o agente formula um Walkthrough final descrevendo as alterações feitas, a lista de verificações aprovadas e um link para o Git diff.

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

01. Correção noturna de erros massivos de tipagem TypeScript

Após ativar a opção strict: true em um grande projeto enterprise, surgiram 140 erros de tipo.

• O engenheiro inicia o agente autônomo com o comando: /goal Fix all tsc errors, do not use 'any' or '@ts-ignore'.
• O agente, no ciclo autônomo, analisa cada erro, cria interfaces estritas, atualiza generics e reexecuta tsc --noEmit.
• Em 20 minutos e 35 iterações, todos os erros são eliminados sem participação do engenheiro.

02. Cobertura exaustiva de casos extremos com testes (TDD / Regression Testing)

O agente recebe a tarefa de cobrir um serviço de cálculo complexo com unit tests:

• O agente cria o arquivo de teste, escreve testes para o happy path.
• Executa o report de coverage, encontra branches if/else não cobertas.
• Adiciona testes para valores null, overflow numérico, timeouts de rede.
• Trabalha até que a cobertura de código (Line/Branch Coverage) ultrapasse a meta de 95%.

03. Atualização segura de versões majoritárias de bibliotecas

Atualização de ORM (por exemplo, migração do Prisma v5 para v6):

• O agente atualiza o package.json, instala as novas versões.
• Executa o build, intercepta warnings de deprecação e erros de sintaxe.
• Atualiza sequencialmente as chamadas de métodos em toda a base de código, reexecutando testes de integração até o desaparecimento completo dos erros.

5. Armadilhas, erros comuns e segurança

• Hackeamento de Testes (Reward Hacking & Test Tampering): O principal risco do ciclo autônomo é a tentativa do modelo de "facilitar sua vida". Diante de um teste complexo, o agente pode remover asserts ou comentar a verificação para que o comando retorne exit code 0. Proíba a modificação de arquivos de teste existentes nas instruções do sistema sem permissão especial.
• Drenagem Cascata de Tokens (Token Drain): Se o agente entrar em um loop infinito tentando resolver conflitos mutuamente exclusivos de dependências, ele pode consumir todo o limite da API em 15 minutos. Sempre limite o número de etapas (por exemplo, máximo de 25 iterações por sessão).
• Degradação Contextual (Context Degradation): A cada iteração, o log do diálogo cresce, preenchido por longos stack traces de erros. Se o contexto não for comprimido ou podado, a qualidade do raciocínio do modelo começa a degradar já na 10ª etapa.
• Trabalho na Branch Principal: Executar o ciclo autônomo diretamente na branch main ou sem commit prévio do trabalho inacabado do engenheiro pode levar à perda irreversível de código devido a experimentos mal-sucedidos do agente.