IA 360
Actualidad

OpenAI lanza Codex, su agente de programación en la nube

OpenAI presenta Codex, un agente basado en codex-1 (una versión de o3 afinada para ingeniería de software) que trabaja en paralelo en entornos aislados, corrige errores y propone pull requests listos para revisión.

7 min de lectura Generado con IA Read in English
OpenAI lanza Codex, su agente de programación en la nube

Representación conceptual de la interfaz de Codex en ChatGPT, mostrando varias tareas de programación ejecutándose en paralelo dentro de entornos aislados en la nube

Un agente asíncrono, no un programador autónomo

OpenAI presentó Codex el 16 de mayo de 2025 como vista previa de investigación: un agente de ingeniería de software en la nube capaz de procesar varias tareas en paralelo. El acceso inicial era para ChatGPT Pro, Business y Enterprise; Plus y Edu figuraban como próximos.

Codex recibe una tarea —escribir una función, corregir un error o responder sobre un repositorio— y trabaja de forma asíncrona en su entorno. Eso reduce la supervisión continua, pero no garantiza que complete el encargo de principio a fin: OpenAI reconoce fallos e incertidumbre y exige revisión humana antes de integrar o ejecutar el código.

Cómo funciona en la práctica

Según explica OpenAI, cada tarea que se asigna a Codex se procesa en un entorno aislado ("sandbox") en la nube, precargado con el repositorio del usuario. Desde la barra lateral de ChatGPT, basta con escribir una instrucción y pulsar "Code" para que el agente se ponga a trabajar, o "Ask" si lo que se quiere es simplemente una pregunta sobre el código existente.

Dentro de ese entorno, Codex puede leer y editar archivos y ejecutar pruebas, linters y verificadores de tipos. El anuncio sitúa la duración típica entre 1 y 30 minutos, según complejidad, con progreso visible en tiempo real. «Típica» no establece un máximo ni una tasa de éxito.

Una vez terminado el trabajo, Codex confirma ("commit") los cambios en su propio entorno y aporta lo que OpenAI llama "evidencia verificable": citas de los registros de terminal y de los resultados de las pruebas, de modo que el usuario pueda rastrear cada paso dado durante la tarea. A partir de ahí, el desarrollador puede revisar el resultado, pedir cambios adicionales, abrir directamente una pull request en GitHub o integrar el código en su entorno local.

OpenAI también ha introducido los archivos AGENTS.md, un formato similar a los README que permite indicarle a Codex cómo moverse por un repositorio concreto, qué comandos usar para las pruebas y qué convenciones sigue el proyecto. La compañía añade que el agente funciona mejor con entornos configurados, pruebas fiables y documentación clara: el repositorio y sus controles forman parte del sistema que se evalúa.

Las cifras de programación también llevan condiciones. OpenAI excluyó 23 muestras de SWE-bench Verified que no pudo ejecutar en su infraestructura y probó codex-1 con un contexto máximo de 192.000 tokens y esfuerzo de razonamiento medio. Su benchmark interno de ingeniería es una selección curada de tareas reales de OpenAI. Ninguno de esos resultados equivale a una tasa universal sobre cualquier repositorio.

El modelo detrás: codex-1

Codex funciona con codex-1, una versión de OpenAI o3 optimizada para ingeniería de software. Según el addendum de seguridad, se entrenó con aprendizaje por refuerzo sobre tareas de programación en distintos entornos para seguir instrucciones, aproximarse a preferencias de estilo y ejecutar pruebas iterativamente. Alcanzar una prueba en verde no equivale a obtener un resultado correcto: la propia ficha contempla código defectuoso o inseguro y falsas declaraciones de tarea completada.

OpenAI dice que un objetivo del entrenamiento fue aproximar las salidas a preferencias humanas de código y que, frente a o3, codex-1 produce parches más limpios para revisión. «Listo para revisión» es la expresión operativa: no significa listo para integración inmediata. Pruebas, revisión del diff y validación en el entorno real siguen siendo controles separados.

Seguridad y ejecución aislada

OpenAI dedica una parte del informe a un agente que escribe y ejecuta código con iniciativa limitada por un contenedor aislado. La ficha completa aclara la secuencia: el contenedor usa red durante la fase de configuración para clonar el repositorio e instalar dependencias; cuando codex-1 toma el control, la red queda deshabilitada. El aislamiento reduce exposición y exfiltración, pero no impide errores dentro de los archivos accesibles.

La frontera de seguridad empieza, por tanto, después de preparar el entorno. El usuario define dependencias, configuración y herramientas antes de la trayectoria del modelo. Desactivar la red durante la ejecución limita conexiones nuevas; no certifica la integridad de lo que ya entró mediante el repositorio o el script de configuración.

Para el riesgo de malware, OpenAI entrenó rechazos y evaluó un conjunto sintético y otro curado por expertos internos. Informa de tasas de rechazo de 0,97 y 0,98, respectivamente; son resultados del fabricante y no «identificación precisa» garantizada para cualquier solicitud. El reto es conservar tareas legítimas de doble uso, como ingeniería de kernel, sin abrir la puerta a daño.

Aun con estas salvaguardas, OpenAI insiste en un punto: sigue siendo esencial que los usuarios revisen y validen manualmente todo el código generado por el agente antes de integrarlo o ejecutarlo.

Quién ya lo está usando

Según OpenAI, equipos técnicos de la propia compañía han empezado a usar Codex en su trabajo diario, sobre todo para tareas repetitivas y bien delimitadas —refactorizar código, renombrar elementos, escribir pruebas— que de otro modo interrumpen la concentración. También resulta útil, señala la empresa, para montar el esqueleto de nuevas funciones, conectar componentes, corregir errores y redactar documentación.

El anuncio recoge casos de un grupo reducido de probadores elegidos por OpenAI. Cisco evaluaba ideas; Temporal mencionaba funciones, depuración, pruebas y refactorización; Superhuman, tareas repetitivas; y Kodiak, herramientas de depuración y comprensión de código. Son testimonios de adopción sin muestra comparativa, línea base o medición común publicada: muestran usos posibles, no una mejora de productividad cuantificada.

A partir de la experiencia de estos primeros probadores, OpenAI recomienda asignar tareas bien delimitadas a varios agentes de forma simultánea y experimentar con distintos tipos de tareas y formulaciones para explorar mejor las capacidades del modelo.

Una versión ligera para el terminal

Junto al lanzamiento de Codex, OpenAI recuerda que el mes anterior presentó Codex CLI, un agente de código ligero y de código abierto que se ejecuta en el terminal del usuario con modelos como o3 y o4-mini. El 16 de mayo anunció además una versión menor basada en o4-mini, optimizada para preguntas y ediciones de baja latencia. Era el modelo predeterminado de la CLI y estaba disponible en la API como codex-mini-latest; el nombre apuntaba a una instantánea que OpenAI actualizaría periódicamente, no a un modelo inmutable.

La CLI y el agente remoto compartían familia, pero no superficie. Una trabajaba en el entorno local e interactivo; el otro delegaba tareas a contenedores en la nube. Antes de comparar resultados hay que identificar modelo, fecha de la instantánea, entorno, herramientas y modo de interacción.

Qué cambia para quien programa

La diferencia respecto al autocompletado está en el grado de delegación: se encarga una tarea y se recibe un diff acompañado de los comandos y pruebas que el agente ejecutó. «Probado» significa que corrieron esas pruebas, no que la cobertura fuera suficiente ni que el cambio sea correcto. El trabajo se desplaza hacia definir el encargo, preparar el entorno, revisar evidencia y decidir qué integrar.

OpenAI enmarca el lanzamiento como una vista previa de investigación, no como un producto cerrado. El 16 de mayo el acceso global empezaba en Pro, Enterprise y Business; Plus y Edu figuraban como próximos. La compañía ofrecía uso amplio sin coste adicional durante unas semanas y anunciaba para después límites de uso y opciones de compra adicional, sin fijar todavía una tarifa estable en esa página.

La propia lista de límites define el producto real: no admitía imágenes para trabajo de interfaz, no permitía corregir el rumbo mientras una tarea estaba en marcha y delegar a un agente remoto podía ser más lento que editar de forma interactiva. Por eso la validación humana del código generado seguía siendo obligatoria antes de integrarlo o ejecutarlo.

Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.

Compartir este artículo

Este sitio web utiliza cookies para mejorar la experiencia de navegación. Política de cookies.

↑↓ navegar ↵ abrir esc cerrar