Responsable del producto de OpenAI Codex explica: ¿Cómo desarrollamos productos sin normas ni hoja de ruta?

“¡El interés y la autonomía son las cualidades más centrales y más importantes para la humanidad en la era de la AGI!”

Compilado y preparado por: Deep Tide TechFlow

Invitados: Alex, responsable de producto de Codex; Romain, experiencia de desarrolladores en Codex

Presentador: Peter Yang

Fuente del podcast: Peter Yang

Título original: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Fecha de emisión: 5 de abril de 2026

Resumen de puntos clave

Alex es el responsable de producto de Codex, y Romain se encarga de la experiencia de los desarrolladores. Me hicieron el favor, de manera poco común, de contarme en profundidad cómo funciona el equipo de Codex, incluyendo cómo usan Codex para construir productos y cómo publican productos sin las especificaciones tradicionales ni un roadmap. Alex también compartió algunas perspectivas únicas sobre el futuro de los gerentes de producto (PM) y los factores que de verdad importan en las contrataciones.

Resumen de ideas destacadas

Construcción en tiempo real y la “velocidad de pensamiento” de Codex Spark

• “Cuando quieres construir algo… puedes cambiar a un modo rápido e incluso a Codex Spark, y entonces obtienes esa velocidad de pensamiento tan loca para construir cualquier cosa. A la izquierda está GPT-5.4 y a la derecha está Codex Spark; en promedio puedes tener alrededor de 1200 datos (tokens) por segundo. Es una velocidad demasiado alocada.” ——Romain

Sobre documentación de especificaciones y el proceso de toma de decisiones

• “Siento que en el equipo de Codex escribimos documentos de especificaciones muy, muy poco. En realidad, creo que gran parte del trabajo consiste en hacer que las personas que están más cerca de la realidad tomen la mayor cantidad posible de decisiones; por eso solo escribimos especificaciones cuando el problema al final se convierte en algo que es muy difícil de meter en la cabeza de una sola persona.” ——Alex

Los límites profesionales se difuminan y la evolución del diseñador

• “Los diseñadores de nuestro equipo ahora escriben más código que los ingenieros hace seis meses. Ahora nuestro enfoque ya no es ‘¿se puede generar código o no?’, lo realmente importante es: qué decidimos hacer y cómo asegurarnos de que el producto tenga una alta calidad. Por eso, para características muy complejas, tiendo más a encontrar a un responsable sólido que las gestione, en lugar de hacer que un gerente de producto (PM) se encargue de materializar y mantener estos sistemas.” ——Alex

Filosofía de diseño de producto: que el modelo sea ‘invisible’

• “Somos muy cuidadosos al diseñar las funciones centrales, asegurándonos de que no se conviertan en un obstáculo entre el usuario y el modelo, sino en que el modelo sea más inteligente y termine automáticamente más tareas.” ——Alex
• “Y a partir de ahí, pensamos en cómo empacar el producto para usuarios avanzados de la forma más configurable posible, para que ellos mismos lo exploren y lo usen. Por ejemplo, ahora ya hay usuarios que implementaron sub-agents (subagentes).”——Romain

Filosofía de planificación: rechazar la ‘incómoda planificación a mitad de camino’

• “En OpenAI, o bien planificamos objetivos a corto plazo o bien planeamos objetivos a largo plazo, pero nunca hacemos planificación intermedia, porque la planificación a mitad de camino es demasiado compleja. La planificación a corto plazo normalmente significa objetivos para, como máximo, ocho semanas desde ahora; ocho semanas es el rango de tiempo más largo que podemos establecer. También formulamos visiones a largo plazo. Por ejemplo, podríamos imaginar el futuro un año después y suponer que para entonces el modelo será más inteligente; pero la planificación intermedia resulta algo incómoda. Suele tomar la forma de un roadmap de producto detallado, pero básicamente no tenemos algo así. Más bien, nos enfocamos en tareas concretas que pueden impulsarnos a alcanzar nuestros objetivos, combinando la visión a largo plazo.” ——Alex

Transformación de la interfaz impulsada por ‘delegación de agentes inteligentes’

• “La codificación se hará de una manera de ‘delegación agentica’ (agentic delegation). Te parecerá muy extraño: abrir varias pestañas en la terminal y hacer que funcionen durante varias horas es una forma de interacción bastante rara. Necesitamos una interfaz completamente nueva, y ese momento es justo el perfecto.” ——Romain

Desaparición de la escalera profesional y ‘colapso del stack de talento’

• “Esto casi hace que cada escalera tradicional de ascenso profesional empiece a volverse borrosa. En realidad, cada uno de nosotros es un ‘builder’; colaboramos todos juntos para construir. Si una startup tiene un PM y menos de unas 20 personas ingenieros, entonces podría ser una señal peligrosa. Interés y autonomía son las cualidades más centrales y más importantes para la humanidad en la era de la AGI.” ——Romain / Alex

Criterios de contratación: las obras ganan a los CV

• “Cuando alguien expresa su interés por unirse a nuestro equipo por mensajes privados, mi primera reacción es mirar si hay enlaces a trabajos. Si hay enlaces, siempre los abro para ver si realmente están construyendo algo. Prefiero entender sus ideas y lo que realmente construyeron. No tengo idea de en qué universidad fueron esos individuos.” ——Alex

Demostración en vivo: construir un juego en pocos segundos con Codex Spark

Presentador Peter: Estoy muy emocionado de presentar a Alex y Romain hoy. Vienen del equipo de Codex de OpenAI. Van a demostrar cómo construir la nueva funcionalidad de Codex, qué capacidades tiene Codex y cómo el equipo de Codex sigue publicando productos sin parar. ¿Quieren una demostración rápida de qué tipo de cosas se pueden construir realmente con un prompt de una sola vez (one-shot)?

Romain:

Claro. Permíteme compartir mi pantalla. Hay muchísimas cosas que podría mostrar, pero quizá una mirada rápida… por ejemplo, aquí está una app de iOS que he estado construyendo. Si quiero crear una nueva funcionalidad para esta app, puedo simplemente decir en voz alta: “Oye, ¿puedes agregar una nueva pantalla a la misión de regreso de la luna de NASA?” Luego envió ese prompt con GPT-5.4 y el modelo crea una pantalla nueva específicamente para esa APP.

Pero también tenemos un modelo de Codex Spark, que te ayuda a concebir y a iterar cualquier cosa en apenas unos segundos. Déjame mostrarte la diferencia en cómo responde rápidamente el modelo Spark. A la izquierda está GPT-5.4, a la derecha está Codex Spark. Luego, en promedio, puedes tener alrededor de 1200 tokens por segundo; es una velocidad demasiado loca. Así que cuando quieres construir algo, como un juego — justo antes de empezar esta conversación, en realidad fui a la app de Codex y con un prompt rápido creé un pequeño juego 2D, similar a Animal Crossing.

Cuando tengo las ideas claras, me encanta usar otra función en Codex: abrir Codex y hacer que la conversación se quede flotando en la parte superior de la pantalla, de modo que si de verdad estoy haciendo este juego, puedo seguir iterando y generando más ideas. ¿Qué ideas tienes, Peter, sobre qué cambiarías en este juego?

Peter: Quizás agregar más decoraciones, casas, árboles, cosas así, para que sea más vívido?

Romain:

Entonces enviaré esta tarea y, básicamente, en segundos Codex Spark puede editar. Veremos los cambios en tiempo real, y listo. Ya vimos aparecer los nuevos árboles.

Por eso estoy tan emocionado con Codex. Realmente puedes tener una velocidad de pensamiento tan loca para construir cualquier cosa: puedes tener un modelo de vanguardia como GPT-5.4, que puede encargarse de tareas muy complejas, como analizar o migrar millones de líneas de código. Pero cuando te aparece la inspiración y tienes claridad, puedes cambiar al modo rápido e incluso a Codex Spark, y entonces tienes esa velocidad de pensamiento loca para construir cualquier cosa.

Con respecto a las especificaciones de producto, escribimos solo como 10 puntos clave, y eso es todo

Presentador Peter: Realmente me da curiosidad cómo, en el equipo, usan Codex para construir productos. Alex, ¿ustedes también escriben especificaciones? ¿O hacen que GPT escriba una especificación? ¿Qué modelo usan para que todas estas cosas funcionen?

Alex:

Siento que en el equipo de Codex escribimos documentos de especificaciones muy, muy poco. En realidad, creo que gran parte del trabajo consiste en hacer que las personas más cercanas a la realidad tomen la mayor cantidad posible de decisiones, por eso solo escribimos especificaciones cuando al final el problema se convierte en algo que es muy difícil de meter en la cabeza de una sola persona.

Por cierto, ahora una persona puede meter muchas cosas en su cabeza, porque pueden hacer muchas cosas: delegan gran parte del trabajo de codificación, así que una sola persona puede hacer mucho. Pero si finalmente se convierte en algo que requiere coordinar a varias personas, o tal vez es una decisión muy difícil que debemos tomar, entonces quizá escribamos una especificación. Pero en estos casos, los documentos que escribimos suelen ser muy, muy cortos. Lo que decimos es algo como 10 puntos clave, y ya se acabó.

Presentador Peter: Bien. ¿Podrían mostrarme cómo funciona eso? Por ejemplo, tú le das a Codex unas cuantas líneas, unos cuantos puntos clave, y tal vez primero escribe requisitos reales.

Romain:

¡Claro que sí! Pero quiero mostrarte antes un ejemplo más sencillo. Supongamos que estamos desarrollando una app de iOS que ya completó algunas tareas. Ahora tú tienes ideas para nuevas funciones para ese proyecto, pero no estás seguro de la dirección específica. En ese momento, el poder de Codex es que nos ayuda a planificar el siguiente paso. Por ejemplo: solo necesito presionar Shift+Tab para entrar en el “modo de planificación” (Plan Mode) y luego ingresar “Qué queremos construir”. Codex automáticamente me generará un plan inicial. Analiza el código existente, entiende el estado actual del proyecto y propone algunas ideas potenciales. Al mismo tiempo, yo también puedo agregar mis propias ideas para guiar al modelo a generar un plan más completo.

Durante este proceso, verás que Codex proporciona sugerencias basadas en el código y los archivos actuales. Por ejemplo, podría preguntar: “¿Deberíamos seguir refinando la función mencionada antes? ¿O deberíamos optimizar el tablero de confiabilidad?” Si decidimos optimizar el tablero de confiabilidad, además nos guía para pensar: ¿cuál es el público objetivo de la optimización? Todo el proceso se siente como colaborar con un compañero de brainstorming.

A menudo uso este método para impulsar la generación de ideas. Por ejemplo, para algunos cambios simples, yo simplemente ingreso un prompt para que Codex genere el código.

Alex:

Y para cambios de una complejidad media, quizá le pida que genere un plan concreto, o que me ayude a razonar la forma de implementar. Y cuando tengo una idea vaga, normalmente simplemente abro Codex para que me ayude a pensar cómo resolver el problema. Incluso si no tengo requerimientos de función claros en mi cabeza, Codex puede ayudarme a aclarar mis ideas mediante preguntas y exploración.

Pero, para ser honesto, a veces no uso directamente las soluciones que genera Codex, especialmente cuando el cambio es bastante complejo. Yo exploro usando el “modo de planificación” de Codex, formo una idea clara y luego comparto esas ideas con el equipo de ingeniería. En última instancia, el proceso de pensamiento es más importante que el plan generado.

Por cierto, en nuestro equipo ahora los diseñadores escriben más código que los ingenieros hace seis meses; antes eso era impensable. Esto se debe principalmente al progreso de las herramientas, que permite que los diseñadores participen de manera más profunda en el desarrollo. Pero también me molestan con frecuencia en el equipo porque hay muy pocas PRs (solicitudes de pull/solicitudes de fusión de código) que presenté el año pasado. Aunque muchos cambios son solo pequeños ajustes, sí creo que debería hacer más.

Ahora, nuestro** enfoque ya no es “si podemos generar código”**, porque los agentes (Agent) ya pueden completar la mayor parte de las tareas de codificación; lo realmente importante es: qué decidimos hacer y cómo aseguramos la alta calidad del producto. Por eso, para características muy complejas, tiendo más a encontrar a un responsable sólido que las gestione, en lugar de dejar que un gerente de producto (PM) sea quien se encargue de materializar y mantener estos sistemas.

Los diseñadores escriben más código que los ingenieros hace 6 meses

**Presentador Peter: **La app de Codex se usa de forma muy intuitiva y sencilla. Comparada con algunos productos profesionales externos, siento que la curva de aprendizaje de Codex es mucho menor. Algunos otros productos profesionales son muy potentes, pero requieren mucho tiempo para aprender. Incluso pienso que, si no siguiera la información relevante en Twitter, probablemente ni sabría cómo usarlos.

Pero lo que me impresionó de Codex es que, además de ser fácil de usar, también ofrece muchas funciones avanzadas, como skills (habilidades) y automations (automatizaciones). ¿Con qué frecuencia usan ustedes estas funciones dentro de su equipo?**

Romain:

Sí, las usamos muchísimo. De hecho, creo que skills es una de las funciones más interesantes dentro de la app de Codex. Por ejemplo, ahora si estás usando Figma junto con un diseñador, solo necesitas abrir la skill de Figma y puedes extraer directamente todos los detalles de React components, variables, etc. del archivo de Figma, y Codex generará automáticamente el código correspondiente. Otro ejemplo: si estás desarrollando una app y quieres compartirla o desplegarla en Vercel, Cloudflare o Render, solo necesitas enviar una instrucción sencilla a través de skills, y Codex hace automáticamente esas tareas.

Hablé recientemente con un amigo. Me dijo que tenía muchas ideas para mejorar un producto. Entonces le dijo a Codex: “Escribe todas estas tareas en Linear para que pueda hacer seguimiento”. Usó la skill de Linear. Luego le dijo: “Me voy a dormir; sigue completando todas las tareas de las que hablamos y márcalas como completadas”. Resultado: al día siguiente, cuando se despertó, vio que realmente se habían completado todas las tareas.

Alex:

Sobre la simplicidad de la app de la que hablaste, creo que podemos compartir cómo pensamos en el diseño. En este campo, muchos desarrolladores se obsesionan con construir herramientas de automatización para simplificar el trabajo diario. Nosotros creemos que una característica clave del producto debe ser altamente configurable. Para Codex, es como una caja de herramientas de código abierto: los usuarios pueden meterse dentro y personalizarla según sus necesidades.

Cada vez que lanzamos una nueva función, siempre hay usuarios en Twitter que se quejan de que esa función tiene un problema (aunque todavía no se haya lanzado oficialmente). Y la causa suele ser que ellos mismos modificaron el código o lo forkearon. Pero, en mi opinión, esto en realidad demuestra que nuestro producto tiene éxito: esos usuarios adelantados están explorando el futuro con nosotros y empujando el progreso del producto.

Sin embargo, también nos dimos cuenta de que** construir productos solo para estos usuarios avanzados no es suficiente**; de lo contrario, el producto terminará siendo complejo y difícil de entender. Necesitamos encontrar un equilibrio: cubrir las necesidades de usuarios avanzados y, al mismo tiempo, que el producto sea simple e intuitivo para los usuarios comunes. Por eso** somos muy cuidadosos en el diseño de las funciones centrales, asegurándonos de que no se conviertan en un obstáculo entre el usuario y el modelo, sino en que el modelo sea más inteligente y complete automáticamente más tareas.**

Romain:

Y a partir de ahí, pensamos en cómo empacar el producto de la forma más configurable posible para usuarios avanzados, para que ellos mismos lo exploren y lo usen. Por ejemplo, ahora ya hay usuarios que implementaron sub-agents (subagentes). Estas funciones no las diseñamos activamente nosotros; las descubrieron y las experimentaron los usuarios. Al observar cómo usan estas funciones, aprendimos muchísimo.

Luego pensamos: ¿cómo hacer que estas funciones también se vuelvan súper simples para otros usuarios? La app de Codex es un gran ejemplo. Para cuando GPT-5.2 Codex se lanzó el mes pasado de diciembre del año pasado, y la habilidad del modelo empezó a estabilizarse de manera gradual, también cruzó un umbral. Los usuarios pudieron delegar tareas más largas y más complejas al modelo, y el modelo pudo completarlas de una sola vez.

Empezamos a notar que algunos usuarios ya usaban tmuxing, que es una forma de ejecutar múltiples tareas en paralelo en la terminal, dividiendo ventanas para ejecutar varias tareas al mismo tiempo. Vimos ejemplos muy interesantes en redes sociales, como una foto de Peter Steinberger donde su pantalla tenía 18 ventanas de terminal, repartidas en tres monitores, pareciendo una especie de “pata abierta de creatividad”. Nos emocionó ver a los usuarios usar Codex de formas tan avanzadas.

Al mismo tiempo, seguimos optimizando la delegación de tareas en el producto base, como el CLI, para que funcionara bien. Pero también nos dimos cuenta de que quizá solo el 1% superior de ingenieros usaría este modo de trabajo. Entonces nos preguntamos: ¿cómo hacer que estas funciones se vean más intuitivas? Por eso desarrollamos la app de Codex.

Cuando abres la app de Codex por primera vez, parece una ventana de chat simple. Puedes empezar a usarla directamente y funcionará bien. Pero con el tiempo, irás descubriendo más funciones: la barra lateral, la capacidad de ejecutar múltiples tareas y la facilidad para cambiar entre tareas. Sentirás que eres muchísimo más eficiente. Luego probablemente notarás la pestaña “skills” y entrarás para explorar más funciones.** Esperamos que, al usar la app de Codex, los usuarios tengan una experiencia casi como un juego: descubriendo posibilidades nuevas continuamente.**

Romain:

Estoy completamente de acuerdo. Y además, esa también era la visión que teníamos desde el principio: la codificación se hará de una manera de “delegación agentica” (agentic delegation). Incluso casi un año antes de que empezáramos a desarrollar Codex, ya pensábamos en ese futuro. Creemos que los ingenieros podrían manejar múltiples tareas a la vez, y que el modelo se encargaría de ejecutar los detalles complejos.

Pero, para ser honestos, en ese entonces las capacidades del modelo todavía no estaban a ese nivel. Tuvimos que esperar al lanzamiento de GPT-5.2 Codex y al umbral que vino después, para ver que el modelo funcionaba de manera muy exhaustiva y confiable durante horas e incluso días. Y en ese momento, de repente nos dimos cuenta de que las interfaces tradicionales de terminal ya no eran adecuadas para esa forma de trabajar. Te parecerá muy extraño: abrir múltiples pestañas en la terminal y hacer que funcionen durante horas es una forma de interacción bastante rara. Así que necesitamos una interfaz completamente nueva, y ese momento era justo el perfecto.

Alex:

Si miramos la evolución de Codex, vimos dos cambios importantes en el “vibe” (puntos de inflexión de tendencia). El primero fue en agosto del año pasado. Llevamos a cabo el lanzamiento del producto Codex Cloud. Fue una idea realmente genial; los usuarios estaban muy emocionados, pero quizá todavía era un poco pronto. Entonces, en agosto lanzamos GPT-5, un modelo de codificación interactivo realmente excelente, y decidimos enfocarnos en resolver los problemas que el modelo podía manejar en ese momento. Lanzamos Codex CLI y plugins de IDE, y la base de usuarios creció rápidamente entre 20 y 30 veces en cuestión de meses. Fue increíble.

El segundo punto de inflexión fue entre diciembre del año pasado y enero de este año. En ese momento, finalmente alcanzamos la visión inicial: delegar tareas al modelo. Las capacidades del modelo llegaron a un nuevo nivel, con capacidad para completar tareas más complejas de forma independiente. Eso marcó que entramos en una etapa completamente nueva.

Nuestra planificación se divide en corto y largo plazo, y nunca hacemos planificación intermedia

Presentador Peter: Tengo curiosidad: ¿cómo se desarrolló la app de Codex? ¿Ustedes hace un año ya habían definido algún roadmap anual, como “planeamos lanzar la app de Codex en algún momento”? O más bien, ¿miraban la demanda del mercado y prototipaban rápidamente algunas ideas?

Alex:

En realidad, no. Escuché una sugerencia genial de nuestro investigador Andre: en OpenAI, o planeamos objetivos a corto plazo o planeamos objetivos a largo plazo, pero no hacemos planificación intermedia porque la planificación intermedia es demasiado compleja.

La planificación a corto plazo normalmente se refiere a objetivos de un máximo de ocho semanas desde ahora. Ocho semanas es el rango de tiempo más largo que podemos establecer. Dentro de ese marco de tiempo, establecemos un objetivo concreto y reunimos al equipo para enfocarse plenamente en completarlo. Esta es una fortaleza de OpenAI: somos muy buenos organizando equipos alrededor de un objetivo claro.

Por otro lado, también formulamos una visión a largo plazo. Por ejemplo, podríamos imaginar el futuro un año después, suponiendo que para entonces el modelo será más inteligente. Por ejemplo, podríamos imaginarnos que los modelos futuros pueden trabajar de forma independiente, sin necesitar usar nuestros recursos informáticos, y ya no estar limitados a completar una sola tarea a la vez. Queremos tener infinitos modelos, que puedan completar tareas de forma independiente, validar su propio trabajo, e incluso auto-desplegarse y auto-supervisarse, sin que nosotros necesitemos escribirles prompts manualmente.

Pero la planificación intermedia resulta bastante incómoda. Normalmente se ve como un roadmap de producto detallado, pero básicamente no tenemos nada de eso. Más bien, combinamos la visión a largo plazo y nos enfocamos en tareas concretas que pueden ayudarnos a alcanzar nuestros objetivos.

Tomemos la app de Codex como ejemplo. En ese momento, uno de nuestros objetivos estratégicos era liberar a los usuarios de un espacio de trabajo específico (workspace). Las herramientas de desarrollo tradicionales (como VS Code) suelen estar ligadas a un espacio de trabajo específico, por ejemplo a un punto de checkout particular de un repositorio de código o una carpeta. Incluso usando git worktree, normalmente solo puedes abrir un directorio de trabajo a la vez, y la CLI tiene una limitación similar.

Pero nuestra visión era esta: los usuarios podrían colaborar con un agente inteligente en la nube (agent), y esos agentes podrían trabajar de forma independiente. Queríamos que los usuarios pudieran interactuar con múltiples agentes al mismo tiempo, e incluso permitir que un agente coordinara el trabajo de varios agentes por el usuario; esa experiencia debería ser natural e intuitiva.

Al mismo tiempo, también nos dimos cuenta de que si dependías completamente de la nube desde el principio, los desarrolladores podrían sentirlo menos conveniente, porque necesitarían configurar el entorno. Y si, durante la ejecución de tareas por parte del modelo, se requería intervención o ajustes manuales, también se volvería complicado. Por eso decidimos desarrollar una experiencia local: que colabore sin problemas con carpetas locales, pero que también mantenga la conexión con los agentes inteligentes de la nube.

Cuando empezamos a desarrollar esta aplicación, teníamos un montón de “pensamientos de visión” así, ideas más bien abstractas. Mientras tanto, nuestros ingenieros también hacían prototipos diversos. Decían cosas como: “Quiero que tengamos una app”. Entonces empezaron a intentar desarrollar varias versiones distintas. Incluso organizamos una “semana de hackeo”, en la que varios ingenieros desarrollaron por separado distintas versiones de la app. Puede que tú también participaste; no me acuerdo.

Cuando el proyecto realmente arrancó, lo único que teníamos que dejar claramente escrito era: **por qué creíamos que era una buena idea desarrollar una aplicación. No teníamos una especificación de producto concreta para la app; fuimos aclarando la dirección del producto a través del trabajo real de desarrollo. **

Pero en ese momento, el proyecto también generaba cierta controversia: ¿realmente necesitábamos desarrollar una app? Nuestros plugins para IDE ya eran muy populares; ¿deberíamos centrarnos en mejorar la calidad de los plugins? La CLI también tenía mucho potencial. Entonces, si íbamos a desarrollar una app, ¿cuál sería su sentido? ¿Hacia qué dirección deberíamos esforzarnos? Eran algunas de las preguntas con las que nos topamos al principio de este proyecto.

Romain:

Sí. Afortunadamente, en ese momento ya contábamos con una solución de plugins para IDE muy madura y la habíamos optimizado en profundidad. Los usuarios podían usar estos plugins en VS Code, Cursor, Windsurf y otros IDE. Acumulamos muchísima experiencia a partir del código base de los plugins de IDE, lo cual nos dio un punto de partida muy sólido para desarrollar la app de Codex.

Alex:

Así es. De hecho, la app de Codex y los plugins de IDE compartían mucho código en la capa subyacente. Ambas se conectan al mismo Codex harness central, que es un framework open source escrito en Rust; la CLI también lo usa. Diseñamos a propósito con una estructura por capas para poder compartir código y extender funcionalidades entre distintas herramientas.

Presentador Peter: En cuanto al proceso de decidir desarrollar la app de Codex… mirando hacia atrás, parece una decisión obvia, porque usar la app de Codex es mucho más intuitivo que abrir un montón de ventanas de terminal. Pero la razón principal por la que tomamos la decisión fue: la app de Codex es más amigable para principiantes, y también es la mejor interfaz para gestionar la colaboración de múltiples agentes inteligentes.

Alex:

Creo que la forma de pensar de nuestro equipo está muy influenciada por la visión de la AGI (inteligencia artificial general). Siempre nos preguntábamos: ¿cómo será el futuro de las formas de trabajo?

Pero, desde otro ángulo, estábamos muy claros en que necesitábamos una interfaz: para que los usuarios puedan delegar tareas de forma natural a múltiples agentes inteligentes. Sabíamos que los modelos futuros tendrían esa capacidad; de hecho, ya vimos a los usuarios intentar delegar tareas entre agentes inteligentes. Necesitábamos una interfaz para que esa forma de colaboración pareciera lógica, y que además pudiera extenderse sin problemas a la nube.

Queríamos que esa interfaz siguiera principios de ergonomía para que el usuario percibiera la colaboración con múltiples agentes inteligentes como algo intuitivo y natural, en lugar de algo que requiera operaciones complejas o habilidades especiales.

Romain:

Sí. Y además, la audiencia de esta aplicación no es solo para principiantes. En realidad, incluso los ingenieros más experimentados, incluso los ingenieros top dentro de OpenAI —como Peter, OpenClaw y Greg Brockman— ya están empezando a usar la app de Codex como herramienta principal para desarrollar. Esto indica que** nuestra visión sobre la delegación de agentes inteligentes (agentic delegation) está avanzando hacia la realidad de forma gradual.**

Alex:

Sí. Mencionamos a Peter porque acaba de incorporarse a OpenAI, y estábamos muy emocionados por eso. En octubre del año pasado, mientras caminábamos con él en Fort Mason en San Francisco, hablamos sobre la idea de desarrollar una nueva interfaz. Le dije que queríamos que una interfaz nueva hiciera que la delegación de tareas fuera más natural. En ese momento, me dijo que nunca usaría algo así.

Pero el fin de semana pasado, tuiteó diciendo: “En realidad, esta app es bastante buena. Me gusta ahora”.

El trabajo diario de Alex como gerente de producto (PM) de Codex

Presentador Peter: Alex, hace un tiempo fuiste el único gerente de producto (PM) en el equipo de Codex, ¿cierto? Ahora, ¿cuántas personas hay en el equipo de Codex? ¿Entre 50 y 100?

Alex:

Casi, más o menos. En mayo éramos como 8 personas; no recuerdo el número exacto. Pero desde entonces el equipo creció muchísimo, y ahora estamos en el rango de unas 50 a 100 personas.

Presentador Peter: Entonces, ¿cómo distribuyes tu tiempo en el día a día? ¿Cómo es tu rutina? ¿O no tienes un día típico?

Alex:

Últimamente también lo he estado pensando, porque me cuesta responder. Me di cuenta de que** mi modo de trabajo está dividido por etapas**; es solo mi manera personal y tal vez no encaje con todos.

Por ejemplo, cuando lanzamos la app de Codex, yo estaba totalmente en modo de ejecución. En ese entonces, toda mi energía estaba puesta en la calidad del producto: asegurar que no se nos escapara ningún detalle y que cada pequeña cosa estuviera bien. En ese modo, yo pasaba mucho tiempo usando herramientas de Codex.

Usamos Codex para obtener feedback. Por ejemplo, para entender de qué se está hablando en Slack, y también para analizar feedback de usuarios. Le pedía a Codex que resumiera esa información y luego la registraba en Linear. Además, también usaba Codex para analizar la calidad del código y hacía pequeños cambios directamente con él. Porque a veces resolver pequeños problemas directamente con Codex es más rápido que coordinar con otras personas y que ellos prioricen el trabajo, especialmente cuando nuestro objetivo era lanzar la app en dos semanas.

En ese proceso, por supuesto, también hay mucho trabajo humano: animar al equipo, motivarlos, y al mismo tiempo mantener una postura crítica hacia el producto que estamos desarrollando. En realidad, he notado que si estoy o no en modo de ejecución se puede ver por la frecuencia con la que uso Twitter. No sé por qué, pero cuando necesito interactuar con gente, uso más Twitter.

Y luego hay otro modo. Por ejemplo, ahora mismo tengo muy claro en mi cabeza: ya estamos en una nueva etapa. Tenemos modelos muy potentes, como GPT-5.4 que se comporta de manera excelente. Nuestra experiencia de aplicación también superó las expectativas y ya abarca todas las plataformas, incluidos Windows. Así que ahora siento que es el momento de volver verdaderamente a la nube, y dedicar más esfuerzo allí.

Cuando entramos en esta etapa, paso más tiempo pensando qué hacer después y entendiendo el estado actual. Es un modo de coordinación. En ese modo, paso menos tiempo en Codex: uso Codex más para comunicar, no tanto para escribir código. Entonces, en general, tengo al menos esos dos modos de trabajo, y quizá haya más.

Presentador Peter: ¿Cuánta alineación entre funciones (cross-functional) necesitan?

Alex:

Dentro del equipo casi no necesitamos mucha alineación cross-functional. Un poco a propósito, nos tratamos como un equipo tipo “barco pirata”. Incluso dentro del equipo de Codex, ahora mismo solo estamos yo y dos nuevos gerentes de producto recién incorporados. Tenemos algunos responsables, aunque hasta hace poco la mayoría de la gente reportaba directamente a mí, básicamente avanzamos el proyecto de manera relativamente flexible y difusa. Así que la alineación dentro del equipo no es mucha.

Pero ahora es cada vez más evidente que construir Codex incluye desarrollar este coding agent. Y todos también lo tienen cada vez más claro: el coding agent no solo sirve para escribir código; también es muy útil para otras tareas.

Por ejemplo, nos dimos cuenta de que los usuarios usan la app de Codex no solo para escribir código. La usan para completar todo tipo de tareas a lo largo del ciclo de vida completo del desarrollo de software. Y ahora, la mayoría de los empleados de OpenAI usan la app de Codex; incluso si no son técnicos, a menudo los veo usando esta app.

Esa comprensión nos hace pensar que necesitamos que Codex no sea útil solo para desarrolladores. Eso requiere más alineación cross-functional, porque como OpenAI también tenemos ChatGPT y muchos usuarios lo usan. Por eso necesitamos ser muy cuidadosos al pensar en cómo integrar mejor estos productos.

Romain:

Desde mi perspectiva, nuestro equipo de experiencia de desarrolladores se parece un poco a una extensión del equipo de Codex. La mayor parte de nuestra energía la invertimos en Codex, principalmente por algunas razones.

Primero, es un producto realmente emocionante, a los desarrolladores les encanta usar Codex y queremos hacerlo aún mejor. Como Alex dijo, nuestro modo de trabajo tiene varias etapas. Nos involucramos con el equipo de Codex en la preparación del lanzamiento del producto: por ejemplo, preparar los materiales necesarios para el lanzamiento y enseñar a los desarrolladores cómo maximizar el uso de Codex. Después del lanzamiento, también guiamos a los desarrolladores para explorar cómo se puede usar Codex en diferentes escenarios.

Otra cosa que nos resulta especialmente interesante es que si miras toda la plataforma de OpenAI, hoy hay millones de desarrolladores usando nuestra API para construir aplicaciones de distintas modalidades, de imagen a voz, etc.

Ahora, la mejor forma de desarrollar se ha convertido en usar Codex como punto de entrada. Si vuelves un año atrás, o incluso al verano del año pasado cuando acabábamos de lanzar GPT-5, necesitábamos escribir muchas guías para enseñar cómo redactar prompts para GPT-5. GPT-5 es un modelo con una capacidad de razonamiento muy fuerte, muy distinto de GPT-4. Y ahora estamos intentando lograr que los desarrolladores, incluso en esos casos de uso, puedan completar tareas usando Codex y sus skills.

Por ejemplo, si necesitas actualizar un sistema de integración, te recomendamos usar Codex y su funcionalidad de habilidades. Resultado: Codex puede ayudarte casi por completo a completar la tarea. Por eso nuestro equipo también pone mucho énfasis en la colaboración cross-functional y considera a Codex como una base fundamental de la plataforma de desarrolladores completa de OpenAI.

Alex:

Creo que hay una característica interesante en cómo trabaja nuestro equipo Codex. Para mí, lo mejor es la interacción con la comunidad. Ya sea en línea o en eventos en la vida real, valoramos mucho el contacto con la comunidad.

Cuando se lanza un producto, nuestro trabajo es muy** orientado al lanzamiento—definir exactamente cuándo lanzar qué contenido.** Y al mismo tiempo también es muy** orientado al feedback—cada vez que la comunidad da feedback, actuamos rápido, arreglamos problemas y nos comunicamos con ellos. Por eso, nuestro equipo se mantiene en un estado de alta presencia en línea; creo que eso es muy importante.

Por ejemplo, cuando lanzamos la app de Codex, colaboramos muy de cerca con Dom y su equipo. Ellos nos ayudaron a organizar una alpha testing a gran escala, invitando a muchos usuarios para co-desarrollar el producto. Gracias a su feedback, no solo mejoramos la aplicación, sino que también refinamos recursos relacionados como skills y documentación.

Creo que esa es justamente una ventaja única de nuestro equipo de Codex: como somos open source, mantenemos un nivel muy alto de transparencia sobre todo lo que hacemos, y la comunidad también respalda enormemente esa forma de actuar y nos da mucho feedback y retorno.

Presentador Peter: Hablemos de Peter (fundador de OpenClaw). Yo soy un usuario temprano de OpenClaw. ¿Cómo lo integraron al equipo? La visión de este agente personal (personal agent), ¿está relacionada con lo que él hace actualmente? ¿Cómo lo planean?

Alex:

Hay dos aspectos. Primero, Peter es un usuario intensísimo de Codex. En realidad, OpenClaw se construyó en gran medida con Codex. Aporta mucho feedback al equipo a través de su propia experiencia de uso. Aunque eso quizá sea solo “su trabajo parcial”, de verdad está muy comprometido, y nos entusiasma mucho.

Segundo, ahora no puedo revelar demasiados detalles, pero se puede decir que está ayudándonos a construir la próxima generación de agentes personales (personal agents) y a integrarlo directamente en ChatGPT.

Romain:

Creo que lo más fascinante de lo que hace Peter es que, cuando todos están usando OpenClaw, tal vez ya puedan intuir algunas posibilidades del futuro. Pero lo que me impacta es que Peter vio esa visión muy temprano.

Si revisas el conjunto de 2025: el año pasado desarrolló más de 40 proyectos open source, y todos giraban alrededor de una visión central: acceder a sus herramientas personales como calendario, tuits y Gmail mediante una interfaz de línea de comandos. A través de esos proyectos, en realidad hizo realidad la visión de skills y de herramientas por línea de comandos. Y el coding agent que usamos hoy está construido precisamente sobre esa visión.

En el futuro, este agente inteligente no será solo una herramienta de programación; se convertirá en cualquier tipo de agente personal (personal agent). Por eso, Peter nos aporta un feedback extremadamente valioso en ese proceso: ya desarrolló muchas herramientas que hoy se han convertido en una parte central del ecosistema open source.

Presentador Peter:

Me parece admirable que una persona como Peter pueda construir una comunidad open source tan excelente. Sus herramientas son tan buenas que ni siquiera quiero abrir otras apps; solo quiero hablar con mi pequeño robot.

Alex:

¿Con qué sistemas lo conectaste? ¿Lo conectaste con todo?

Presentador Peter:

Sí, lo conecté con muchos servicios. Por ejemplo, puede acceder a mi información bancaria, mi cuenta de YouTube, mi asistente de voz, mi calendario y servicios de Google. Cuando estoy acostado en la cama, mi esposa me pregunta: “¿Con quién estás hablando?” Yo le respondo: “Estoy hablando con mi robot OpenClaw”.

Pero ahora hay muchos “oportunistas” que cobran hasta 5000 dólares para ayudar a configurar OpenClaw para otros. Así que si ustedes pueden hacerlo más masivo, más fácil de empezar, eso sería un gran avance. De verdad están yendo en la dirección correcta.

La escalera tradicional de ascenso profesional ya no aplica

Presentador Peter: Recuerdo que ustedes solían decir algo como “ahora la mayoría de los equipos ya no necesitan tantos PM”.

Romain:

Creo que lo más sorprendente de estas herramientas es que no se trata solo de si necesitas PM o de si necesitas o no PM. Esto casi hace que borremos cada escalera tradicional de ascenso profesional. Antes teníamos funciones claramente definidas: el diseñador se encarga del diseño, el ingeniero se encarga del desarrollo, el PM se encarga de la gestión, y quizá también un porcentaje específico, como algún tipo de “proporción de oro”.

Pero ahora, si eres un ingeniero, tu productividad aumenta significativamente. Si eres un diseñador, con estas herramientas obtienes superpoderes y te vuelves más técnico. Si eres un PM, antes solo podías escribir documentos de estrategia; pero ahora puedes prototipar directamente. Esto no significa que debas ser responsable de una función para miles de millones de usuarios, pero sí puedes usar estas herramientas para construir cosas reales y mostrarle al equipo tu visión.

Entonces, lo más fascinante para mí es que, ahora los límites entre todas las escalas profesionales se están difuminando. En realidad, cada uno de nosotros es un “builder” y todos colaboramos para construir.

Alex:

Recuerdo que en algún lugar en internet dije que, si una startup tiene un PM y menos de unos 20 ingenieros, entonces podría ser una señal peligrosa. Quizá sí dije algo así.

Como tú dices, todos estos roles se están fusionando poco a poco. Los diseñadores pueden hacer más trabajo de ingeniería; los ingenieros pueden meterse en el diseño; los PM también pueden participar en la construcción. Pero normalmente los ingenieros tienen que enfocarse en escribir código, y por eso antes no manejaban cosas como priorización de tareas u otros componentes de gestión de proyectos que hace un PM.

Pero ahora, todo eso se vuelve mucho más fácil. Puedes simplemente dejar que un agente, como Codex, analice el feedback y la prioridad; así el ingeniero libera tiempo para enfocarse en su trabajo. Siento que ahora todos pueden hacer el trabajo de otros.

Scott Belsky propuso una idea: “colapso del talent stack (collapse the talent stack)”. Me gusta esa perspectiva y creo que de hecho está pasando. Cuantas menos personas se necesiten en la sala, más fluido avanza todo, y cada decisión queda más clara.

Entonces la pregunta se vuelve: ¿qué puede hacer un PM? Siento que muchos PM en realidad deberían considerar cambiar de rol. Por ejemplo, si eres un PM que siempre quiso ser ingeniero pero te gusta más gestionar personas y no tienes mucha capacidad de ingeniería, entonces quizás ahora puedas convertirte en un engineering manager. Con agentes inteligentes, ese podría ser un rol más claro para ti. Del mismo modo, algunos PM quizá prefieran convertirse en diseñadores, más cerca del trabajo de construcción real.

Creo que al final depende del interés personal. Para mí,** el interés y la autonomía son las cualidades más centrales y más importantes para la humanidad en la era de la AGI.** Así que si te interesa más escribir código, y antes solo estabas en este rol porque necesitabas que alguien hiciera el trabajo de PM, entonces ahora puedes cambiarte completamente a ingeniería y continuar haciendo lo mismo desde la perspectiva de la ingeniería. En el campo del diseño es similar.

Pero si de verdad te interesa interactuar con los usuarios, incluso si eso te aleja del trabajo de construcción real—por ejemplo, intentar entender las necesidades de los usuarios, captar tendencias del mercado, etc.—entonces en un equipo suficientemente grande aún hay espacio para que el PM contribuya.

Romain:

Yo agregaré algo más: todavía creo que cada área de problema necesita una persona humana responsable, pero no necesariamente tiene que ser un PM. Depende mucho de la naturaleza del producto.

Tenemos mucha suerte porque estamos trabajando para Codex, que es una herramienta orientada a desarrolladores. Nosotros somos los mejores usuarios. Además, como es open source, podemos interactuar directamente con la comunidad y desarrollar de forma conjunta.

Pero si retrocedes diez años: por ejemplo, cuando yo trabajaba en Stripe. En ese entonces la empresa tenía 250 personas, pero no había un PM; ni siquiera había herramientas de IA. ¿Por qué? Porque Stripe es un producto de API, y todos nosotros éramos ingenieros con una comprensión muy intuitiva de lo que hace que una API sea excelente. Lo que estábamos construyendo era precisamente la API de nuestros sueños: una solución elegante que se logra con apenas unas líneas de código.

Pero si estás en un campo diferente, por ejemplo donde los ingenieros no tienen tanta intuición sobre las necesidades del usuario, entonces podrías necesitar más PM para comunicarte con los clientes, entender sus necesidades. Especialmente cuando la industria o el dominio en el que te encuentras no coincide del todo con la intuición de los ingenieros, el rol del PM se vuelve más importante. Pero en el equipo de Codex tenemos mucha suerte, porque estamos construyendo una herramienta que nosotros mismos queremos usar.

Alex:

En ese entorno, el rol de PM podría ser solo una etiqueta, que se refiere a la persona que está más interesada en el usuario y más se preocupa por las necesidades del usuario. Esa persona puede ser perfectamente un ingeniero muy cercano al usuario. Entonces, yo siento que estas etiquetas profesionales están perdiendo gradualmente su significado tradicional, aunque haya un poco de caos, y aun así no es algo malo.

Presentador Peter:

También descubrí algo similar en mi propio equipo. Creo que el mejor tipo de ingeniero no te pregunta “¿Qué deberíamos construir ahora?”, sino que va a hablar con usuarios, por su cuenta descubre qué hay que desarrollar y luego lo conversa conmigo. Así todos tienen objetivos muy alineados.

Romain:

Esa es, de hecho, la forma en que trabaja nuestro equipo de Codex. Muchas de las funciones que se usan hoy en la app de Codex provienen de ideas brillantes que propusieron ingenieros de abajo hacia arriba (bottom-up), porque ellos mismos necesitaban esas funciones.

Alex:

Pero lo que quiero decir es que hay un tipo de ingeniero con el que realmente me gusta colaborar.** Les gusta conversar con usuarios y pensar qué funcionalidad se debería construir.** Estas personas normalmente también son excelentes construyendo sistemas: van rápido, tienen mucha capacidad y una forma clara de pensar. Pero también hay ingenieros que no tienen ningún interés en interactuar con usuarios; solo quieren enfocarse en construir el sistema. Yo creo que esas personas también tienen un enorme potencial de crecimiento.

Enfatizo de nuevo: esta es mi visión para la era de la IA —todos podemos ser más “nosotros mismos”. La IA y el equipo te ayudarán a hacer aquellas cosas que no quieres hacer, para que te enfoques en tus intereses y fortalezas.

Presentador Peter:

Sí, de verdad creo que la etiqueta de “builder” es muy importante. Siento que muchos PM quieren ser líderes, pero en la escalera tradicional de ascenso profesional, cuando te conviertes en cargos como VP, pierdes tiempo de construcción. Todos los días estás en revisiones de producto, solo dando feedback, pero sin tiempo real para desarrollar. Creo que muchos PM no quieren que sea así; quiero seguir muy cerca de los usuarios y realmente lanzar productos.

Alex:

Estoy completamente de acuerdo. Yo no considero que PM sea un rol de liderazgo; más bien lo veo como un “rol para llenar vacíos”. A veces, este rol puede requerir ciertas responsabilidades de liderazgo, pero incluso así, el liderazgo se trata más de ayudar al equipo a lograr un consenso, en lugar de depender de que una sola persona presente una solución genial.

Hay algo que sí puedo asegurar: en OpenAI, los mejores PM se meten en los detalles concretos. Y yo también pienso que unirse a OpenAI en un puesto de liderazgo senior es algo muy desafiante, porque aquí la cultura todavía enfatiza la atención a los detalles. Por eso, la mejor forma es meterse en los detalles desde el principio.

¿Qué valora el equipo de Codex al contratar? (La respuesta no es tu currículum)

Presentador Peter: Cuando ustedes contratan para el equipo de Codex, además de pedir que el candidato sea un usuario intensivo de Codex, ¿qué otras cualidades valoran?

Alex:

Mencioné antes que valoro muchísimo la “agencia” (agency) del candidato. Queremos encontrar personas que se ponen manos a la obra por iniciativa propia; esa es una de las cualidades más importantes.

En OpenAI, especialmente en el equipo de Codex, nuestra cultura no es de ese tipo: “cuando te unas, aquí van 12 tareas que aumentan la dificultad paso a paso”. Nuestro estilo es más como: “Bienvenido. ¡Ahora, empieza tu exploración!”

Por lo tanto, solemos inclinarnos por buscar personas autodirigidas: con iniciativa, con sus propias ideas, saben lo que quieren hacer y no les asusta desafiar las ideas existentes. Porque, seamos honestos, algunas de las ideas existentes podrían estar equivocadas; quizá solo fueron una decisión accidental que tomamos en el pasado.

Mi compañero de equipo ideal es alguien que está dispuesto a asumir responsabilidades extra, incluso hacerse cargo de áreas desconocidas. Esas son cualidades que valoramos especialmente. En cuanto a habilidades específicas, normalmente priorizamos a candidatos con capacidades técnicas fuertes, relacionados con ingeniería.

Romain:

Estoy totalmente de acuerdo. En mi equipo de experiencia de desarrolladores (DevX), normalmente busco personas con alta autonomía. Necesitan ser muy fuertes técnicamente y sobresalir al usar herramientas como Codex. Pero además de eso, también valoro mucho a quienes tienen una pasión especial por trabajar con desarrolladores y builders (constructores), y por compartir conocimiento.

Por ejemplo, esta semana acabamos de anunciar que Thomas se va a unir a mi equipo. Él fue quien desarrolló el open source Codex monitor. No solo es muy creativo; también es un usuario intensivo de Codex y está muy entusiasmado por compartir cómo usa Codex para construir herramientas.

Necesitamos a ese tipo de talento porque estamos intentando llevar a millones de desarrolladores hacia el brillante futuro que representa Codex. Creo que la programación con agentes inteligentes (agentic coding) está cambiando por completo la forma en la que pensamos tradicionalmente sobre el desarrollo de software, las aplicaciones y la construcción de productos. Nuestro objetivo es mostrar al mundo que esto es posible y ayudar a que los desarrolladores aprendan a usar estas herramientas para materializar sus propias ideas. Esa es la cualidad que busco.

Alex:

Agregaré algo más: en mi opinión, el candidato ideal para el equipo DevX se puede describir simplemente como** “un ingeniero extraordinario que además sabe aprovechar las redes sociales y la interacción con la comunidad”.**

Romain:

Tienes razón en una parte. Pero quiero añadir algo: queremos que los candidatos tengan un fuerte sentido de responsabilidad hacia la comunidad, y también considerar los hábitos de uso de redes sociales de distintas regiones a nivel global. Por ejemplo, en algunos lugares, los desarrolladores pueden preferir usar LinkedIn u otras plataformas, en lugar de Twitter. Así que necesitamos ampliar la definición: el candidato tiene que tener un buen desempeño en redes sociales a escala global.** Valoramos especialmente a quienes disfrutan interactuar con la comunidad, y están entusiasmados por enseñar y compartir conocimiento.**

Presentador Peter:

En realidad, la autonomía de una persona se puede ver incluso antes de la entrevista. Por ejemplo, si han publicado trabajos en línea, si tienen side projects propios.

Alex:

Cuando alguien me escribe por mensaje privado diciendo que le interesa unirse a nuestro equipo, mi primera reacción es: “¿Tienes algún enlace?” Si hay un enlace, casi siempre lo abro para revisarlo. Me da curiosidad por comprobar sus trabajos y ver si realmente están construyendo algo.

Por supuesto, algunos envían una carta de solicitud explicando por qué les interesa el puesto, e incluso adjuntan su currículum, pero yo prefiero ver sus ideas y lo que realmente construyeron. Hace poco me di cuenta de un detalle interesante: no tengo idea de en qué universidad fueron esas personas.

Presentador Peter: A quién le importa, ¿quién se fija? De verdad me alegra que ahora estemos viviendo en una era tonta en la que la educación ya no es tan importante. Con que me muestres lo que realmente construiste, eso es suficiente.