Si preguntas cuál es el producto de IA con el crecimiento más notable en 2026, "Codex" seguro ocuparía el primer lugar.
Desde enero de este año, los usuarios activos semanales de este producto han crecido más de 5 veces, con una curva de crecimiento muy pronunciada. Actualmente, su escala de usuarios activos semanales ya alcanza los 5 millones. Entre ellos, la velocidad de adopción de Codex por parte de trabajadores del conocimiento (no desarrolladores) es más de 3 veces mayor que la del grupo de desarrolladores.
Es importante señalar que estas curvas de crecimiento tan pronunciadas tienen un importante catalizador: el lanzamiento de la aplicación de escritorio en febrero. Esta versión de escritorio ofrece una interfaz de uso exclusiva y optimizada, reduciendo drásticamente la barrera de entrada, lo que trajo consigo un crecimiento explosivo en las descargas y adopción de Codex.
Y detrás de esta pronunciada curva de crecimiento, impulsando el cambio en la forma del producto, está un rol relativamente menos discutido públicamente: Andrew Ambrosino, director del equipo de la aplicación de escritorio de Codex.
Como la persona directamente responsable de la evolución del producto de Codex para escritorio, se encuentra al mismo tiempo entre dos mundos que se superponen rápidamente: por un lado, la cadena de herramientas de desarrollo centrada en "escribir código", y por el otro, la entrada de trabajo de IA general que se expande rápidamente a casi todos los escenarios de trabajo del conocimiento. Desde el ritmo de lanzamiento de productos hasta los cambios en el comportamiento del usuario, pasando por cómo el equipo interno redefine los límites entre "diseño", "ingeniería" y "producto", lo que él observa a menudo está más cerca de la esencia de este cambio que los propios datos de crecimiento.
La siguiente entrevista, precisamente desde su perspectiva, desglosa qué cambió Codex, por qué se fusionó con ChatGPT, y cuáles son sus direcciones futuras de iteración.
Enlace del video: https://www.youtube.com/watch?v=P3KDebPTUrw
Hemos organizado parte del contenido de la entrevista. Para los detalles completos, consulta el video original.
La implementación se abarató,
¿entonces qué se encareció?
Hace unos años, la lógica del desarrollo de productos era esta: implementar era caro. Por lo tanto, antes de empezar a escribir código, tenías que hacer mucho trabajo previo para mitigar riesgos: escribir documentación, investigar, crear prototipos, con el objetivo de abaratar el diseño. Precisamente porque el costo de la implementación era alto, tenías que dejar todo claro desde el principio.
Pero ahora esta premisa se ha invertido por completo. En OpenAI, la situación es esta: se le da a la gente muchos tokens, todos tienen buenas ideas, así que todos están creando cosas. El resultado es que, para una característica que se necesita hacer, puede haber 90 equipos diferentes explorando simultáneamente 90 formas distintas de implementación.
Esto significa que la implementación ya no es la parte costosa. ¿Entonces qué se encareció? Andrew es directo: el gusto. Más concretamente, el proceso de curación. Cuando te enfrentas a estos 90 intentos diferentes, necesitas tener criterio para juzgar: ¿qué cosas se hicieron bien? ¿Cómo deberían integrarse en otras funcionalidades? ¿Cómo se debe enmarcar esto? ¿Cuántos niveles debería tener este interruptor? Estas decisiones en sí mismas son ahora lo más caro, lo que más requiere reflexión.
¿Qué es exactamente el gusto?
La palabra "gusto" (taste) está muy manoseada en Silicon Valley. Pero para Andrew, tiene un significado muy concreto.
Hay una anécdota divertida de que el responsable de producto de Linear dijo que alguien enfatizaba demasiado la parte estética del gusto, y puso a Paul Graham como ejemplo: Paul Graham obviamente tiene buen gusto, pero usa pantalones de trabajo. Esto demuestra que el gusto va mucho más allá de la apariencia. Andrew enumera las connotaciones del gusto: está la dimensión estética, pero es solo una parte; está la dimensión del pensamiento sistémico, es decir, cómo encaja esto en todo el sistema; está la dimensión del sentido de dirección, de qué tema forma parte esto; está la dimensión de cómo se presenta. Por supuesto, también hay niveles de detalle, como si la animación de interacción coincide con la intención semántica que quiere expresar: ¿es demasiado rápida para expresar ese concepto?
Pero la verdadera pregunta central sobre el gusto es esta: si podemos construir cualquier cosa, ¿entonces qué queremos? ¿Qué es esto? ¿Cómo llegamos allí? Estas son las verdaderas cuestiones de gusto.
No se trata solo de elegir qué hacer. También se trata de cómo presentar la información, cómo lograr los objetivos, qué medio usar. El gusto es el lugar donde la mente humana sigue siendo más valiosa en esta nueva era.
¿Por qué la IA aún no hace bien el diseño?
Esta es una paradoja interesante: Codex es muy potente escribiendo código, pero cuando se usa para generar diseño, la calidad de la salida suele ser mediocre. Rara vez se puede decir "¡Vaya, lo hizo perfecto!".
Andrew cree que hay varias razones detrás de esto. Primero, razones prácticas. El diseño es más difícil de puntuar que el software, porque el gusto humano que evalúa lo que es un buen diseño es en sí mismo parte del mecanismo de retroalimentación. Esto dificulta entrenar el modelo, a diferencia del código, donde es difícil medir con estándares objetivos (¿se compila el código? ¿Funciona?). En segundo lugar, desde la perspectiva de la inversión en investigación, los laboratorios tradicionalmente han destinado más recursos a mejorar aquellas capacidades que aceleran la propia investigación en IA. En los primeros días de los modelos de codificación, claramente poder escribir código correcto aceleraba la investigación. Pero si la capacidad de diseño es buena o no, su efecto acelerador en la investigación en IA es menos directo.
Un problema más profundo involucra la complejidad del trabajo de diseño en sí mismo. El diseño tiene una capa cultural: lo que se considera "buen diseño" está determinado culturalmente. El año pasado, todos los nuevos sitios web copiaban el diseño de Linear, eso es buen diseño, tiene gusto. Pero si un modelo siempre genera algo que parece Linear, eso no es progreso, es un fracaso. El diseño necesita novedad, mientras que la ingeniería de software es todo lo contrario, casi siempre quieres que el código siga patrones conocidos.
El problema más difícil de resolver está en la capa de abstracción. Cuando el código impulsa el diseño visual, existe una interacción profunda entre ambos. Por ejemplo, algo en la esquina superior izquierda debería compartir la misma abstracción en el código base que algo en la parte inferior. Esto no es solo decir que el modelo necesita ser un mejor diseñador, sino que el modelo necesita comprender estas relaciones estructurales más profundas: si la empresa mañana hace un rebranding, el enfoque superficial sería actualizar uno por uno los 263 componentes, pero la comprensión profunda sería: estas dos cosas que parecen diferentes son semánticamente iguales, ambas son listas, tienen el mismo estilo, transmiten el mismo patrón de interacción. Esta comprensión de la capa de abstracción sigue siendo inalcanzable para la IA por ahora.
¿Por qué Codex no pudo lanzarse antes?
Esta es una observación muy profunda: el éxito de un producto no solo depende del diseño en sí, sino también del momento oportuno de las capacidades del modelo.
Andrew está muy seguro de que si la aplicación Codex se hubiera lanzado en noviembre del año pasado, habría fracasado por completo en el mercado. Mientras que el mismo producto lanzado en febrero obtuvo un gran éxito. La única variable fue el progreso en las capacidades del modelo durante esos meses intermedios. En otras palabras, el diseño de interacción, la interfaz de usuario, todo el concepto del producto no cambiaron, pero la mejora en la inteligencia del modelo cambió por completo el resultado.
Esto revela una verdad profunda: en la era de la IA, si un producto es fácil de usar o valioso, no lo determina solo el diseño de la UI o la interacción, sino lo que "el modelo puede hacer en este momento". La misma idea, implementada con el modelo antiguo podría ser inútil, pero con el nuevo modelo puede ser fascinante.
Esto también cambia la forma de planificar productos. Andrew vio este cambio en su empresa anterior: ya no es "planeamos qué hacer durante todo el año", sino que se convierte en "creemos qué puede hacer el modelo en qué momento, hagamos una lista de todo lo que nos interesa, prototipemos todo, y luego decidamos qué podemos hacer ahora, y dejemos el resto en espera; cuando el modelo dé un nuevo salto, probemos esas ideas previamente pospuestas con el modelo actualizado". Porque la premisa de si toda una funcionalidad es buena o no, no es la forma del diseño, sino si el modelo es lo suficientemente inteligente.
¿Han desaparecido los límites entre ingeniero, diseñador y PM?
Lenny menciona que, al ver el currículum de Andrew, ha sido ingeniero, diseñador, gerente de producto, emprendedor, y ahora dirige toda la aplicación de escritorio. Pregunta si el equipo de diseño también depende de él. Andrew sonríe y dice "depende de la semana": la relación de reportes siempre está cambiando, pero el equipo siempre ha estado trabajando juntos, estrechamente, integrados.
Andrew dice que el mundo exterior ya está discutiendo la "desaparición de roles", diciendo que en el futuro ya no habrá divisiones de roles. Su equipo aún no ha llegado a ese punto, pero la superposición entre roles es ciertamente más evidente que en otros departamentos de la empresa, e incluso en toda la industria, en parte porque Codex es un producto técnico orientado a ingenieros, los diseñadores del equipo pueden hablar el lenguaje de los ingenieros, los gerentes de producto también pueden escribir código, por ejemplo, el otro gerente de producto, Alexander, tiene una maestría en ciencias de la computación, mientras que Andrew mismo no la tiene.
Él cree que ahora una descripción más precisa sería: una persona ya no está definida por límites como "dónde termina el diseño, dónde comienza la ingeniería", sino por en qué pasa su tiempo en promedio. Esto también tiene que ver con cómo trabaja el equipo, porque toda la aplicación se ejecuta internamente "comiendo tu propia comida para perros", todos quieren hacer las cosas dentro de la aplicación en la medida de lo posible, incluso si temporalmente no es la mejor herramienta para ello, para que lentamente se convierta en la mejor herramienta. También comentan sobre el origen del título "miembro del personal técnico" (member of technical staff). Andrew cree que quizás fue Xerox quien comenzó a llamarlo así, y hoy en día es una especie de tradición en empresas impulsadas por la investigación.
Lenny pregunta si esto significa que en el futuro todos se convertirán en "constructores" sin funciones definidas, y si las clasificaciones de habilidades como PM, diseño, ingeniería seguirán existiendo. La postura de Andrew es clara: no está de acuerdo con eliminar por completo la división de roles. Ha visto muchas empresas proclamar "eliminar el puesto de producto, todos son constructores", y el resultado es que las mejores prácticas y experiencias de error acumuladas durante años en la profesión de producto se descartan como inútiles debido a la idea de "yo también puedo escribir código". Desaparecer el sentido de límites del tipo "esto no es tu territorio" es algo que él celebra, pero cada profesión sigue teniendo su propio umbral de habilidades: no es que cualquiera que use Excel pueda cubrir un turno en el departamento de finanzas.
También menciona que ahora cambiar de rol es ciertamente más fácil que antes, porque la capacidad ya no está vinculada a "si dominas una herramienta específica": él mismo durante mucho tiempo pensó que no debería ser ingeniero porque no le gustaba profundizar en lenguaje ensamblador, memorizar la sintaxis de TypeScript, y este umbral de "dominar una herramienta específica para hacerlo bien" se está desmoronando. Sin embargo, también advierte que esta tendencia está siendo exagerada por el mundo exterior en este momento.
Las formas más avanzadas actuales de desarrollo asistido por IA
Lenny lleva la conversación un nivel atrás: desde escribir código puramente manual, hasta que la IA puede escribir el 100% del código, y ahora "escribir código" se ha convertido en "guiar a la IA". Evaluar cuánto código escribió una persona casi se convierte en "¿cuántas veces corregiste la dirección de la IA?". Pregunta: ¿La práctica más avanzada ahora es "loop" (desarrollo en ciclo autónomo)? ¿Cómo operan específicamente ahora los equipos de IA más avanzados?
Andrew menciona que una cuestión fundamental es que la pregunta "¿cuánto código escribió la IA?" ya no es importante, porque según los estándares del año pasado, ahora casi el 100% del código lo escribe la IA; lo que realmente hay que preguntar es si este código se escribió de manera "supervisada" o "no supervisada", son dos cosas completamente diferentes. Dice que le gusta que este criterio de evaluación se renueve constantemente, porque eso demuestra que el producto está avanzando. El equipo ha explorado bastante en la dirección del "desarrollo de software autónomo", incluyendo muchos intentos relacionados con la "ingeniería de arnés" (harness engineering), como imaginar que el modelo se ejecute solo por la noche, haciendo una limpieza de "reciclaje de basura" en el código base.
También admite que actualmente todos los modelos tienen un defecto común: tienden a hacer que el código sea cada vez más complejo. Bromeando medio en serio, dice que si algún equipo de investigación está escuchando, espera que mejoren la capacidad del modelo para "eliminar código". Este también es un problema práctico que se encuentra al entregar completamente el desarrollo a la conducción autónoma, tanto del lado humano como del código base: cómo enseñar al modelo a juzgar qué características hacer, cuáles ignorar, cuáles combinar y reclasificar; cómo enseñarle a construir las estructuras abstractas correctas. Estas capacidades están mejorando, pero cree que todavía no es posible lograr "establecer un ciclo para que mejore el producto por sí solo, mientras monitorea Twitter, Slack, correos electrónicos", aunque el equipo sigue esforzándose en esa dirección.
Lenny pregunta si algún día el equipo simplemente le dará a la IA un objetivo final como "ganar" o "ganarme mil millones". Andrew sonríe y dice que no se atreve a cerrar la puerta, no diría fácilmente "nunca" o "definitivamente".
¿Por qué tenían que fusionar Codex y ChatGPT?
¿Hacia dónde se dirige el futuro de Codex?
Codex era originalmente una herramienta de línea de comandos, luego se convirtió en una aplicación independiente. Su posicionamiento inicial era claro: una "herramienta para desarrolladores", no un IDE, podía ver código, pero no permitía editarlo.
Antes del lanzamiento oficial de la aplicación al público, el equipo hizo una ronda de pruebas internas en OpenAI (enero-febrero). En escenarios de ingeniería e investigación, el feedback fue muy claro y positivo. Pero al mismo tiempo, el equipo descubrió que personas de marketing, relaciones públicas, finanzas, legal, prácticamente todos los departamentos también estaban usando esta aplicación, a pesar de que la experiencia no era amigable para ellos: la interfaz estaba llena de código y solicitudes de permisos de línea de comandos, no estaba diseñada para ellos.
La respuesta inicial del equipo fue trasladar las capacidades de Codex a otras interfaces de producto, como la aplicación de escritorio de ChatGPT y el navegador Atlas, convirtiéndolas en herramientas de trabajo de conocimiento más generales. Pero el resultado fue que nadie quería abandonar la aplicación Codex para usar esas aplicaciones "especializadas". Esto hizo que el equipo se diera cuenta de que el límite entre las herramientas para desarrolladores y las herramientas de conocimiento general se está desmoronando. Codex y ChatGPT son más como diferentes entradas para la misma capacidad, no dos productos independientes.
La conclusión del equipo fue: este conjunto de productos debe convertirse en una base lo suficientemente genérica y extensible para manejar simultáneamente escenarios profundos como finanzas, legal, ciencia, etc. El verdadero desafío solo está en "cómo hacerlo lo suficientemente genérico". Esta es también la respuesta del equipo a la pregunta "¿Codex es una herramienta para desarrolladores o simplemente es ChatGPT?".
El presentador Lenny señala que Codex ya es más fácil de usar y más divertido que la propia aplicación ChatGPT, los usuarios se van a usarlo, por lo que la fusión es una dirección inevitable para evitar confusión.
Andrew responde con una sonrisa que algunas personas llaman a esta dirección "super aplicación" (super app), y se arrepiente de que alguien pronunciara esa palabra, porque desde entonces, está rodeado por esa expresión todos los días.
Lenny pregunta: no la llamemos "super aplicación" por ahora, pero ¿la idea central no es que "el usuario llegue a un lugar y pueda hacer todo"? ¿O es que esto aún no está decidido?
La respuesta que da Andrew es el concepto de "home base" (base de operaciones): esto debería ser un buen "campo base", un lugar donde el usuario pueda rastrear todas sus tareas pendientes en diferentes interfaces de producto. Algunas cosas, el usuario puede completarlas por completo dentro de la aplicación; otras cosas, la aplicación se encarga de llamar o abrir otras aplicaciones para completarlas. Por ejemplo, la aplicación puede conectarse a Excel, y de hecho tiene un editor de hojas de cálculo incorporado, pero para alguien que necesita hacer modelos financieros complejos para una financiación de miles de millones de dólares en OpenAI, ese editor incorporado podría estar muy lejos de ser suficiente. Por lo tanto, la aplicación hablaría directamente con el complemento de Microsoft Excel en el escritorio del usuario, y cuando el trabajo esté hecho, el usuario puede cerrar Excel directamente.
Es decir, nunca se trató de "dibujamos un cuadro en la pantalla, y todo debe suceder dentro de este cuadro", sino que esto debería convertirse en un "hogar" para el usuario: aquí comienzas el trabajo, lo terminas, lo automatizas, y cuando necesitas usar alguna herramienta, va a llamar a esa herramienta.
Para ilustrar esto, Andrew cuenta una historia concreta. Cuando se lanzó inicialmente la aplicación Codex, el equipo grabó algunos videos promocionales, y el trabajo de edición recayó en el fotógrafo interno. Resulta que el fotógrafo editó completamente esos videos usando Codex. Este fue uno de los primeros momentos en que el equipo realmente se dio cuenta de "Dios mío, la gente realmente está usando esto para eso".
Al fotógrafo se le ocurrió usar Codex para editar video puramente por curiosidad, solo para ver si Codex realmente podía hacerlo. Codex en sí mismo no es en absoluto un editor de video, y la interfaz no tiene ninguna UI relacionada con la edición, pero podía entender que el fotógrafo usaba Premiere Pro, y podía completar parte de la edición editando directamente los archivos de proyecto detrás de Premiere Pro que sostienen el contenido mostrado en pantalla, pero esto no cubría todas las necesidades. Entonces, lo que hizo Codex a continuación fue escribirse a sí mismo una extensión que podía instalarse en Premiere Pro, y luego usar esta extensión para "hablar" con Premiere Pro: "Oye, extensión de Premiere Pro, ¿puedes ayudarme a cambiar este punto de marca?". La primera vez que el equipo vio ocurrir este proceso de verdad, todos pensaron que era increíble.
De esto, Andrew resume un modelo: en este mundo ya existen muchas herramientas profesionales que han alcanzado la excelencia en sus respectivos campos. Codex, ahora con ChatGPT, quiere hacer dos cosas a la vez.
Lo primero es cómo colaborar perfectamente con las herramientas que el usuario ya está usando: el equipo no necesita reinventar un mejor editor de video, sino hacer que Codex y ChatGPT aprendan a usar las herramientas existentes, poder interactuar con ellas, pasarles tareas, generalmente a través de conectores (connectors), capacidad de uso de la computadora (computer use), o como en el caso de Premiere Pro, a través de extensiones.
Lo segundo es el tipo de visión que mencionó Dan Shipper: los usuarios ya tienen un montón de aplicaciones web que pueden usar haciendo clic, pero desean poder abrir estas aplicaciones directamente en Codex, para que Codex haga más cosas por ellos dentro de ellas. Estos dos modos son casi imágenes especulares el uno del otro, y el equipo está impulsando ambas líneas simultáneamente en este momento.
Este artículo proviene del WeChat público "Machine Heart" (ID:almosthuman2014), autor: Machine Heart
