Técnicas avanzadas y optimización de velocidad: la lentitud no se debe al modelo, sino al desorden del contexto provisto
📚 Navegación de la serie: El artículo anterior 「30 Cómo elegir el modelo」 explicó la selección de modelos de lenguaje y la configuración de sus esfuerzos de razonamiento. Esta sección avanza en esa línea: una vez seleccionado el modelo, el factor que determina su productividad diaria es cómo gestiona el contexto de la conversación, los hilos de chat y la ejecución en paralelo de tareas. El siguiente artículo 「32 Migrar desde Claude Code」 guiará a los usuarios experimentados en la migración de sus flujos de trabajo.
Al final del artículo anterior mencioné que: en muchas ocasiones, las demoras no se deben a limitaciones del modelo, sino a la falta de estructuración en el contexto provisto. En esta sección analizaremos este tema a detalle.
Les comparto una experiencia propia. En marzo de 2025, al desarrollar una herramienta en Python, me encontré atascado durante una tarde entera intentando programar una función con Codex. Al revisar el historial de conversaciones mediante /status al final del día, comprobé que la tarea consumió 11 ciclos (turns) de interacción. Durante el proceso, el modelo modificó archivos incorrectos en dos ocasiones y "optimizó" de forma no solicitada archivos de configuración que no debía tocar. Al realizar la retrospectiva, el problema resultó evidente: no se debió a limitaciones de gpt-5.5, sino a que mi primera instrucción se limitó a "ayúdame a añadir una función de exportación", lo cual obligó a pasar los siguientes diez ciclos aclarando detalles del contexto que debí definir desde el inicio.
En la programación asistida por IA, la principal causa de demoras no es el tiempo de razonamiento del modelo, sino la necesidad de reescribir y corregir el código generado (rework). Si la instrucción inicial es ambigua, el modelo tomará un camino equivocado y usted deberá guiarlo de regreso, consumiendo ciclos adicionales y tiempo valioso. El modelo más ágil no supera los minutos ahorrados al obtener el código correcto en el primer intento.
Esta sección detalla seis prácticas concretas para estructurar sus requerimientos, optimizar las conversaciones y agilizar los tiempos de respuesta.
Al terminar de leer este artículo, obtendrás:
- Un criterio de velocidad contraintuitivo: evitar reescrituras de código > priorizar la velocidad bruta; obtener el código correcto en la primera iteración es la forma más efectiva de agilizar el desarrollo.
- La estructura de un requerimiento efectivo: Objetivo + Contexto + Restricciones + Criterios de Aceptación, incluyendo una tabla comparativa de ejemplos de prompts del tipo Antes/Después.
- Tres prácticas para administrar la ventana de contexto (context window): compactación con
/compact, inicio oportuno de nuevas conversaciones y asignación precisa de archivos mediante@en lugar de indexar todo el repositorio. - Criterios para reducir el esfuerzo del modelo según la complejidad de la tarea (complementando la selección de modelos del artículo anterior).
- Estrategias avanzadas para ejecutar tareas en paralelo y delegar la auto-validación de código en Codex.
- Un ejercicio práctico para reestructurar un requerimiento ambiguo bajo el esquema de cuatro secciones para reducir el margen de error.
⚠️ Los comandos, variables y comportamientos se contrastan con la documentación oficial de Codex. Los multiplicadores de créditos y el modo
/fastpueden variar según las actualizaciones del sistema.
01 Priorizar la precisión para evitar reescrituras de código
Antes de abordar las técnicas operativas, es necesario comprender el criterio principal de optimización.
Al buscar "acelerar el desarrollo", la primera reacción suele ser migrar a modelos más rápidos, reducir los niveles de esfuerzo de razonamiento o habilitar modos rápidos de procesamiento. Si bien estas opciones son útiles, constituyen aspectos secundarios. El factor determinante del tiempo total de desarrollo es la reducción de ciclos de reescritura.
Analogía: La preparación de una receta de cocina. Si el proceso se demora, rara vez se debe a que la potencia de la estufa sea baja. En la mayoría de los casos, se debe a que a mitad de la preparación nota que le falta un ingrediente, agregó sal en exceso y debe empezar de nuevo, o leyó incorrectamente los pasos de la receta. La repetición de tareas es lo que consume el tiempo, no la potencia de la estufa. Aumentar el fuego no salvará el platillo de un cocinero que debe rehacer la preparación constantemente.
En el desarrollo asistido por IA ocurre lo mismo. Si Codex toma una ruta de diseño incorrecta, modifica un archivo equivocado o malinterpreta su instrucción, guiarlo de regreso requiere un costo en tiempo y tokens que supera con creces los segundos que el modelo tarda en razonar la respuesta inicial.
La documentación oficial señala que el rendimiento y la calidad del código de Codex aumentan significativamente cuando el sistema dispone de mecanismos para validar su propio trabajo. Esto significa que garantizar que el modelo avance en la dirección correcta es más prioritario que acelerar la generación de respuestas.
Les comparto otro caso de estudio personal. Solicité al sistema "optimiza esta función" sin detallar qué optimizar, qué librerías no alterar o qué comportamiento validar. El modelo reescribió la función modificando la firma de la interfaz, provocando fallos en cascada en tres módulos que la consumían. Tardé veinte minutos en revertir los cambios y corregir el código. A partir de ese momento establecí la regla de no enviar requerimientos ambiguos como 'optimiza esto', obligándome a detallar las pautas de diseño.
Comparación de enfoques de velocidad:
| Enfoque ineficaz | Enfoque optimizado |
|---|---|
| ❌ Forzar el uso del modelo rápido para todas las tareas | ✅ Detallar el requerimiento en la primera instrucción para evitar ciclos correctivos |
| ❌ Desactivar el razonamiento para obtener respuestas rápidas | ✅ Ajustar el esfuerzo de razonamiento según la complejidad técnica (ver artículo anterior) |
| ❌ Indexar todo el repositorio en la consulta | ✅ Declarar explícitamente los archivos relevantes usando @ |
| ❌ Mantener una única sesión de chat para todas las tareas | ✅ Iniciar un chat limpio para cada tarea independiente o compactar el historial |
| ❌ Revisar visualmente cada línea modificada por el modelo | ✅ Definir criterios de aceptación y ordenar la ejecución de pruebas automáticas |
💡 Resumen en una frase: La mayor causa de demoras en la programación asistida es la reescritura de código; la regla de oro para optimizar el tiempo es asegurar la precisión en el primer intento.
02 La estructura de un requerimiento efectivo: la regla de las cuatro secciones
Establecido que la precisión es prioritaria, ¿cómo evitamos que Codex deba interpretar las instrucciones a partir de datos incompletos? La respuesta consiste en estructurar el prompt inicial para evitar ambigüedades.
Analogía: Indicar las especificaciones de entrega a un mensajero. Si solicita "tráeme comida", el mensajero elegirá según su propio criterio, lo cual puede no coincidir con sus preferencias. Si especifica "tráeme una porción de arroz salteado, sin cebolla, bajo en sal y de tal restaurante", la entrega se ajustará a su requerimiento en el primer viaje. Con Codex ocurre lo mismo: cada detalle omitido obliga al modelo a tomar decisiones de diseño por su cuenta, incrementando el riesgo de errores.
La documentación oficial recomienda estructurar los prompts incorporando cuatro secciones clave:
- Objetivo (Goal): qué funcionalidad desea implementar, modificar o corregir.
- Contexto (Context): qué archivos, APIs, documentación o registros de error son relevantes. Utilice
@para adjuntar los archivos correspondientes. - Restricciones (Constraints): qué librerías no usar, qué convenciones de código respetar o qué archivos no alterar.
- Criterios de Aceptación (Done when): qué comportamiento define que la tarea ha finalizado con éxito (ej. pruebas unitarias aprobadas, comportamiento específico validado).
Si bien no es necesario desarrollar extensamente cada sección en tareas menores, declarar el objetivo y los criterios de aceptación es indispensable.
Ejemplos de prompts del tipo Antes/Después:
| ❌ Antes (Ambiguo, genera errores) | ✅ Después (Estructurado, reduce ciclos correctivos) |
|---|---|
| Añade una función de exportación al proyecto | Objetivo: Implementar una función en report.py para exportar datos en formato CSV. Contexto: Tomar como referencia la estructura del exportador de JSON en @export/json_export.py. Restricciones: Reutilizar la clase de datos Report sin modificar su firma ni sus propiedades. Criterios de Aceptación: La función debe exportar las columnas con sus encabezados y la prueba unitaria en tests/test_export.py debe aprobarse sin fallos. |
| El rendimiento de esta función es bajo, optimízala | Objetivo: Reducir el tiempo de ejecución de la función search() de 2 segundos a menos de 200 ms bajo cargas de 10,000 registros. Contexto: La función se encuentra en @core/search.py. Restricciones: No modificar la firma de la función ni la estructura del objeto de retorno. Criterios de Aceptación: Ejecutar la prueba de rendimiento mediante pytest tests/test_search.py::test_perf y validar que el tiempo reportado sea inferior a 0.2 segundos. |
| Corrige el bug del login | Objetivo: Resolver el redireccionamiento a pantalla en blanco después de que el usuario inicia sesión. Contexto: El flujo de autenticación es "credenciales válidas → clic en login → redirección a blanco"; código relevante en @auth/login.py. Restricciones: No alterar el middleware de validación de tokens. Criterios de Aceptación: Validar manualmente que tras el inicio de sesión se muestre el dashboard principal. |
La estructuración del prompt en el formato "Después" reduce las interacciones necesarias para completar la tarea, disminuyendo el tiempo total de desarrollo en comparación con prompts cortos que requieren múltiples aclaraciones de diseño.
Si el requerimiento es complejo y no tiene claras las pautas de diseño iniciales, inicie la tarea en modo planificación (Plan mode) (usando /plan en la CLI o mediante el atajo Shift+Tab). En este modo, Codex analizará el proyecto, le formulará preguntas de aclaración y diseñará el plan de trabajo para su validación antes de proceder a modificar el código.
💡 Resumen en una frase: Un prompt estructurado contiene Objetivo, Contexto, Restricciones y Criterios de Aceptación, evitando que el modelo deba asumir pautas de diseño que generen errores en el código.
03 Administración de la ventana de contexto: alimentar con precisión
Una vez estructurado el prompt, el siguiente paso es acotar la información que el modelo leerá del repositorio. Consiste en proveer toda la información relevante y excluir los datos no asociados al requerimiento.
La ventana de contexto (context window) representa la capacidad máxima de información que el modelo puede retener y procesar en una conversación (thread). Si el historial o los archivos cargados superan este límite, el sistema comprimirá u omitirá información antigua, reduciendo la precisión de sus respuestas.
Analogía: El espacio de trabajo en su escritorio. Si coloca únicamente los planos de la sección que está reparando, podrá analizarlos de forma ordenada; si vacía los archivadores con toda la documentación histórica de la empresa sobre la mesa, dificultará la búsqueda de los planos específicos y aumentará el riesgo de confusión. La ventana de contexto funciona de la misma forma: a mayor cantidad de datos irrelevantes, mayor es la distracción del modelo.
Prácticas recomendadas para administrar la ventana de contexto:
1. Usar el direccionamiento preciso con @. declare de forma explícita los archivos de código que el modelo debe analizar usando @. Esto evita que el agente deba ejecutar búsquedas generales en todo el repositorio, agilizando el procesamiento y manteniendo limpia la ventana de contexto.
2. Implementar la compactación con /compact. En conversaciones prolongadas donde se han abordado múltiples enfoques, ejecute el comando /compact para que Codex resuma los acuerdos e interacciones anteriores, liberando espacio en la ventana de contexto para continuar el desarrollo.
3. Iniciar un chat limpio para cada tarea independiente. Evite utilizar un único chat para desarrollar múltiples requerimientos a lo largo del día. La documentación oficial desaconseja el uso de "un chat por proyecto", recomendando en su lugar "un chat por tarea".
Comandos útiles de gestión de contexto en la CLI:
/compact Resume el historial de la conversación actual para liberar espacio de contexto.
/status Muestra el estado de la sesión, indicando el consumo actual de la ventana de contexto.
/fork Crea una nueva ramificación de la sesión actual, conservando el historial previo en un chat nuevo.
/resume Retoma una conversación registrada en el historial mediante su identificador.Regla de decisión: si el trabajo actual es la continuación lógica de la tarea anterior, mantenga la sesión activa; si inicia un requerimiento independiente, cree una nueva conversación o use /fork si comparte parte del contexto. Esta separación evita saturar la ventana de contexto con requerimientos resueltos.
💡 Resumen en una frase: Gestione la ventana de contexto cargando archivos específicos con
@, compactando el historial largo con/compacte iniciando una sesión limpia para cada tarea independiente.
04 Ajustar el esfuerzo según la complejidad del requerimiento
Complementando las directrices de selección de modelos del artículo anterior, aplique los niveles de esfuerzo de razonamiento de forma proporcional a la tarea para optimizar el tiempo de respuesta:
- Tareas directas y acotadas: use el nivel de esfuerzo
low(o inferior) para agilizar la respuesta en ediciones simples. - Modificaciones de lógica estándar y adición de funciones: use el nivel predeterminado
medium. - Análisis de arquitectura, refactorizaciones complejas o depuración: eleve el esfuerzo a
highoxhighpara priorizar la precisión del diseño.
Para tareas sencillas como renombrar variables o estructurar documentación, configure el modelo ligero gpt-5.4-mini con un esfuerzo de razonamiento low para obtener respuestas casi inmediatas y optimizar el consumo de créditos.
05 Ejecución de tareas en paralelo y delegación de validación
Una vez optimizada la sesión individual, incorpore la ejecución en paralelo para agilizar el desarrollo general:
Evite esperar a que Codex termine una tarea prolongada antes de continuar su trabajo; ejecute procesos en segundo plano.
Para evitar que los procesos en segundo plano interfieran con su área de trabajo activa, implemente la separación mediante git worktrees (explicada en el artículo [25]), asignando un directorio temporal aislado para cada tarea en segundo plano.
Estructura de paralelismo recomendada:
| Método | Aislamiento | Propósito |
|---|---|---|
| Multitarea simultánea | Un directorio git worktree independiente por cada tarea en ejecución | Ejecutar modificaciones concurrentes en el repositorio sin conflictos |
| Subagentes (subagents) | El agente principal delega tareas de exploración o pruebas a subagentes | Evitar que la sesión principal se detenga por tareas secundarias (ver artículo 21) |
La recomendación oficial para subagentes consiste en: mantener al agente principal enfocado en la lógica del requerimiento principal y delegar tareas acotadas de investigación, generación de pruebas unitarias o validación sintáctica a subagentes secundarios.
Un flujo de trabajo optimizado consiste en: desarrollar la lógica en su sesión principal mientras un subagente en segundo plano (en un directorio worktree aislado) ejecuta las pruebas unitarias y el linter para comprobar la consistencia del código.
Delegar la auto-validación de código
Para reducir el tiempo invertido en revisiones manuales, instruya a Codex para que valide su propio entregable antes de dar por terminada la tarea.
Declare los criterios de aceptación de forma explícita en su prompt o en el archivo de reglas AGENTS.md (como se describió en el artículo [11]), ordenando la ejecución de las siguientes pruebas de consistencia:
- Escribir o actualizar las pruebas unitarias correspondientes a los cambios.
- Ejecutar el comando del test runner del proyecto.
- Ejecutar el linter, formateador o verificador de tipos (TypeScript, etc.).
- Comparar las diferencias del código generado (diff) frente a la versión base para identificar posibles regresiones.
Puede ejecutar el comando /review local para realizar auditorías sintácticas de los cambios sin confirmar antes de integrarlos.
Incluir en su prompt la instrucción: "ejecuta las pruebas unitarias al terminar y notifícame únicamente cuando el resultado sea exitoso" evita ciclos manuales de corrección del tipo "el desarrollador ejecuta las pruebas → fallan → solicita corrección a Codex → Codex aplica cambios → el desarrollador vuelve a ejecutar las pruebas". Al delegar este ciclo en el agente, este corregirá los fallos de compilación internamente antes de reportar la solución terminada.
💡 Resumen en una frase: Optimice su tiempo ejecutando tareas en segundo plano mediante worktrees, delegando tareas secundarias a subagentes y ordenando al agente ejecutar las pruebas y linter de forma autónoma antes de entregar los resultados.
06 El modo rápido de Codex
Codex ofrece un modo rápido (Fast mode) que acelera el procesamiento de los modelos compatibles aproximadamente un 50% mediante una asignación de recursos prioritaria, a cambio de una tasa de consumo de créditos superior.
Para verificar y gestionar el estado del modo rápido desde la CLI, utilice los siguientes comandos:
/fast on Activa el modo rápido de procesamiento.
/fast off Desactiva el modo rápido.
/fast status Muestra el estado actual del modo rápido en la sesión.Para activar de forma permanente el modo rápido en su entorno local, declare las siguientes propiedades en su archivo ~/.codex/config.toml:
service_tier = "fast"
[features]
fast_mode = trueAspectos a considerar:
- El modo rápido está disponible para inicios de sesión a través de cuentas de ChatGPT; no se encuentra habilitado para accesos directos de API key (los cuales se rigen por los esquemas de tarificación estándar de la API de OpenAI).
- Esta opción representa una optimización de velocidad de procesamiento; se aconseja implementar primero las prácticas de estructuración de contexto y reducción de reescrituras antes de valorar el costo adicional de este modo.
07 Ejercicio práctico: Reestructurar un prompt ambiguo
Realizaremos un ejercicio práctico para evaluar la reducción de ciclos correctivos al estructurar una solicitud de desarrollo.
Requisitos: contar con Codex instalado y configurado en un repositorio Git de pruebas.
Paso 1: Evaluar un prompt ambiguo
Inicie una sesión limpia y envíe una solicitud vaga como la siguiente:
Añade un sistema de registro de logs a este proyecto.Resultado esperado: Codex probablemente responderá con preguntas sobre qué niveles de logs configurar, qué librería utilizar o dónde almacenar los archivos de log; o implementará una solución genérica que podría no ajustarse a la estructura de su proyecto. Registre la cantidad de interacciones requeridas para obtener una respuesta funcional.
Paso 2: Estructurar la misma solicitud bajo la regla de las cuatro secciones
Inicie una sesión de chat limpia para borrar el historial anterior. Envíe el requerimiento estructurado de la siguiente forma:
Objetivo: Implementar un sistema de registro de logs centralizado que exporte mensajes de nivel INFO y ERROR a la consola y a un archivo local en logs/app.log.
Contexto: Tomar como referencia el lector de configuraciones del archivo @utils/config.py para definir la ruta de logs.
Restricciones: Utilizar únicamente la librería estándar de Python `logging` sin agregar dependencias externas; no alterar las firmas de las funciones existentes.
Criterios de Aceptación: Validar la exportación del archivo logs/app.log tras invocar el inicializador en el archivo main.Resultado esperado: Codex identificará las pautas del diseño directamente (librería estándar, niveles de logs, ruta de configuración y criterios de éxito), escribiendo y configurando el código de forma alineada en la primera respuesta. El flujo de desarrollo se reduce habitualmente a 1 o 2 interacciones, eliminando las consultas de diseño intermedias.
Este ejercicio demuestra cómo estructurar los prompts reduce las iteraciones necesarias para implementar código en sus tareas de desarrollo.
💡 Resumen en una frase: La práctica de optimización de prompts consiste en: evaluar el comportamiento del modelo ante una instrucción vaga → iniciar un chat limpio → estructurar la misma instrucción definiendo Objetivo, Contexto, Restricciones y Criterios de Aceptación → comprobar la reducción de interacciones necesarias para obtener el código final.
Resumen
En este artículo hemos analizado estrategias para optimizar la velocidad de desarrollo y reducir las reescrituras de código en Codex:
- La precisión es prioritaria: evitar las reescrituras de código mediante prompts claros es el factor con mayor impacto en el tiempo de desarrollo.
- Estructura del prompt: aplique las secciones de Objetivo, Contexto, Restricciones y Criterios de Aceptación para evitar que el modelo deba asumir pautas de diseño.
- Ajustar el contexto: use
@para referenciar archivos específicos, libere espacio de la ventana de contexto con/compacte inicie chats nuevos por cada tarea. - Automatizar validaciones: ordene al agente ejecutar pruebas unitarias y linter antes de entregar los resultados para evitar ciclos de depuración manuales.
- Paralelismo: implemente git worktrees para ejecutar tareas en segundo plano y subagentes para delegar procesos de exploración de código.
La adopción de estas pautas reduce el tiempo de desarrollo total al evitar interpretaciones erróneas y ciclos correctivos del código generado.
El siguiente artículo 32 · Migrar desde Claude Code: explicaremos la transición al entorno de Codex para desarrolladores con experiencia previa en el uso de Claude Code, detallando las equivalencias de comandos, archivos de configuración de agentes y flujos de trabajo.