Autoresearch: Experimentação Iterativa Autônoma

Um ciclo de experimentação autônoma para qualquer tarefa de programação. Você define o objetivo e como medi-lo; o agente itera autonomamente — modificando código, executando experimentos, medindo resultados e mantendo ou descartando alterações — até ser interrompido.

Esta habilidade é inspirada no autoresearch de Karpathy, generalizada do treinamento de ML para qualquer tarefa de programação com um resultado mensurável.

Regras de Comportamento do Agente

1. DEVE guiar o usuário através da fase de Configuração interativamente antes de iniciar o ciclo.
2. DEVE estabelecer uma medição de linha de base antes de fazer quaisquer alterações.
3. DEVE confirmar cada tentativa de experimento antes de executá-la (para que possa ser revertida de forma limpa).
4. DEVE manter um log de resultados (TSV) rastreando cada experimento.
5. DEVE reverter alterações que não melhorem a métrica (git reset para o último estado conhecido bom).
6. DEVE rodar autonomamente assim que o ciclo começar — nunca pause para perguntar "devo continuar?".
7. NÃO DEVE modificar arquivos que o usuário marcou como fora do escopo.
8. NÃO DEVE pular a etapa de medição — cada experimento deve ser medido.
9. NÃO DEVE manter alterações que regridam a métrica, a menos que o usuário tenha explicitamente permitido compensações.
10. NÃO DEVE instalar novas dependências ou fazer alterações de ambiente, a menos que o usuário as tenha aprovado.

Fase 1: Configuração (Interativa)

Antes que qualquer experimentação comece, trabalhe com o usuário para estabelecer estes parâmetros. Pergunte ao usuário diretamente por cada item. Não assuma nem pule nenhum.

1.1 Definir o Objetivo

Pergunte ao usuário:

O que você está tentando melhorar ou otimizar?

Exemplos: tempo de execução, uso de memória, tamanho do binário, taxa de aprovação de testes, cobertura de código, latência de resposta da API, taxa de transferência, taxa de erros, pontuação de benchmark, tempo de compilação, tamanho do pacote, linhas de código, complexidade ciclomática, etc.

Registre a resposta do usuário como o objetivo.

1.2 Definir a Métrica

Pergunte ao usuário:

Como medimos o sucesso? Qual comando exato produz a métrica?

Preciso de:

1. O comando a ser executado (ex: dotnet test, npm run benchmark, time ./build.sh, pytest --tb=short)
2. Como extrair a métrica da saída (ex: um padrão regex, uma linha específica, um campo JSON)
3. Direção: Menor é melhor ou maior é melhor?

Exemplo: "Execute dotnet test --logger trx, conte os testes aprovados. Maior é melhor." Exemplo: "Execute hyperfine './my-program', extraia o tempo médio. Menor é melhor."

Registre:

• METRIC_COMMAND: o comando a ser executado
• METRIC_EXTRACTION: como extrair a métrica numérica da saída
• METRIC_DIRECTION: lower_is_better ou higher_is_better

1.3 Definir o Escopo

Pergunte ao usuário:

Quais arquivos ou diretórios tenho permissão para modificar?

E quais arquivos estão FORA DE LIMITES (somente leitura)?

Registre:

• IN_SCOPE_FILES: arquivos/diretórios que o agente pode editar
• OUT_OF_SCOPE_FILES: arquivos/diretórios que não devem ser modificados

1.4 Definir Restrições

Pergunte ao usuário:

Existem restrições que devo respeitar?

Exemplos:

• Orçamento de tempo por experimento (ex: "cada execução deve levar < 2 minutos")
• Sem novas dependências
• Devo manter todos os testes existentes aprovados
• Não devo alterar a API pública
• Devo manter a compatibilidade retroativa
• Limite de VRAM/memória
• Limites de complexidade de código (preferir soluções mais simples)

Registre como CONSTRAINTS.

1.5 Definir o Orçamento de Experimentos (Opcional)

Pergunte ao usuário:

Quantos experimentos devo executar, ou devo continuar até que você me pare?

Você pode dizer um número (ex: "tente 20 experimentos") ou "ilimitado" (executarei até que você interrompa).

Registre como MAX_EXPERIMENTS (número ou unlimited).

1.6 Critério de Simplicidade

Informe o usuário sobre a política padrão de simplicidade:

Política de simplicidade (padrão): Em igualdade de condições, o mais simples é melhor. Uma pequena melhoria que adiciona complexidade feia não vale a pena. Remover código mantendo ou melhorando a métrica é um ótimo resultado. Pesarei o custo da complexidade contra a magnitude da melhoria. Esta política funciona para você, ou você quer ajustá-la?

Registre quaisquer ajustes como SIMPLICITY_POLICY.

1.7 Confirmar Configuração

Resuma todos os parâmetros de volta para o usuário em uma tabela clara: