Key Takeaways
The deployment gap is the distance between what a model can do in a demo and what a team can reliably put into production with real data, real systems, and real users.
A Forward Deployed Engineer (FDE) works inside that gap. They start with the business outcome, write production code, and leave something the customer team can own and extend.
Senior mobile and product engineers are unusually well suited to this work. They already ship under hard constraints, care about reliability, and know what “it works” actually means when people depend on it.
The hard part of applied AI is almost never the model. It is the system around it.
Most AI pilots fail to deliver lasting value. Not because the models are weak, but because the distance between “it works in the notebook” and “it works in the product” is larger than it looks.
OpenAI calls this the deployment gap: the distance between what models appear capable of and what people can reliably use to do their work. That gap is where Forward Deployed Engineering lives.
I have been a mobile engineer for more than a decade. I have shipped production apps used by millions at Sky, BetMGM, WWE and BritBox. More recently I have been building contained AI features in independent products — a production concierge on Paglipat and the live assistant on this site. The work looks different on the surface, but the pressure is familiar: ship something that holds up under real constraints, with clear ownership and a path for the next person to maintain it.
That experience maps more cleanly to the FDE role than many people expect.
What an FDE actually does
A Forward Deployed Engineer embeds with a customer (or a product team) to understand a hard problem and build a solution that works in their real environment. They write production code. They own a business outcome. They feed what they learn back into the product or platform so the next customer starts further ahead.
The role was popularised by Palantir and has been adopted, in different flavours, by OpenAI, Anthropic, Snowflake, Databricks and others. At OpenAI the framing is clear: start with the outcome, do what it takes to get something useful into people’s hands, then make what works repeatable. If the team can make itself obsolete every few months because the product now handles that class of problem, they are doing the job well.
It is not pure research. It is not pure product engineering inside the vendor’s walls. And it is not traditional consulting that stops at a recommendation or a proof of concept. The FDE stays until the solution is live, measured, and transferable.
What it is not
| Role | Primary focus | Stays until… |
|---|---|---|
| AI/ML Engineer | Model capability, training, research | The model improves |
| Product Engineer | Feature delivery inside one product | The feature ships |
| Solutions Architect/SE | Fit, architecture, demo | The deal or design is accepted |
| Forward Deployed Engineer | Outcome in the customer’s real environment | The solution works in production and can be owned or productised |
The distinction matters because the failure mode is different. Many teams can get a model to answer questions in a controlled setting. Far fewer can connect it to existing systems, keep cost and latency inside budget, define what “correct” means for that workflow, measure it, and hand it over without creating permanent dependence.
Why mobile and product engineers fit this work
Mobile engineers spend their careers inside constraints that are hard to ignore: battery, thermal, network variability, offline states, storage, fragmentation, and users who will notice when something is slow or wrong. Those constraints train a particular set of habits.
- You already think in failure modes and recovery paths.
- You know the difference between “it works on my machine” and “it works for the people who actually use it.”
- You are used to incremental delivery and to leaving systems that the next person can understand.
- You have experience with observability, testing, and the cost of shipping something that is only 80 % correct.
Applied AI has its own constraints — tokens, latency, cost per request, grounding, safety boundaries, and evaluation. The mental model is similar. A senior mobile engineer who has already shipped production features under real pressure often has less to unlearn than someone whose experience is mostly model training or demos.
I am not saying every mobile engineer should become an FDE. I am saying the skills that make someone effective at shipping reliable mobile systems transfer more cleanly than the industry currently acknowledges.
What this looks like in practice
On Paglipat I built a production AI concierge that answers questions about visas, housing and flights. The engineering detail is in Beyond the LLM Wrapper. The model is not trusted to remember rules. It can only call typed tools (check_visa, get_checklist, search_hotels, and so on). A fast model routes simple turns; a stronger model is used only when the turn justifies the cost. Every factual claim is grounded in verified data with a date. There are hard budget and rate limits, a 90-day retention policy enforced in code, and a full test suite around prompt assembly, tool schemas, routing and guardrails.
The assistant on this site follows the same pattern: bounded knowledge, evaluation golden set, clear handoff to a human contact form when the conversation leaves the supported scope.
Neither of these is a large enterprise engagement. Both are examples of the same loop an FDE runs: understand the real task, constrain the system so it cannot fail in expensive or unsafe ways, ship something people can use, and leave it maintainable. That is the independent version of the work.
What product teams usually need
Most teams do not need a custom foundation model. They need a contained feature that:
- Starts from a clear outcome (not “add AI somewhere”).
- Uses tools and grounding instead of relying on the model’s memory for facts that matter.
- Has an evaluation set that reflects real failure modes.
- Stays inside a cost and latency budget.
- Can be maintained by the existing team after the initial delivery.
That is the scope I work in. It is also the scope where the deployment gap is closed most often — not by bigger models, but by better systems around them.
Bottom line
The models will keep improving. The hard part remains the same: connecting them to real data, real workflows, and real constraints so that people can rely on the result. Forward Deployed Engineers exist to do that work. Senior engineers who already know how to ship under pressure are better prepared for it than the job title suggests.
If you are trying to move an AI feature from a promising pilot into something that holds up in production, the gap is usually not the model. It is the system around it.
If you need help scoping or shipping contained AI features with grounding, evaluation, cost controls and a clear handoff, discuss a project.
Ideas clave
La brecha de despliegue es la distancia entre lo que un modelo puede hacer en una demo y lo que un equipo puede poner en producción de forma fiable, con datos reales, sistemas reales y usuarios reales.
Un Forward Deployed Engineer (FDE) trabaja dentro de esa brecha. Empieza por el resultado de negocio, escribe código de producción y deja algo que el equipo del cliente puede mantener y ampliar.
Los ingenieros sénior de móvil y de producto encajan especialmente bien en este trabajo. Ya publican bajo restricciones duras, cuidan la fiabilidad y saben qué significa «funciona» cuando hay personas que dependen de ello.
La parte difícil de la IA aplicada casi nunca es el modelo. Es el sistema que lo rodea.
La mayoría de los pilotos de IA no dejan un valor que dure. No porque los modelos sean flojos, sino porque la distancia entre «funciona en el notebook» y «funciona en el producto» es más grande de lo que parece.
OpenAI llama a esto la brecha de despliegue: la distancia entre lo que los modelos parecen capaces de hacer y lo que las personas pueden usar de forma fiable para hacer su trabajo. Ahí es donde vive la ingeniería forward deployed.
Llevo más de una década como ingeniero de móvil. He publicado apps de producción usadas por millones de personas en Sky, BetMGM, WWE y BritBox. Más recientemente he construido funciones de IA acotadas en productos independientes: un conserje de producción en Paglipat y el asistente en vivo de este sitio. El trabajo se ve distinto por fuera, pero la presión es la misma: publicar algo que aguante restricciones reales, con una propiedad clara y un camino para que la siguiente persona lo mantenga.
Esa experiencia encaja con el rol de FDE mejor de lo que mucha gente espera.
Qué hace de verdad un FDE
Un Forward Deployed Engineer se integra con un cliente (o con un equipo de producto) para entender un problema difícil y construir una solución que funcione en su entorno real. Escribe código de producción. Se hace cargo de un resultado de negocio. Devuelve lo que aprende al producto o a la plataforma, para que el siguiente cliente empiece más adelante.
El rol lo popularizó Palantir y lo han adoptado, con matices distintos, OpenAI, Anthropic, Snowflake, Databricks y otras empresas. En OpenAI el encuadre es claro: empezar por el resultado, hacer lo que haga falta para poner algo útil en manos de la gente y después convertir lo que funciona en algo repetible. Si el equipo puede volverse prescindible cada pocos meses porque el producto ya cubre esa clase de problema, está haciendo bien el trabajo.
No es investigación pura. No es ingeniería de producto pura dentro de las paredes del proveedor. Y no es la consultoría tradicional que se detiene en una recomendación o en una prueba de concepto. El FDE se queda hasta que la solución está en vivo, medida y se puede transferir.
Qué no es
| Rol | Foco principal | Se queda hasta que… |
|---|---|---|
| Ingeniero de IA/ML | Capacidad del modelo, entrenamiento, investigación | El modelo mejora |
| Ingeniero de producto | Entrega de funcionalidades dentro de un producto | La funcionalidad se publica |
| Arquitecto de soluciones / SE | Encaje, arquitectura, demo | Se acepta el acuerdo o el diseño |
| Forward Deployed Engineer | Resultado en el entorno real del cliente | La solución funciona en producción y el equipo puede apropiársela o convertirla en producto |
La distinción importa porque el modo de fallo es otro. Muchos equipos consiguen que un modelo responda preguntas en un entorno controlado. Muchos menos consiguen conectarlo con los sistemas que ya existen, mantener el coste y la latencia dentro del presupuesto, definir qué significa «correcto» en ese flujo de trabajo, medirlo y entregarlo sin crear una dependencia permanente.
Por qué encajan los ingenieros de móvil y de producto
Los ingenieros de móvil pasan la carrera dentro de restricciones que no se pueden ignorar: batería, temperatura, red variable, estados sin conexión, almacenamiento, fragmentación y usuarios que notan cuándo algo va lento o mal. Esas restricciones entrenan hábitos concretos.
- Ya piensas en modos de fallo y en caminos de recuperación.
- Sabes la diferencia entre «funciona en mi máquina» y «funciona para las personas que de verdad lo usan».
- Estás acostumbrado a entregar de forma incremental y a dejar sistemas que la siguiente persona pueda entender.
- Tienes experiencia con observabilidad, pruebas y el coste de publicar algo que solo está correcto en un 80 %.
La IA aplicada tiene sus propias restricciones: tokens, latencia, coste por petición, anclaje a fuentes, límites de seguridad y evaluación. El modelo mental es parecido. Un ingeniero sénior de móvil que ya ha publicado funciones de producción bajo presión real suele tener menos que desaprender que alguien cuya experiencia es, sobre todo, entrenar modelos o hacer demos.
No digo que cada ingeniero de móvil deba convertirse en FDE. Digo que las habilidades que hacen a alguien eficaz publicando sistemas móviles fiables se transfieren con más limpieza de lo que el sector reconoce ahora.
Cómo se ve esto en la práctica
En Paglipat construí un conserje de IA de producción que responde preguntas sobre visados, vivienda y vuelos. El detalle de ingeniería está en Más allá del wrapper de un LLM. El modelo no es de fiar para recordar las reglas. Solo puede llamar a herramientas tipadas (check_visa, get_checklist, search_hotels, y otras). Un modelo rápido enruta los turnos sencillos; un modelo más capaz se usa solo cuando el turno justifica el coste. Cada afirmación factual se ancla en datos verificados, con una fecha. Hay límites duros de presupuesto y de tasa, una política de retención de 90 días aplicada en el código, y una batería de pruebas alrededor del ensamblado del prompt, los esquemas de las herramientas, el enrutado y las barreras.
El asistente de este sitio sigue el mismo patrón: conocimiento acotado, un golden set de evaluación y un traspaso claro a un formulario de contacto con una persona cuando la conversación sale del alcance cubierto.
Ninguno de los dos es un encargo grande de empresa. Los dos son ejemplos del mismo bucle que recorre un FDE: entender la tarea real, acotar el sistema para que no pueda fallar de formas caras o inseguras, publicar algo que la gente pueda usar y dejarlo mantenible. Esa es la versión independiente del trabajo.
Qué suelen necesitar los equipos de producto
La mayoría de los equipos no necesitan un modelo fundacional a medida. Necesitan una función acotada que:
- Empiece por un resultado claro (no por «añadir IA en algún sitio»).
- Use herramientas y anclaje a fuentes, en lugar de fiarse de la memoria del modelo para los hechos que importan.
- Tenga un conjunto de evaluación que refleje los modos de fallo reales.
- Se mantenga dentro de un presupuesto de coste y de latencia.
- La pueda mantener el equipo que ya existe, después de la entrega inicial.
Ese es el alcance en el que trabajo. También es el alcance en el que la brecha de despliegue se cierra más a menudo: no con modelos más grandes, sino con mejores sistemas alrededor de ellos.
En resumen
Los modelos van a seguir mejorando. La parte difícil sigue siendo la misma: conectarlos con datos reales, flujos de trabajo reales y restricciones reales para que las personas puedan fiarse del resultado. Los Forward Deployed Engineers existen para hacer ese trabajo. Los ingenieros sénior que ya saben publicar bajo presión están mejor preparados de lo que el título del puesto sugiere.
Si intentas pasar una función de IA de un piloto prometedor a algo que aguante en producción, la brecha no suele estar en el modelo. Está en el sistema que lo rodea.
Si necesitas ayuda para acotar o publicar funciones de IA contenidas, con anclaje a fuentes, evaluación, control de coste y un traspaso claro, hablemos de tu proyecto.
Loading comments…Cargando comentarios…