OpenAI revela cómo trabaja su equipo FDE: el 90% del código a medida acabó en skills de Codex

OpenAI ha publicado un análisis de cómo trabajan sus forward deployed engineers (FDE). El equipo se formó a principios de 2025 para resolver un problema concreto: sobre el papel el modelo sabe hacer mucho, pero las personas todavía no pueden apoyarse en él en su flujo de trabajo. Eso es el «deployment gap». Resultados de cuatro proyectos: de 3 a 6 meses hasta producción en semiconductores, un 50% más de capacidad de procesamiento para contables fiscales, un modelo de voz que sube del 60% a más del 90% en los evals clave y cerca del 90% del código a medida descartado tras el lanzamiento de Codex.

El lema del equipo es: empieza por el resultado, haz lo necesario para lograrlo y escala después. Igor Akimov, autor del canal AI Product, señala que los proveedores hablan a coro de modelos superinteligentes, pero faltan implantaciones por verticales. Según su estimación, hoy los tokens los queman sobre todo las startups con dinero ajeno. Los FDE trabajan justo donde esa brecha hay que cerrarla a mano.

Chips, impuestos y telecom: cuatro casos con cifras

• Ingeniería de semiconductores, mediados de 2025. Unos 15 FDE trabajaron en más de 10 casos de uso: generación de pruebas, búsqueda de causas de fallos y un asistente de arquitectura. La verificación consume en el sector cerca del 70% del esfuerzo de un proyecto. Parte de los ingenieros llegó a OpenAI pocos días antes del arranque y no sabía de chips. Se sentaron con los ingenieros del cliente, estudiaron el dominio y construyeron las métricas juntos. En 3–6 meses todos los casos de uso llegaron a producción. Resultado: cerca de un 48% de ahorro de tiempo en la generación de pruebas, una mejora de rendimiento mediana del 22% en la optimización de kernels y semanas de depuración reducidas a horas.
• Migración a Codex. Cuando Codex maduró, todos los casos de uso se trasladaron a una capa común con Codex en el centro. Las aplicaciones a medida pasaron a ser plugins y skills, y se eliminaron las CLI y las interfaces propias. En cada proyecto se descartó cerca del 90% del código a medida. En uno de los casos, la primera implantación tardó 2 meses y la ampliación a un segundo equipo, 1 día.
• IA fiscal para las firmas contables de Thrive Holdings. En el piloto se procesaron 7 000 declaraciones y la capacidad de procesamiento aumentó en torno a un 50%. Las más difíciles resultaron ser las declaraciones de operaciones inmobiliarias: hicieron falta 6 semanas de ingeniería y revisiones por parte de profesionales para alcanzar un 90% de precision y recall.
• Voz para telecomunicaciones. La voz representa cerca del 90% de las consultas de soporte. El modelo alcanzaba cerca del 60% en los evals clave, algo insuficiente para producción. Se sumó el equipo de Research: en 6 meses llevó el resultado al 80% y después a más del 90%. Ese modelo de voz ya funciona también con otros clientes.

El código a medida dura medio año

Lo más interesante desde el punto de vista de la ingeniería es la historia de Codex. Los proyectos se construyeron sobre aplicaciones, CLI e interfaces propias: cada cliente tenía su propio conjunto de capas. En cuanto la plataforma aprendió a encargarse de la orquestación, todo eso se convirtió en plugins y skills. La diferencia entre 2 meses para la primera implantación y 1 día para la ampliación muestra dónde se acumula el coste. Cuanto menos código único hay en un proyecto, más barato resulta cada nuevo cliente o equipo.

Hay también un cambio de arquitectura. Según Akimov, OpenAI ha pasado de un esquema multiagente a un solo agente con skills. Es exactamente lo que recomendaba Anthropic. Los dos mayores laboratorios convergen en un mismo patrón: un agente más un conjunto de habilidades conectables.

Para la economía de los tokens, la conclusión es directa. Mientras alrededor del modelo crece una capa de lógica propia, aumentan los costes de mantenimiento y el riesgo de que, dentro de seis meses, la plataforma ofrezca lo mismo de serie. En el equipo lo adoptaron como principio de trabajo: el criterio de éxito de un FDE es volverse innecesario cada par de meses. Cuando Codex empezó a montar de una sola vez lo que los ingenieros construían en meses, la pregunta «qué hacer» tuvo una respuesta sencilla: buscar un problema más difícil.

Qué debe llevarse el integrador

Hay tres activos duraderos: el conocimiento del dominio, los datasets y las métricas construidos junto con los expertos del cliente, y la comprensión de dónde el modelo no da la talla. El caso fiscal lo confirma: el 90% de precision y recall en operaciones inmobiliarias no lo lograron las funcionalidades, sino seis semanas de revisiones por parte de profesionales. El caso de la voz lo muestra desde el otro lado: pasar del 60% a más del 90% exigió incorporar a Research. Para el responsable de producto y el integrador, de aquí se derivan pasos prácticos:

• empezar por evals y métricas acordados con los expertos del cliente, no por la interfaz;
• construir la solución sobre primitivas de la plataforma (skills, plugins), no sobre CLI propias;
• mantener un solo agente con skills mientras la multiagencia no demuestre su necesidad en las métricas;
• asumir que la capa de orquestación habrá que reescribirla cada pocos meses.

A los desarrolladores que temen que Codex les quite el trabajo, este análisis les responde así: el valor se desplaza hacia el planteamiento de las tareas y la medición de la calidad. Eso es justo lo que hacían las personas que, una semana antes del arranque del proyecto de chips, no sabían nada de chips.