Uno de los patrones de uso más interesantes que he observado con Codex Plus no tiene tanto que ver con cómo redacto los prompts, sino con el momento en que los uso.
Cuando me queda solo el último 3–5 % de mi límite de 5 horas o semanal, ya no gasto ese margen en solicitudes pequeñas. Hago justo lo contrario. Aprovecho lo que queda para lanzar las tareas de ingeniería más grandes que puedo ejecutar en varios proyectos que ya dejé preparados.
Eso suele significar trabajos como migraciones completas a TypeScript, limpieza de ESLint en todo el repositorio, revisiones profundas de errores en bases de código enteras o grandes refactorizaciones que normalmente parecerían demasiado costosas para lanzar sin pensarlo mucho.
Lo que cambió mi forma de trabajar
La razón es sencilla: más de una vez he visto que Codex sigue trabajando incluso cuando el límite visible ya parece agotado. La sesión da la impresión de haber terminado, pero la tarea sigue avanzando y a veces incluso se completa.
No presento esto como una regla garantizada del producto. Estoy describiendo una experiencia repetida que me llamó lo bastante la atención como para cambiar mi comportamiento. Desde que detecté ese patrón, los últimos puntos porcentuales dejaron de parecerme algo que había que proteger. Empezaron a parecerme el mejor momento para activar el trabajo más costoso y de mayor impacto.
Cómo uso ahora ese tramo final
En lugar de gastar el final del límite en prompts seguros y baratos, ahora lo trato como una ventana de lanzamiento para operaciones de ingeniería intensivas, por ejemplo:
- migraciones completas a TypeScript
- limpieza de ESLint en todo el repositorio
- revisiones profundas de errores en bases de código grandes
- refactorizaciones estructurales de gran alcance
La clave es la preparación. Este enfoque funciona mejor cuando el proyecto ya está listo para ejecutarse y la tarea está bien definida. En ese punto, usar el margen restante en algo pequeño muchas veces se siente como desperdiciar el momento de mayor apalancamiento.
Por qué me parece importante
Herramientas como Codex Plus no solo dependen de su capacidad bruta. También importa cómo distribuyes el esfuerzo en el tiempo. Un cambio pequeño en el momento puede modificar mucho el valor práctico que obtienes del mismo límite.
En mi caso, esto cambió incluso la psicología del producto. Los últimos puntos ya no se sienten como el final de una sesión. Se sienten como el momento en que debo dejar de dudar y delegar la tarea más pesada que tenga sentido ejecutar.
A veces, sinceramente, da la sensación de que Codex sigue trabajando para mí incluso después de que el límite visible ya desapareció. No sé si es un caso límite deliberado o simplemente la forma en que algunas tareas terminan en la práctica, pero me ha resultado lo bastante útil como para organizar mi flujo de trabajo alrededor de ello.
Una idea práctica para otros desarrolladores
Si usas Codex Plus para ingeniería de software, puede valer la pena probar tu propio flujo de trabajo al final del límite en lugar de asumir que ese último porcentaje debe gastarse con extrema cautela. En mi caso, el enfoque contrario me ha funcionado mejor.
Me daría mucha curiosidad saber si otros desarrolladores han visto el mismo patrón, sobre todo al usar Codex para migraciones, limpieza de lint, revisiones amplias o refactorizaciones grandes en varios repositorios.