Actualidad
Vibe coding: el x10 no está en el prompt, está en el test
Entre «aquí hay un problema» y «alguien usa la solución todos los días» hay una distancia que en la mayoría de las empresas se mide en meses. El Forward Deployed Engineer existe para acortarla: alguien que se sienta dentro del problema, construye allí y responde de que la solución se use, no de haberla entregado. El nombre lo puso Palantir, y arrastra una palabra que despista: de las tres cosas que promete —ir por delante, desplegarse y hacer ingeniería— la última es la menos importante.
Cuando entré en Origen, mi puesto se llamaba AI expert. Demasiado pomposo para lo que un experto debería saber de verdad sobre inteligencia artificial. Un día Palantir le puso nombre a todo esto y lo llamó Forward Deployed Engineer. La etiqueta agarró, y con ella un malentendido.
Conviene decirlo sin rodeos: yo no soy ingeniero. Vengo de años de producto, diseño y experiencia de usuario, y durante mucho tiempo me vi limitado porque no controlaba la parte de desarrollo; había cosas en mi cabeza que no podía llevar hasta el final. Lo que ha cambiado no es que me haya vuelto ingeniero. Es que construir ha dejado de ser la barrera. La inteligencia artificial me dio la pieza técnica que me faltaba, y con ella la posibilidad de cerrar la línea entera: de la idea a algo que alguien usa cada día.
Ahí está el desplazamiento que explica el rol. Cuando construir era lo caro, lo escaso era quien sabía construir. Ahora que construir es barato, lo escaso es quien sabe qué merece la pena construir, quién lo va a usar y por qué hoy no lo usa. Eso no es una competencia de ingeniería.
Un FDE es el fruto de todos sus puestos anteriores. No es una especialidad nueva: es un poso. Si puedo hacer hoy lo que hago es por los años que pasé en los roles de antes, y por una parte humana que el trabajo exige a diario y que ninguna herramienta sustituye: escuchar de verdad, leer una sala, ganarse a quien lleva veinte años resolviéndolo de otra manera y sostener la relación cuando algo sale mal.
Por eso un FDE no se contrata por un lenguaje ni por un framework, y no sale de un curso. Se acumula.
| Consultor | Diagnostica y recomienda; construye otro. El FDE entrega una prueba de concepto funcionando, y desarrollo añade las capas finales. |
| Ingeniero de producto | Construye para un usuario agregado y un roadmap. El FDE, para un usuario y un problema concretos. |
| Preventa o arquitecto de soluciones | Demuestra lo que la tecnología ya hace. El FDE resuelve lo que todavía no hace. |
| Desarrollador asignado a un área | Ejecuta lo que se le especifica. El FDE decide qué merece la pena construir. |
La diferencia de fondo es una sola: un FDE no recibe requisitos por escrito. Se sienta donde está el problema, ve cómo se trabaja hoy y decide allí qué construir.
Cuando me preguntaron por las cualidades que pide el puesto, no mencioné ningún lenguaje ni ningún framework. Dije escucha, flexibilidad —en la ideación, en la construcción y con el cliente— y capacidad creativa: ser capaz de visualizar problemas, soluciones y casos de uso. Hay gente que se sienta contigo y lo ve al momento, y otra con la que no hay manera. Nada de eso se aprende en una formación técnica.
La razón es que el rol recorre el ciclo entero, y cada tramo pide una cosa distinta.
| Detectar | Observa el trabajo tal como es hoy, al lado de quien tiene el problema. Exige escucha y curiosidad de negocio. |
| Encuadrar | Decide qué se construye y qué se descarta, con el impacto y el coste sobre la mesa. Exige criterio de producto y capacidad de decir que no. |
| Construir | Prototipo funcionando en días, sobre datos y sistemas reales. Exige soltura con las herramientas y velocidad. |
| Validar | Lo pone delante del usuario, recoge lo que falla y corrige o abandona. Exige comunicación y desapego del propio trabajo. |
| Industrializar | Lo lleva a producción y deja al equipo capaz de operarlo sin él. Exige rigor operativo y didáctica. |
De esas cinco exigencias, cuatro son humanas. La técnica aparece en una sola fase, y es justo la que más ayuda ha recibido en los últimos dos años. Escuchar, decidir qué se descarta, encajar un no y enseñar siguen dependiendo enteramente de la persona. Y ninguna se puede delegar en el tramo siguiente: quien encuadra tiene que haber estado en la detección, y quien industrializa tiene que haber sufrido la validación. Ahí está la razón de que sea un perfil difícil de encontrar.
Si cuatro de las cinco exigencias son humanas, conviene decir cuáles. Es la parte que no aparece en ninguna descripción de puesto, la que no se puede certificar, y la que más se nota cuando falta.
Escuchar, para empezar, que no es esperar tu turno. La gente rara vez te cuenta su problema: te cuenta el apaño que lleva años usando para esquivarlo. Hay que sentarse a su lado, verla trabajar y entender qué le duele de verdad, no qué dice que le duele. De ahí sale todo lo demás, y si eso falla dará igual lo bien construido que esté lo que venga después.
Luego está la confianza, y hay que ganársela cada vez. Llegas a un puesto donde alguien lleva veinte años resolviendo lo suyo a su manera, y traes una herramienta que a primera vista parece que viene a quitarle el sitio. Si esa persona no te cree, no te enseña cómo trabaja de verdad: te enseña el procedimiento oficial, que casi nunca es lo mismo. Sin eso no hay proyecto, por buena que sea la tecnología.
Y está el desapego. Vas a proponer cosas que el cliente va a tirar, y tienes que ser capaz de tirarlas tú también, sin defenderlas solo porque son tuyas. Construir hoy sale barato; encariñarse sale caro.
Nada de esto es la parte blanda del trabajo. Es lo que decide si un proyecto acaba usándose o se queda en una demo bonita, y es justo lo que ninguna herramienta va a hacer por ti. La solvencia técnica hoy se consigue. Esto se acumula, con los años y con los golpes.
En Origen el FDE no improvisa, pero tampoco aplica siempre la misma receta. Lo primero que decide, una vez ha visto el problema de cerca, es con qué se resuelve. Y esa respuesta no siempre es un agente.
Cuando el caso encaja, trabajamos sobre Genesis, nuestra plataforma de producción de agentes, con un recorrido de doce pasos repartidos en tres fases: entender, construir, y activar y aprender. Ahí el reparto es explícito: Genesis automatiza lo automatizable —captura del brief, cuestionario de requisitos, consejo de expertos, auditoría de seguridad, generación del paquete del agente y QA— y el cliente aporta la realidad y valida.
Pero Genesis es una solución más, no la respuesta a todo lo que nos plantean los clientes. Hay problemas que se resuelven con una integración, con un cambio en el proceso, con una herramienta que la empresa ya paga y nadie usa, o dejando de hacer algo que ya no hace falta. Parte del trabajo, y de las partes menos agradecidas, es reconocer cuándo el problema no pide un agente y decirlo.
Lo que no cambia es el papel del FDE. Con Genesis o sin ella, es el hilo que recorre el caso de punta a punta haciendo lo que ninguna plataforma puede hacer: observar el proceso real en el puesto, arbitrar las recomendaciones con lo que ha visto allí, negociar los permisos con IT, probar con datos de verdad y responder del resultado en producción.
La idea
Sin FDE, una plataforma produce demos. Con FDE, produce agentes que se usan.
Hay además un ritmo que este trabajo permite y el anterior no. Hoy es tan barato fallar, revertir y rehacer que planteas algo, te equivocas, el cliente te dice que no y lo rehaces sin drama. No se parece en nada a la currada de dibujar 7.000 pantallas en Figma. He llegado a construir delante del cliente, viendo cómo su herramienta tomaba forma en la misma reunión. Y cuando construyes algo con alguien, esa persona lo siente suyo.
En su primera versión el agente solo lee. Consulta correo, ERP, ficheros y datos, y redacta borradores, resúmenes y propuestas de acción. No cambia nada en los sistemas del cliente: si se equivoca, no rompe nada.
La escritura se gana. Solo se abre cuando las pruebas con datos reales cumplen el criterio acordado, el cliente confirma que las propuestas del agente eran las correctas y hay alguien nombrado para aprobar lo irreversible. Y se abre una acción cada vez, con mínimo privilegio, registro de cada paso y reversión documentada.
Hay más reglas de ese tipo:
Pero la de la lectura es la que mejor explica el oficio. La confianza no se declara: se demuestra.
Un agente que no se usa no existe. Por eso un FDE no se mide por número de entregables ni de pilotos abiertos, sino por uso real: cuántas personas lo han incorporado a su día a día y lo siguen usando semanas después.
Eso cambia dónde termina el trabajo. No termina en la entrega: termina cuando el equipo opera la solución sin depender de nadie. Formación en el puesto y con los casos del cliente, no con diapositivas. Acompañamiento las primeras semanas. Y si no se usa, averiguar por qué.
En Origen lo decimos de otra forma: si no hemos conseguido que el cliente lo sienta, no estamos. Tiene que notar que esto le va a hacer crecer.
De cada cosa que montas dudas seriamente de que aguante. Que caduque, que haya que rehacerla en seis meses o que no llegue a servir. Uno acaba interiorizándolo; el problema es cuando el cliente no. Antes Windows Vista duraba tres años. Ahora una solución dura tres meses.
Y conviene decir lo otro sin adornos: se venden millones de licencias y suscripciones, las cifras se oyen todo el rato, pero dentro de las empresas la gente todavía no usa esto. En España, menos. Estamos muy lejos de lo que ya se puede hacer hoy. No de lo que vendrá: de lo que ya existe.
Esa distancia es exactamente el trabajo. Alguien tiene que sentarse donde está el problema, construir allí y quedarse hasta que se use. Ese alguien no tiene por qué ser ingeniero: tiene que saber escuchar, decidir y quedarse.
Una última cosa, por honestidad: la ansiedad en este oficio no la generan los usuarios, ni los clientes, ni tu jefe. La genera la propia tecnología, porque no te deja respirar. Profesionalmente es bueno —cuanto más exigente es, más al día estás y más singular te vuelves—, pero conviene saberlo antes de entrar.
Para profundizar en cómo trabaja realmente un Forward Deployed Engineer, puedes ver la conversación completa entre Rodrigo San Andrés, Forward Deployed Engineer en Origen, y Matteo Di Paolantonio, de Orbitant.
En ella hablan del cambio del ciclo de producto, de cómo se pasa del problema del cliente a una prueba de concepto funcional, del peso de las soft skills, de la adopción tecnológica y de qué ocurre cuando una solución tiene que llegar de verdad a producción.
Puedes ver la entrevista completa a continuación:
Escrito por
Rodrigo San Andrés
Forward Deployed Engineer en Origen
Entre «aquí hay un problema» y «alguien usa la solución todos los días» hay una distancia que en la mayoría de las empresas se mide en meses. El Forward Deployed Engineer existe para acortarla: alguien que se sienta dentro del problema, construye allí y responde de que la solución se use, no de haberla entregado. El nombre lo puso Palantir, y arrastra una palabra que despista: de las tres cosas que promete —ir por delante, desplegarse y hacer ingeniería— la última es la menos importante.
Cuando entré en Origen, mi puesto se llamaba AI expert. Demasiado pomposo para lo que un experto debería saber de verdad sobre inteligencia artificial. Un día Palantir le puso nombre a todo esto y lo llamó Forward Deployed Engineer. La etiqueta agarró, y con ella un malentendido.
Conviene decirlo sin rodeos: yo no soy ingeniero. Vengo de años de producto, diseño y experiencia de usuario, y durante mucho tiempo me vi limitado porque no controlaba la parte de desarrollo; había cosas en mi cabeza que no podía llevar hasta el final. Lo que ha cambiado no es que me haya vuelto ingeniero. Es que construir ha dejado de ser la barrera. La inteligencia artificial me dio la pieza técnica que me faltaba, y con ella la posibilidad de cerrar la línea entera: de la idea a algo que alguien usa cada día.
Ahí está el desplazamiento que explica el rol. Cuando construir era lo caro, lo escaso era quien sabía construir. Ahora que construir es barato, lo escaso es quien sabe qué merece la pena construir, quién lo va a usar y por qué hoy no lo usa. Eso no es una competencia de ingeniería.
Un FDE es el fruto de todos sus puestos anteriores. No es una especialidad nueva: es un poso. Si puedo hacer hoy lo que hago es por los años que pasé en los roles de antes, y por una parte humana que el trabajo exige a diario y que ninguna herramienta sustituye: escuchar de verdad, leer una sala, ganarse a quien lleva veinte años resolviéndolo de otra manera y sostener la relación cuando algo sale mal.
Por eso un FDE no se contrata por un lenguaje ni por un framework, y no sale de un curso. Se acumula.
| Consultor | Diagnostica y recomienda; construye otro. El FDE entrega una prueba de concepto funcionando, y desarrollo añade las capas finales. |
| Ingeniero de producto | Construye para un usuario agregado y un roadmap. El FDE, para un usuario y un problema concretos. |
| Preventa o arquitecto de soluciones | Demuestra lo que la tecnología ya hace. El FDE resuelve lo que todavía no hace. |
| Desarrollador asignado a un área | Ejecuta lo que se le especifica. El FDE decide qué merece la pena construir. |
La diferencia de fondo es una sola: un FDE no recibe requisitos por escrito. Se sienta donde está el problema, ve cómo se trabaja hoy y decide allí qué construir.
Cuando me preguntaron por las cualidades que pide el puesto, no mencioné ningún lenguaje ni ningún framework. Dije escucha, flexibilidad —en la ideación, en la construcción y con el cliente— y capacidad creativa: ser capaz de visualizar problemas, soluciones y casos de uso. Hay gente que se sienta contigo y lo ve al momento, y otra con la que no hay manera. Nada de eso se aprende en una formación técnica.
La razón es que el rol recorre el ciclo entero, y cada tramo pide una cosa distinta.
| Detectar | Observa el trabajo tal como es hoy, al lado de quien tiene el problema. Exige escucha y curiosidad de negocio. |
| Encuadrar | Decide qué se construye y qué se descarta, con el impacto y el coste sobre la mesa. Exige criterio de producto y capacidad de decir que no. |
| Construir | Prototipo funcionando en días, sobre datos y sistemas reales. Exige soltura con las herramientas y velocidad. |
| Validar | Lo pone delante del usuario, recoge lo que falla y corrige o abandona. Exige comunicación y desapego del propio trabajo. |
| Industrializar | Lo lleva a producción y deja al equipo capaz de operarlo sin él. Exige rigor operativo y didáctica. |
De esas cinco exigencias, cuatro son humanas. La técnica aparece en una sola fase, y es justo la que más ayuda ha recibido en los últimos dos años. Escuchar, decidir qué se descarta, encajar un no y enseñar siguen dependiendo enteramente de la persona. Y ninguna se puede delegar en el tramo siguiente: quien encuadra tiene que haber estado en la detección, y quien industrializa tiene que haber sufrido la validación. Ahí está la razón de que sea un perfil difícil de encontrar.
Si cuatro de las cinco exigencias son humanas, conviene decir cuáles. Es la parte que no aparece en ninguna descripción de puesto, la que no se puede certificar, y la que más se nota cuando falta.
Escuchar, para empezar, que no es esperar tu turno. La gente rara vez te cuenta su problema: te cuenta el apaño que lleva años usando para esquivarlo. Hay que sentarse a su lado, verla trabajar y entender qué le duele de verdad, no qué dice que le duele. De ahí sale todo lo demás, y si eso falla dará igual lo bien construido que esté lo que venga después.
Luego está la confianza, y hay que ganársela cada vez. Llegas a un puesto donde alguien lleva veinte años resolviendo lo suyo a su manera, y traes una herramienta que a primera vista parece que viene a quitarle el sitio. Si esa persona no te cree, no te enseña cómo trabaja de verdad: te enseña el procedimiento oficial, que casi nunca es lo mismo. Sin eso no hay proyecto, por buena que sea la tecnología.
Y está el desapego. Vas a proponer cosas que el cliente va a tirar, y tienes que ser capaz de tirarlas tú también, sin defenderlas solo porque son tuyas. Construir hoy sale barato; encariñarse sale caro.
Nada de esto es la parte blanda del trabajo. Es lo que decide si un proyecto acaba usándose o se queda en una demo bonita, y es justo lo que ninguna herramienta va a hacer por ti. La solvencia técnica hoy se consigue. Esto se acumula, con los años y con los golpes.
En Origen el FDE no improvisa, pero tampoco aplica siempre la misma receta. Lo primero que decide, una vez ha visto el problema de cerca, es con qué se resuelve. Y esa respuesta no siempre es un agente.
Cuando el caso encaja, trabajamos sobre Genesis, nuestra plataforma de producción de agentes, con un recorrido de doce pasos repartidos en tres fases: entender, construir, y activar y aprender. Ahí el reparto es explícito: Genesis automatiza lo automatizable —captura del brief, cuestionario de requisitos, consejo de expertos, auditoría de seguridad, generación del paquete del agente y QA— y el cliente aporta la realidad y valida.
Pero Genesis es una solución más, no la respuesta a todo lo que nos plantean los clientes. Hay problemas que se resuelven con una integración, con un cambio en el proceso, con una herramienta que la empresa ya paga y nadie usa, o dejando de hacer algo que ya no hace falta. Parte del trabajo, y de las partes menos agradecidas, es reconocer cuándo el problema no pide un agente y decirlo.
Lo que no cambia es el papel del FDE. Con Genesis o sin ella, es el hilo que recorre el caso de punta a punta haciendo lo que ninguna plataforma puede hacer: observar el proceso real en el puesto, arbitrar las recomendaciones con lo que ha visto allí, negociar los permisos con IT, probar con datos de verdad y responder del resultado en producción.
La idea
Sin FDE, una plataforma produce demos. Con FDE, produce agentes que se usan.
Hay además un ritmo que este trabajo permite y el anterior no. Hoy es tan barato fallar, revertir y rehacer que planteas algo, te equivocas, el cliente te dice que no y lo rehaces sin drama. No se parece en nada a la currada de dibujar 7.000 pantallas en Figma. He llegado a construir delante del cliente, viendo cómo su herramienta tomaba forma en la misma reunión. Y cuando construyes algo con alguien, esa persona lo siente suyo.
En su primera versión el agente solo lee. Consulta correo, ERP, ficheros y datos, y redacta borradores, resúmenes y propuestas de acción. No cambia nada en los sistemas del cliente: si se equivoca, no rompe nada.
La escritura se gana. Solo se abre cuando las pruebas con datos reales cumplen el criterio acordado, el cliente confirma que las propuestas del agente eran las correctas y hay alguien nombrado para aprobar lo irreversible. Y se abre una acción cada vez, con mínimo privilegio, registro de cada paso y reversión documentada.
Hay más reglas de ese tipo:
Pero la de la lectura es la que mejor explica el oficio. La confianza no se declara: se demuestra.
Un agente que no se usa no existe. Por eso un FDE no se mide por número de entregables ni de pilotos abiertos, sino por uso real: cuántas personas lo han incorporado a su día a día y lo siguen usando semanas después.
Eso cambia dónde termina el trabajo. No termina en la entrega: termina cuando el equipo opera la solución sin depender de nadie. Formación en el puesto y con los casos del cliente, no con diapositivas. Acompañamiento las primeras semanas. Y si no se usa, averiguar por qué.
En Origen lo decimos de otra forma: si no hemos conseguido que el cliente lo sienta, no estamos. Tiene que notar que esto le va a hacer crecer.
De cada cosa que montas dudas seriamente de que aguante. Que caduque, que haya que rehacerla en seis meses o que no llegue a servir. Uno acaba interiorizándolo; el problema es cuando el cliente no. Antes Windows Vista duraba tres años. Ahora una solución dura tres meses.
Y conviene decir lo otro sin adornos: se venden millones de licencias y suscripciones, las cifras se oyen todo el rato, pero dentro de las empresas la gente todavía no usa esto. En España, menos. Estamos muy lejos de lo que ya se puede hacer hoy. No de lo que vendrá: de lo que ya existe.
Esa distancia es exactamente el trabajo. Alguien tiene que sentarse donde está el problema, construir allí y quedarse hasta que se use. Ese alguien no tiene por qué ser ingeniero: tiene que saber escuchar, decidir y quedarse.
Una última cosa, por honestidad: la ansiedad en este oficio no la generan los usuarios, ni los clientes, ni tu jefe. La genera la propia tecnología, porque no te deja respirar. Profesionalmente es bueno —cuanto más exigente es, más al día estás y más singular te vuelves—, pero conviene saberlo antes de entrar.
Para profundizar en cómo trabaja realmente un Forward Deployed Engineer, puedes ver la conversación completa entre Rodrigo San Andrés, Forward Deployed Engineer en Origen, y Matteo Di Paolantonio, de Orbitant.
En ella hablan del cambio del ciclo de producto, de cómo se pasa del problema del cliente a una prueba de concepto funcional, del peso de las soft skills, de la adopción tecnológica y de qué ocurre cuando una solución tiene que llegar de verdad a producción.
Puedes ver la entrevista completa a continuación:
Escrito por
Rodrigo San Andrés
Forward Deployed Engineer en Origen
