Codex responsable: «Todo el mundo es constructor» es una pésima idea.

Andrew Ambrosino es el líder del equipo OpenAI Codex. Con formación en diseño, ha trabajado como ingeniero, producto y también ha emprendido. Ahora, Codex, del que es responsable, ya tiene más de 5 millones de usuarios activos semanales. Probablemente sea una de las personas más indicadas hoy para responder a la pregunta "cómo se debe hacer un producto en la era de la IA".

Desde su perspectiva, cuando casi todos en la empresa pueden crear rápidamente un prototipo funcional, el verdadero desafío ya no es "si se puede hacer", sino "si se debería hacer".

En su conversación con Lenny, Andrew Ambrosino detalló el proceso de desarrollo interno de OpenAI: cuando el costo de implementación se reduce drásticamente gracias a la IA, cada etapa del desarrollo de productos, desde la aprobación del proyecto, la documentación, los prototipos, el diseño, hasta la división de roles, la colaboración en equipo y la planificación del producto, está cambiando. ¿Qué reglas antiguas están fallando? ¿Qué nuevos estándares se están formando? Cuando la implementación ya no es escasa, ¿qué recurso es realmente escaso?

Algunas ideas clave:

Cuando 90 personas pueden crear 90 prototipos de productos que parecen listos para lanzarse, lo más valioso es el gusto.

Uno de los criterios estrictos de contratación del equipo de Codex es el gusto: la capacidad de distinguir señales del ruido en medio de un mar de contenido. En un mundo de "tokens infinitos", no quieren producir contenido basura.

Si Codex se hubiera lanzado tres meses antes, habría fracasado por completo; la única variable fue la mejora del modelo. No juzgues fácilmente que una función es mala; puede que simplemente no haya llegado su momento.

Si una función es lo suficientemente buena, a menudo la premisa no es la forma de la función en sí, sino si el modelo es lo suficientemente inteligente.

Así como Codex revolucionó ChatGPT, Codex también puede ser revolucionado por nuevos intentos. Hay que preservar una cultura de exploración de abajo hacia arriba; no se puede esperar que el mismo equipo refine los detalles y se revolucione a sí mismo.

A continuación, lo más destacado de la conversación.

Cuando el costo de implementación baja, el gusto se vuelve más importante.

Lenny: Dijiste que la IA está cambiando la forma del trabajo de producto. Ahora trabajas en lo que probablemente sea el equipo de producto de IA más avanzado del mundo. Específicamente, ¿cómo ha cambiado la forma de trabajar del equipo de producto en comparación con hace dos años?

Andrew Ambrosino: Ahora, como líder de equipo, lo más difícil es que el proceso se ha invertido.

Antes, todos conocían el proceso de hacer productos: primero investigar, luego generar ideas, hacer prototipos. Incluso después de la era del desarrollo en cascada, la lógica subyacente seguía siendo la misma: la implementación era costosa. Por lo tanto, antes de implementar, había que eliminar todos los riesgos mediante documentos, investigaciones y prototipos. Porque los prototipos y los diseños eran más baratos que el desarrollo, esa era la suposición básica del pasado.

Ahora esa suposición ha cambiado por completo; cualquiera puede hacer cualquier cosa. Realmente creo que, empezando desde cero y conversando con estos modelos, ya sean los nuestros o los de otras empresas, puedes construir cualquier funcionalidad que desees. Esto no es necesariamente la parte más difícil del desarrollo de software, pero sí es muy genial.

Le das a la gente tokens ilimitados, y todos en OpenAI son proactivos y tienen buenas ideas. Así que todos están haciendo todo tipo de cosas. Ahora hay una función que necesitamos urgentemente, y estoy seguro de que hay al menos 90 equipos pequeños diferentes y no coordinados que la están implementando y probando por su cuenta. De esos 90 intentos, ¿cuáles son buenos? ¿Qué partes deberían integrarse en otros aspectos? ¿Cómo debería definirse? ¿Debería ser parte de otra función? ¿Cuántas opciones debería tener el interruptor? Se trata de estas cosas.

La respuesta corta es: se ha invertido. No es que la gente esté haciendo roles fundamentalmente diferentes, ni que las habilidades hayan desaparecido o los roles no existan. La implementación ya no es la parte más cara; me atrevo a decir que lo más caro es el gusto.

Lenny: Entonces, antes la gente escribía PRD, documentos de estrategia; ahora la gente hace directamente prototipos. Mucha gente en la empresa tiene ideas similares, y aparecen 90 cosas diferentes, y luego se elige una dirección.

Andrew Ambrosino: Sí, esto ocurre mucho. No solo en OpenAI; ya has visto a muchos responsables de producto decir "el PRD ha muerto, los prototipos son el camino", pero en realidad no estoy de acuerdo en absoluto.

Porque la implementación se ha vuelto barata en todos los medios, se vuelve muy tentador saltarse el pensamiento y pasar directamente al prototipo. Especialmente si no eres ingeniero, si nunca has escrito código, no tienes interés o tiempo, te dan ganas de decir: "El PRD ha muerto, déjame mostrarte directamente lo que quiero".

Pero también he notado un fenómeno contrario. Para los ingenieros, escribir mucha documentación se vuelve tentador, mucha documentación que no vale la pena leer. No estoy diciendo que quienes escriben documentos sean malos, sino que cuando la implementación se vuelve abundante, elegir el formato correcto para expresar tu punto de vista se vuelve realmente importante.

Si estás expresando claridad sobre un producto en un área difusa, probablemente deberías escribir un documento. Si quieres que la gente pruebe y someta a presión un patrón de interacción, haz un prototipo. La clave es elegir el medio correcto.

Lenny: Hay un concepto llamado "primal mark" (marca primigenia), el primer trazo que el pintor da en el lienzo, y todo lo demás se deriva de él. ¿Quieres decir que a veces el prototipo es el primer trazo incorrecto? Porque la gente se ancla en él, en lugar de pensar en el plan más amplio.

Andrew Ambrosino: Sí. Antes había una señal implícita: cómo se veía algo indicaba en qué etapa del proceso se encontraba. Si veías algo que parecía un producto listo para lanzar, significaba que ya estaba en una etapa avanzada, los riesgos se habían eliminado, el diseño se había revisado, los objetivos comerciales eran razonables.

Ahora estas cosas se han desconectado. La razón es que antes, para obtener recursos para construir, tenías que reducir suficientemente el riesgo, y ahora ese umbral ha desaparecido. Así que algo que solo estaba en la fase de exploración ya parece listo para lanzarse, visualmente está listo. Pero puede que no sea la dirección correcta, que no coincida con la investigación, que no sea lo que los usuarios realmente necesitan, ni lo mejor para el negocio.

No es que quiera exagerar la importancia del gusto. Pero, una vez más, saber qué hacer, cómo presentarlo, cómo alcanzar el objetivo, qué medio usar, se está convirtiendo en la habilidad más importante en todos los ámbitos.

Lenny: La palabra "gusto" es una palabra de moda ahora. Específicamente, ¿qué es exactamente el "buen gusto" del que hablas?

Andrew Ambrosino: El gusto hay que desglosarlo.

Ciertamente hay una parte estética, pero también hay una parte de pensamiento sistémico: cómo encaja esto en todo el sistema; una parte direccional: a dónde vamos, de qué tema forma parte esto; una parte expresiva: cómo presentar esta información; y otra parte del gusto es a nivel de interacción: esta animación no coincide con la semántica que debería transmitir, es demasiado abrupta, no se ajusta al significado que expresa.

Estas cosas son realmente importantes, pero el verdadero problema del gusto es: si podemos hacer cualquier cosa, ¿cuál es el objetivo? ¿Cómo llegar allí?

Lenny: A medida que la IA se vuelve más fuerte y hace más cosas, ¿en qué áreas el cerebro humano seguirá teniendo valor? El gusto parece ser una de ellas. Pero los resultados de diseño de la IA aún no son muy buenos. ¿Por qué los modelos de primer nivel no hacen bien el diseño?

Andrew Ambrosino: Hay algunas razones prácticas y otras más difíciles de resolver. El diseño es más difícil de evaluar que el software. Crear un bucle de retroalimentación para entrenar al modelo sobre qué es un buen diseño es mucho más engorroso que entrenarlo para que el código compile, porque el gusto humano es parte del mecanismo de retroalimentación.

Además, históricamente, los laboratorios han priorizado que los modelos sean buenos en cosas que puedan acelerar la investigación en IA. Que un modelo pueda escribir código correcto claramente acelera la investigación, mientras que el diseño no puede defender el mismo argumento. No es que el diseño no sea importante, sino que no está en ese volante.

Estas son razones prácticas y desaparecerán. Los modelos serán bastante buenos en diseño, pero hay cosas más difíciles.

Primero, el diseño tiene un aspecto cultural. ¿Recuerdas el año pasado que todos los sitios web nuevos copiaban el diseño de Linear? Si el modelo siempre genera el sitio web de Linear, ese no es el desafío. La importancia de la novedad en el diseño es mucho mayor que en la ingeniería de software. En ingeniería, deseas que el modelo siga patrones conocidos, pero el diseño requiere cierta aleatoriedad y novedad.

Segundo, está la interacción entre el diseño visual y el código. Si la empresa cambia de marca mañana, el enfoque superficial es actualizar los 263 componentes uno por uno. El enfoque profundo es entender que dos cosas que se ven diferentes en realidad pertenecen al mismo estilo de lista y transmiten el mismo patrón de interacción. Esta capa de abstracción aún no está al alcance de la tecnología actual.

Lenny: Jenny Wen (directora de diseño de Anthropic Claude Code) dijo que el proceso de diseño ha muerto, solo hay que construir directamente. ¿Qué opinas?

Andrew Ambrosino: Puede que Jenny y yo estemos de acuerdo en muchas cosas. En cuanto al proceso formal de diseño, estoy de acuerdo con ella: ha muerto. Y antes de la IA, yo ya no era fan de ese proceso.

Hace años, cuando tenía mi startup, había un artículo llamado "La fábrica de casos de estudio", que hablaba de cómo los diseñadores eran entrenados para seguir un proceso fijo y gradualmente daban más importancia al proceso en sí que al resultado. Si algo pasaba por este proceso, se asumían dos conclusiones: primera, sería bueno, el proceso garantizaba la calidad; segunda, incluso si nadie lo usaba, seguía siendo bueno porque había seguido el proceso.

Investigación de usuarios, divergencia, convergencia... el marco es correcto, pero siempre fue un poco académico. La premisa de ese proceso era que la implementación era cara, solo podías construir una vez, por lo que debías agotar todo el espacio de problemas y soluciones antes de hacerlo.

Luego llegaron Figma y Origami, y agregamos el prototipo interactivo al proceso. Ahora el problema es que puedes llevar toda la implementación al frente del proceso. Un prototipo completamente pulido, que parece listo para lanzar directamente. Suficientes personas en la empresa lo ven y preguntan: "¿Podemos lanzarlo ahora?". Pero en realidad, todavía están en la fase inicial de exploración del diseño, solo que nadie lo dice explícitamente.

Así que decir que el proceso de diseño ha muerto es a la vez correcto e incorrecto. Si estás atado a herramientas y rutinas diarias específicas, entonces sí ha muerto. Pero la conciencia de "en qué etapa del proceso estamos" es más importante que nunca.

Atar el proceso de diseño a un medio específico, ahí es donde está el peligro. Los diseñadores ahora tienen más herramientas: pueden poner cosas directamente en el producto existente, hacer pruebas A/B. Muchas empresas tienen versiones bebé de sus productos, baby Cursor, baby Codex, una base de código muy simplificada que simula todas las interacciones del producto real. Puedes usarlo para "vibe code" (codificación por intuición), diciendo "¿y si la barra lateral se ve así? ¿Y si aparece un panel?". Esta es la nueva herramienta del diseñador, pero requiere la antigua conciencia: ¿dónde estás en el proceso ahora?

Los puestos y roles se están fusionando, pero los PM no desaparecerán.

Lenny: Muchas empresas dicen que "los roles están desapareciendo". ¿Crees que la división entre PM, ingeniero y diseñador desaparecerá por completo?

Andrew Ambrosino: Algunas empresas gustan de seguir las tendencias y llegar a extremos. El peligro de eliminar el concepto de rol es que también podría eliminar la noción de que estas áreas son profesiones con mejores prácticas que se pueden aprender.

He oído a muchas empresas decir "vamos a eliminar el rol de producto", y creo que es una pésima idea, y luego decir "todos son constructores". El resultado es que la gestión de productos, que ya había acumulado verdaderas mejores prácticas y lecciones aprendidas, es directamente desechada. Porque alguien escribió unas líneas de código y cree que todo está bien, ese no es un buen estado.

Doy la bienvenida a que desaparezcan los límites de "esto no es tu área, no puedes tocarlo", pero se necesita equilibrio. No todo el mundo puede hacer todo, ni en amplitud ni en profundidad, y por eso los gerentes no desaparecerán.

Además, cada disciplina tiene un componente de habilidad. Muchos ingenieros no reconocen esto, piensan que la ingeniería tiene habilidades y que los demás roles son "ambiente". No es así, saber usar Excel no significa que puedas trabajar en finanzas.

Creo que lo que está sucediendo ahora es más que la gente colabora más fácilmente entre roles, y es más fácil aprender las mejores prácticas de otras áreas, sin necesidad de atar tu eficiencia en un rol con la capacidad de usar una herramienta específica.

Pasé mucho tiempo pensando que no debería ser ingeniero de software porque no me importaba el lenguaje ensamblador ni quería recordar el sistema de tipos de TypeScript. Siempre hubo barreras en estos roles, como si "ser bueno en este rol equivaliera a dominar esta herramienta". Creo que esto está empezando a disolverse, pero la gente lo exagera.

Lenny: En tu equipo de Codex, ¿hay una mayor fusión de roles? ¿Cómo es exactamente?

Andrew Ambrosino: En el equipo de Codex, ciertamente vemos una mayor fusión de roles que en otros equipos de la empresa y en otras industrias. En parte, porque es un producto técnico dirigido a ingenieros. Así que nuestros diseñadores hablan el idioma de los ingenieros, nuestros product managers hablan el idioma técnico y saben programar.

Internamente, tenemos una forma de describir la colaboración: hoy en día, la superposición entre roles es mucho mayor que en el pasado. Definir a una persona ya no se basa en los límites de responsabilidad como "dónde termina el diseño y dónde comienza la ingeniería", sino en la distribución promedio de todo su trabajo.

Si tomas todas las cosas que hace alguien en el equipo de diseño, puede incluir mucho trabajo de programación y también mucho trabajo relacionado con el producto. Pero si tomas el "promedio" de esas tareas, al final seguirá cayendo en un área más orientada al diseño.

Lenny: Mencionaste que el trabajo del product manager es más como una "defensa de zona". ¿Qué significa exactamente?

Andrew Ambrosino: Si dos product managers colaboran demasiado estrechamente, generalmente no es una buena señal. Más bien, deberías ver el equipo como un diseño de fuerzas dirigidas: ¿dónde hay vacíos? ¿Qué áreas no están cubiertas?

En el mundo de hoy, la curaduría, la orientación y la alineación se han convertido en el trabajo más importante. Todos están constantemente lanzando ideas, todo el entorno está lleno de ruido. La forma de arriba hacia abajo y de planificación anual ya no funciona. Necesitamos a alguien que actúe como guardián del gusto, que guíe algo desde el concepto hasta el producto, y eso significa que debes cubrir todos los rincones de la empresa.

Por lo tanto, debes extender el equipo y ver quién es bueno en qué. Mantener cierta distancia entre ellos para asegurar una cobertura completa. Luego llenar los vacíos, por ejemplo: "Queremos contratar a un ingeniero con una mentalidad muy de producto". No queremos que un grupo escriba mucho código y luego todo el equipo de producto tenga que revisar y ajustar la consistencia del producto. Queremos que todos tengan estas habilidades, solo que sus áreas de profundización deben cambiar.

Lenny: Entonces, la persona más valiosa ahora es la que puede impulsar todo desde la idea hasta la finalización y tiene el gusto para saber "esto es genial"?

Andrew Ambrosino: Sí, creo que este es el cambio central en este momento. Esto también refleja mi comprensión de la relación entre IC (contribuyente individual) y gerente. No es que la gerencia vaya a desaparecer, ni que todos sean solo IC, sino que ahora cada persona desempeña ambos roles hasta cierto punto.

Si eres IC, ya no estás escribiendo código carácter por carácter. En realidad, estás gestionando algo: gestionando agents, gestionando el trabajo organizado para completar tareas. Si eres gerente de equipo, haces esencialmente lo mismo, solo que con un nivel de granularidad diferente.

Las personas que busco, además de tener habilidades sólidas en su área, deben tener gusto. Porque en un mundo de "tokens ilimitados", no podemos producir contenido basura. Debes tener la capacidad de distinguir señales del ruido en medio de un mar de contenido.

Cada vez que alguien pregunta cuántas personas hay en el equipo de Codex, mi respuesta es: "Entre 10 y varios miles". Suena como una broma, pero en realidad, el trabajo de todos converge en este producto: investigación de modelos, uso del navegador, personalidad del modelo, infraestructura frontend, experiencia de usuario, todo forma parte del producto.

Pero al mismo tiempo, no estamos recibiendo PR (solicitudes de extracción) de miles de personas todos los días. El equipo tiene decenas de ingenieros, el número de diseñadores es aproximadamente la mitad del de ingenieros, más algunos product managers, la mayoría son IC. El impacto del equipo es grande, pero la jerarquía gerencial no es espesa. Aquí hay muchas personas que han fundado empresas, muchas que trabajan con "mentalidad de fundador" en grandes empresas, y muchas personas con un gusto excelente.

Toda la aplicación Codex ha sido moldeada por el ciclo de dogfooding. Todos compartimos el deseo de hacer todo lo posible dentro de la aplicación, incluso si temporalmente no es la mejor herramienta, porque solo así tendrá la oportunidad de ser la mejor. A menudo evitamos mejorar ciertos procesos internos, dejando que el producto mejore por sí mismo para soportar esos procesos. Esto es un estado muy incómodo. Pero semana tras semana, continúa cambiando.

Si Codex se hubiera lanzado tres meses antes, habría muerto; la única diferencia fue la mejora del modelo.

Lenny: Con un ritmo de cambio tan rápido, ¿cómo hacen la planificación? ¿Hasta dónde miran?

Andrew Ambrosino: No tenemos nada revolucionario en la planificación. El principio básico es que cuanto más cercano al presente, más específica debe ser la planificación. No es que no hagamos planes a nueve meses, sino que esos planes deben mantenerse muy vagos. Porque cualquier precisión que agregues a un plan de nueve meses es precisión falsa, solo perderás tiempo.

En el lado de la aplicación de producto, lo que puedes planificar en noviembre puede seguir siendo correcto en diciembre, pero para febrero ya no lo será en absoluto.

En mi empresa anterior, cuando empezamos a impulsar el desarrollo de funciones basándonos en las capacidades del modelo, el proceso de producto existente básicamente colapsó. Luego se transformó en: listar todas las direcciones de interés, hacer prototipos, determinar cuáles ya son factibles, y aplazar las demás. Cada vez que las capacidades del modelo daban un salto, sacábamos las cosas aplazadas y las probábamos de nuevo. Porque la premisa de si una función es lo suficientemente buena a menudo no es la forma de la función en sí, sino si el modelo es lo suficientemente inteligente. Mucha gente ha estado insatisfecha con mi forma de planificar. Pero es algo realmente difícil.

Lenny: ¿Hay un ejemplo concreto de lo importante que es el momento?

Andrew Ambrosino: Hay una buena historia sobre Codex. Estoy muy seguro de que la aplicación Codex que lanzamos en febrero, si hubiera estado lista en noviembre y se hubiera lanzado, habría fracasado por completo en el mercado. La única diferencia es que el modelo mejoró entre noviembre y febrero. El mismo producto, exactamente la misma forma, resultados completamente diferentes, solo por unos meses de diferencia.

Lenny: Entonces, ¿lo que ahora no funciona podría funcionar más adelante? ¿Hay que mantener una mayor ambición?

Andrew Ambrosino: Sí. Recomiendo a la gente que no juzgue fácilmente "esto ahora no funciona, así que es una mala función"; puede que simplemente no haya llegado su momento.

Volviendo al lanzamiento inicial de Codex, Codex web. Básicamente le das una tarea al modelo, él la hace y vuelve con el resultado. No suena radical, pero el problema es que no lo hacía lo suficientemente bien, esa forma era demasiado adelantada a su tiempo.

Luego llegó Claude Code, completamente local, sin conexión a la nube, sin fingir ser demasiado AGI. Te hace preguntas, espera allí, no puedes delegarle toda tu vida. Es mucho más útil porque coincidía con el nivel de capacidad del modelo en ese momento.

Nosotros estábamos demasiado "AGI", a menudo pienso en esta lección. Antes, el fracaso de un producto en el mercado a menudo te decía mucho sobre la forma del producto o la forma de comunicarlo. Ahora es diferente, puede que necesites lanzar la misma cosa seis veces hasta que tenga éxito, y la forma puede no cambiar en absoluto.

El navegador dentro de la aplicación también es así. Una vez tuvimos una versión funcional, en la época de Atlas, ya teníamos agentes ejecutando tareas en el navegador. Antes de eso, estaba Operator en ChatGPT, que no tuvo éxito. Pero si conectas Operator, Atlas, Codex y ChatGPT, verás que en realidad se puede trazar una línea de evolución continua. Es esencialmente la misma función, solo que con cambios en el nivel de inteligencia, ha sido relanzada repetidamente, y los resultados han cambiado por completo.

Una vez que un producto o función ya existe, la gente tiende a centrarse en varios problemas de detalle y microoptimizaciones, y deberían hacerlo. Pero también es por eso que siempre mantenemos una cultura de exploración de abajo hacia arriba. Porque a veces, así como la aplicación Codex revolucionó ChatGPT de alguna manera, el propio Codex puede ser revolucionado por nuevos intentos en el futuro. No puedes esperar que el mismo equipo produzca innovaciones disruptivas de manera continua y al mismo tiempo se centre en la calidad del producto y los detalles de pulido. En algún momento, debes diseñar un mecanismo para que ambas capacidades coexistan.

Lenny: ¿Cuál es la visión de Codex? ¿Hacia dónde lo llevas?

Andrew Ambrosino: En enero y febrero de este año, durante las pruebas internas de autoutilización, encontramos un claro PMF en los flujos de trabajo de ingeniería e investigación. Pero al mismo tiempo, personas de marketing, comunicación, finanzas y legal también usaban Codex, aunque la aplicación no era amigable para ellos, les mostraba código y les pedía aprobar la ejecución de herramientas de búsqueda en línea de comandos.

Intentamos agregar las capacidades de Codex a otros productos: la aplicación de escritorio de ChatGPT, el navegador Atlas. Y lo más molesto ocurrió: nadie quería salir de la aplicación Codex para usar esos productos supuestamente diseñados para ellos.

La lección que sacamos es que hay muchas sutilezas en común entre las herramientas para desarrolladores y las herramientas para el trabajo general del conocimiento. Realmente creemos que la forma de producto que estamos construyendo es la forma correcta para albergar varios escenarios verticales profundos. Comenzar simple y luego agregar complejidad según sea necesario.

No es un producto del tipo "dibuja un rectángulo en la pantalla y todo debe hacerse dentro de él". Es más bien un campamento base donde comienzas tu trabajo, lo terminas, gestionas automatizaciones, y él invoca todas las herramientas que necesitas. Alguien llamó a esta forma "super app", y desearía que no lo hubieran hecho, porque ahora oigo esa palabra casi todos los días.

Dan Shipper tuvo una idea muy interesante: piensa que en el futuro usaremos herramientas SaaS "desde adentro hacia afuera" dentro de Codex. Notion, Linear, Salesforce no se abren en el navegador, sino que un agent las opera dentro de Codex. Y nosotros también estamos haciendo esto: navegador dentro de la aplicación, extensión de Chrome, uso de computadora (computer use), todas son formas de que Codex interactúe con herramientas externas.

Un ejemplo excelente: nuestro productor de video interno, Brent, usó Codex para editar el video de lanzamiento de Codex. Codex no es un editor de video, no tiene esa interfaz de usuario. Pero entiende que Brent usa Premiere Pro, y puede hacer modificaciones editando los archivos detrás de Premiere Pro. Cuando descubre que no puede hacer todo, él mismo escribe una extensión para Premiere Pro, la instala, y luego se comunica con Premiere Pro a través de esa extensión. Nos quedamos impactados al verlo.

Es un buen patrón: herramientas profesionales hacen cosas profesionales. Codex no necesita ser un mejor editor de video; solo necesita interactuar sin problemas con las herramientas profesionales.

Saber escribir código ya no es importante; saber borrar código es lo importante.

Lenny: Desde código escrito a mano hasta código 100% escrito por IA, y ahora los agents y los loops. ¿Cómo trabajan realmente los equipos más avanzados hoy?

Andrew Ambrosino: ¿Loops? Eso fue la semana pasada.

Seguimos discutiendo el problema de "¿qué porcentaje del producto está escrito por IA?". Según los estándares del año pasado, ahora el 100% de nuestro código está escrito por IA. Así que la pregunta ya no es "cuánto está escrito por IA", sino "si el código se escribe bajo supervisión o sin supervisión", una dimensión completamente diferente. Doy la bienvenida a que estos estándares se renueven constantemente, porque significa que estamos logrando avances en el producto.

Hemos explorado mucho en el desarrollo autónomo de software, por ejemplo, mucha ingeniería de arneses (harness engineering), como "¿y si el modelo hace automáticamente recolección de basura y limpieza del código base durante la noche?".

Pero actualmente todos los modelos tienen un problema: siempre aumentan la complejidad. Si los investigadores están escuchando: por favor, enseñen a los modelos a borrar código. Cuando intentas dejar el desarrollo completamente en modo autónomo, esto se convierte en un problema grave, tanto a nivel humano como a nivel del código base.

Las solicitudes de funciones (feature requests) también son así. ¿Cómo le enseñas al modelo a juzgar qué funciones vale la pena hacer, cuáles ignorar, cuáles fusionar y redefinir? ¿Y cómo le enseñas a construir la abstracción correcta?

Estas capacidades están mejorando continuamente. Pero no creo que hayamos llegado a una etapa en la que puedas configurar un loop para que el modelo mejore automáticamente la aplicación, escuchando constantemente Twitter, Slack y correos electrónicos, y luego iterando de forma autónoma. Aunque estamos intentando hacerlo realidad.

Lenny: ¿Crees que llegaremos a ese punto? Es decir, establecer un objetivo: "ganar".

Andrew Ambrosino: "/goal gáname mil millones de dólares". No lo sé. No diré que nunca sucederá o que siempre sucederá.

Lenny: Como responsable de producto e ingeniería, ¿cómo usas tú mismo la IA para trabajar?

Andrew Ambrosino: Creo que ahora tengo posiblemente el mejor trabajo del mundo.

Cuando empecé con Codex, mi objetivo personal era que fuera lo suficientemente bueno como para que yo pudiera usarlo para escribir el código de Codex. Era un ciclo de autoutilización muy estrecho: no podía hacer algo, lo arreglaba, luego podía hacerlo, y luego podía hacer más cosas.

Luego mi rol cambió. Necesitaba hacer más descubrimiento de producto, entender qué estaba haciendo el equipo, corregir desviaciones. Así que Codex se convirtió en mi herramienta para hacer estas cosas. "Ayúdame a crear una hoja de cálculo para organizar estos datos." "Ayúdame a hacer una investigación profunda interna para ver qué exploraciones se han hecho en esta dirección en el pasado."

La serie de lanzamientos de mayo: navegador dentro de la aplicación, uso de computadora (computer use), creación de artefactos (artifact creation), fue la primera vez que usamos "vibe coordination" (coordinación por intuición) para gestionar un lanzamiento. Tenía un documento de Notion con todas las tareas pendientes, y usaba Codex para ir automáticamente a los PR, canales de Slack para recopilar progreso y actualizar el rastreador de estado. En ese momento, sentía que era la forma más avanzada de gestionar el lanzamiento de un producto.

Ahora, cada mañana, veo el informe diario que Codex genera para mí, filtrando lo que necesita mi atención de los 3000 canales de Slack a los que me he unido. Puedo responder "dame cinco preguntas, yo las respondo". Se autoajusta: si digo "la próxima vez, céntrate menos en este flujo de trabajo" o "esto ocurrió pero no apareció en el informe, asegúrate de capturarlo la próxima vez", actualiza la forma de notificar y ajusta el foco de atención.

Lenny: ¿Cómo se configura eso? ¿Cuál es el flujo de trabajo?

Andrew Ambrosino: Todavía está en fase de descubrimiento. Es básicamente una tarea programada: "revisa mis canales de Slack, estas son las cosas que me importan, clasifícalas según estas categorías, aquí hay algo de contexto". Las primeras veces puede necesitar orientación. La ventaja es que no necesito buscar cómo editar las instrucciones; le digo directamente "la próxima vez, cámbiame esto", y lo actualiza.

Pero creo que este es también el problema central de la forma de chatbot. Sé cómo configurarlo porque para mí esto es descubrimiento de producto. Pero si no trabajas en OpenAI ni desarrollas esto, no querrás averiguarlo. Necesitamos pensar cómo hacer que estas formas sean accesibles para la gente común.

Lenny: Yo también usé Codex para hacer una automatización de filtrado de spam. Uno de los pasos era ir a la consola de Google Cloud para configurar un montón de activadores de API, y esa interfaz era muy molesta. Le pedí a Codex que lo hiciera por mí, y tomó el control de mi computadora directamente usando la función "computer use".

Andrew Ambrosino: Es como: "No me importa si tienes conectores, amigo, empiezo a hacer clic".

Es muy interesante cómo se dividen los límites entre conectores, navegador dentro de la aplicación, extensión de Chrome y computer use. Muchas veces, estos límites se determinan por intuición.

Creo que estos flujos de trabajo personales son particularmente interesantes. Cada uno está probando cosas diferentes, y cada persona construirá sistemas completamente distintos. Pero gradualmente, surgirán algunos patrones comunes. Entonces nos daremos cuenta: "Esto debería ser una experiencia de primera clase en el producto".

Por ejemplo, la memoria (memory). Mucha gente configura una base de conocimientos de Obsidian o un espacio de Notion para construir su palacio mental. No deberías tener que hacerlo tú mismo; debería haber una función de memoria lo suficientemente genérica que lo haga por ti. Hemos estado seleccionando: qué es efectivo a nivel personal pero debe quedarse a nivel personal, y qué debería entrar en el producto como componente básico.

Lenny: Desde fuera, la gente solo ve que estás ganando. Pero seguro que ha habido cosas que no funcionaron.

Andrew Ambrosino: Es gracioso que lo digas. Esta es la primera vez que siento que no estoy fracasando.

Antes emprendí durante muchos años, y al final básicamente desmantelé y vendí la empresa. Trabajar en industrias altamente reguladas fue un fracaso constante. Luego fui a otra startup, haciendo herramientas de IA en otra industria cerrada y regulada, y una y otra vez no funcionaba. En realidad, he fracasado mucho. A veces es solo cuestión de tiempo: las habilidades, la pasión y la ventana de mercado se alinean.

Incluso ahora, en este proyecto de combinar Codex con ChatGPT, hay innumerables pequeños fracasos. Decimos "debería verse así", lo publicamos en Slack, y luego hay 2000 mensajes diciendo lo estúpidos que somos. Eso es lo que me gusta de OpenAI: la gente nos dice directamente, y no tienen piedad con los fracasos de los productos internos, y por eso los productos externos están bien. Antes de llegar a donde estoy ahora, fracasé entre 10 y 15 años. Así que todavía me sorprendo un poco cada día de que las cosas estén yendo bien.

Lenny: ¿Algún consejo final para los lectores?

Andrew Ambrosino: No te cases con tu flujo de trabajo actual. Lo que realmente debes mantener son los resultados que solo tú puedes entregar de manera única. Luego, sigue intentando cambiar tu proceso. Si tu habilidad de la que más te enorgulleces es "soy el mejor en auto layout de Figma", ¿qué estás haciendo? La IA será mejor que tú también. Encuentra cosas que valgan la pena hacer, y luego encuentra la manera de hacerlas.