Cuando salió Codex, alguien del equipo me preguntó: «¿Qué hacemos cuando Codex pueda resolver de un solo intento (one-shot) los casos de uso que llevamos meses construyendo?»
Esa pregunta llega al corazón de lo que significa FDE en OpenAI. Trabajamos junto a los clientes para entender sus problemas más difíciles y construir soluciones en las que puedan confiar. Lo que aprendemos ayuda a dar forma a nuestros productos y le da a Research problemas concretos que resolver.
Eso es progreso. Si nos volvemos obsoletos cada dos meses, nuestro equipo de FDE está haciendo su trabajo.
Fundé el equipo a principios de 2025 para cerrar lo que llamamos «la brecha de despliegue»: la distancia entre lo que los modelos parecen capaces de hacer y lo que las personas pueden usar de manera confiable para realizar su trabajo.
Las capacidades de los modelos han avanzado más rápido que los sistemas y procesos necesarios para ponerlas en uso. A veces la pieza que falta es un producto. A veces un modelo rinde bien en un benchmark pero no puede hacer el trabajo con variables y restricciones de la vida real.
Nos enfocamos en los problemas más difíciles de los clientes. Donde nuestros modelos pueden hacer el trabajo hoy, trabajamos con Product y con el cliente para hacer la solución repetible y, donde se quedan cortos, trabajamos con los clientes y con Research para definir la brecha y lograr mejoras. Nuestro objetivo es que cada compromiso deje al siguiente cliente un mejor punto de partida: si elevamos el nivel mínimo hasta el punto de que nuestros clientes no necesiten FDE para resolver esta clase de problema la próxima vez, habremos hecho bien nuestro trabajo.
El desafío para John Deere, un negocio agrícola de 200 años, era cómo escalar el asesoramiento personalizado para los agricultores.
Un ejemplo es See & Spray, su tecnología de control preciso de malezas, que usa cámaras y aprendizaje automático para identificar y rociar malezas en lugar de tratar campos enteros, reduciendo el uso de químicos hasta en un 70%.
Pero materializar esos beneficios depende de que los agricultores sepan cómo configurar la tecnología, planificar su temporada y ajustar sus prácticas a medida que cambian las condiciones.
John Deere desplegó las APIs de OpenAI para ayudar a que ese soporte fuera personalizado y escalable.
La IA puede responder las preguntas de los agricultores en lenguaje natural, proporcionar orientación y recomendaciones de configuración personalizadas, identificar cuándo los equipos pueden no estar ofreciendo todo su potencial y ayudar a los agricultores a entender el valor que obtienen de la tecnología.
La oportunidad va más allá de una sola interacción: ofrecer orientación relevante a lo largo de todo el recorrido del cliente, ayudando a los agricultores a aprovechar mejor sus equipos mientras se mejora la eficiencia y la sostenibilidad.
Este es el tipo de desafío que los FDE de OpenAI trabajan por resolver: ayudar a las organizaciones a pasar de capacidades de IA a sistemas que ofrezcan valor práctico en entornos complejos del mundo real.
Pero los problemas suelen estar totalmente abiertos, puede que no exista una verdad fundamental establecida y no hay un manual. Todos quieren construir algo que nunca ha existido. Menos personas quieren hacer lo necesario para llegar allí.
Encontrar FDE con talento mientras se eleva el estándar de «suficientemente bueno» ha requerido experimentación y aplicación constantes.
Comenzar con el resultado
Al inicio de cada sesión del equipo de FDE, proyecto una diapositiva con un valor central: «Comenzar con el resultado, hacer lo necesario para tener éxito y luego seguir con la escala».
Una demo impresionante puede recorrer un largo camino antes de que alguien pregunte si funciona en el mundo real.
Nuestro trabajo es resolver el problema del cliente con un estándar que podamos respaldar en producción.
A mediados de 2025, teníamos alrededor de 15 FDE trabajando con un gran cliente de semiconductores en más de 10 casos de uso. La ambición era hacer que su proceso de verificación fuera nativo de IA, cubriendo:
Generación de pruebas dirigidas
Análisis de causa raíz y depuración
Un asistente de arquitectura
La verificación puede representar alrededor del 70% del esfuerzo de un proyecto en esta industria. La oportunidad era enorme y había muchos lugares posibles por donde empezar.
Algunos FDEs se habían unido a OpenAI apenas días antes y nunca habían trabajado en semiconductores. Se integraron con el equipo de verificación del cliente, estudiaron el diseño de chips en su tiempo libre y construyeron evals con los ingenieros para probar si la IA podía generar pruebas útiles y diagnosticar correctamente fallos de chips.
Junto con ese aprendizaje, construimos harnesses personalizados para los casos de uso individuales. Durante los primeros 3-6 meses, todos ellos llegaron a producción y lograron una adopción temprana por parte de los usuarios. La recompensa fue ver las métricas:
~48% de tiempo ahorrado mediante generación dirigida de pruebas basada en IA.
22% de mejora mediana en el rendimiento mediante optimización de kernels.
Semanas de depuración comprimidas en horas
Cuando reprodujimos todo esto, el Director de Hardware preguntó: “¿Trabajaron como diseñadores de chips antes de venir aquí?”
Nuestros FDE no necesitan conocer la industria desde el primer día, pero es su responsabilidad aprenderla.
A medida que los asistentes de programación hacen que el software sea más rápido de construir, comprender el negocio del cliente se vuelve aún más importante. Construimos equipos con una mezcla de generalistas y expertos en dominios.
Necesitas suficiente conocimiento para tomar juicios sólidos, y suficiente curiosidad para cuestionar los supuestos sobre el statu quo.
En ciencias de la vida, por ejemplo, las formaciones científicas de nuestros FDE les ayudan a ganarse la confianza de investigadores que trabajan en tareas de descubrimiento preclínico de fármacos, como la validación y priorización de dianas, el análisis de expresión génica y la reconstrucción de rutas de síntesis química. Esa experiencia les permite aportar un juicio informado sobre cómo podrían mejorar esos flujos de trabajo.
Hacer que el éxito sea repetible
Habíamos demostrado que estos flujos de trabajo podían entregar valor, pero cada uno aún requería demasiada integración personalizada para extenderlo a otro equipo. El siguiente desafío era preservar esos resultados mientras hacíamos el software más fácil de desplegar y mantener.
Para entonces, Codex había crecido en capacidades. Un FDE probó reconstruir su aplicación alrededor de este, y luego trabajó con el equipo para trasladar los casos de uso a un arnés común con Codex en su núcleo.
Las aplicaciones personalizadas se convirtieron en plugins y skills construidos sobre primitivas comunes de Codex. Codex también se convirtió en la interfaz, lo que nos permitió retirar las UIs de terminal y las CLIs separadas que habíamos escrito para casos de uso individuales.
Pudimos eliminar aproximadamente el 90% del código personalizado de cada proyecto, y esto cambió cómo construimos, mantenimos y escalamos estos flujos de trabajo:
Podíamos beneficiarnos de las mejoras centralizadas de Codex, reduciendo la cantidad de código de pegamento necesario para cada caso de uso individual
Las funcionalidades clave se empaquetaron como skills y plugins, lo que facilitó compartirlos entre nosotros y controlarlos de forma centralizada por el AI CoE. Esto significaba que extender de un equipo al siguiente podía ser tan simple como cambiar conectores/servidores MCP, construir evals nuevas (para lo cual también teníamos un skill) y ponerse en marcha.
En un ejemplo de agosto de 2026, el despliegue inicial tomó dos meses. Extender la solución a un segundo equipo tomó un día. Los siguientes equipos se incorporaron más rápido a medida que escalábamos—esto ha continuado, con un caso de uso en agosto de 2026 que tomó 1 día para el segundo equipo después de que el despliegue inicial tomara 2 meses.
Esa es una versión de hacernos obsoletos. El trabajo que hicimos para llegar a producción estableció lo que importaba. A medida que el producto subyacente mejoraba, pudimos reemplazar gran parte de nuestra implementación personalizada y conservar el valor que entregaba.
Por eso el orden importa. Los LLM nos permiten construir rápido. Usa esa velocidad para poner algo valioso en manos de los usuarios, aprender qué se sostiene en la práctica y luego escalar lo que funciona.
El mismo principio se aplica en todos los compromisos.
OpenAI Presence, nuestro producto para agentes de voz y chat empresariales, surgió de despliegues reales con clientes. El trabajo comenzó con Swarm(se abre en una nueva ventana) y evolucionó a través de la Agents API, y hoy un cliente gestiona más de la mitad de sus llamadas con IA.
Llevar esos despliegues a producción nos enseñó qué problemas necesitaban una solución personalizada y qué bloques de construcción podrían usar otros equipos. Incorporamos esos bloques en Presence, facilitando que los desarrolladores automaticen flujos de trabajo regulados sin reconstruir la infraestructura subyacente. Cada despliegue ayudó a dar forma al producto y dio al siguiente cliente un mejor punto de partida.
Con Thrive Holdings, los FDE e investigadores de OpenAI trabajaron junto a ingenieros y contadores para construir Tax AI para las firmas contables de Crete. Durante su piloto, Tax AI procesó 7,000 declaraciones de impuestos y aumentó el rendimiento en aproximadamente un 50%.
Uno de los desafíos más difíciles fue automatizar las declaraciones de propiedades en alquiler, lo que requirió seis semanas de ingeniería y revisión de profesionales para alcanzar un 90% de precisión y exhaustividad. El trabajo creó patrones reutilizables que facilitaron extender Tax AI a otros formularios fiscales complejos.
Los equipos ahora están aplicando el mismo enfoque a la contabilidad, la auditoría y el soporte de TI—construyendo sistemas que mejoran mediante comentarios de profesionales y uso en el mundo real.
Cerrar las brechas de inteligencia a medida que aparecen
A veces un mejor producto nos permite simplificar lo que construimos, pero a veces el propio modelo todavía no puede hacer el trabajo.
Si solo construimos lo que los modelos de hoy ya hacen posible, no descubriremos las brechas de inteligencia que Research debe cerrar a continuación. Por ello, muchas de nuestras colaboraciones más importantes comienzan en esos límites, con el cliente, el FDE y Research comprometidos a superarlos juntos.
Ya habíamos desarrollado una plataforma de atención al cliente con un gran cliente de telecomunicaciones, y querían extenderla a la voz.
La voz representaba alrededor del 90% de su volumen de atención al cliente. Estos casos eran más costosos de contener que el chat, y planteaban una serie de nuevos desafíos técnicos para llevar los acentos, el tono y la latencia/precisión a un nivel de producción. Hacerlo bien marcaría una diferencia sustancial para su negocio.
Durante la fase de definición del alcance, nuestro modelo obtuvo alrededor de 60% en las evaluaciones clave que usábamos para determinar si podía hacer el trabajo en producción. Habíamos alcanzado los límites de sus capacidades. La llamada de funciones y el seguimiento de instrucciones en escenarios de atención al cliente necesitaban mejorar.
Se lo explicamos al cliente e incorporamos a Research al trabajo. FDE trabajó con el cliente para construir la plataforma y definir lo que el modelo debía hacer. Research trabajó en cerrar las brechas de capacidad, con sucesivas instantáneas del modelo que nos permitían medir el progreso frente a los requisitos del cliente.
A lo largo de seis meses, el rendimiento en las evaluaciones clave pasó de alrededor de 60% a 80% y luego a más de 90%, alcanzando los niveles necesarios para producción.
El modelo de voz resultante ahora respalda el despliegue de ese cliente, otros despliegues personalizados de atención al cliente y despliegues gestionados a través de Presence. Un problema encontrado en el negocio de un cliente ayudó a identificar mejoras que podrían servir a muchos otros.
Cada parte importó. El cliente se comprometió a trabajar en un problema que el modelo aún no podía resolver. FDE permaneció lo suficientemente cerca para enmarcar ese problema, construir la plataforma e impulsar el compromiso de principio a fin. Research mejoró las capacidades del modelo subyacente.
Esta es la otra versión de volvernos obsoletos: ayudar a convertir un problema que los modelos de hoy no pueden resolver en una capacidad que los modelos del futuro puedan ofrecer. El retorno de nuestro trabajo va más allá de las horas que pasamos con un solo cliente.
Ve a buscar el problema más difícil
Me uní a OpenAI para ayudar a hacer que la IA sea útil en el trabajo cotidiano de las personas. Eso sigue guiando al equipo. A menudo les digo al equipo que, en la mayoría de los casos en el desarrollo de LLM, se aplica la navaja de Occam: la solución más simple es la mejor. En una empresa definida por su investigación de vanguardia y en una industria empañada por la exageración, queremos construir cosas que funcionen de manera confiable y en las que las personas del campo puedan confiar.
El objetivo es que cada compromiso mejore lo que viene después: un producto más fácil de desplegar, un modelo capaz de manejar una tarea más difícil o menos trabajo personalizado para el siguiente cliente.
Si tienes un problema difícil que quieres resolver, nos encantaría trabajar contigo. Si quieres ayudar a resolver esos problemas, nos encantaría que te unieras a nosotros.
Entonces, ¿qué hacemos cuando Codex puede manejar el trabajo que pasamos meses construyendo?
Ve a buscar el problema más difícil.