Qué hace un FDE en el día a día: discovery, scoping y delivery

Seguro leíste que un Forward Deployed Engineer (FDE) trabaja embebido con el cliente, y aun así no logras imaginar un martes cualquiera. ¿Escribe código? ¿Pasa el día en reuniones? ¿Es un consultor con laptop? Qué hace un FDE en el día a día es un poco de todo eso, con un hilo conductor claro: toma un problema de negocio que ni el propio cliente sabe explicar del todo y lo lleva hasta que funciona en producción. En esta nota lo ordenamos en cuatro etapas (discovery y scoping, POC, integración y delivery) para que veas qué pasa en cada una.

Qué hace un FDE y bajo qué títulos lo vas a encontrar

Un Forward Deployed Engineer es un ingeniero que trabaja dentro de la empresa cliente, entiende un problema real y construye, despliega y sostiene la solución en los sistemas del propio cliente. Es dueño del problema de punta a punta, no solo del código.

El modelo lo popularizó Palantir a principios de los 2010: sus avisos describen a estos ingenieros como personas que trabajan directamente con los clientes para entender sus mayores problemas y diseñar e implementar soluciones. Según The Pragmatic Engineer, hasta alrededor de 2016 Palantir tenía más ingenieros de este tipo que ingenieros de software convencionales.

Lo que cambió en 2026 es la demanda. Según una encuesta de TechCrunch y Christian & Timbers a más de 250 ejecutivos de contratación en 180 empresas, la proporción de empresas que planea contratar FDEs pasó del 5-10% a comienzos de año al 70% al cierre del segundo trimestre. Detrás hay un problema que la tecnología sola no resuelve: quien sabe construir no conoce el negocio del cliente, y quien conoce el negocio no sabe construir. El FDE cubre ese hueco.

Hay dos confusiones frecuentes. La primera es pensar que es un ingeniero de soporte que además programa: el trabajo es construir y llevar a producción, no resolver tickets. La segunda es creer que existe un único puesto con ese nombre. «Forward Deployed Engineer» se usa en el mercado para trabajos distintos, y los conteos públicos de avisos suelen estar inflados.

Por eso conviene pensar en una capacidad, la de traducir un problema de negocio ambiguo en una solución que llega a producción, que se ofrece bajo varios roles:

Esa capacidad, además, es durable. Como señala The Pragmatic Engineer, el rol es anterior a la AI generativa, y lo que no se deprecia es convertir una necesidad ambigua en un sistema que funciona. Si quieres ver cómo se compara con otros perfiles, lo desarrollamos en Forward Deployed Engineer vs AI Engineer: cuál elegir.

El trabajo se ordena en cuatro etapas:

En la práctica las etapas se solapan y se repiten, pero sirven como mapa. Veámoslas una por una.

Discovery y scoping: entender el problema antes de escribir código

Imagina una empresa de logística cuyo equipo de operaciones revisa a mano las facturas de proveedores. La petición llega como «queremos usar AI para esto». Un FDE no empieza por elegir un modelo: se sienta con el equipo y recorre el proceso paso a paso. Hace entrevistas a los stakeholders y pregunta dónde viven los datos (el mail, el ERP, una planilla), quién decide qué, en qué punto un error cuesta dinero y qué hace hoy cada persona cuando algo no cuadra. Palantir tiene un playbook propio para esta fase, que es referencia en el rol.

Esta etapa existe porque el FDE entra justamente cuando la ambigüedad no está resuelta y nadie dentro de la empresa puede resolverla. Convertir un pedido vago en algo construible es parte del trabajo del ingeniero, no de un analista que entrega un brief limpio. A eso se suma que quien pide el proyecto y quien lo va a usar no siempre son la misma persona, y a veces no coinciden en lo que esperan sin habérselo dicho. Sacar eso a la luz temprano evita retrabajo después.

El resultado del discovery es el scoping: un documento de alcance (scope doc) que define qué se va a construir, qué queda fuera y cómo se va a saber que funcionó. En el ejemplo, un criterio de éxito medible podría ser reducir el tiempo de revisión por factura o la cantidad de discrepancias que llegan sin detectar a contabilidad. Cada proyecto es un intercambio entre alcance, velocidad y calidad, y el FDE tiene esa conversación en voz alta con el cliente, en el momento en que aparece.

POC sprint: prototipar con AI y mostrar avances rápido

Con el alcance acordado empieza el sprint de prueba de concepto (POC). La idea es llegar rápido a algo que el cliente pueda ver y tocar, apoyándote en desarrollo asistido por AI. Siguiendo el ejemplo, una primera versión podría leer facturas, extraer los campos clave con un LLM y marcar las que no coinciden con la orden de compra. No tiene que ser perfecta: tiene que funcionar con datos reales de la empresa.

Las demos semanales son la herramienta principal de esta etapa, en lo que se conoce como demo-driven development. Cada una pone el prototipo frente a quienes lo van a usar y genera feedback inmediato: un campo que nadie mencionó, una excepción que ocurre todos los meses, una regla que solo conoce una persona del equipo. Ese ciclo corto es una de las diferencias con el desarrollo de producto tradicional, donde el feedback suele llegar por analítica o investigación de usuarios, con más demora.

Un FDE de Rippling que antes trabajó en Palantir resume el rol con tres sombreros a la vez: consultor, product manager e ingeniero de software. En un POC se usan los tres en la misma semana.

Integración y producción: donde el prototipo se vuelve difícil

Un POC que funciona en una demo todavía no es una solución. Esta etapa es la que más separa a un FDE de alguien que solo codea. Hay que conectar el prototipo con sistemas legacy que no fueron pensados para eso (a menudo vía SOAP o REST, con procesos ETL de por medio), resolver identidad y permisos (SSO, OAuth) y, según el sector, cumplir requisitos de compliance como SOC 2, HIPAA o PCI. Todo lo que bloquee el despliegue pasa a ser trabajo del FDE. Y cuando la solución está lista, hay un último paso: el handoff, es decir, dejarla en condiciones de que el cliente la opere.

Este es también el punto donde fracasan muchos proyectos de AI en empresas. The New Stack, citando el informe de 2025 de MIT NANDA, señala que cerca del 95% de los pilotos de AI empresariales fracasan, en buena parte porque los datos de la compañía están aislados y son difíciles de integrar. Un modelo que rinde bien en un laboratorio no equivale a un sistema que funciona dentro de un banco, un hospital o una fábrica, cada uno con sus datos, sus reglas de seguridad y sus herramientas heredadas. Cerrar esa brecha es la razón de ser del rol.

Por eso un FDE escribe código de producción en el entorno del cliente y se queda hasta que la solución corre de manera confiable, no solo hasta que la demo sale bien.

Delivery y valor: comunicar, medir y llevar el POC a contrato

Que el sistema funcione es necesario, pero no alcanza. La última etapa es demostrar que genera valor y que vale la pena seguir. El FDE se comunica a nivel ejecutivo, traduce lo técnico al lenguaje del negocio y mide el ROI contra los criterios de éxito definidos en el scoping. Quien patrocina el proyecto va a renovar lo que pueda defender frente a su propia dirección, así que tener los resultados medidos y explicables es parte del entregable.

También hay una vuelta hacia adentro: los FDEs suelen llevar al equipo de producto de su empresa los arreglos y los casos borde que descubren en el campo, y así el trabajo con un cliente mejora el producto para los siguientes. Y el delivery incluye llevar el POC al contrato, es decir, convertir un proyecto piloto exitoso en una relación sostenida.

Mirado de punta a punta, el FDE no es alguien que programa para un cliente. Es dueño del problema desde que se define hasta que produce resultados medibles.

Cómo se reparte la semana de un FDE y qué se necesita para empezar

No existe un día típico, porque la semana la marca lo que esté bloqueando al cliente. Según las descripciones de Palantir, un día puede incluir discutir arquitectura con otros ingenieros, trabajar con grandes volúmenes de datos, programar una aplicación web a medida, hablar con ejecutivos del cliente y definir la estrategia del equipo.

Los viajes varían: algunos FDEs pasan buena parte del mes en el sitio durante los primeros despliegues y después pasan a revisiones remotas, y otros rotan entre varios clientes. Desde LATAM, hablar español y compartir huso horario con clientes de la región es una ventaja práctica.

El rol también tiene costos: el ritmo puede ser exigente y el avance depende de resultados del cliente que no controlas por completo. Es un trabajo para quien disfruta sentarse con el cliente y tolera que el plan cambie a mitad de semana.

Y es un rol de oficio, no de entrada. Según bloomberry, solo el 12% de las búsquedas de FDE son entry-level y el 60% pide entre 3 y 5 años de experiencia. El punto de partida habitual es ya construir con LLMs: Python, RAG, agentes, FastAPI, Docker y cloud. Sobre esa base, lo que suma el FDE es la capa que casi nadie enseña: discovery, scoping, delivery y medición de impacto.

Si ya construyes con LLMs y quieres sumar la capa consultiva y de delivery, súmate a la waiting list de la Carrera de Forward Deployed Engineer de Henry y entérate primero cuando abran las inscripciones.