Fluxo do Codex
Codex Gastando Tokens Demais? Como Testo o Fluxo de “Verificar no Final”
Observei que concluir um conjunto coerente de alterações antes de rodar toda a suíte pode reduzir saídas repetidas. É uma hipótese de fluxo, não um truque universal.
- Observado
- Em alterações delimitadas e relacionadas, uma suíte completa final pareceu reduzir idas e vindas e logs repetidos.
- Verificado
- A OpenAI documenta que a compactação reduz o contexto preservando o estado relevante.
- Limite
- Não há percentual universal comprovado; modelo, raciocínio, repositório, falhas e volume de logs mudam o resultado.
Pontos principais
- Adiar suítes completas repetidas não significa pular a verificação.
- A comparação precisa medir chamadas, logs, retrabalho, tempo e uso nas mesmas condições.
- Lógica de alto risco ainda precisa de testes direcionados cedo.
Dois ritmos de teste
- 01Mudanças relacionadas
- 02Checagens
- 03Suíte completa
- 04Registrar
Por que medir a ordem dos testes
Cada suíte completa adiciona saída que o agente precisa ler e carregar. Rodá-la após toda edição parcial pode repetir resultados corretos e avisos irrelevantes.
Com o critério de aceitação claro, concluir a alteração coerente primeiro pode reduzir chamadas, saída duplicada e diagnósticos de um estado intencionalmente incompleto.
Uma comparação A/B reproduzível
Use tarefas equivalentes ou dois worktrees do mesmo commit. Mantenha modelo, raciocínio, instruções, dependências e comandos de aceitação.
O fluxo A roda a suíte completa após cada mudança. O B mantém verificações estáticas e testes direcionados para riscos, rodando a mesma suíte ao final.
- Registre tempo e chamadas de ferramentas.
- Conte execuções e volume de saída.
- Registre input, cached input e output quando disponíveis.
- Conte falhas e retrabalho.
A regra que uso hoje
Migrações, autenticação, pagamentos, concorrência e APIs compartilhadas pedem feedback direcionado cedo. Copy, componentes próximos e tipos dentro de uma função aceitam melhor uma suíte final.
A instrução correta define o escopo, permite checagens rápidas de risco e exige depois testes completos e build até tudo passar.
Como saber se houve economia
Parecer mais rápido não prova menos tokens. Uso, tempo, quantidade de testes e retrabalho precisam aparecer juntos.
Se um defeito surgir tarde e exigir depuração longa, o ganho some. Minha conclusão é medir a frequência de testes como variável, não vender um número.
Minha conclusão atual
O valor da frase está em esclarecer o limite da entrega antes de produzir evidência.
Até ter amostras comparáveis, vou chamar isso de observação, não de percentual.