Flujo de Codex
¿Codex Consume Demasiados Tokens? Cómo Pruebo el Flujo de “Verificar al Final”
He observado que terminar un bloque coherente de cambios antes de ejecutar toda la suite puede reducir salidas repetidas. Es una hipótesis de trabajo, no un truco universal.
- Observado
- En cambios acotados y relacionados, una suite completa final pareció reducir idas y vueltas y logs duplicados.
- Verificado
- OpenAI documenta que la compactación reduce el contexto conservando el estado relevante.
- Límite
- No existe un porcentaje universal demostrado; modelo, razonamiento, repositorio, fallos y volumen de logs cambian el resultado.
Puntos clave
- Retrasar suites completas repetidas no significa omitir la verificación.
- La comparación debe medir llamadas, logs, retrabajo, tiempo y uso en condiciones iguales.
- La lógica de alto riesgo sigue necesitando pruebas dirigidas tempranas.
Dos ritmos de prueba
- 01Cambios relacionados
- 02Checks dirigidos
- 03Suite completa
- 04Registrar
Por qué medir el orden de las pruebas
Cada suite completa añade salida que el agente debe leer y mantener. Ejecutarla tras cada edición parcial puede repetir resultados correctos y avisos irrelevantes.
Con un criterio de aceptación claro, terminar el cambio coherente primero puede reducir llamadas, salida duplicada y diagnósticos de un estado deliberadamente incompleto.
Una comparación A/B reproducible
Usa tareas equivalentes o dos worktrees del mismo commit. Mantén modelo, razonamiento, instrucciones, dependencias y comandos de aceptación.
El flujo A ejecuta toda la suite tras cada cambio. El B conserva chequeos estáticos y pruebas dirigidas para riesgos, y ejecuta la misma suite completa al terminar.
- Registra tiempo y llamadas a herramientas.
- Cuenta ejecuciones y volumen de salida.
- Registra input, cached input y output cuando estén disponibles.
- Cuenta fallos y retrabajo.
La regla que uso ahora
Migraciones, autenticación, pagos, concurrencia y APIs compartidas requieren feedback dirigido temprano. Copy, componentes cercanos y tipos dentro de una función admiten mejor una suite final.
La instrucción correcta define el alcance, permite chequeos rápidos de riesgo y exige después todas las pruebas y el build hasta quedar en verde.
Cómo saber si realmente ahorra
Sentir más velocidad no demuestra menos tokens. Hay que mostrar juntos uso, tiempo, número de pruebas y retrabajo.
Si un defecto aparece tarde y abre una larga depuración, la ventaja desaparece. Mi conclusión es medir la frecuencia de pruebas como una variable, no vender una cifra.
Mi conclusión actual
El valor de la frase está en aclarar el límite de entrega antes de generar evidencia.
Hasta tener una muestra comparable, lo describiré como observación y no como porcentaje.