Los roles para los que te prepara este libro
El mercado inventa títulos más rápido de lo que puede definirlos. La mayoría de esos títulos son la misma disciplina con distintos niveles de profundidad: la disciplina que enseña este libro. Este es el mapa y hasta dónde te lleva exactamente el libro hacia cada rol.
La pregunta detrás de cada título
El historiador Yuval Noah Harari ha planteado la pregunta más difícil de la educación moderna: por primera vez en la historia, no tenemos idea de cómo será el mercado laboral dentro de diez años, así que no sabemos qué enseñar hoy a los jóvenes. La respuesta anterior era sencilla: enseñarles a programar. Esa respuesta se está desmoronando porque la IA aprende a programar y, dentro de un año, podría escribir la mayor parte del código mejor que la mayoría de los seres humanos. Enseñar sintaxis es enseñar una habilidad que la máquina absorbe en tiempo real.
Esta página es la respuesta del libro a la pregunta de Harari. No formes redactores de sintaxis; forma a las personas que se sitúan por encima de la máquina: quienes especifican qué construir, supervisan a los AI Workers que lo construyen y verifican lo que reciben. La sintaxis puede automatizarse. El criterio, la especificación y el despliegue no: suben un peldaño a medida que la máquina asciende. Cada rol que aparece abajo ocupa un lugar en esa escalera, y los datos de demanda de esta página muestran que el mercado ya paga precisamente por esto, porque tampoco puede responder la pregunta de Harari y contrata a quienes sí pueden.
📚 Ayuda didáctica
::tip Abrir la presentación completa Ver la presentación completa, Los roles para los que te prepara este libro ::
Aquí definimos los roles de la nueva era de la IA agéntica: los trabajos que existen porque las empresas ahora fabrican, operan y gobiernan AI Workers. Las entradas están ordenadas según cómo se agrupa realmente el trabajo, y el veredicto junto a cada una traza con honestidad el alcance: hasta dónde te lleva este libro y dónde toman el relevo las vías de certificación. Los veredictos importan más que los nombres. Cuando el libro se detiene, lo dice. Y como un rol solo es tan real como la demanda que lo respalda, esta página sigue esa demanda en todos los mercados que ya contratan estos perfiles: laboratorios de IA, hiperescaladores, gigantes de consultoría, firmas independientes de servicios y el mercado abierto de trabajo autónomo.
El mapa: tres niveles, una línea. Una sola frase mantiene unida toda esta página. Este libro te prepara para construir AI Workers (Digital FTEs) y para combinar esos Workers en una empresa que funciona con ellos, una AI-Native Company. El mercado laboral tiene un nombre nuevo y muy solicitado para quien puede hacer todo esto: Forward Deployed Engineer (FDE). Hay tres niveles y cada uno construye el siguiente: la persona (tú), la unidad (el AI Worker que construyes) y la empresa (la organización que forman esos Workers). Cada rol de esta página es una parada en esa línea, un rol que la apoya o un límite que el libro traza con honestidad. Una precisión más: «FDE» describe dónde trabajas, no lo que sabes. Si trabajas dentro de la empresa de un cliente, el mercado te llama FDE. Si esa empresa te contrata, las mismas habilidades te convierten en su AI-Native Company Architect. El libro forma las habilidades; el mercado escoge el nombre.
Esa definición es correcta y también incompleta, porque una dirección no dice nada sobre lo que llevas al cruzar la puerta. El FDE de un proveedor lleva la plataforma del proveedor. Qué lleva uno neutral respecto del proveedor es una pregunta más difícil, y tiene una respuesta precisa: dos Systems of Record, uno que recibe y otro que construye. Esa sección está dentro del mapa del FDE porque la respuesta solo cobra sentido después de ver cómo funciona la versión del proveedor.
Todos empiezan en los mismos Fundamentos, las habilidades de navegador que todo lector necesita antes de trabajar con agentes. Sobre ese piso están los dos modos de uso de agentes generales. El Modo 1 consiste en usar un agente general para hacer tu propio trabajo más rápido: una competencia necesaria para todos, no un puesto. El Modo 2 consiste en fabricar AI Workers que hacen el trabajo por ti, y ahí viven los títulos laborales. El mapa empieza con el piso de Fundamentos y el Profesional de Modo 1, y después pasa a los roles de Modo 2, que constituyen casi todo lo demás.
¿Eres nuevo en el vocabulario (Digital FTE, SKILL.md, Agent Factory)? Empieza por la Tesis y el glosario, porque esta página los da por conocidos.
Una disciplina aplicada en dos contextos: cuatro roles llevan el pipeline dentro de tu propia empresa; un Forward Deployed Engineer lleva el mismo pipeline al cliente.
Todo el mapa de un vistazo: el pipeline central, lo que lo extiende y apoya, dónde se detiene el libro y la base que sostiene todo.
La base de la que todos parten
Fundamentos: el piso, antes de cualquier modo. Todo lector empieza del mismo modo, en una pestaña del navegador, en los Fundamentos: cómo hacer prompting, los dos lenguajes documentales del trabajo agéntico, cómo encargar código que nunca escribes, skills y conectores y cómo pensar en la era de la IA. Sin modo, sin rol, sin nada que instalar. Este es el piso sobre el que se sostiene todo el mapa. Donde todos empiezan, no un título que ostentas.
Profesional de Modo 1: no es un título, es una competencia. Sobre ese piso, usas un agente general para hacer tu propio trabajo más rápido: razonar, escribir, programar, analizar, planificar, entregar un resultado y cerrar la sesión. Esto es el Modo 1, y el libro lo forma para todos: ingenieros mediante Claude Code u OpenCode, expertos de dominio mediante Claude Cowork u OpenWork, bajo los Siete Principios de resolución de problemas con agentes generales. Es el primer modo que todo lector recorre antes de los roles de Modo 2 de abajo, y te hace más agudo en el trabajo que ya tienes en lugar de entregarte uno nuevo. El primer modo que todos ejecutan, no un título que ostentas.
El núcleo generalista
Estos roles centrales funcionan como un solo pipeline, desde la intención hasta producción: Outcome Architect (qué) → Digital FTE Builder (construir) → AI-Native Company Architect (sistema) → Cloud AI Engineer (operar). Ejecútalo dentro de tu propia empresa y son estos cuatro roles; ejecútalo dentro de la de un cliente, llevado de principio a fin por un único ingeniero embebido y neutral respecto del proveedor, y es el Forward Deployed Engineer. Todo lo demás en el mapa apoya, extiende o acota esta línea.
Cuatro roles ejecutan la línea dentro de tu propia empresa; un ingeniero embebido lleva la misma línea dentro de la de un cliente.
Outcome Architect: es responsable de la intención, no de la ejecución. El trabajo en la era de los agentes se divide en tres: intención, ejecución y verificación. El Worker asume la ejecución; este rol asume la intención. Decide qué debe lograr un Worker, redacta la especificación que lo fija, define qué significa «correcto» y prioriza qué Workers merece la pena construir: la persona que responde qué y por qué antes de que el Builder responda cómo. Mientras la vía de Strategist se ocupa del descubrimiento frente al cliente y del ROI, el Outcome Architect se ocupa de la hoja de ruta interna de Workers y de las especificaciones que la respaldan. El libro lo enseña directamente: el desarrollo guiado por especificaciones es, en esencia, la disciplina de escribir una intención por la que se pueda responsabilizar a un Worker.
Durante casi toda la historia del software, la parte lenta era construir. Los agentes de programación rompieron esa restricción. Un solo ingeniero ahora entrega varias veces más que antes porque el agente hace la construcción. Pero esa velocidad reveló una nueva parte lenta. Si un ingeniero puede construir cinco cosas a la vez, alguien aún debe decidir cuáles cinco vale la pena construir y describir con suficiente claridad qué debe hacer cada una para que un agente pueda ejecutarla. Esa decisión es el trabajo que este rol llama intención, y no se volvió más rápida.
El cambio cabe en una cifra. Las empresas solían tener aproximadamente un product manager, una persona que marcaba la dirección, por cada ocho ingenieros. Al multiplicarse la producción de cada ingeniero, esa misma persona ahora debe alimentar, en la práctica, el trabajo de veinte.1 La construcción escaló. La decisión no. Por eso decidir se convirtió en el cuello de botella: el punto del que depende todo lo demás.
El mercado observa esto y concluye que faltan product managers. Este libro lo interpreta de otra manera: es el momento en que el Outcome Architect, el rol responsable de la intención, se convierte en el puesto más importante de la empresa. Cuanto más crece la fuerza laboral de IA, más depende de una persona capaz de decir con precisión qué debe construir.
La ejecución escaló con la programación agéntica; decidir qué construir no. La brecha creciente, no la escasez de ingenieros, es lo que mide la nueva proporción.
Lo enseña por completo: es la disciplina sobre la que descansa todo el método.
Digital FTE Builder: el producto unitario, construido de principio a fin. El mercado llama a esto AI Engineer, su término comodín para alguien que crea aplicaciones a partir de componentes de IA y dirige agentes de programación con IA. El nombre de este libro es más preciso porque lo que construyes también lo es: el Digital FTE, la unidad con la que se ensambla toda la empresa. Este es el principal perfil graduado del libro. Aprende toda la columna vertebral: desarrollo guiado por especificaciones, autoría de SKILL.md, arquitectura de agentes, interfaces de herramientas y MCP (el estándar para conectar un agente con herramientas y datos externos), evaluación y supervisión humana, con suficiente despliegue para llegar a producción y dejando la profundidad al Cloud AI Engineer. Lo enseña de extremo a extremo.
AI-Native Company Architect: diseña la empresa, no un solo Worker. Toda la organización: el modelo de dos capas, la capa de gestión, la fuerza laboral, el sistema nervioso que transporta eventos entre ambas y el sistema de registro contra el que funciona todo. Agent Factory es el proceso que practica este arquitecto; AI-Native Company es el producto que entrega. El libro es su fuente canónica. El programa Certified Agentic AI Architect de cinco trimestres es su credencial. Formación completa; certificación mediante la vía de Architect.
Cloud AI Engineer: quien opera el AI Worker y la AI-Native Company en producción. Construir un Digital FTE es la mitad del trabajo; operarlo de forma fiable es la otra, al igual que operar toda la AI-Native Company a la que pertenece. Mientras el AI-Native Company Architect diseña la empresa, este rol la opera: despliega y escala los Workers, la capa de gestión y el sistema nervioso sobre infraestructura real de nube, con Azure Container Apps para entregar, Inngest para la ejecución duradera y Dapr y Kubernetes para escalar. Aquí el sistema deja de ser un prototipo y se convierte en una empresa de la que una organización puede depender. Enseña la ruta a producción; la escala profunda y las operaciones de plataforma pertenecen a la vía de nube.
El Forward Deployed Engineer (FDE): la versión neutral respecto del proveedor que el mercado no encuentra
Los cuatro roles centrales anteriores recorren la línea dentro de tu propia empresa. Lleva esa misma línea a la empresa de un cliente, mediante un solo ingeniero integrado y de extremo a extremo, y aparece el nombre que el mercado se apresura a contratar.
Qué hace realmente un FDE. La mayoría de los ingenieros de software crean un producto en la sede central y nunca conocen al cliente que lo usa. Un FDE hace lo contrario. Va al lugar de trabajo real del cliente, se sienta junto a las personas que hacen el trabajo, entiende los problemas reales que enfrentan y crea soluciones ahí mismo, en sitio, usando la plataforma de su empresa. No una demo. No una presentación. Software funcional que se ejecuta en el entorno real del cliente.
Piensa en la diferencia entre un médico que lee tu expediente desde otra ciudad y un médico que se sienta en la sala, te examina y empieza el tratamiento en ese mismo momento. El FDE es el segundo médico.
Palantir, una gran empresa de analítica de datos para gobiernos y grandes compañías, creó este rol a comienzos de la década de 2010 y lo llamó originalmente «Delta».2 Hasta aproximadamente 2016, Palantir tenía más FDE que ingenieros de software convencionales porque sus clientes necesitaban a alguien en el lugar capaz de atravesar la burocracia interna con mentalidad de startup. La diferencia se explica así: un desarrollador normal se concentra en una capacidad para muchos clientes; un FDE, en un cliente y muchas capacidades. El puesto se parece al de un CTO de startup: asume todo de principio a fin en proyectos de alto riesgo. La genealogía ya tiene confirmación externa: al lanzar su propia unidad de 6.000 personas en 2026, Microsoft atribuyó públicamente a Palantir la popularización del título.3
FDE 101: por qué Palantir necesitó el rol
Quién lo explica y por qué cuenta. El relato más claro sobre la razón de ser de este rol proviene de Kevin Bai y su charla Forward Deployed Engineering 101, presentada a mediados de 2026 en la AI Engineer World's Fair, dentro de la misma serie de nueve sesiones que incluyó la charla de Brunet citada más adelante.4 Su carrera es la historia breve del rol contada por una sola persona. Dirigió proyectos FDE en Palantir, la empresa que inventó el puesto, para lo que describe como las instituciones más importantes del mundo. Después creó la función donde no existía: entró en Rippling como la primera persona de su equipo FDE y la hizo crecer hasta unas veinticinco personas en un año. Hizo desde dentro lo que esta página describe desde fuera: inició una práctica FDE desde cero en una empresa que no la tenía y la dotó de personal. Hoy integra el equipo Applied AI de Anthropic, del que procede el título Applied AI Engineer que esta página menciona. Su trayectoria combina diplomacia, ventas, desarrollo de negocio, gestión de producto, éxito del cliente e ingeniería de software, con forward deployed engineering como el único trabajo que reúne todo: el mismo diagrama de Venn que aparece abajo antes incluso de dibujarlo.
Antes del argumento, dos notas honestas. Bai habló de la disciplina en general y se negó explícitamente a comentar su trabajo actual, así que nada de esto describe la práctica interna de un laboratorio de frontera. Además, lo que sigue es el marco de un profesional y cifras recordadas en el escenario, no investigación auditada. Esta página le da el mismo estatus que a la aritmética de Aggarwal y al manual de Brunet: testimonio identificado de alguien que realmente dirigió esta función.
El problema nunca fue el software. Empieza por lo que Palantir realmente vende. Foundry permite que una organización de cualquier tamaño centralice sus datos y construya una ontología: convierte la tabla uno, la tabla dos y la tabla tres en nombres propios, de modo que una empresa con almacenes tenga una tabla que sea la verdad sobre sus almacenes. Encima de ella, los clientes construyen aplicaciones.
Muéstraselo a un líder industrial y la respuesta, según Bai, es: ya organizaste mis datos, ¿qué aporta eso a mi negocio? Ahí es donde vender tecnología por sí sola se queda corto. Además, el éxito del proveedor depende de que el cliente aprenda a usarla, de modo que paga dos veces: una por la plataforma y otra por formar a su gente hasta que pueda construir algo con ella. Bai lo llama una forma terrible de hacer negocios, y su solución es la frase que da nombre al primer rol de esta página. Deja de vender software, deja de vender horas y vende el resultado. Envía personas que comprendan la naturaleza del negocio del cliente, deja que construyan la solución sobre la plataforma y entrega el resultado. A un ejecutivo de productos de consumo le importan la colocación en estantes y el rendimiento de ventas. Bai afirma que la organización de los datos debe ser un detalle de implementación.
Qué compradores lo necesitaban y por qué. Foundry es una plataforma para construir aplicaciones, por lo que no interesaba a las empresas que ya tienen grandes ingenieros, como Google, Meta o los laboratorios, capaces de construir lo que la organización necesitara. Lo necesitaban las Fortune 500 de petróleo y gas, donde, como dice Bai, las tuberías no son pipelines de datos. La oferta para ese comprador eran ingenieros prestados: personas que el cliente no tenía que contratar, reclutar, gestionar ni retener, formadas en la plataforma y lo bastante cerca del trabajo para descubrir el problema real y construir la solución.
La prueba está en el tamaño del contrato. Si se comparan las empresas SaaS públicas que atienden a Fortune 500 por valor contractual promedio, es decir, cuánto gasta un solo cliente con el proveedor, Bai sitúa a Palantir primero con unos 4 millones de dólares, a ServiceNow después con 1,2 millones, a Workday con 600.000 y a ninguna otra por encima de medio millón.4 Lee esas cifras junto a la plantilla de pocos miles que menciona en la misma intervención y a la capitalización que aparece después. Vender resultados se valora de manera distinta a vender asientos, y el valor contractual promedio es la cifra que lo demuestra. También es la afirmación de este libro sobre los Digital FTE, llegada desde el lado del proveedor.
La prueba anterior a todo: ¿necesitas siquiera un FDE?
El filtro de Bai es una matriz de dos por dos: cuán técnico es lo que vendes y cuán técnica es la persona que lo compra. Tres de las cuatro celdas no necesitan despliegue avanzado.
- Producto técnico, comprador técnico. GitHub, Datadog. El software es complejo, pero el comprador es CTO o CIO y quien lo usa es ingeniero; absorber esa complejidad forma parte de su trabajo. Atiéndelos con documentación y relaciones con desarrolladores.
- Producto configurable, comprador técnico. Tampoco hace falta nada especial. Un comprador técnico configura un producto sencillo sin que nadie viaje a ayudar. Autoservicio o movimiento dirigido por ventas.
- Producto configurable, comprador no técnico. Rippling, Jira, Slack. Pueden ser complejos, pero se configuran en vez de desarrollarse. Funciona una estrategia de ventas tradicional.
- Producto técnico, comprador no técnico. La única celda donde el FDE es necesario, el rincón de Palantir.
La disciplina detrás del diagrama importa más que el diagrama. La pregunta no es «¿quiero una función FDE?», porque es fácil querer lo que está de moda. La pregunta es si debes llevar algo técnicamente complejo a un comprador que no puede implementarlo. Si la respuesta es no, el despliegue avanzado probablemente no sea adecuado y te servirán mejor la relación con desarrolladores o una estrategia comercial.
El filtro de Bai antes de todo: tres de cuatro celdas no necesitan FDE y el giro agéntico empuja a los proveedores hacia la cuarta. Su marco, no una medición.
Dos matrices, dos preguntas distintas. La matriz de Bai decide si un proveedor debería tener una función FDE. La de Brunet, más adelante, decide si un cliente concreto es cliente para FDE. Quien lee este libro usa ambas desde una tercera posición, pues no vende una plataforma propia. La matriz de Bai indica hacia qué clientes caminar: quienes tienen algo técnico que no pueden implementar, lo que después del cambio descrito abajo abarca a casi todos. La de Brunet indica cómo delimitar el proyecto una vez dentro.
No es lo mismo que un Solutions Architect o un Sales Engineer. Un Solutions Architect asesora: ejecuta demos, diseña soluciones en pizarras y crea prototipos de prueba de concepto con datos de muestra para convencer a un prospecto de firmar. Una vez cerrado el trato, su participación suele disminuir. Un FDE toma el relevo donde el Solutions Architect termina. Escribe código de producción directamente en la infraestructura del cliente, con datos reales, y se queda hasta que el cliente obtiene valor real. La prueba simple: si el rol es responsable de lograr que un trabajo específico para el cliente funcione realmente en producción, está más cerca de un FDE. Si es responsable de demostrar o explicar el producto, está más cerca de un solutions architect.
Un ejemplo real es el trabajo de OpenAI con John Deere, la empresa agrícola de casi 190 años, que muestra la misma lógica de despliegue: IA aplicada dentro de un contexto operativo real, alrededor de See & Spray, el éxito del cliente, los flujos de trabajo de los concesionarios y las recomendaciones previas a la temporada. John Deere atribuye a See & Spray una reducción de hasta el 70% en el uso de productos químicos, y el caso de OpenAI muestra cómo se usa la IA para la configuración, las recomendaciones durante la temporada, el soporte a concesionarios y los informes de ROI.5 El trabajo vive en el calendario de siembra del cliente, no en una hoja de ruta de producto. Ese es el trabajo del FDE en una frase: software real de producción, construido en el mundo del cliente y entregado cuando el cliente realmente lo necesita.
El FDE es donde se encuentran código, producto y cliente: la capacidad de construcción del software engineer, el instinto de producto del platform engineer y la lectura del cliente del solutions architect, en una persona que construye en el mundo del cliente, no en la sede.
Bai comprime la misma imagen en una prueba de contratación con dos condiciones: un FDE es un software engineer orientado al cliente, alguien que contratarías para el equipo de ingeniería solo por su nivel técnico y en quien también confiarías frente al cliente.4 Ambas mitades deben cumplirse. Sin la primera, tienes un account manager que no puede construir. Sin la segunda, un ingeniero al que debes mantener lejos de las personas cuyo problema resuelve.
Por qué ahora todas las empresas de IA quieren FDE. Las ofertas crecieron más de un 800% en los tres primeros trimestres de 2025.6 Salesforce creó un equipo dedicado para respaldar Agentforce.7 OpenAI creó la «Deployment Company», una filial con participación mayoritaria y respaldo de unos 4.000 millones de dólares de un consorcio de inversores, centrada en gran medida en dotar de FDE a las empresas.8
A mediados de 2026 el modelo llegó a los hiperescaladores. AWS comprometió 1.000 millones de dólares para una unidad FDE que envía pods de cinco o seis ingenieros durante unos 45 días y planea emplear a miles. Fue el primer gran proveedor de nube en hacer la apuesta y la financió por completo con su propio balance, no mediante una empresa conjunta de capital privado como OpenAI o Anthropic.9 Dos días después Microsoft respondió con el mayor compromiso hasta entonces: Microsoft Frontier Co., una unidad operativa de 2.500 millones y 6.000 personas que reúne FDE existentes de Microsoft, consultores técnicos, personal de soporte y vendedores con experiencia sectorial, todos integrados directamente en clientes iniciales como Unilever y Novo Nordisk.3 En una semana, los dos mayores proveedores de nube pusieron 3.500 millones detrás del mismo título. El modelo también saltó de sector: QuantumBlack de McKinsey contrata Lead Forward-Deployed Engineers con más de ocho años de ingeniería práctica, una consultora que admite que el consejo sin despliegue ya no basta.10
Un detalle del anuncio de Microsoft merece conservarse. No promete instalar una plataforma ni integrar modelos, sino un equipo que codiseña, despliega y mejora continuamente sistemas de IA, juzgado por resultados empresariales medibles.3 Es la prueba de éxito del cliente escrita en la carta del proveedor, la misma que una responsable de FDE formula después desde el lado de la entrega.
La razón es sencilla: un estudio de 2025 del MIT Media Lab, Project NANDA, halló que cerca del 95% de los pilotos empresariales de IA personalizada no muestran retorno medible.11 No porque la IA no funcione, sino porque integrarla en los sistemas reales y desordenados de una empresa es extremadamente difícil. Los FDE existen para cerrar esa brecha. Esa es una razón del ascenso de Palantir por encima de una capitalización de 136.000 millones de dólares a fines de 2024, superando a Lockheed Martin,12 y de que todas las empresas de IA quieran imitar el modelo.
El mismo estudio también explica qué hicieron quienes sobrevivieron. La cifra del 95% explica el fracaso. Un segundo hallazgo del mismo informe explica la excepción: las iniciativas dirigidas con socios externos llegaron al despliegue aproximadamente el 67% de las veces, mientras que las herramientas construidas totalmente dentro de la empresa llegaron a él cerca del 33%.11 Lee las dos cifras con cuidado, porque miden cosas distintas. El 95% se refiere al efecto en pérdidas y ganancias. El 67% se refiere a llegar siquiera al despliegue. Juntas dicen que los pilotos no mueren por modelos débiles. Mueren por el trabajo de integración que nadie está integrado para hacer, y las empresas que incorporaron a personas externas para hacerlo entregaron el doble de veces.
Dos límites para esa cifra. El informe afirma que la relación entre socios externos y éxito no demuestra causalidad, califica sus propios hallazgos como preliminares y observó cada despliegue durante solo seis meses.11 Y conviene mirar exactamente qué comparó: comprar a un proveedor frente a construir sin ayuda. La neutralidad respecto del proveedor es una tercera columna que el estudio nunca muestreó porque en 2025 apenas existía. Por eso el hallazgo lleva al lector hasta la puerta de esta sección y no más allá. La experiencia externa supera a hacerlo solo. Si esa experiencia debe llegar soldada a la plataforma de un único proveedor es la pregunta que esta sección aborda a continuación.
¿Por qué ahora y no en 2012? La tasa de fracaso explica por qué se paga el rol. No explica el momento. El modelo de Palantir fue público, rentable y visible durante una década, y casi nadie lo copió. La hipótesis de Bai es estructural y es la mejor explicación disponible: lo que cambió no fue que el sector por fin se diera cuenta de que Palantir tenía razón. Lo que cambió fue el propio negocio del software. Casi todas las plataformas son ahora agénticas. Agéntica significa personalizable. Y personalizable significa que el cliente ya no sabe qué hace el producto ni hasta dónde puede llevarlo, lo que coloca a casi todos los proveedores en la única celda de su matriz que exige despliegue avanzado: algo técnico vendido a un comprador que no puede implementarlo.4 Si dejas el éxito de tu producto en manos de la capacidad del cliente para implementarlo, advierte Bai, no venderás a grandes empresas ni entrarás en otra industria.
Ambos hallazgos encajan. Bai nombra la causa: las plataformas agénticas convirtieron a cada proveedor en Palantir. MIT midió el efecto: pilotos que no llegan a ninguna parte porque nadie estaba integrado para cerrar la brecha de implementación. Los 4.000, 1.000 y 2.500 millones de dólares son la industria pagando por cerrarla.
Lo que paga el mercado, leído con honestidad. Las publicaciones virales sobre este rol abren con «hasta un millón de dólares al año». Las cifras reales son suficientemente fuertes sin inflarlas. Indeed contó 643 ofertas de FDE en Estados Unidos en abril de 2025 y 5.330 un año después, un aumento del 729%, con bandas habituales de 170.000 a más de 200.000 dólares; las ofertas de Anthropic van de 200.000 a 300.000.10 En todo el mercado, la mediana ronda 190.000, con un intervalo aproximado de 160.000 a 220.000.13 Los FDE senior y staff de laboratorios de frontera superan 450.000 a 600.000, y existen cifras de siete dígitos en la cima de una escala de ingeniería, pero ese es el techo de una carrera, no la puerta de entrada.14 Dos detalles importan más que una cifra aislada. Primero, las ofertas crecieron más de 800% en nueve meses mientras el grupo de candidatos creció cerca de 50%: una brecha de oferta que genera presión salarial y abre el espacio para un lector formado.6 Segundo, una revisión de roles FDE verificados no encontró ni uno con cuota de ventas: el mercado paga a los FDE como ingenieros, no vendedores, la distinción con el sales engineer de arriba puesta en cifras.14 Los datos de esta sección se verificaron por última vez en julio de 2026; el rol cambia rápido y lo duradero es la disciplina, no una banda salarial ni un recuento de vacantes.
La industria de servicios ve la misma aritmética: desde el otro lado
Los proveedores envían FDE; el outsourcing tiene una razón más existencial para prestar atención, pues su modelo completo, miles de personas vendiendo horas de ejecución humana, es justo la capa que absorbe la IA. En la semana posterior a los anuncios de AWS y Microsoft, ese mundo empezó a reposicionarse alrededor del FDE. Sanjeev Aggarwal, fundador de Daksh, pionera del BPO indio, y después de Fundamentum junto con Nandan Nilekani de Infosys, expuso la aritmética en Young Turks Reloaded de CNBC-TV18: el FDE fusiona ingeniero, product manager y arquitecto de IA en una sola persona, «casi como un unicornio, un ingeniero 10x», y sobre esa fusión una firma podría construir un negocio de 100 millones de dólares con unos 100 FDE, frente a 2.000 o 2.500 personas en servicios tradicionales, con márgenes brutos que sitúa entre 70% y 90%.15 Son proyecciones de un veterano, no mediciones, pero importa quién proyecta. El hombre que construyó el modelo anterior declara su sucesor: veinticinco puestos de la pirámide sustituidos por uno, la compresión del pod de uno aplicada a escala empresarial. Su conclusión geográfica es que India puede ser la fábrica mundial de FDE, al convertir décadas de entrega de TI en la nueva disciplina. La afirmación llega más lejos de lo que él la lleva: décadas de servicios de TI enseñaron a Asia del Sur a integrarse en sistemas desordenados de clientes y entregar, una capacidad que existe en Karachi y Lahore tanto como en Bangalore. Lo que la convierte en el nuevo rol no es la geografía, sino la formación; el método de este libro es esa conversión y está disponible para cualquiera que haga el trabajo.
La aritmética de Aggarwal dibujada a escala: la compresión del pod de uno aplicada a la empresa. Su proyección, no una medición.
Y las firmas de servicios profesionales están cambiando el precio de su producto. Aggarwal proyecta; las Big Four ya entregaron. En marzo de 2026, el CEO estadounidense de PwC, Paul Griggs, dijo al Financial Times que la firma ofrecería alternativas a cobrar a los clientes por las horas de su personal y convertiría partes de impuestos y consultoría en herramientas de IA que los clientes usarían directamente, sin un profesional de PwC en los primeros pasos, quizá vendidas mediante suscripción anual.16 Esa plataforma llegó como PwC One con seis servicios automatizados, desde diligencia de M&A hasta reglas fiscales. Griggs fue directo sobre el efecto interno: los líderes que no piensen primero en IA serán sustituidos por quienes sí lo hagan y quien crea que puede excluirse no durará en la firma.
Léelo como tres cosas a la vez, porque lo es.
Es la aritmética de Aggarwal confirmada desde el otro extremo. Él proyectó una compresión de veinticinco a uno. PwC elimina por completo al humano de los primeros pasos de ciertos servicios: la misma compresión como decisión de producto en vez de proporción de personal. Dos firmas muy distintas, una procedente de los servicios de TI indios y otra de las Big Four, llegaron al mismo lugar en el mismo trimestre.
Es la afirmación sobre cobrar por resultados hecha por una firma cuya economía dependía de lo contrario. Las cifras de valor contractual promedio de Bai sostienen que los resultados se valoran de manera distinta a los asientos. Una Big Four que abandona la hora facturable aplica ese argumento contra su propio modelo de ingresos. La hora facturable no era una preferencia de precios; era todo el negocio.
Y es una jaula nueva. PwC One es una plataforma. Un profesional de PwC desplegado en un cliente construye sobre ella y lo que conserva el cliente después funciona allí. La estructura es idéntica al lock-in del proveedor descrito en la sección siguiente, con la consultora ocupando ese asiento. Por tanto, el argumento de neutralidad no termina en los laboratorios de IA y los hiperescaladores. También alcanza a los servicios profesionales, y quien compita por trabajo profesional integrado debe esperar encontrar esta versión.
Otra frase de Griggs pertenece aquí: si pones IA encima de un proceso ineficiente, obtienes un proceso más complicado y un informe rápido de lo malo que siempre fue. Es la tasa de fracaso del MIT explicada por un comprador y la descripción del FDE desde el lado del cliente: alguien debe reconstruir el proceso, no decorarlo.
Trata todo esto como la estrategia de una firma, no como una medición de la industria, en la misma clase que la proyección de Aggarwal y las cifras recordadas por Bai. La plataforma, en cambio, no es una proyección: ya se lanzó.
El manual desde dentro de un proveedor. Las cifras de demanda anteriores provienen de comunicados y recuentos de ofertas. En junio de 2026 llegó la vista desde dentro: Pauline Brunet, responsable del equipo FDE global de Cursor tras diez años desplegando IA empresarial, presentó su manual en la AI Engineer World's Fair, que celebró por primera vez una pista dedicada a FDE.17 Abrió con la misma lectura que esta página: espera el artículo que declare al FDE el trabajo más solicitado de 2026. Cuatro reglas importan porque describen el trabajo desde el lado que lo paga.
Primero, la prueba de encaje. Brunet puntúa cada proyecto según la madurez digital del cliente y la personalización del producto. Un cliente maduro con producto simple necesita documentación, no un FDE; uno inmaduro con producto simple necesita un despliegue tradicional, tampoco un FDE. El FDE vive en la banda de personalización profunda: transformación integrada cuando el cliente no puede aportar personal y aceleración cuando puede, pero la construcción es profunda. La lección para un lector neutral es directa: esta matriz muestra cómo ya piensa el comprador. Entra en una llamada de descubrimiento sabiendo en qué celda estás.
Cómo delimita el comprador el rol: el FDE vive donde la personalización es profunda, especialmente donde el cliente no puede dotar el trabajo. Redibujado de la charla de Brunet; su marco, no una medición.
Segundo, el límite con el aumento de personal. La señal de alarma es «nos falta personal»: pide alquilar horas, no transferir capacidad, y Brunet lo rechaza. Su respuesta es una pregunta: ¿quién será el equipo de trabajo? Si el cliente no puede nombrar a quienes construirán contigo, es body-shopping disfrazado. Conserva esa pregunta. Es la prueba de campo para la diferencia entre el FDE y la pirámide de servicios.
Tercero, alcance direccional. Rechaza por igual los proyectos abiertos, «dos FDE durante seis meses», y las promesas waterfall fijas. Su formato consiste en nombrar el problema, nombrar el KPI de base, «este proceso tarda tres horas; el éxito son veinte minutos», comprometer un plan direccional de seis semanas por fases y esperar cambiar según lo que enseñen los sistemas reales del cliente. Su razón resultará familiar: todavía no ha visto los datos, los procesos ni los sistemas del cliente, así que la precisión antes del contacto sería una mentira. Es desarrollo guiado por especificaciones expresado desde el lado de la entrega: la especificación se endurece conforme llega la realidad sobre el terreno.
Lee esa regla con cuidado, porque es fácil interpretarla como un argumento a favor de llegar sin nada preparado. No lo es. Lo que no puede ser preciso antes del contacto es el plan para ese cliente: sus sistemas, sus datos y su cifra de base. Lo que puede y debe existir de antemano es el conocimiento gobernado de la propia profesión, que no varía entre clientes. El equipo de Brunet llega con la plataforma de Cursor ya construida. La versión neutral respecto del proveedor llega con la profesión ya gobernada. Ninguna llega con las manos vacías ni finge conocer las cifras del cliente.
Cuarto, ROI en tres preguntas. Todo proyecto debe terminar respondiendo al menos una: ¿aumentamos los ingresos, reducimos los costes o mitigamos el riesgo? Un cliente se alarmó porque un agente costaba 2.000 dólares al día, hasta que Brunet preguntó qué hacía. Enviaba al técnico correcto a equipos averiados, y el cliente admitió que el agente era barato. El cliente había medido el coste y nunca había medido el retorno. La vía de Strategist enseña este marco; Brunet confirma que es el único marco que usa el lado comprador.
Dos revelaciones más merecen una lectura clara. Contrata solo ingenieros con cinco o más años y todavía no candidatos al inicio de su carrera: la puerta asalariada del proveedor es hoy una puerta senior. Este libro no pretende lo contrario. Ofrece puertas que no verifican antigüedad: portfolio, mercado freelance y pod de uno, donde la credencial es un Worker desplegado y un slice gobernado de una profesión, no una línea del currículum. También nombró un servicio que nunca planeó y ahora construye porque los clientes lo exigen: ayudar a reorganizar la propia empresa, decidir a quién contratar, qué deben decir los puestos y cómo cambia el trabajo al llegar los agentes. Léelo con atención. Un equipo FDE de proveedor está recibiendo desde el cliente la pregunta de Harari. Ese servicio es esta página y la vía de Strategist que la respalda.
Un último detalle: su equipo despliega agentes de nube de Cursor y construye aplicaciones con Cursor SDK dentro del código del cliente. Recuérdalo al leer el párrafo siguiente.
El problema del lock-in con proveedores. Esta es la trampa. Todo FDE de Palantir construye sobre la plataforma de Palantir. Todo FDE de OpenAI construye sobre los modelos de OpenAI. Todo FDE de Salesforce construye sobre las herramientas de Salesforce. Todo FDE de Cursor despliega los agentes de Cursor y construye sobre Cursor SDK. El ingeniero se integra profundamente en la empresa del cliente, conecta el producto de ese único proveedor con todo y se marcha. Cambiar después resulta doloroso y caro, como contratar a un fontanero que solo instala una marca de tuberías: la instalación funciona, pero nunca puedes contratar a otro fontanero sin arrancar las paredes. Como señaló Andrew Ng en The Batch, a los clientes les cuesta encontrar FDE que no estén ligados a un solo proveedor, porque para el proveedor el objetivo mismo del rol es retener al cliente.18 El propio lanzamiento de AWS deja ver la trampa. Prometió que los clientes terminarían siendo autosuficientes y podrían seguir construyendo por su cuenta, y en la misma frase especificó que los sistemas agénticos que conservarían se ejecutarían dentro de su propio entorno AWS. Autosuficiencia en la nube de un único proveedor. Es lock-in reformulado como función: eres libre de seguir construyendo siempre que sigas construyendo aquí. El lanzamiento de Microsoft hizo la misma concesión de otra manera. Cuando le preguntaron por la comparación con Palantir, el ejecutivo responsable de Frontier sostuvo que Microsoft admite más modelos, más conectores de datos y más integraciones con sistemas de registro abiertos que su rival.3 Observa qué significa esa defensa: un proveedor mide su propio lock-in frente al de otro y presenta la jaula más amplia como ventaja. La objeción que plantea este libro acaba de ser admitida desde el propio escenario del proveedor.
Este libro forma al FDE que el mercado sigue pidiendo y no encuentra. El método no está ligado a ningún proveedor. Quien se gradúa lleva el pipeline completo, especificar la intención, construir el Worker, diseñar el sistema y operarlo en producción, dentro de la organización de un cliente sin encerrarlo en una sola plataforma. Cuando aparezca un modelo mejor el próximo trimestre o se publique un runtime más barato el próximo año, cambia. El cliente conserva la libertad de elegir y el ingeniero conserva una disciplina que funciona en cualquier stack. Hay un intercambio honesto que conviene nombrar: el FDE de un proveedor está muy subsidiado, a veces es gratuito, porque el proveedor recupera el coste mediante lock-in, mientras que al FDE neutral respecto del proveedor lo paga el cliente o una firma independiente. Esa es la función, no el defecto: el cliente compra opcionalidad ahora en lugar de pagar costes de cambio más adelante. El plano operativo dentro del que trabaja este ingeniero es el FDE AF Model: cinco capas desde el marco hasta el cliente, incluida la forma en que el FDE gana en cada una.
Pocos programas forman de extremo a extremo esta versión neutral respecto del proveedor y, para ser exactos con la afirmación, lo que este libro enseña es el núcleo técnico del FDE neutral, la mitad que el mercado no encuentra. La otra mitad, el descubrimiento con el cliente, la priorización, el marco de ROI y la disciplina necesaria para rechazar una petición irreal, pertenece a la vía Certified Agentic AI Business Strategist. Forma el núcleo técnico; la capa de consultoría vive en la vía de Strategist.
La objeción más difícil: sin plataforma, eres una empresa de desarrollo
La sección anterior afirmó que la plataforma es una jaula. Considera ahora la respuesta más fuerte, formulada por el mismo profesional que explicó por qué existe el rol.
Bai se adelanta a la persona del público que afirma que una función FDE no puede sobrevivir en la empresa, porque construir algo personalizado para cada cliente te deja gestionando decenas de repositorios que nadie puede mantener y a ingenieros que renuncian antes que aprenderlos. Bai está de acuerdo, con una condición. Si cada FDE construye totalmente desde cero, entonces, en sus palabras, no tienes una función FDE, sino una empresa de desarrollo: quizá sea un negocio rentable, pero no es el mismo negocio. Lo que la convierte en una función FDE es que los ingenieros nunca escriben software desde cero. Ya existe un conjunto de primitives compartidos y el ingeniero los ensambla para crear algo de valor arbitrario para el cliente. Sin eso, afirma, el coste de mantenimiento devorará tu cuenta de pérdidas y ganancias, suponiendo que todos tus ingenieros no hayan renunciado antes.4 Sobre la granularidad que deben tener los primitives, se niega a ofrecer una respuesta universal: en algunos sectores la aplicación está construida en un 60% y el cliente personaliza el resto; en otros, el dominio exige herramientas granulares. La comparación útil es AWS, que te entrega DynamoDB para que nadie tenga que inventar una base de datos, precisamente porque atiende a un conjunto de clientes extremadamente amplio.
Tómalo en serio: es la factura de la neutralidad. Quitar al proveedor también quita sus primitives. Si no haces nada, el pod de uno se convierte en empresa de desarrollo de uno: código a medida, nada reutilizable y mantenimiento creciente hasta consumir el margen. La prueba de Bai es honesta: ¿tengo plataforma o estoy dispuesto a invertir en construirla?
La respuesta está en la sección siguiente, y esa es la razón de que exista. El FDE neutral respecto del proveedor sí lleva primitives compartidos. Simplemente no son código propiedad de un proveedor.
Qué llena el pod: dos Systems of Record
Todo lo anterior dice dónde trabaja un FDE. Todavía no dice qué lleva al cruzar la puerta, la pregunta que obliga a responder la neutralidad.
Pregunta primero por la versión del proveedor. Un ingeniero de Palantir llega con la ontología y las herramientas de Palantir ya construidas por otra persona. Es una ventaja real y explica por qué un ingeniero puede hacer ahora en semanas lo que antes llevaba años a un equipo. También es la jaula descrita en la sección anterior: el cliente conserva la libertad de seguir construyendo siempre que siga construyendo allí.
Ahora quita al proveedor. ¿Qué queda? Si la respuesta honesta es «el método, en su cabeza», entonces vende horas de ejecución humana, que es la pirámide de servicios que debía sustituir, y el cliente que dice «nos falta personal» está pidiendo exactamente eso. El pod de uno no puede sobrevivir con horas. Sobrevive con activos que viajan de un cliente al siguiente.
Viajan dos, ambos Systems of Record. Lo que llevas contigo presenta el argumento completo; esta es su mitad profesional.
El primero es el método y no lo construyó ella. Este libro, profundo y gobernado, servido como web para personas y por MCP para agentes. Contiene cómo especificar un resultado, fabricar un Worker, ejecutar el bucle, confiar en el verificador y demostrarlo en producción. Cada graduado lleva el mismo, idéntico en una firma contable de Karachi y otra de Chicago porque el método no cambia con el dominio.
El segundo es la profesión y lo construyó ella. Un vertical, una jurisdicción, gobernado por ella y licenciado por un experto comprometido: ley, normas, procedimientos derivados, invariantes y mapa de decisiones. Empieza con un resultado profesional cubierto por completo y se espesa proyecto tras proyecto. Nadie más posee este.
Ambos hablan MCP, por lo que su agente lee los dos a la vez: uno le dice cómo construir un Worker; el otro, qué exige la profesión. No hay integración adicional porque el núcleo del ecosistema se diseñó para esa pareja.
Y esto responde a la objeción de la empresa de desarrollo. La condición de Bai eran primitives compartidos para que el ingeniero nunca partiera de cero. Los dos Systems of Record superan esa prueba. El método es la capa de primitives de cómo se construye el trabajo: especificar el resultado, fabricar el Worker, ejecutar el bucle, confiar en el verificador y demostrar el resultado en producción. Es idéntico en cada cliente, justo la propiedad que Bai exige y que una empresa de desarrollo no tiene. La profesión es la capa de primitives de lo que el trabajo debe obedecer en un vertical y una jurisdicción. Ninguno es código bifurcado por cliente. Eso dobla la curva de mantenimiento: se conserva un corpus gobernado y el código circundante se regenera en vez de cuidarlo indefinidamente. De ahí se desprenden dos cosas que deben decirse con claridad. Primero, la condición se cumple sin proveedor, que es toda esta página reducida a una frase. Segundo, el coste no desaparece, se mueve. Ahora mantienes un corpus en lugar de repositorios y alguien debe financiarlo antes del primer cliente: construir primero, vender después. Lee esta segunda mitad como razonamiento del libro, en la misma categoría que la aritmética de Aggarwal. La advertencia de Bai procede de una década viendo caer costes de mantenimiento sobre equipos reales; que un corpus gobernado aplana la curva es todavía una afirmación, no una medición.
Cómo se espesa el segundo. Bai también establece la regla de lo que conserva un proveedor: todo lo hecho a medida y exclusivo de un cliente debe existir solo para ese cliente, y todo lo generalizable debe generalizarse con el tiempo. Así, el despliegue avanzado se convierte en una función de exploración, la forma en que el proveedor descubre qué debe incorporar después al producto.4 La versión neutral respecto del proveedor aplica la misma regla a un destino distinto. Lo que se generaliza no entra en la plataforma de un proveedor. Entra en el System of Record vertical: la norma que resultó regir a tres clientes en vez de uno, el procedimiento que el experto escribió una vez y ahora firma en todas partes, la invariante que se mantuvo en cada firma de la jurisdicción. Eso es lo que significa mecánicamente que se espesa proyecto tras proyecto, y por eso atender al segundo cliente cuesta menos que atender al primero.
Y aquí está la razón por la que la neutralidad respecto del proveedor obliga a elegir. El FDE de un proveedor se especializa por plataforma. Si quitas la plataforma, la especialización tiene que residir en alguna parte o te conviertes en un consultor generalista sin nada que reutilizar. Pregunta qué viaja del cliente dos al cliente tres. La forma del trabajo viaja gratis, porque leer un documento frente a una regla, citar la regla y escalar lo que no está claro es método, y ya se encuentra en el primer System of Record. Nadie paga una prima por eso. Lo que paga un comprador es la parte que no se generaliza: qué norma rige esta pregunta, qué versión estaba vigente en este periodo, qué regulador nacional es responsable de esta regla y qué debe firmar personalmente el socio. Todo ello es profesional y jurisdiccional. Nada de ello sobrevive al paso de expedientes de auditoría a declaraciones aduaneras.
El eje es la profesión y la neutralidad lo coloca allí. Elegir tu vertical explica cómo escogerlo y Diseñar el System of Record vertical, cómo construirlo.
Las dos respuestas en paralelo. El ingeniero de un proveedor llega con una plataforma que se queda atrás; uno neutral llega con el método recibido y la profesión que construyó.
De ahí se desprende un orden que decide cómo empieza una carrera. Construye primero, vende después. El slice no es un paso que espera a que aparezca un cliente. Es el paso que produce uno. Esta página ya ha explicado la razón tres veces sin nombrarla: el portfolio es la credencial, el currículum se filtra por sistemas entregados y un comprador al que no se le ha mostrado nada no te dirá su propia cifra de base. Entra en una firma mediana con una página gobernada de la propia profesión de esa firma y la siguiente pregunta llegará desde su lado de la mesa.
La pregunta más justa del cliente cierra el argumento. El ingeniero de un proveedor puede responder con facilidad: traigo nuestra plataforma y la ventaja se queda con nosotros. La versión neutral responde de otra manera: traigo el método y una profesión ya gobernada, y lo que conservarás cuando me marche es un sistema funcional que puedes cambiar, sobre un stack que elegiste y con la opción de contratarme directamente. Observa lo que esa respuesta no afirma. El cliente no se marcha como propietario del System of Record vertical. Lo conserva la startup de dominio que construyeron ella y su experto, contiene material del experto bajo licencia y contiene fuentes de terceros bajo sus propias condiciones. Por eso, una licencia para prestar servicio a una norma dentro de su sistema no se convierte en la licencia del cliente por el mero hecho de que ella la ofreciera. Lo que el cliente conserva es la libertad que la versión del proveedor no puede ofrecer.
Una etiqueta honesta, en el espíritu de la sección salarial anterior. Los datos de demanda están medidos. El pod de uno se deduce del método. Pero todavía no existe un recuento verificado de personas graduadas y neutrales respecto del proveedor que hayan convertido un corpus gobernado en su primer cliente, porque la categoría es nueva y el estante de abajo sigue vacío. Lee este orden como razonamiento del libro, en la misma categoría que la aritmética de Aggarwal: sólido y todavía no medido.
Un pod de uno
AWS envía pods de cinco o seis ingenieros durante unos 45 días. Así se ve el despliegue cuando las personas aún construyen a mano: requiere un equipo pequeño. Este libro cambia quién está en el pod. Un graduado lleva el mismo trabajo al cliente por sí solo y las personas que antes se sentaban a su lado ahora son Digital FTE, los Workers que el ingeniero construye y opera. El equipo se reduce a una persona que dirige una fuerza laboral de Workers. El trabajo es el mismo; cambia lo que llena el pod. El poder ya no proviene de añadir personas, sino del método y de los Workers que produce. Leído junto a la sección anterior, el pod tiene dos mitades: los Workers sustituyen a las personas y los dos Systems of Record sustituyen la plataforma del proveedor. Es el mismo cambio que muestra desde el otro lado la nueva proporción entre producto e ingenieros: la producción de cada persona sigue creciendo mientras disminuye el número de personas. El arco completo, pod heredado → pod comprimido → pod de uno, aparece en «Cómo el equipo se hizo tan pequeño».
Un riesgo que esto crea, nombrado por alguien que antes lo dotó de personal a la manera tradicional. Cuando le preguntaron si varios FDE debían trabajar en un mismo proyecto, Bai respondió que es un buen patrón, y su razón es la que importa aquí: no quieres un único punto de fallo, una sola persona que guarda toda la información, se va de vacaciones y deja el proyecto detenido detrás de ella.4 Un pod de uno es ese riesgo en su forma más pura, y fingir lo contrario sería deshonesto. La respuesta del libro no es que el riesgo desaparezca, sino que sale de la cabeza humana. Lo que aporta un segundo ingeniero es redundancia de conocimiento, y en este método el conocimiento ya está escrito: la especificación, los evals, el corpus gobernado, el Worker desplegado y su runbook. La afirmación es redundancia mediante artefactos en lugar de plantilla, y viene con una prueba que puedes aplicarte. Si no estuvieras disponible durante dos semanas, ¿podría otra persona graduada de este libro retomar el proyecto solo a partir de tu repositorio? Si no, no tienes un pod de uno. Tienes un bus factor de uno.
La tercera puerta: el FDE freelance
Hasta aquí el FDE tenía dos direcciones: la nómina del proveedor y la firma independiente. Ahora se abrió una tercera: el mercado freelance. Upwork mantiene una categoría dedicada a contratar Forward Deployed Engineers y publica bandas aproximadas de 2.000 a 5.000 dólares por una primera integración, 5.000 a 15.000 por una implementación a medida, 15.000 o más por despliegues empresariales, 4.000 a 10.000 mensuales por soporte continuo y 150 a 250 por hora en consultoría estratégica.19 En Reino Unido, los contratos pagan £600-750 al día en nivel medio, £750-1.200 senior y £1.200-2.000 principal, y un reclutador especializado informa que los FDE senior eligen activamente contratos frente a puestos permanentes.20 También surgieron plataformas fraccionales con matching dedicado y vacantes de «Fractional Forward-Deployed Engineering Lead» que se cubren en días.21
Ahora viene la lectura honesta, porque la página del marketplace recompensa una mirada atenta. La categoría existe; la oferta que hay debajo no. Recorre los perfiles que Upwork presenta como Forward Deployed Engineers y encontrarás generalistas capaces, desarrolladores full-stack, ingenieros DevOps y builders de aplicaciones, ninguno de los cuales describe trabajo FDE, entrega integrada ni un pipeline de extremo a extremo. El marketplace construyó el estante antes de que nadie lo abasteciera. Es la frase inicial de esta página representada en la capa del marketplace: el título llegó antes que la formación. Para la mayoría de los títulos laborales, un estante vacío es una advertencia. Para un lector formado, es la apertura: el lado de la demanda publica proyectos y paga tarifas conocidas dentro de una categoría que el lado de la oferta todavía no ha aprendido a ocupar.
Tres cosas hacen que esta puerta sea distinta de las otras dos. Primero, es el mercado natural del FDE neutral respecto del proveedor. Un FDE de proveedor no puede trabajar como freelance: su rol solo existe dentro de la nómina del proveedor, soldado a su plataforma. Todo FDE freelance auténtico es, por construcción, la versión neutral que forma este libro. En el mercado abierto, la neutralidad respecto del proveedor deja de ser un diferenciador y se convierte en el requisito de entrada. Segundo, el nivel de retainer no es mantenimiento disfrazado. Es el modelo de suscripción de Digital FTE que enseña este libro, operado desde fuera, y la tarifa mensual te paga por operar los Workers que fabricaste: el pod de uno convertido en ingresos recurrentes. Tercero, y lo más importante para quienes leen este libro, esta puerta no tiene frontera. El mercado asalariado de FDE exige en gran medida una dirección de trabajo en Estados Unidos o Europa; el mercado freelance y fraccional exige un portfolio y una conexión. Lo que Aggarwal atribuye a las décadas de TI de India circula por este canal para cualquiera: el mismo contrato se ejecuta desde Karachi, Lagos o Bangalore.
Dos restricciones, expresadas con claridad. Integrarse es la esencia del trabajo, y la integración remota es más difícil que la programación remota: el FDE freelance gana comunicando de más, manteniendo horarios compatibles con el huso del cliente y tratando la presencia ocasional en sitio como parte del precio de la prima. Y la propia prima se gana, no basta con publicarla: los perfiles sin resultados demostrados empiezan cerca de las tarifas generalistas, y lo que hace subir a un ingeniero por las bandas son los resultados comprobados, exactamente lo que producen los proyectos finales de este libro. Un Worker desplegado, un plugin entregado, una app de conectores activa y un slice gobernado de una profesión: en este mercado, esas son las credenciales. El libro forma la entrega; el descubrimiento con el cliente y la disciplina de precios viven en la vía de Strategist; la reputación debes construirla tú, contrato a contrato.
Contrata directamente al FDE y el título desaparece. «FDE» nunca fue una descripción del ingeniero ni de sus habilidades. Describe dónde trabaja: integrado dentro de la empresa de un cliente, como persona externa, llevando toda la línea de extremo a extremo. Por tanto, la pregunta decisiva es sencilla: ¿en la empresa de quién construye? Si construye dentro de su propia empresa, el trabajo corresponde a los cuatro roles centrales. Si construye dentro de la empresa de un cliente, el mismo trabajo se llama FDE. Ahora contrata directamente a ese ingeniero. La empresa del cliente se convierte en su propia empresa. Ya no está desplegado hacia delante, sino simplemente desplegado. Nada cambió en el trabajo; solo cambió la dirección. Por eso el título FDE desaparece y el ingeniero vuelve al núcleo interno: una persona responsable de todo el pipeline dentro de la empresa que la contrató. El nombre único para ese rol es AI-Native Company Architect, que diseña la empresa y normalmente también la opera como Cloud AI Engineer.
Esa libertad solo pertenece al FDE neutral: puede incorporarse a la empresa. El cliente puede contratarlo como empleado y al día siguiente hará exactamente el mismo trabajo porque la disciplina vive en la persona, no en una plataforma; entra por la puerta con ella. El FDE de proveedor no puede hacer ese viaje. El día que abandona Palantir u OpenAI, la plataforma sobre la que se construyó todo el puesto queda atrás. El ingeniero sigue teniendo talento, pero la ventaja se queda con el proveedor. Por eso el FDE de proveedor está en préstamo permanente: es útil mientras permanece integrado y desaparece en cuanto termina la relación con el proveedor. Nuestra persona graduada puede contratarse para quedarse. El cliente puede alquilarla como FDE y después incorporarla como AI-Native Company Architect sin perder el paso. Eso compra la neutralidad: un ingeniero que la empresa puede conservar, no solo tomar prestado.
Persiste una asimetría. El primero de los dos, el Agent Factory System of Record, viaja con ella porque pertenece al ecosistema y es abierto. El segundo pertenece a su startup de dominio, respaldado por la licencia del experto y términos de terceros, así que una contratación directa exige una conversación comercial, no una transferencia automática. La disciplina es portátil; el activo tiene dueño.
La ruta de contratación directa: desplegado en el cliente es FDE; contratado, vuelve al núcleo como AI-Native Company Architect. Solo un FDE neutral puede hacer este viaje.
Conseguir el puesto es otra disciplina. El currículum se filtra por señales distintas y la entrevista incluye una ronda en la que fracasan muchos buenos ingenieros. Los Apéndices A y B cubren ambas; el C conecta los cursos del libro con cada ronda.
El Subject Matter Expert como Skill Author
Subject Matter Expert como Skill Author: el rol que el mercado todavía no ha nombrado. El contador, abogado o experto en cadena de suministro codifica su criterio en SKILL.md, un archivo de texto que empaqueta una habilidad que el agente puede cargar y seguir, y se convierte en el motor de conocimiento de un Digital FTE. El trabajo es concreto: toma la regla tácita que aplicas sin pensar, como la forma en que un auditor experimentado decide qué transacciones señalar o un perito de siniestros interpreta un caso límite, y escríbela con precisión suficiente para que un agente la ejecute. Después comprueba si las decisiones del agente coinciden con las tuyas y revisa SKILL.md hasta que lo hagan. La mayoría de los mapas del mercado omite este rol porque aún imagina el trabajo de IA como exclusivamente ingeniería. Este libro trata el criterio de dominio como algo que puede redactarse, probarse y desplegarse, y forma al experto para hacer las tres cosas. Como el Forward Deployed Engineer neutral, es un rol que casi nadie más forma. Lo enseña por completo: entra criterio, sale un agente funcional.
Observa que estos dos roles sin nombre no son simplemente parecidos. Se necesitan mutuamente. El segundo System of Record del FDE neutral respecto del proveedor no puede existir sin un autor, porque los procedimientos que contiene se escriben con la voz de un profesional y se derivan de sus archivos reales. Y el Skill Author necesita a alguien que construya el hogar gobernado donde vivirá su criterio. Ninguno es un socio menor. El experto aporta veinte años y la licencia. El ingeniero aporta el método y la construcción. Esa pareja es la unidad que el FDE AF Model llama vertical, y por eso Elegir tu vertical se niega a lanzar uno sin un experto comprometido.
El mercado acaba de poner precio a este rol. A mediados de 2026, Business Insider presentó el caso de Yousuf Imran, un ejecutivo de cuentas de Google cuyas comisiones de ventas convertían un salario base de 170.000 dólares en aproximadamente 986.000 dólares al año. En abril renunció para fundar Mangosteen Studio, un laboratorio de productos de IA que construye herramientas de ventas para vendedores.22 Mira más allá de la cifra del titular y observa lo que no es: un software engineer. Su activo declarado eran veinte años aprendiendo los problemas que enfrentan los vendedores, y su apuesta es que ese criterio, codificado en productos de IA de su propiedad, vale más que un salario cercano al millón de dólares por alquilarlo. Explicó la decisión en términos de propiedad: si el capital es donde reside el potencial de esta era, ese capital debe estar en una empresa que él mismo construya. Esa es la apuesta del Skill Author, hecha al precio más visible que el mercado ha publicado hasta ahora y, como la aritmética de Aggarwal, es la apuesta de una persona, una señal, no una estadística. El titular dice que un hombre se alejó de 986.000 dólares; el mecanismo dice que la experiencia de dominio se convirtió en un insumo de fabricación y el experto conservó la fábrica.
El Connector and Plugin Engineer
Connector and Plugin Engineer: amplía los hosts de agentes que otras personas ya usan. Antes de construir un Worker dueño de su bucle, existe una disciplina completa dedicada a construir aquello que el agente alcanza cuando debe actuar, y el mercado la llama de cinco maneras: MCP engineer, integrations engineer, connector developer, plugin developer y agent-tooling engineer. Es un mismo trabajo en dos direcciones. Una app nativa de conectores amplía la aplicación de chat, claude.ai, para usuarios finales: entregas un servidor MCP remoto, herramientas, estado persistente, un inicio de sesión real y una compuerta de sesión que falla de forma cerrada; una persona desconocida la añade pegando una URL y, desde ese momento, el propio modelo es tu cliente. Un plugin amplía el agente de código, Claude Code u OpenCode, para builders: skills, subagentes, hooks y servidores MCP tras una instalación, donde un hook determinista separa el consejo que el modelo puede omitir de la regla que siempre se ejecuta. Es el mismo movimiento en dos hosts y debajo de ambos se encuentra el mismo artefacto, un servidor MCP; por eso el libro los enseña de manera consecutiva. El hilo conductor es una idea de la tesis: entregas una unidad que un host carga y posees la extensión mientras el host posee el bucle. Forma ambos de extremo a extremo hasta llegar a un artefacto desplegado. Emitir identidad, es decir, tu propio servidor de inicio de sesión e identidad para agentes, pertenece al curso AI Identity, y construir el runtime queda fuera de alcance, como explica la sección sobre dónde se detiene el libro.
Los roles de apoyo
Todo pipeline necesita personas que revisen el trabajo, establezcan las reglas y asuman responsabilidad. Estos tres roles hacen eso.
Evals Engineer: quien somete a pruebas de choque a los AI Workers antes de que entren en producción. No lanzarías un automóvil sin someterlo a pruebas de choque. No lanzarías un medicamento sin ensayos clínicos. Un AI Worker que toma decisiones que afectan a personas reales y dinero real necesita la misma disciplina. Evals Engineer diseña esas pruebas: ¿da el Worker la respuesta correcta? ¿Falla con elegancia cuando recibe algo que nunca ha visto? ¿Permanece dentro de los límites que se le asignaron? No es una ocurrencia tardía añadida al final. Forma parte de cada capítulo. Currículo central, no complemento.
AI Governance Officer: decide qué puede hacer la IA. Todo empleado de una empresa tiene límites. Un contador junior puede aprobar gastos de hasta 500 dólares, pero necesita la firma de un responsable para superar esa cantidad. Un cajero bancario puede procesar un depósito, pero no aprobar un préstamo. Los AI Workers necesitan la misma estructura. Governance Officer escribe esas reglas para toda la empresa: qué puede decidir la IA por sí sola, qué debe enviarse a un humano para su aprobación y qué no debe tocar nunca. También realiza el mapeo con las regulaciones que deba seguir la organización, como las normas de igualdad crediticia en un banco, la privacidad del paciente en un hospital o las leyes de residencia de datos en Europa. AI-Native Company Architect construye el sistema que aplica esas reglas; Governance Officer decide qué deben decir. El libro enseña directamente la disciplina del marco; las regulaciones concretas de tu sector son el insumo que aportas. Enseña el marco de gobernanza; las normas de tu jurisdicción debes proporcionarlas tú.
Digital FTE Supervisor: la persona cuyo nombre queda comprometido. Cuando un AI Worker procesa una reclamación, redacta un contrato o marca una transacción, alguien debe responder. Esa persona es Supervisor. Es el humano dentro del bucle: revisa el trabajo, aprueba la salida y es el nombre al que apunta el registro de auditoría cuando algo falla. No es quien construyó el Worker. Es quien lo opera a diario, como un jefe de turno dirige un equipo. El libro lo enseña.
Dónde se detiene el libro de forma deliberada
LLMOps Engineer: hasta el modelo, no el modelo mismo. Operar agentes en producción pertenece a Cloud AI Engineer y el libro lo enseña. También enseña fine-tuning de forma práctica, pero como último recurso, no como predeterminado. Un fine-tune liga el sistema a una instantánea del modelo y sacrifica la opcionalidad que protege todo el método, por lo que solo se usa cuando prompting, contexto, herramientas y retrieval realmente no bastan. La línea firme es construir el modelo: preentrenar un modelo fundacional desde cero queda fuera de alcance porque esa capacidad se está mercantilizando. Enseña fine-tuning y las operaciones alrededor del modelo, no la construcción de modelos fundacionales.
Harness Engineer: el runtime que usas, no el que construyes. El harness es el runtime del agente, OpenAI Agents SDK, los agentes gestionados de Claude y otros sistemas similares, que ejecuta el bucle del agente, gestiona el estado y realiza llamadas a herramientas. El libro enseña a usarlos con soltura y mantener la portabilidad entre ellos, porque tu disciplina sobrevive a cualquiera que resulte vencedor. Construir el propio runtime no es el trabajo. Forma al operador que usa cualquier runtime, no al ingeniero que lo construye.
AI Data Engineer: la capa de datos orientada al agente. El trabajo del System of Record toca esa capa: Postgres, pgvector y MCP como columna vertebral de la que lee un agente. La ingeniería clásica de pipelines y almacenes es adyacente, no central. Enseña la capa de datos orientada al agente, no la ingeniería de datos general.
El segundo eje: tu tipo, no solo tu puesto
El mapa anterior indica dónde se sitúa el trabajo. No indica qué asiento encaja contigo. En junio de 2026, Boris Cherny, creador de Claude Code y de la herramienta que más impulsó la explosión de ejecución medida aquí, observó su propio equipo y preguntó qué ocurre con los roles cuando ingeniería, producto, diseño y ciencia de datos se «funden en una nueva clase de rol».23 Su respuesta fueron cinco arquetipos, ninguno de ellos una función laboral. Prototyper produce ideas completamente nuevas, muchas de las cuales nunca llegan a producción. Builder convierte con rapidez un prototipo en producto o infraestructura de calidad de producción. Sweeper simplifica el sistema, limpia la interfaz, retira funciones y optimiza. Grower itera un producto construido hacia product-market fit. Maintainer se responsabiliza de un sistema maduro y lo mantiene seguro, fiable, rápido y eficiente mientras escala.
Los cinco arquetipos de Cherny y dónde riman con este mapa: con fuerza, pero no uno a uno.
Dos observaciones hacen el trabajo. Primero, los arquetipos no están ligados a títulos: en Anthropic hay diseñadores Prototypers, Builders y Sweepers, y la misma distribución aparece entre ingenieros, PM y data scientists. Es la afirmación inicial de esta página, que el título ya no describe el trabajo, confirmada desde dentro del laboratorio. Segundo, la mayoría de las personas abarca dos arquetipos, a veces tres, y la mezcla que necesita un equipo cambia con la fase del producto: el trabajo anterior a product-market fit se apoya en los tres primeros; un producto maduro, en los tres últimos. Leídas frente a este mapa, las correspondencias son claras sin ser uno a uno. Outcome Architect es un puesto de Prototyper; Digital FTE Builder, de Builder; Evals Engineer, de Sweeper; Cloud AI Engineer y Supervisor, de Maintainer. Abarcar varios es el pod de uno visto desde dentro: los Workers absorben las tareas, mientras los dos o tres arquetipos del humano deciden qué puestos puede ocupar de verdad y qué disciplinas de apoyo debe pedir prestadas en vez de fingir, evals para la resta de Sweeper y gobernanza para la prudencia de Maintainer. Cherny termina con una pregunta, no una afirmación: quizá los roles de producto del futuro se parezcan más a estos cinco y menos a los dominios actuales. Esta página ofrece una respuesta. Los roles dicen dónde está el trabajo; tus arquetipos, qué asientos ocupar.
El patrón lo revela. La era de los agentes distribuye el trabajo en muchos roles: construir Workers, operarlos, gobernarlos y enseñarles criterio. El mapa es lo importante: encuentra dónde estás, qué arquetipos abarcas y hasta dónde te lleva el libro.
Apéndice A: el currículum del FDE, seis señales
Las prácticas de selección cambian con rapidez; este apéndice y el siguiente se verificaron con fuentes de mediados de 2026.
Los reclutadores no leen un perfil FDE como uno de software engineer. El análisis de prácticas reales de selección converge en seis señales, y un perfil que las oculta se rechaza antes de poner a prueba el nivel técnico.24 Las tres primeras preguntan si realmente entregaste: sistemas en producción, despliegues reales, no funciones pendientes en el backlog de un equipo; impacto cuantificable, no «construí la función X», sino qué obtuvo el cliente expresado en cifras; y contacto directo con clientes, es decir, te sentaste con la parte interesada en vez de mantenerte detrás de un product manager. Las otras tres preguntan cómo entregas: trabajo con datos desordenados, porque los entornos reales nunca están limpios; responsabilidad bajo ambigüedad, porque dirigiste el proyecto cuando nadie lo había definido; y profundidad en IA/LLM, incluidos RAG, agentes y evals, la razón de ser del rol.
De ahí salen tres reescrituras. Primero, convierte toda actividad en resultado: «construí un pipeline ETL» pasa a «entregué un pipeline que redujo el cierre mensual del cliente de cinco días a dos». Segundo, escribe «yo», no «nosotros»: los evaluadores de FDE interpretan «nosotros» como «me llevaron» y lo investigan en la entrevista con el hiring manager. Tercero, elimina los premios de programación competitiva. Un premio por resolver acertijos de estructuras de datos demuestra preparación para la entrevista equivocada. Sustitúyelos por un portfolio. La sección freelance ya nombró la regla, el portfolio es la credencial: un Worker desplegado, un plugin entregado y una app de conectores en vivo, cada uno con un resultado en una línea. Cada proyecto final del libro se diseñó para producir exactamente esa línea.
Un elemento es diferente y un candidato neutral debe encabezarlo: un slice gobernado de una profesión, publicado para lectores y agentes. Un Worker demuestra que construyes. Un slice demuestra que posees algo que ningún empleador te entregó y será una línea que el evaluador casi nunca vio.
Apéndice B: la entrevista FDE, el circuito y la trampa
El circuito tiene entre cinco y ocho etapas durante tres a seis semanas: selección inicial con recruiter, entrevista con hiring manager, programación práctica, diseño de sistemas, caso de descomposición, simulación de cliente y entrevista conductual; algunos laboratorios de IA añaden un ejercicio para casa basado en sus API.24 Dos rondas deciden el resultado y ninguna es la que suelen preparar los ingenieros.
La descomposición es el filtro. Recibes un problema empresarial real y vago: «una gran ciudad quiere reducir los tiempos de respuesta ante emergencias; tiene datos de llamadas, tráfico y GPS de ambulancias; cuentas con sesenta minutos». El rechazo más común es responder de inmediato. Quien empieza con «construiría un modelo predictivo con XGBoost» ya falló porque resolvió antes de delimitar. Puntúa la secuencia: aclarar la meta real, nombrar las partes interesadas y la métrica de éxito, mapear qué datos existen y quién los posee, dividir el problema en partes ordenadas según el riesgo y proponer primero el esqueleto más delgado de extremo a extremo. Los supuestos se declaran en voz alta, los modos de fallo se exponen sin que nadie los pida y el razonamiento se narra continuamente. Quien lee este libro reconocerá la secuencia: es desarrollo guiado por especificaciones realizado verbalmente. La ronda no prueba si conoces la respuesta, sino si escribes la especificación antes de permitir que alguien, humano o agente, ejecute.
La simulación del cliente es el segundo filtro. Un entrevistador representa a un cliente, a veces frustrado y a veces no técnico, y tú comunicas malas noticias, rechazas una petición que compromete la gobernanza o explicas por qué el sistema no puede prometer 100% de precisión, todo sin jerga ni promesas imposibles. Cinco señales rojas se repiten entre las fuentes: resolver antes de aclarar, ignorar costes y restricciones, historias débiles de producción, sin explicar qué ocurrió cuando una API falló en producción, ausencia total de vocabulario de cumplimiento en sectores regulados y falta de instinto de cliente.24
Otro formato se extiende: la construcción en vivo. Un circuito documentado duró tres horas: treinta minutos para convertir un caso vago en requisitos bajo preguntas, noventa para construir con un agente de programación verificando todo y depurando en vivo, y sesenta para presentar a una parte interesada en lenguaje empresarial.25 No hubo LeetCode. La ronda central es Modo 1 bajo observación: dirige al agente, verifica cada salida y narra el bucle.
El matiz de cada empresa importa en los márgenes: Palantir enfatiza ingeniería de datos, pensamiento ontológico y la ronda de descomposición que inventó; OpenAI, construir y evaluar sistemas contra sus API, con «¿cómo sabes que realmente funciona?» como pregunta diferenciadora; Anthropic, que llama al puesto Applied AI Engineer, enfatiza sistemas LLM de producción, evals y alineación con la misión.24 Sin embargo, los fundamentos anteriores conforman el circuito en todas partes, y la preparación exige de cuatro a seis semanas de disciplina: primero fundamentos e historias, después diseño de sistemas, luego práctica cronometrada de descomposición con una pareja y grabada, porque la mayoría se sorprende de lo rápido que salta a soluciones, y por último el ajuste específico para cada empresa.
Apéndice C: prepararte para FDE con este libro
La entrevista no se diseñó alrededor del libro, pero podría parecerlo. Cada ronda corresponde a material ya asignado:
| Ronda | Qué evalúa | Dónde lo enseña este libro |
|---|---|---|
| Caso de descomposición | Delimitar antes de resolver, disciplina de especificación en voz alta | Desarrollo guiado por especificaciones, Cómo pensar en la era de la IA |
| Programación práctica | Ingeniería real con un agente, verificada | Python en la era de la IA; Código que nunca escribes; los Siete Principios de resolución de problemas |
| Profundidad específica de IA | RAG, agentes, evals, «¿cómo sabes que funciona?» | Dar contexto consultable a tu IA, Construir agentes de IA, Desarrollo guiado por evaluaciones |
| Diseño de sistemas | Despliegue empresarial bajo restricciones | Invariantes de la Tesis; Elegir arquitecturas agénticas; Desplegar el Agent Harness |
| Simulación de cliente | Confianza, oposición, lenguaje empresarial | Equipos humano-agente; vía de Strategist |
| Construcción en vivo | Dirigir un agente bajo observación | Claude Code y OpenCode; Fundamentos de ingeniería agéntica |
| Portfolio | Resultados entregados y demostrables | Cada proyecto final: Worker desplegado, plugin, app nativa de conectores, slice gobernado |
Lee la tabla de abajo arriba y verás algo que merece atención: las rondas más difíciles, descomposición, construcción en vivo y la pregunta sobre evals, no son material adicional unido al currículo. Son el currículo examinado. Quien realmente fabricó un Worker bajo disciplina de especificación entra en la ronda de descomposición después de ensayarla decenas de veces, porque escribir una intención por la que se pueda responsabilizar a un Worker y delimitar en voz alta un problema empresarial vago son la misma habilidad a dos volúmenes distintos.