OpenAI, Anthropic y las grandes grandes consultoras están invirtiendo miles de millones en el Forward Deployed Engineer. Detrás de este perfil y de otros dos roles cercanos, el Product Engineer y el Product Builder, hay una única línea divisoria: la barrera entre una prueba y un sistema en producción. En este artículo, Renaud Chevalier, CTO en Thiga, analiza las similitudes y diferencias entre estos tres roles.
El 11 de mayo de 2026, OpenAI puso en marcha la OpenAI Deployment Company, con una inversión inicial de más de 4 mil millones de dólares. Una semana antes, Anthropic anunciaba una nueva empresa de servicios de IA junto con Blackstone, Hellman & Friedman y Goldman Sachs. En ambos casos, el objetivo es el mismo: dejar de limitarse a vender modelos para ayudar a las empresas a integrarlos en sus operaciones.
El perfil que está ganando protagonismoa se denomina Forward Deployed Engineer. Las ofertas de empleo se dispararon más de un 800% entre enero y septiembre de 2025. Este puesto, que ahora recibe inversiones a gran escala, entra en un terreno en el que ya encontramos otros dos roles consolidados: el Product Engineer, un ingeniero que piensa en Producto, y el Product Builder, nacido del no-code antes de ser reiventado con la IA.
A primera vista, los tres se parecen: hablan con los usuarios, construyen soluciones, buscan generar impacto… Lo suficiente como para preguntarse si el sector no habrá inventado tres nombres para una misma profesión. La respuesta es no. Lo que los diferencia se reduce a un único punto: su posición respecto a la barrera que separa una prueba de un sistema en producción.
- Años 2010: Palantir inventó el Forward Deployed Engineer
- 2019: el Product Engineer antes de la IA
- 2021: el Product Builder nace en el no-code
- La barrera entre la prueba y la producción
- 2026: el regreso del Forward Deployed Engineer
- Por qué los confundimos
- Lo que los diferencia
- Juez y parte: conviene estar alerta
- Ninguno de los tres trabaja solo
- Un vocabulario para no creer en la magia
Años 2010: Palantir inventa el Forward Deployed Engineer
Enviar ingenieros a trabajar con el cliente es casi tan antiguo como el propio software empresarial. Partes enteras de SAP R/1 se desarrollaron en las instalaciones de ICI y John Deere durante los años 70. Desde los ingenieros de preventa hasta los servicios profesionales y los integradores, los perfiles técnicos en contacto directo con el cliente siempre han existido, aunque bajo denominaciones diferentes y con cada uno centrado en una parte concreta del problema. Lo que Palantir inventó a principios de la década de 2010 fue una forma de trabajar y un nombre para definirla.
El contexto lo exigía. Sus clientes eran agencias de inteligencia incapaces de expresar sus necesidades dentro de un ciclo de discovery convencional. Las necesidades había que descubrirlas sobre el terreno, en contacto directo con los datos y las operaciones del cliente.
Este modelo rompe con lo establecido en dos aspectos. El primero: prescindir de intermediarios. Tradicionalmente, el software empresarial se despliega siguiendo una estructura triangular: el proveedor vende, un partner integra y el cliente opera. Palantir rompe ese triángulo y envía a sus propios ingenieros a instalar su plataforma directamente en el sistema de información del cliente. Su organización distingue dos grandes perfiles: los Devs, que desarrollan las plataformas Foundry y Gotham, y los Deltas, que trabajan directamente con los clientes bajo el título de Forward Deployed Software Engineers. Son ingenieros que escriben código para adaptar la plataforma a la realidad sobre el terreno. Hasta 2016, Palantir llegó a tener más Deltas que ingenieros convencionales.
La segunda ruptura: lo aprendido sobre el terreno alimenta el producto. Mientras que el trabajo de un consultor o un integrador suele quedarse en el cliente, el trabajo de los Deltas vuelve a la organización y contribuye a mejorar la propia plataforma. Es este ciclo de feedback el que diferencia al FDE de los perfiles que lo precedieron.
Durante una década, esta forma de trabajar permanece prácticamente ligada a Palantir, hasta que empieza a extenderse. Scale AI y C3.ai adoptan directamente el mismo título, mientras que Databricks y Snowflake desarrollan funciones equivalentes.
2019: el Product Engineer antes de la IA
El segundo rol proviene de la cultura de la ingeniería. En las empresas orientadas al producto, la división clásica entre un PM que decide y un ingeniero que ejecuta empieza a mostrar sus límites. Aislados de la realidad sobre el terreno por sucesivas capas de procesos, los ingenieros reciben una versión edulcorada de lo que ocurre y disponen de menos contexto para tomar buenas decisiones.
La respuesta se va construyendo progresivamente. En Atlassian, el PM Sherif Mansour publica un ensayo sobre los Product Engineers. Gergely Orosz retoma la idea y publica en 2019 The Product-Minded Software Engineer, el retrato de un desarrollador que quiere entender por qué se toman determinadas decisiones y cómo utilizan las personas aquello que construye. En 2023, Vercel cambia la denominación de sus puestos: Fullstack pasa a llamarse Product Engineer. PostHog lleva el planteamiento todavía más lejos y lo convierte en un principio organizativo: allí son los ingenieros quienes lideran los equipos de producto y hablan directamente con los usuarios. Los PM no son los propietarios ni de la roadmap ni de las decisiones.
2021: el Product Builder en el no-code
El tercer rol nace dentro de la cultura de producto. Aparece a principios de la década de 2020 en el ecosistema no-code para definir un perfil híbrido entre Product Manager y experto en herramientas visuales como Webflow, Airtable o Make, que utiliza para crear productos. En España, el término también empieza a aparecer en el mercado laboral, con ofertas de Product Builder que combinan Product Management, capacidad de ejecución y uso intensivo de IA para llevar una idea hasta una solución funcional. La promesa era clara: construir sin tener que pasar por Engineering. Pero pronto se encontró con el techo del Shadow IT.
Después, la IA cambia por completo las reglas del juego. Cuando un agente puede generar código en cuestión de horas, trabajar en silos se convierte en un lujo que ralentiza el proceso. El PM especifica, el diseñador crea las maquetas, el ingeniero implementa… y, mientras tanto, el producto espera.
La respuesta más radical llega de la mano de un CPO. En LinkedIn, Tomer Cohen pone en marcha en 2024 el programa Full Stack Builder: el desarrollo de producto pasa a ser responsabilidad de un único profesional asistido por IA, en lugar de funcionar como una cadena de tareas. LinkedIn acaba institucionalizando el modelo. Su histórico programa Associate Product Manager es sustituido por Associate Product Builder, que combina en una misma formación código, Design y Product Management. El rol cuenta además con su propio recorrido profesional, abierto a cualquier persona que quiera llevar un producto desde la idea hasta el lanzamiento, independientemente de la función de la que proceda.
LinkedIn habla de Full Stack Builder, Meta de AI builders. El término empieza a extenderse: Builder pasa a designar a cualquier persona capaz de identificar un problema y movilizar la IA para resolverlo.
El Product Builder, nacido en el no-code, cambia de escala con la IA y encarna una nueva capacidad. La pregunta deja de ser "¿quién decide dentro del equipo?", para convertirse en "¿hasta dónde puede llegar una persona por sí sola?".
La barrera entre la prueba y la producción
La respuesta cabe en una sola frase. Si bien construir se ha convertido en algo trivial, operar en producción no lo es.
El mercado lo ha cuantificado. Según el MIT, el 95% de las implementaciones de IA en las empresas no producen ningún resultado medible, y McKinsey llega a la misma magnitud: ocho de cada diez empresas no obtienen beneficios concretos en sus resultados. Y lo que es más importante, el MIT señala la causa: el problema no está en los modelos, sino en su integración dentro de las empresas. Es precisamente ese paso del piloto a un sistema que funciona dentro de un sistema de información real, con sus datos legacy, sus comités y sus requisitos de compliance, donde aparece la dificultad. Es uno de los primeros aprendizajes cuantificados de esta ola de IA y dibuja una barrera entre la prueba y la producción: seguridad, escalabilidad, compliance, observabilidad y ejecución. Generar código apenas cuesta ya nada, pero este nivel de exigencia no ha cambiado.
La industria empieza a formalizar esta diferencia. Con AI-DLC, su metodología de desarrollo dirigido por IA, AWS traza una frontera clara. Los sistemas sencillos, que pueden construir perfiles no técnicos, quedan en el terreno del no-code. La metodología se centra en los sistemas complejos, aquellos que requieren arquitectura y compliance. En este enfoque, llegar a producción constituye una fase de validación en sí misma: código empaquetado, sometido a evaluaciones y probado en términos de seguridad, requisitos no funcionales y riesgos operativos. Estar prod-ready se convierte así en un verdadero nivel de cualificación.
El territorio del Product Builder se extiende desde la idea hasta la prueba. Y es amplio. Pero al llegar a la barrera, su autonomía termina. ¿Quién la cruza?
En primer lugar, el Product Engineer. Forma parte de su propia definición: arquitectura, calidad, ejecución y responsabilidad sobre aquello que está funcionando en producción. Allí donde el Builder demuestra que algo funciona, el Engineer lo lleva a producción. De los tres perfiles, es el único cuyo ownership incluye de forma natural el otro lado de la barrera y quien construye los productos complejos destinados a producción. Cuanto más rápido llegan las pruebas, más crítico se vuelve quien consigue llevarlas al otro lado. Así es como la IA, sin haber creado el rol, termina por consagrarlo.
2026: el regreso del Forward Deployed Engineer
El regreso del FDE nace de un problema al que se enfrentan los proveedores de modelos. Han prometido un valor enorme y han levantado miles de millones sobre esa promesa. Pero sus pilotos se quedan al pie de la barrera: la promesa no se materializa y el hype amenaza con volverse en su contra. Necesitan cruzar esa barrera dentro de las empresas clientes, a gran escala y rápidamente. Las consultoras y las empresas de servicios tecnológicos no tienen ni el volumen ni la velocidad necesarios, mientras que la demanda de FDE ha aumentado un 800% en nueve meses sobre una cantera de talento todavía demasiado escasa. Así que los propios proveedores están creando sus estructuras siguiendo el modelo de Palantir.
OpenAI formaliza el puesto en 2025 y lo diferencia explícitamente del Solution Architect. La descripción oficial del puesto es clara: el FDE se responsabiliza del discovery, el alcance técnico, el system design, el build y el rollout a producción, con hasta un 50% de desplazamientos. Su éxito se mide por la adopción en producción, el impacto sobre los workflows y la capacidad de trasladar aprendizajes del terreno que influyan en las roadmaps, tanto del producto como del modelo.
Es la misma lógica de feedback de Palantir, llevada mucho más lejos. Lo que un FDE aprende con un cliente puede incorporarse al producto e incluso al propio modelo de IA, beneficiando después al resto de clientes.
En mayo de 2026 se industrializa este enfoque. La Deployment Company de OpenAI reúne más de 4.000 millones de dólares y diecinueve inversores liderados por TPG, en una entidad participada mayoritariamente por OpenAI. Las grandes consultoras no han quedado fuera: han entrado en el capital. Antes, el proveedor recurría a partners para entrar en el sistema de información del cliente. Ahora son esos partners quienes invierten en el vehículo del proveedor. La empresa conjunta de Anthropic sigue una lógica similar, con Blackstone, Hellman & Friedman y Goldman Sachs.
La tendencia se extiende. Salesforce apuesta por un equipo de 1.000 FDE. Deloitte contrata a sus propios Forward Deployed Engineers (AWS», organizados en pods que trabajan directamente con los clientes sobre el stack de Amazon, mientras AWS, fiel a su nomenclatura histórica, continúa llamando a los suyos Solutions Architects. Desplegar soluciones en el entorno del cliente por cuenta del proveedor se ha convertido en toda una industria.
La estructura financiera delata lo que está en juego. Estos acuerdos van mucho más allá de una simple estrategia de contratación. Según ha publicado la prensa financiera, el vehículo de OpenAI garantizaría a sus inversores una rentabilidad mínima del 17,5 % anual durante cinco años. Una estructura así no se crea para hacer una apuesta. Se crea para asumir una obligación de resultados.
¿Por qué los confundimos?
Tres roles, tres épocas, tres culturas: la del proveedor para el FDE, la de Engineering para el Product Engineer y la de Producto para el Builder. Y, sin embargo, sus descripciones de puesto se solapan ampliamente en torno al discovery, el build, el despliegue, la medición de impacto y la autonomía.
La IA difumina las fronteras entre los roles, en todas partes al mismo tiempo. El FDE de 2026 reúne en una sola persona lo que Palantir repartía entre la plataforma y el trabajo sobre el terreno. El Full Stack Builder, por su parte, absorbe lo que antes correspondía al PM, al designer y al ingeniero. Misma causa, mismo efecto: los perfiles de competencias convergen.
Convergen hacia una forma que Kent Beck definió mucho antes de la IA: el Paint Drip. Frente al perfil en T, profundo en una única competencia, Beck propone otra imagen. El pincel recorre el lienzo —la exploración permanente— y las gotas que caen representan las sucesivas especializaciones, cuya profundidad nunca conocemos de antemano. Producto, ingeniería, negocio, evaluación: los tres roles requieren este perfil con múltiples áreas de profundidad. Cuando las competencias se solapan, parece que estamos viendo el mismo trabajo.
Lo que los diferencia
Los perfiles convergen; sus posiciones, no. Hay cuatro preguntas que permiten diferenciarlos.
La primera: ¿dónde termina el ownership? El Product Builder se detiene en la validación. El Product Engineer llega hasta la producción. El Forward Deployed Engineer lleva esa responsabilidad hasta el sistema de información de otra organización.
La segunda tiene que ver con qué parte del ciclo cubren. En la secuencia Inception, Construction, Operations que formaliza AI-DLC, el Builder domina las primeras etapas. El Engineer se responsabiliza de la construcción y después de las operaciones. El FDE, por su parte, atraviesa todo el ciclo, pero lo hace dentro del entorno del cliente.
La tercera diferencia se centra en integrar y crear. El Builder y el Engineer crean. El FDE nace como integrador antes de convertirse en creador, siendo el único que se sitúa entre ambos. Esta posición híbrida es su sello distintivo.
Queda una última pregunta que nunca aparece escrita en las ofertas de empleo: ¿quién lo envía y para quién trabaja? El Product Builder y el Product Engineer trabajan para la organización que construye el producto, ya sea como empleados o como consultores. El Forward Deployed Engineer es enviado por el proveedor al sistema de información del cliente para desplegar allí la solución de ese proveedor. Y lo que aprende durante ese trabajo alimenta la roadmap del proveedor.
Juez y parte: conviene estar alerta
Esta última cuestión merece una reflexión detenida. El FDE que entra en tu sistema de información acumula tres funciones que los procesos de compra y gobierno tradicionalmente han procurado mantener separadas. La misma persona asesora sobre tu arquitectura, te vende la solución que ha recomendado y después reporta los resultados del proyecto a la empresa que la emplea. Es, por tanto, un consultor al que le falta precisamente aquello que caracteriza al consultor: no tener un interés directo en la respuesta.
La consecuencia tiene un nombre: el bloqueo. Cada proyecto con un FDE integra el stack del proveedor en el corazón de tu sistema de información, allí donde se encuentran tus datos y tus controles. Lo que antes era una dependencia de una aplicación sustituible pasa a convertirse en una dependencia arquitectónica. Y se instala a la velocidad del FDE, es decir, rápidamente. Precisamente para eso se le paga.
La cuestión es cómo mantenerlo bajo control. Exige reversibilidad desde el contrato. Mantén evaluaciones independientes de las del proveedor, porque es él mismo quien mide su propio éxito. Y acompaña a cada FDE con tus propios Product Engineers: la transferencia de conocimiento es la única puerta de salida que está realmente en tus manos.
Ninguno de los tres trabaja solo
Hay una última lección que atraviesa las tres culturas y que contradice la fantasía del héroe solitario que transmiten estos títulos.
Palantir estructuró el rol en equipos respaldados por los equipos de plataforma. En AI-DLC, AWS hace converger los silos técnicos, pero mantiene deliberadamente al Product Owner, los desarrolladores y QA, reunidos en rituales colectivos en los que todo el equipo valida lo que propone la IA. McKinsey llega a la misma conclusión: los equipos de entre ocho y doce personas dan paso a pequeños grupos de profesionales altamente cualificados, que supervisan la ejecución por parte de los agentes. La polivalencia tiene sus límites: el riesgo, la carga cognitiva, la posibilidad de acabar haciendo de todo a medias. Y esos límites siguen existiendo incluso cuando los agentes multiplican las capacidades de una persona. La unidad de producción que acaba estabilizándose sigue siendo colectiva. Es el pod, con una composición variable.
Y lo que determina el tamaño de ese pod es la plataforma. Lee Robinson, responsable del cambio de denominación de los roles en Vercel, concibe al Product Engineer en pareja con el Platform Engineer, el ingeniero que construye aquello sobre lo que trabajan los demás. Cuanto más sea capaz de absorber la plataforma —con sus guardrails, sus golden paths y su compliance automatizada—, más baja será la barrera y más pequeño podrá ser el pod. Quien construye la plataforma no juega el partido. Define sus reglas.
Un vocabulario para no creer en la magia
Estos tres nombres no acabarán fusionándose porque responden a necesidades diferentes. El Builder llega rápidamente hasta la prueba. El Engineer mantiene el sistema en producción. El Forward Deployed Engineer introduce la solución de un proveedor dentro de un sistema de información complejo, y en ese caso conviene saber exactamente qué está conectando. Todos trabajan dentro de un pod, cuyo tamaño viene determinado por la plataforma.
Utilizar la palabra adecuada en el momento adecuado ayuda a desmontar una creencia que no deja de crecer. Los agentes de código impresionan: describes lo que quieres y la máquina lo produce. De ahí surge la ilusión de que, con suficientes agentes, podríamos llevar a producción sistemas que ya nadie entiende. La práctica dice lo contrario, y las cifras también.
La generación de código parece magia. Llevarlo a producción sigue siendo un oficio. Confundir ambas cosas es confundir la demostración con la realidad. Estos tres roles no son lo mismo. Ponerles nombre es el primer paso para empezar a gestionar la transformación que estamos viviendo.
El Product Builder en acción. Pierre Sur, Product Builder en Thiga, nos cuenta su experiencia sobre el terreno tras más de seis meses en el rol: metodologías, herramientas, fuentes de información fiables, dinámicas de equipo, etc.
