El 14 de septiembre TechCrunch publicó tres piezas de agenda de Disrupt 2026: una invitación a escuchar cómo la IA puede diseñar el regreso de la naturaleza con el fundador de una startup de desextinción valuada en miles de millones, una sesión sobre qué pasa cuando OpenAI publica tu roadmap, y el recordatorio de que el 18 de septiembre cierra la aplicación para mesas de expo frente a más de 10.000 fundadores, inversores y líderes técnicos. Las tres venden entradas: no hay contenido técnico adentro. Dos días antes, Latent Space publicó el análisis de Vinoo Ganesh sobre Forward Deployed Engineers, y ahí sí hay algo para leer con atención.
Por qué importa
Los títulos de un evento son un buen termómetro de la ansiedad del mercado. Que TechCrunch arme una sesión entera alrededor de la pregunta ¿y si el laboratorio de modelos publica exactamente lo que vos estabas por construir? te dice que la preocupación dejó de ser hipotética. La nota lo plantea sin vueltas: la pregunta no es si los modelos fundacionales van a seguir evolucionando, sino si tu empresa va a seguir generando valor mientras eso pasa.
El texto de Ganesh es la otra mitad de la misma conversación. Él construyó la función de forward deployed tres veces en más de una década: en Palantir, donde lideró Project Frontline y pasaron unos 250 ingenieros por esa rotación; en Citadel, donde el único criterio era si el software ayudaba a los portfolio managers a generar alpha; y hoy en Kepler, donde el rol vive adentro de producto y no adentro de ventas. Su observación central es incómoda: casi nadie coincide en qué se supone que ese ingeniero tiene que lograr. En una cena de fellows del programa de a16z encontró que la misma etiqueta describía, según el asiento, a un sales engineer que entra en la segunda llamada, a un vendedor con cuota que sabe Python, y a un consultor con una laptop y un statement of work.
Mi lectura: el FDE no es una moda de títulos, es la respuesta laboral a la commoditización de la capa fina. Cuando el modelo hace cada vez más, lo que queda como defendible es el contexto del cliente: sus datos sucios, su proceso raro, su definición particular de "correcto". Meter un ingeniero adentro de esa operación es una decisión de arquitectura disfrazada de decisión de contratación.
Qué cambia en la práctica
Si trabajás todos los días sobre una API de modelos, el cambio concreto es dónde ponés el esfuerzo. Deja de rendir pulir el wrapper y empieza a rendir todo lo que el modelo no puede adivinar: esquemas de datos del cliente, reglas de negocio no escritas, validación determinística de salidas. Ganesh describe el dominio de Kepler como uno donde una respuesta plausible pero equivocada es peor que no tener respuesta. Esa frase debería estar pegada en la pared de cualquier equipo que integre LLMs en un flujo con consecuencias.
La distinción que más sirve para decidir es cuál de estos tres roles estás contratando en realidad. El material de Ganesh los separa así:
| Eje | FDE | Consultoría | Sales engineer |
|---|---|---|---|
| Dónde reporta | Producto (el caso de Kepler) | Servicios, contra un statement of work | Ventas |
| Dónde trabaja | Adentro de la operación del cliente | Sobre un alcance acordado de antemano | En el ciclo de venta |
| Qué deja atrás | Capacidad que puede volver al producto | Un entregable cerrado | Un cierre |
| Cómo se lo mide | Si el problema del cliente quedó resuelto | Cumplimiento del contrato | Cuota |
La columna que decide todo es la primera. Si el rol cuelga de ventas, el incentivo empuja a prometer lo que el producto no hace, y el ingeniero termina tapando el agujero con código que solo existe en un cliente. Si cuelga de producto, cada implementación tiene que responder una pregunta adicional: ¿esto es una generalización que vuelve al core, o es un fork que vamos a mantener para siempre? Esa pregunta es la que te salva de despertarte con doce ramas de producto y un solo equipo.
Cuándo NO conviene
Primero, lo obvio: si no podés escribir en una línea qué entrega ese ingeniero, no lo contrates todavía. El artículo mismo muestra que el mercado ni siquiera acordó la definición. Contratar un rol ambiguo con un título de moda es la forma más cara de descubrir que en realidad querías un consultor.
Segundo, el tamaño del equipo. En un equipo chico, el FDE es el ingeniero que no está mejorando el producto. Si tenés tres personas y ponés una adentro del cliente, bajaste un tercio la velocidad del core para subir la satisfacción de una cuenta. A veces vale; conviene decidirlo con los ojos abiertos y no llamarlo estrategia.
Tercero, la honestidad sobre los datos. No hay en este material ninguna cifra de retención, margen, tiempo de implementación ni éxito comparado. Hay experiencia de primera mano de alguien que armó la función tres veces, y eso vale, pero no es evidencia cuantitativa. Cualquiera que te venda el FDE como modelo probado con números está agregando datos que en la fuente no están.
Cuarto, y esto aplica al evento en sí: las tres notas de TechCrunch son promoción. La de desextinción no aporta un solo detalle técnico sobre cómo se aplica IA al problema. Tratarlas como análisis sería un error; son el índice de temas, no el contenido.
Qué haría hoy
Si estoy construyendo sobre modelos de terceros, dedico esta semana a una sola pregunta: si el proveedor publicara mañana el 80% de lo que hago, ¿qué me queda? Si la respuesta es "la integración con los datos y el proceso del cliente", vas bien y el patrón de forward deployed te sirve como forma de organizar el trabajo. Si la respuesta es "la interfaz", tenés un problema de arquitectura, no de contratación, y ningún título nuevo lo arregla.