Por Simon Gonzalez de Cruz (el build en público en X @KyaniteLabs_). 2026-08-24. Primero la respuesta directa, después los recibos.
Un forward deployed engineer es el ingeniero que va adonde la IA tiene que funcionar de verdad, y logra que funcione ahí. No es quien entrena el modelo. Es quien toma un modelo que se ve bien en un benchmark y lo convierte en un sistema que un negocio real puede usar todos los días. El trabajo tiene tres partes: encontrar el punto de palanca en un flujo real, construir lo más pequeño que lo mueva, y quedarse a cargo en producción. El resto del post es esa frase desempacada, demostrada en un mini-PC de $1.400.
El título suena fuerte ahora porque los laboratorios de IA están contratando gente para este puesto tan rápido como pueden. El trabajo es más viejo que el nombre. Cualquiera que haya instalado software en una sucursal bancaria, un hospital o una planta ha hecho trabajo forward deployed. Yo hice versiones de esto durante doce años en sistemas de aprendizaje empresariales. Hoy corro el trabajo completo en mi propio hardware, y cada número que vas a ver es público.
Parte uno: encontrar el punto de palanca
En un negocio hay diez cosas que parecen automatizables. Normalmente solo una importa. El FDE la encuentra mirando el trabajo real, no leyendo un pitch. La herramienta para esto es la medición, no la opinión.
Una decisión de palanca medida en este escritorio: ¿el modelo local debe razonar por defecto? Lo corrimos de las dos formas sobre un set fijo de problemas. En 40 problemas duros, pensar rescató 15 que fallaban sin él. En HumanEval-30, pensar no compró nada: 28/30 en ambos casos. Así que el default que se entrega es pensar apagado, con override manual para tareas duras. Esa sola decisión de ruteo ahorra tokens todo el día y no cuesta nada donde el trabajo es fácil. Método completo en la nota de knees medidos.
Ese patrón escalado se vuelve ruteo de modelos: aquí el trabajo se mueve entre cinco lanes, elegidos por costo y velocidad medidos, no por marca. La misma disciplina, más superficie.
Parte dos: construir con evals
El cliente nunca pregunta "es inteligente". Pregunta "puedo entregarle trabajo e irme". Ningún leaderboard responde eso. Así que el FDE construye la prueba que sí.
Construimos una. Es open source: delegation-bench. Nueve clases de trabajo real. Tests ocultos que el sistema nunca ve. Una celda de sabotaje con una instrucción mala plantada. Pisos certificados, es decir estadística exacta que dice "al menos esto de confiable", no vibras. Resultado en esta máquina: 495 trials, 29 celdas, todas las celdas de capacidad en 20/20, y ocho celdas con certificación walk-away en 35/35 o 30/30 con pisos de 90.5 a 91.8 por ciento. Código, debugging, búsqueda en documentos, razonamiento, decisiones, dos tipos de visión: todos en el nivel walk-away.
La habilidad de código debajo de eso también es medible. 93% HumanEval (28/30, subset congelado, semilla publicada) y 67% LiveCodeBench-30 (20/30, intervalo Wilson 95% de 49 a 81). Siempre cita el intervalo. Misma caja de $1.400.
Parte tres: quedarse a cargo en producción
Esta es la parte que separa el título del demo. El sistema corre sin atención. Está siempre encendido, con watchdogs automáticos, recuperación de reinicios y disciplina de cola. Cuando se rompe, el FDE es el pager.
Una historia real de producción de este rig: a mitad de proyecto, el contexto largo y la visión se rompieron en silencio. La lectura fácil era "el modelo empeoró". No nos quedamos con la lectura fácil. Hicimos bisect de noches de cambios hasta un commit upstream de llama.cpp, lo reportamos como issue 26209, lo arreglamos local y validamos el fix upstream en nuestro silicio con 9/9 respuestas idénticas pareadas. Después re-corrimos los benchmarks congelados para confirmar que nada se movió. Ese es el trabajo. La historia completa de serving está en este blog con logs crudos.
La lista real de habilidades FDE
La gente busca "habilidades fde" y encuentra listas de deseos. Esta es la honesta, cada habilidad probada con un artefacto de arriba:
- Evals y estadística básica. Puedes probar "al menos 90 por ciento confiable" con intervalos exactos, o no puedes afirmarlo.
- Pegamento de integración. La IA nunca trabaja sola. Vive en un pipeline con documentos, colas y aprobaciones.
- Debugging de entorno. Cuando la salida se vuelve basura, encuentras la capa que se rompió. Aquí fue un commit de host buffers, no el modelo.
- Ownership de producción. Watchdogs, reinicios, logs, y la disposición a que te llamen de noche.
- Hablar claro con no ingenieros. La tabla de decisión se entrega con los pisos impresos, para que un operador lea "puedes irte" sin saber qué es un quant.
Lo que el trabajo no es
No es trucos de prompt. No es un demo que funciona una vez en el escenario. Y no es data science: el FDE entrega sistemas, no notebooks. Si te gusta más la última milla que el laboratorio, este es tu trabajo. Si te gustan los problemas limpios, quédate cerca del modelo.
Cada afirmación de este post tiene un log crudo o un repo público detrás. Ese es el estándar. Apúntalo a tu propia máquina y mira cómo se ven tus pisos.
Siguiente en la serie: el decodificador de títulos FDE y por qué las evals son la habilidad FDE que nadie lista. Necesitas este tipo de trabajo en tu entorno? Intake de implementacion. Condiciones de cada número: GMKtec EVO-X2 de $1.400, Qwen3.8-27B Q4_K_XL, llama.cpp, logs crudos en delegation-bench y el repo del stack.