Ingeniería dentro de tu operación, no un informe sobre ella.
El ingeniero se sienta con quien opera, escribe código en tu ambiente y responde por lo que queda en producción. Es el modelo que Palantir creó a principios de los años 2010 y que OpenAI y Anthropic pasaron a usar para meter IA dentro de una empresa que ya funciona.
Antes del nombre: qué hace la persona.
Quita la etiqueta en inglés y queda una descripción simple. Es un ingeniero de software que trabaja desde dentro de tu empresa, en tu sistema, con tu dato real, junto a quien hace el trabajo todos los días. No escribe un documento sobre tu operación: escribe el código que tu operación va a usar.
Tres cosas definen el formato. Quitar cualquiera de ellas convierte el modelo en otra cosa.
Se queda donde ocurre el trabajo
No es una reunión de estado. Es acompañar a quien opera, en el horario en que la operación corre, y ver el paso que nadie escribe en el documento porque para quien lo hace es obvio.
Escribe código en tu ambiente
Tu repositorio, tu nube, tu dato real, no una prueba de concepto sobre una base anonimizada que después alguien tiene que reescribir en serio.
Responde por el resultado
El criterio no es "se entregó el alcance". Es que la operación mejoró y sigue funcionando después de que el ingeniero sale de la sala.
El modelo no es nuevo. Se volvió urgente ahora.
Nació en una empresa que vendía software a gobiernos y industria pesada, donde entregar la licencia y irse nunca funcionó. Cuando la IA pasó a depender del dato y del proceso de cada cliente, el mismo problema volvió, y las empresas de frontera copiaron la solución.
Dónde se creó el puesto
El ingeniero trabajaba dentro del cliente en lugar de en la sede. Hasta alrededor de 2016, la empresa tenía más gente en ese formato que ingenieros de producto.
Fuente: The Pragmatic EngineerQuién copió primero
El equipo empezó a principios de 2025 con dos ingenieros y pasó de diez, repartidos en ocho ciudades, para llevar modelos de frontera hasta producción dentro del cliente.
Fuente: The Pragmatic EngineerQué pide la vacante
Construir aplicaciones de producción dentro del sistema del cliente, viajar entre 25% y 50% del tiempo para trabajar presencialmente, y devolverle al equipo de producto el patrón que se repite.
Fuente: descripción de la vacantea16z llamó al puesto el más disputado del sector y abrió un programa propio: 65 personas en la primera camada, elegidas entre miles de postulaciones. Fuente: a16z
Qué se rompe cuando el ingeniero se queda afuera.
El piloto funciona y no llega a producción
Lo que corre en la presentación no tiene integración, no tiene quién lo opere y no tiene respuesta lista para cuando se equivoque.
Escribimos sobre esto →La regla que decide el caso difícil no está escrita
Está con la persona que hace eso desde hace años. Y solo la cuenta cuando alguien está al lado, mirando la pantalla con ella, en el momento en que aparece el caso difícil.
La integración aparece el día del cambio
El campo que viene vacío en una parte de los registros, el sistema que solo acepta carga de madrugada, el reporte que alguien corrige a mano desde siempre. Un relevamiento por reunión no encuentra nada de eso.
Nadie es dueño después de salir a producción
Entrega firmada, equipo desmovilizado, y el primer error en producción no tiene a quién recurrir. Ahí es donde el proyecto se vuelve pérdida, no en la construcción.
Cómo ocurre en Moonxi, semana por semana.
No es un sexto frente. Es el formato en que Moonxi entrega los frentes de construcción, desarrollo de software y squad dedicado. La cotización sigue saliendo cerrada por frente, en el diagnóstico.
Conversamos con quien opera. Acceso de solo lectura a los sistemas y a la base. Mapa del dato: dónde está, en qué estado, quién lo usa. Qué intentaste antes y dónde se detuvo.
Dónde entra la IA primero, cuál arquitectura, cuánto cuesta operarla al mes, qué necesita aprobación humana. Cotización cerrada por frente, con plazo. Ni una línea de código.
El ritmo pasa a ser semanal: una revisión con quien opera, un pedazo funcionando en tu ambiente y la lista de lo que cambió. Tu equipo revisa cada paso mientras la construcción ocurre.
Alguien de tu equipo aprende a operar, revisar y corregir mientras construimos. Lo que sale a producción sale con documentación y manual de operación.
Lo que no cambia: las reglas de cómo trabajamos valen igual aquí. Todo número lleva su fuente, alguien aprueba antes de que la acción salga, y el dato sensible no sale de tu ambiente.
Para quién es.
La decisión que quieres automatizar está dentro de una operación que ya funciona, con gente, sistema y volumen.
Equivocarse cuesta dinero, plazo o riesgo regulatorio, y alguien tiene que responder cuando pase.
Existe una persona de tu lado dispuesta a operar, revisar y corregir. No necesita saber programar.
Para quién no es.
Lo que necesitas es una recomendación para llevar al directorio. Ahí lo que resuelve es el frente de descubrimiento y arquitectura.
Lo que falta es mano de obra por hora, sin meta. Eso es alquiler de cuerpos, y Moonxi no lo hace.
Ningún sistema tuyo puede ser tocado por gente de afuera. Sin un acceso acordado al ambiente real, este modelo no existe.
Qué cambia frente a una consultoría o a un contrato por hora.
Los tres formatos existen porque resuelven problemas distintos. La diferencia que importa es siempre la misma: dónde trabaja la persona, qué queda cuando se va, y quién responde cuando se rompe a las tres de la tarde de un miércoles.
Consultoría
Sirve cuando el cuello de botella es la decisión, no el sistema.
Contrato por hora
Sirve cuando ya tienes arquitectura, meta y quién revisa.
Forward Deployed Engineer
Sirve cuando el sistema tiene que funcionar todos los días y alguien tiene que tener nombre cuando no funcione.
Preguntas sobre este modelo.
¿Forward Deployed Engineer es un sexto frente de Moonxi?
No. Es el formato en que Moonxi entrega los frentes de construcción, desarrollo de software y squad dedicado. La cotización sigue saliendo cerrada por frente, en el diagnóstico.
¿El ingeniero se queda dentro de mi oficina?
Parte del tiempo, cuando la operación es presencial. El resto es dentro de tu ambiente digital: tu repositorio, tu nube, las ceremonias de tu equipo. El acuerdo sale en el diagnóstico, antes de empezar.
¿Necesitan acceso a mis sistemas?
Sí, y el nivel de acceso se acuerda antes. En el diagnóstico el acceso es de solo lectura. Donde el dato es sensible, la arquitectura estándar mantiene el dato identificado dentro de tu ambiente.
¿Esto es alquiler de cuerpos con otro nombre?
No. Alquilar cuerpos es vender horas sin meta. Aquí hay alcance cerrado, plazo y alguien que responde por lo que está en producción.
¿Y si después quiero seguir por mi cuenta?
Puedes. Lo que sale a producción sale con documentación y manual de operación, y alguien de tu equipo aprende a operar, revisar y corregir mientras construimos.
¿Cuánto cuesta?
La cotización sale cerrada en el diagnóstico, por frente. No hay lista de precios porque no hay dos proyectos iguales.
Empieza con un diagnóstico.
Dos semanas, un documento, una cotización cerrada.
Agendar diagnóstico →