Si tu imagen de Codex sigue anclada en mayo de 2025, volver ahora puede resultar un poco desconcertante. Ya no parece el mismo tipo de producto.

En el anuncio de Codex del 16 de mayo de 2025, el planteamiento era muy claro: Codex era un agente de ingeniería de software basado en la nube. Ya era un cambio importante, pero el modelo mental con el que muchos desarrolladores se quedaron seguía siendo bastante sencillo. Le dabas trabajo, lo ejecutaba en la nube y regresaba con un resultado. El centro de gravedad seguía siendo la ejecución de tareas.

Eso ya no describe todo el producto. El cambio no consiste únicamente en que programe un poco mejor. El giro más importante es que Codex ha ido creciendo alrededor del workflow: terminal, IDE, aplicación de escritorio, skills, automations, varios agentes, worktrees y puntos de entrada persistentes. Cuando todas esas piezas aparecen juntas, Codex deja de sentirse como un agente puntual y empieza a parecerse más a una capa de entrada a un entorno de desarrollo.

Si eres desarrollador, o una de las muchas personas que hoy hacen alguna forma de vibe coding, esa diferencia importa. Cambia cómo utilizas la herramienta. Dejas de verla como algo que simplemente responde prompts y empiezas a tratarla como algo capaz de absorber progresivamente partes de tu forma de trabajar.

La cronología deja bastante claro el cambio

Creo que la mejor forma de verlo es dejar de buscar una única función espectacular y colocar en orden los hitos del producto.

• El 16 de mayo de 2025, OpenAI publicó Introducing Codex. El énfasis estaba en un agente de software en la nube capaz de asumir tareas de programación en un entorno aislado.
• El 15 de septiembre de 2025 llegó Introducing upgrades to Codex. Es ahí donde la experiencia empieza a verse mucho más unificada entre terminal, IDE, web y teléfono.
• El 2 de febrero de 2026, OpenAI publicó Introducing the Codex app. En ese momento la forma del producto queda mucho más clara: app, agentes en paralelo, worktrees, bandeja de tareas, skills y automations. Empieza a parecer menos una superficie de chat y más un centro de mando.
• El 4 de marzo de 2026 se añadió también soporte para Windows. La dirección multi-surface ya resulta difícil de ignorar.

Así que, si alguien dice que “el nuevo Codex añadió skills y funciones de app parecidas a plugins”, entiendo perfectamente a qué se refiere, pero aun así no lo describiría como un sistema clásico de plugins. Es más preciso decir que Codex está pasando de una experiencia centrada en un único agente a una capa de workflow de desarrollo más reutilizable, integrable y orquestable. El propio vocabulario de OpenAI está más cerca de Skills, Automations, superficies de aplicación e integración con IDE que de un marketplace tradicional de extensiones.

Los Skills son probablemente el cambio práctico más importante

Cuando se comparan herramientas de programación con IA, la conversación suele empezar por la potencia del modelo: calidad del código, latencia, si puede terminar una tarea de punta a punta. Todo eso importa, pero no es la parte que más me interesa aquí.

A largo plazo pesa más todo aquello que no quieres volver a explicar una y otra vez: reglas del repositorio, estándares de código, estilo de review, restricciones de despliegue, comprobaciones antes de operaciones arriesgadas o convenciones concretas del proyecto. En los flujos antiguos, gran parte de eso acababa dentro de prompts largos que se repetían en cada sesión, y nunca era especialmente estable.

Ahí es donde Skills cobra importancia. No es simplemente otra función añadida al modelo. Permite empaquetar una manera repetible de trabajar para poder volver a llamarla después. Para un equipo, significa capturar proceso en vez de tener que explicarlo una y otra vez. Para una persona, significa menos desperdicio de prompt y menos deriva.

Por eso mucha gente compara instintivamente la idea con plugins. La comparación tiene sentido hasta cierto punto. Un plugin clásico suele significar “instala una capacidad”. Un skill se parece más a “conserva un método”. No consiste solo en añadir un botón, sino en enseñar a la herramienta cómo espera trabajar un entorno concreto.

La diferencia importa a públicos distintos por razones distintas. Los desarrolladores quieren que la herramienta respete el repositorio y sus reglas en lugar de moverse libremente por él. Los usuarios de vibe coding están cansados de tener que reconstruir el mismo contexto desde cero en cada ejecución.

Pero quedarse solo con los Skills sería subestimar lo que ha cambiado. OpenAI ya dispone de una capa de plugins específica para Codex, y el planteamiento oficial es más concreto de lo que mucha gente espera. En la documentación de Codex Plugins, los plugins se describen como paquetes instalables para workflows reutilizables de Codex. Esa formulación importa. No se trata de “añadir una pequeña extensión y seguir”, sino de un modelo para distribuir formas repetibles de trabajar.

La captura ya da una pista bastante buena. El nuevo Codex ya no es simplemente “puedes escribir unos cuantos archivos de skill si quieres”. Ahora hay un directorio de plugins, superficies de instalación, categorías y entradas orientadas a workflows. Cuando GitHub, Slack, Linear, Figma, Netlify, Cloudflare y Sentry aparecen en un mismo directorio, el producto deja de parecer un chatbot de programación y empieza a parecer un entorno con distribución integrada.

Más importante todavía es lo que puede agrupar un plugin. Según la documentación, un plugin puede empaquetar tres capas distintas:

• skills
• apps, es decir, integraciones opcionales o mappings de conectores
• servidores MCP para herramientas o contexto compartido

Por eso sigo describiendo esto como un cambio hacia un entorno de desarrollo, no como una simple mejora del modelo. Una vez existen plugins, la reutilización deja de vivir únicamente dentro del prompt. Los equipos pueden empaquetar un workflow en lugar de explicarlo de nuevo. Una persona puede conservar el comportamiento de su toolchain y moverlo entre entornos en vez de reconstruirlo desde cero.

Los plugins convierten los skills en algo que realmente puedes distribuir

Esta es probablemente la parte más infravalorada de la actualización.

Antes, incluso un skill muy bueno solía quedarse en el ámbito personal. Podías saber dónde almacenarlo, cómo invocarlo y cómo reutilizarlo localmente, pero eso no lo hacía automáticamente fácil de descubrir o instalar para otra persona. La capa de plugins cambia eso.

La estructura oficial es bastante explícita. Un plugin mínimo empieza con .codex-plugin/plugin.json como punto de entrada. A partir de ahí, la raíz también puede incluir:

• skills/
• .app.json
• .mcp.json
• assets/

Es un diseño muy práctico para desarrolladores. Ya no compartes un prompt flotante escondido en una nota. Compartes un paquete con manifest, metadata, capacidades agrupadas, texto opcional para la superficie de instalación e incluso capturas. La documentación llega a campos como displayName, shortDescription, defaultPrompt, brandColor y screenshots. Eso indica que instalación y discovery ya se están tratando como superficies reales de producto, no como una idea vaga para el futuro.

Hay otro detalle útil: OpenAI no limita los plugins al directorio oficial. Codex puede leer marketplaces desde tres lugares:

• el directorio curado de OpenAI
• $REPO_ROOT/.agents/plugins/marketplace.json
• ~/.agents/plugins/marketplace.json

Esto importa más de lo que parece. Significa que puedes crear un marketplace local al repositorio para workflows de equipo, skills específicos del proyecto y bundles de conectores sin tener que esperar a que exista una historia pública completa de ecosistema. Para desarrolladores independientes y equipos pequeños, probablemente esa sea además la forma de valor más realista.

OpenAI incluso incluye un skill @plugin-creator para generar la estructura inicial de plugins locales. Me gusta ese detalle porque demuestra que la función ya está pensada para usarse, no solo para presentarse.

Hay otra señal oficial que merece la pena mencionar. En Introducing the Codex app, OpenAI afirma que el uso total de Codex se duplicó desde el lanzamiento de GPT-5.2-Codex a mediados de diciembre y que más de un millón de desarrolladores utilizaron Codex durante el último mes. Eso ayuda a entender por qué packaging y distribución importan de repente tanto. A esa escala, “escribe un buen prompt” deja de ser suficiente. Las capas de workflow reutilizables se convierten en infraestructura del producto.

La diferencia entre el Codex antiguo y el nuevo es, en el fondo, memoria de workflow

Mi lectura es bastante sencilla.

El Codex anterior se sentía como un agente en la nube muy capaz al que podías entregar trabajo. Era útil, a veces sorprendentemente útil, pero seguía comportándose como ayuda externa. Mucho contexto estaba ligado al momento. Cuando una tarea terminaba, a menudo había que empezar de nuevo la siguiente vez con instrucciones frescas.

El Codex más reciente parece apuntar a otra cosa. Sigue aceptando tareas, evidentemente, pero también empieza a aceptar reglas, superficies, rutinas y acciones recurrentes. Puedes moverte entre distintos puntos de entrada. Puedes conservar skills reutilizables. Puedes delegar trabajo repetitivo a automations. La forma general es mucho más persistente.

Para desarrolladores, eso reduce fricción de ingeniería. Pasas menos tiempo describiendo de nuevo el repositorio y más tiempo empujando trabajo real. Para quienes hacen vibe coding, la diferencia también se nota. Mucha gente no tenía problemas con las ideas, sino con tener que reconstruir el mismo setup en cada ejecución. La reutilización cambia esa dinámica.

Debajo de todo esto hay otro giro importante. Muchas experiencias anteriores de programación con IA se sentían como “modelo potente, entorno fino”. El nuevo Codex está intentando claramente mejorar la segunda mitad de esa frase. No solo quiere demostrar que puede escribir código; quiere demostrar que puede operar dentro de un ciclo de desarrollo más realista.

Es un cambio mucho mayor de lo que parece a primera vista.

Si ya habías usado Codex, hoy tiene sentido replantearlo

Yo miraría el Codex actual de otra manera.

No lo juzgaría solo por si es capaz de escribir una función o terminar una pequeña feature. Eso deja fuera el cambio de fondo. La pregunta más interesante es si puede absorber tus reglas de trabajo y seguir reduciendo el setup repetido.

Y si con “plugins” en realidad te refieres a “formas de ampliar o conectar workflows”, tiene más sentido mirar Skills, Automations, la integración con IDE y las superficies de la app que salir a buscar una tienda clásica de extensiones. La nueva dirección se parece más a una capa de integración que a un simple catálogo de plugins.

Después de leer la documentación oficial, iría incluso un paso más allá. El nuevo Codex ya no es simplemente “parecido a un sistema de plugins”. Ya dispone de un modelo real de empaquetado y marketplace. Simplemente no encaja uno a uno con la idea mental de una extensión de navegador o de VS Code. Se parece mucho más a bundles de workflow y paquetes de integración.

Por eso creo que este cambio importa tanto a desarrolladores como a usuarios de vibe coding. Lo interesante no es solo que Codex responda mejor. Es que está empezando a comportarse como un lugar donde el trabajo puede continuar. Y cuando eso ocurre, el valor deja de estar únicamente en una respuesta concreta y pasa a estar en la forma acumulativa en que la herramienta se adapta al proceso.

Ese es, para mí, el verdadero upgrade. No que escriba un poco más rápido, sino que cada vez conserve mejor cómo trabajas.