Um dos padrões de uso mais interessantes que percebi no Codex Plus tem menos a ver com a forma de escrever prompts e mais com o momento em que eles são usados.
Quando chego aos últimos 3–5% do meu limite de 5 horas ou do limite semanal, deixo de gastar esse resto com pedidos pequenos. Faço justamente o contrário. Uso a capacidade restante para disparar as maiores tarefas de engenharia que consigo colocar em andamento em vários projetos já preparados.
Normalmente isso significa trabalhos como migrações completas para TypeScript, limpeza de ESLint em todo o repositório, revisões profundas de bugs em codebases inteiras ou grandes refatorações que, em condições normais, pareceriam caras demais para acionar de forma casual.
O que mudou meu workflow
O motivo é simples: mais de uma vez eu vi o Codex continuar trabalhando mesmo depois de o limite visível parecer esgotado. A sessão parece ter acabado, mas a tarefa continua avançando e às vezes chega até o fim.
Não estou apresentando isso como uma regra garantida do produto. Estou apenas descrevendo uma experiência recorrente que foi marcante o suficiente para mudar meu comportamento. Depois que notei esse padrão, os últimos pontos percentuais deixaram de parecer algo a ser preservado. Passaram a parecer o melhor momento para iniciar o trabalho mais caro e de maior impacto.
Como eu uso essa reta final hoje
Em vez de gastar o final do limite com prompts seguros e baratos, agora trato esse momento como uma janela de lançamento para operações de engenharia pesadas, como:
- migrações completas para TypeScript
- limpeza de ESLint em todo o repositório
- revisões profundas de bugs em codebases grandes
- grandes refatorações estruturais
A chave está na preparação. Esse workflow é mais útil quando o projeto já está pronto para execução e a tarefa foi claramente definida. Nesse ponto, usar o restante do limite em algo pequeno muitas vezes parece desperdiçar o momento de maior alavancagem.
Por que isso me parece importante
Ferramentas como o Codex Plus não são apenas sobre capacidade bruta. Também importa como você distribui o esforço no tempo. Uma pequena mudança de timing pode alterar bastante o valor prático que você extrai do mesmo limite.
No meu caso, isso mudou até a psicologia do produto. Os últimos poucos por cento deixaram de parecer o fim da sessão. Passaram a parecer o momento em que eu devo parar de hesitar e entregar à ferramenta a tarefa mais pesada que faça sentido iniciar.
Às vezes, sinceramente, parece que o Codex continua trabalhando por mim mesmo depois que o limite visível some. Não sei se isso é um caso de borda intencional ou simplesmente a forma como algumas tarefas se concluem na prática. O que sei é que isso foi útil o bastante para eu passar a organizar meu workflow em torno dessa observação.
Uma conclusão prática para desenvolvedores
Se você usa Codex Plus para engenharia de software, talvez valha a pena testar o seu próprio workflow de fim de limite em vez de assumir que os últimos poucos por cento devem ser usados de forma conservadora. No meu caso, a abordagem oposta foi mais eficaz.
Fico realmente curioso para saber se outros desenvolvedores perceberam o mesmo padrão, especialmente em migrações, limpeza de lint, revisões amplas ou grandes refatorações em vários repositórios.