← Todas las vacantes

Parte 1 · PoC Services

Forward Deployed Engineer

Entra en una empresa que nunca se ha automatizado, averigua cómo funciona de verdad y ten algo funcionando delante de ellos en dos semanas. Después entrégalo como es debido y vete a hacerlo a otro sitio.

  • Barcelona · con viajes
  • Abierta
  • 1 plaza

De qué te haces cargo

  • 01 Entender el proceso, sobre el terreno
  • 02 Escribir la arquitectura funcional
  • 03 Dirigir el desarrollo agéntico hasta la PoC
  • 04 Llevar el bucle con los stakeholders
  • 05 Cuantificar el beneficio, y decir que no cuando es que no
  • 06 El paquete de entrega
Anillos mecanizados concéntricos, cada uno con una línea de luz ininterrumpida. Anillos mecanizados concéntricos, cada uno con una línea de luz ininterrumpida.
Un método, muchos productos

Mainloop AI es una empresa de ingeniería en Barcelona. Somos dueños de lo que construimos y respondemos ante nosotros mismos. Te llevas la parte interesante de una empresa nueva, con un cliente real y productos reales desde el primer día.

Lo que construimos es el software que automatiza el trabajo de los servicios profesionales, en unos quince países, para empresas que se ahogan en administración. Esa es la materia prima: la administración. Los formularios, las aprobaciones, las conciliaciones, los traspasos de once días, la hoja de cálculo que alguien rehace cada mes. Trabajamos en dos mitades. Una mitad —esta— entra en una empresa, averigua qué pasa allí de verdad y construye algo lo bastante rápido como para demostrar si merece la pena tenerlo. La otra coge lo que demostramos y lo convierte en algo de lo que la empresa depende.

Casi todos los equipos de automatización tienen solo la primera mitad, y por eso acaban con un cajón lleno de demos. Casi todo el resto tiene solo la segunda, y por eso construyen lo que a alguien se le ocurrió pedir. Estamos contratando a las personas de la primera mitad.

No buscamos solo a un desarrollador. Buscamos a alguien con instinto de consultor que sepa construir: alguien a quien le interese más por qué la factura tarda once días que qué framework usamos, y que después pueda ir y construir lo que lo arregla.

En qué consiste el trabajo de verdad

Llega un proyecto. Normalmente es una frase: «nuestra gente dedica dos días al mes a conciliar esto a mano». A partir de ahí es tuyo.

  • Vas allí. En persona, al país que toque, y te sientas con las personas que hacen el trabajo. No la descripción que hace el jefe del trabajo: el trabajo.
  • Entiendes el proceso a fondo. Cómo funciona de verdad, quién lo toca, dónde duele y lo que cuesta hoy. Casi siempre es trabajo administrativo: ahí es donde se va el tiempo en una empresa de servicios profesionales, y ahí es donde ganamos. Cuánto tarda lo fija el proceso, no un calendario. Algo sencillo son días. Algo genuinamente complejo son semanas antes de construir nada, y decirlo es parte del trabajo: preferimos con mucho oír «esto está más enredado de lo que parecía» en la semana uno que en la seis.
  • Compruebas qué tenemos ya, antes de construir nada. Este es un paso real, no una cortesía. Tenemos una cartera, y buena parte de hacer bien este trabajo es conocerla lo suficiente para que, cuando una empresa te describa su problema, ya sepas que tenemos casi todo. A veces la respuesta es esto lo tenemos, solo hay que configurarlo. Más a menudo es la mayor parte de esto existe por ahí, y coges ese código y recortas una PoC justo de la parte que necesitas. Y no lo harás solo de memoria: tienes inteligencia de código sobre todo el estado, conectada a un agente al que puedes pasarle una especificación y preguntarle ¿qué de lo nuestro hace ya esto?
  • Escribes la arquitectura funcional. Cómo funciona la cosa: el flujo, los actores, las reglas, los datos que se mueven y las decisiones que hay en medio. Primero lo funcional: este es un trabajo de procesos de negocio, no de diseño de sistemas. Tomarás decisiones técnicas y tienes que ser capaz de tomarlas, pero la arquitectura técnica profunda no es para lo que estás, y las partes que la necesitan van al Tech Lab. Este documento es a partir del cual construyen los agentes, lo que convierte escribirlo con precisión en la hora de más apalancamiento de tu semana.
  • Lo construyes. Desarrollo agéntico, dirigido por ti: de la idea a algo enseñable en una o dos semanas, una vez que entiendes el proceso.
  • Lo pones delante de la gente, una y otra vez. Una serie corta de prototipos cada vez más reales, cada uno enseñado a los stakeholders, cada uno mejor por lo que volvió del anterior. Ese bucle es tuyo, y las primeras pruebas también.
  • Dices si merece la pena. Llevas dimensionando el beneficio desde el primer día, así que cuando la respuesta es no, puedes decirlo con números.
  • Lo llevas hasta MVP, y consigues que la gente lo use de verdad. Formar a los usuarios y hacer el seguimiento posterior es tuyo, no un añadido de otro.
  • Escribes el paquete de entrega mientras construyes, entregas el conjunto a un Product Owner y a un ingeniero, y pasas al siguiente.

Y luego vuelves a hacerlo, en otro sitio, con algo completamente distinto.

La línea donde paras, y por qué te conviene

Llevas un proyecto hasta MVP. No hasta producción, y no durante años. Una vez demostrado y casi listo, nuestro Tech Lab toma el relevo: endurecimiento, escala, seguridad, el largo plazo. Tú sales, y sales del todo, no te quedas «disponible para dudas».

Esa línea es deliberada y es lo mejor de este trabajo. Nunca acumulas una cola. No eres la persona a la que siguen llamando catorce meses después por algo que construyó en una tarde, no mantienes seis prototipos medio tuyos mientras intentas empezar el séptimo, y no te conviertes poco a poco en el soporte de tu propio catálogo. Así es como este puesto quema a la gente en todos los sitios donde existe, y es el fallo concreto para el que montamos un segundo equipo.

De vez en cuando te quedarás un poco más, y será porque es más rápido. Si el seguimiento posterior al lanzamiento va bien y el Product Owner aún no está libre, puede que sigas al frente un tiempo en vez de dejar que la cosa pierda impulso: una decisión que tomamos a propósito, en abierto, y siempre con un ingeniero ya al otro lado. Lo que no hacemos es dejarte sosteniéndolo en silencio.

A cambio te llevas la parte que casi todos los ingenieros dicen querer y rara vez consiguen: un problema nuevo, una empresa nueva y una página en blanco cada pocas semanas, con alguien competente a quien entregar lo terminado.

Un «no» honesto es aquí un resultado real

Parte de lo que mires no merecerá la pena automatizarlo. Cuando sea así, paras, escribes por qué, y eso cuenta como resultado entregado: porque la siguiente persona no repite el trabajo, y la empresa se lleva una respuesta en lugar de un proyecto.

Esto solo funciona si alguien lleva cuantificando el beneficio desde la primera conversación, y ese alguien eres tú. Es también la razón por la que va en serio: tendrás la legitimidad para matar tu propio proyecto, que no es una frase que muchas empresas puedan escribir con honestidad.

Vas a llegar a ser muy bueno construyendo con agentes de IA

Esta es la parte que subrayaríamos. Somos un equipo nativo en IA de verdad, no un equipo que ha añadido una licencia de Copilot. Todo el mundo tiene su propia suscripción a Claude Max y un orquestador de escritorio que ejecuta varios agentes de código en paralelo. Aprenderás a manejar eso como es debido: cómo sacar velocidad y calidad a la vez, dónde falla, y cómo mirar lo que salió y saber si de verdad está bien.

Lo cual cambia cómo se siente el trabajo. Muy poco de tu semana es teclear implementación. La mayor parte son las cosas que deciden si el software es bueno —qué debería existir, qué forma debería tener, qué va a adoptar de verdad el negocio— y luego bajar al detalle exactamente donde el detalle importa. No hace falta que sepas escribir a mano código de producción; hace falta que sepas especificar con precisión, dirigir bien y juzgar lo que vuelve. Te formaremos en nuestra arquitectura, nuestros patrones y nuestro proceso. Esa parte corre de nuestra cuenta.

«Si lo construyen los agentes, ¿para qué estoy yo?»

Es una pregunta justa ante un anuncio como este, así que aquí va la respuesta honesta: los agentes son la parte más rápida del equipo y la menos fiable, y no esperamos que eso cambie. Todo lo que decide si el proyecto merecía la pena pasa por una persona.

Lo que sigue siendo tuyo, de forma permanente:

  • Averiguar qué pasa en realidad. Nadie lo ha escrito. Quien hace el trabajo te describirá la versión del procedimiento, no la que tiene los tres apaños dentro, y los apaños son el proyecto. Ver esa diferencia exige a una persona en una sala.
  • Decidir qué no construir. La mitad de hacer esto bien es reutilización, alcance y negativa. Un agente construirá encantado lo que nadie necesitaba.
  • Dimensionar el beneficio, y estar dispuesto a decir que no. Números, y el temple de ponerlos delante de quien pidió el proyecto.
  • Convertirlo en una especificación lo bastante precisa como para construirse. Un agente construirá exactamente lo que especificaste, y muy bien, incluso cuando lo que especificaste tenía la forma equivocada. Llegar de «necesitan esto» a una especificación que produce lo correcto es la hora más difícil de tu semana y la única que no automatiza nada.
  • Todo lo humano. Que confíen en ti personas que no pidieron que aparecieras. Decirle a un stakeholder que su idea favorita no merece la pena. Entregar tan bien que quienes lo heredan no vuelvan a necesitarte.

Nuestra postura, dicha claramente: somos nativos en IA porque permite a un equipo pequeño hacer muchísimo más de lo que le corresponde por tamaño, no porque pensemos que las personas son la parte prescindible. Contratamos a menos gente y mejor, y le damos a cada una mucho más apalancamiento: lo contrario de contratar a menos porque los necesitamos menos.

Cómo construimos

Todos los proyectos parten del mismo andamiaje, y es el mismo en casi todos nuestros repositorios, a propósito. Para ti ese es justo el punto: empiezas algo nuevo cada pocas semanas, y ninguna de esas semanas debería irse en volver a decidir las mismas cinco preguntas. También significa que el equipo al que entregas puede coger tu proyecto sin capa de traducción, y que el código que encontraste en uno de nuestros productos se puede recortar para hacer un prototipo de otro.

No hace falta que llegues sabiendo nuestras herramientas. Sí hace falta que te muevas con soltura por el front y el back de una aplicación web como para dirigir un desarrollo y darte cuenta de cuándo algo va mal. El resto —nuestra arquitectura, nuestros patrones, nuestro proceso— es en lo que te formamos, y es buena parte de para qué sirve el certificado.

Cosas que conviene saber de entrada

  • Vas a viajar mucho, y lo decimos claramente. Barcelona es tu base y donde está el equipo, pero las empresas están repartidas por unos quince países y vas tú a ellas. A veces son unos días. A veces son unas semanas en un sitio, porque un proceso que no puedes ver es un proceso que vas a entender mal. Estar en la sala es el método aquí; no es un extra ocasional sobre un trabajo de oficina, y si esa no es la vida que quieres, este no es el puesto y los dos preferimos saberlo ahora.
  • Los viajes y el alojamiento corren de nuestra cuenta, y nos importa la diferencia entre una cama y un sitio donde se pueda vivir de verdad cuando la estancia es larga. Pregúntanos: preferimos hablar de cómo llevamos un despliegue de tres semanas a que lo descubras sobre la marcha.
  • No eres un consultor vendiendo días. Nadie cuenta tus horas. Lo que se mira es si la cosa funcionó, si se usó y si la entrega aguantó.

Si te mudarías a Barcelona por esto

No esperamos que asumas el coste de mudarte, y preferimos decir qué cubrimos a dejar que lo preguntes.

  • Pagamos por traerte. Vuelos, el alojamiento del primer mes mientras encuentras algo propio, los costes de visado y papeleo, y un gestor que se ocupe de la burocracia —el NIE, la cita del TIE, las apostillas— en lugar de dejarte solo ante la administración española. Clases de español si las quieres.
  • Un bonus de reubicación, pagado a la llegada y no a plazos. Solo es reembolsable si te vas en los primeros dieciocho meses, y esa condición es justo lo que nos permite pagarlo por adelantado: mudarse de país cuesta dinero al principio, no en el segundo año.

Tres cosas de aquí valen más de lo que parecen al comparar ofertas, sobre todo frente a una estadounidense:

  • Sanidad sin prima, sin franquicia y sin cuadro médico, desde el primer día y sin quedar atada a seguir en este trabajo.
  • Treinta días naturales de vacaciones —es decir, 22 laborables— más catorce festivos, unas siete semanas en total. Es el mínimo legal en España, no un beneficio con el que estemos siendo generosos.
  • Nadie está de guardia. Nunca. Sin turnos, sin busca, sin número de teléfono. Las alertas se publican en un canal y esperan.

Y los viajes se leen distinto según dónde estés. Todo lo de arriba es cierto y no lo estamos suavizando: es mucho tiempo fuera de casa. Pero si parte de por qué sigues leyendo es que preferirías trabajar por Europa a leer sobre ella: este trabajo te lleva a quince países, lo paga todo, y te da un sitio al que volver.

Qué buscamos

Hay un listón por encima de todo lo demás de esta lista, así que aquí va claro. No exigimos que seas el programador experto: para el código tienes agentes de IA. Sí exigimos que sepas arquitecturar el proyecto: entender la necesidad, estar genuinamente al día de lo que puede hacer la tecnología, conocer la infraestructura sobre la que construyes, y luego implementarlo y llevarlo de cero a MVP, donde se lo entregas a un Product Owner y a un ingeniero. Si has leído eso y has pensado ese es el trabajo que quiero, sigue leyendo.

Lee el resto como una descripción de la persona que serás aquí, no como una lista con la que tengas que llegar. Casi nadie lo marca todo el primer día, y preferimos contratar el instinto y formar lo demás, que es buena parte de para qué sirve el certificado. Si varias de estas son ciertas en ti y las otras suenan a cosas en las que quieres ser bueno, preséntate.

  • Te interesa cómo funcionan las empresas de verdad. Los procesos, el desorden que hay dentro y por qué la gente hace la cosa rara que hace. Esta no se puede enseñar y todo lo demás de aquí sí.
  • Sabes construir. Te mueves con soltura por el front y el back de una aplicación web. Qué lenguaje has estado usando nos importa mucho menos que si sabes llegar de una idea a algo que funciona por tu cuenta.
  • Antes de escribir nada, miras qué existe ya. Los ingenieros que no queremos son aquellos para los que cada problema es un repositorio nuevo. El nuestro es un trabajo de cartera: saber qué tenemos, y alegrarte en vez de decepcionarte cuando la respuesta es ya hemos construido casi todo esto.
  • Usas agentes de código en serio, y lees lo que producen como leerías el trabajo de un compañero.
  • Sabes entrar en una sala llena de gente que no pidió que estuvieras allí y salir con la verdad. Hacer la pregunta que consigue la respuesta real es casi toda la primera etapa.
  • Escribes bien. La arquitectura, el informe cuando la respuesta es no y el paquete de entrega son documentos, y los tres los leen personas que no estaban en la sala.
  • Sabes soltar. Cuando se entrega, deja de ser tuyo. A gente muy buena esto le cuesta de verdad, y conviene saberlo de uno mismo antes de presentarse.
  • Inglés, con fluidez. Es nuestro idioma de trabajo: trabajamos en unos quince países. El español es genuinamente útil en el día a día. El catalán no es un requisito.
  • Barcelona, con viajes.

Nos da igual qué estudiaste. Nos importa qué has construido, qué entendiste del negocio para el que lo construiste, y si sabes explicarnos las decisiones que hay dentro.

Cómo contratamos: las dos rondas hechas para esta plaza

  1. Una conversación de treinta minutos. Qué has construido, cómo trabajas y cómo lo piensas. Te pediremos que nos lleves por algo que hayas construido y que después justifiques una decisión concreta de dentro. No hay forma de preparar eso y no busca pillarte: es como distinguimos entender de estar familiarizado.
  2. Un proyecto. Te damos un encargo y un entorno de trabajo donde construirlo, con Claude Code ya montado y conectado a una clave, para que construyas como construimos de verdad en lugar de hablar de ello en una pizarra. Es trabajo real y no un acertijo, lo haces a tu ritmo —sin cogerte una semana, sin vuelos, sin nada que exija que ya estés libre— y después repasamos juntos lo que construiste.

Mainloop · Barcelona. Preséntate con algo que hayas construido y un párrafo sobre un proceso de negocio que tuviste que entender antes de poder arreglarlo.

El camino

Todos los proyectos siguen la misma ruta: se demuestran rápido, se endurecen en el mismo paso y luego los mantienen las personas que los construyeron.

Cierto para todas las plazas

  • Nadie está de guardia. Nunca. Sin turnos, sin busca, sin número de teléfono. Las alertas se publican en un canal y esperan. Contra las tres de la mañana nos protegemos con ingeniería —infraestructura como código, restauraciones probadas, rollback en un clic—, no con las tardes de la gente.
  • Estamos formando el equipo este año, y darás forma a cómo funciona. Algunos de nuestros procesos están escritos y otros no, y los que se escriban después de que llegues llevarán tus huellas.

El certificado Mainloop Barcelona

Durante tus dos o tres primeros años aquí recorres un cuerpo de conocimiento definido: nuestra arquitectura, el método de desarrollo agéntico, cómo leer un proceso de negocio y cómo llevar algo de una conversación a un producto en marcha del que una empresa depende. Cuando puedas demostrar que sabes llevar un proyecto a nuestra manera, se te concede el certificado.

Es tuyo. Va en tu CV, y pretendemos que signifique algo en este mercado: una señal de que quien lo tiene puede entrar en una empresa y construir software de nivel producción con agentes de IA, no solo llegar a una demo a base de prompts. El trabajo de entrada que está desapareciendo ahora mismo en todas partes es el trabajo que hacen estos agentes. Este es el trabajo que hay al otro lado.

Cómo contratamos

Cuatro rondas, y ninguna es un acertijo. Dos son iguales para todo el mundo y están aquí; las otras dos están hechas a medida de la plaza y están más arriba en esta página.

  1. Quince minutos con el Head of Engineering. Quién eres, qué buscas y qué es esto en realidad: lo suficiente para que ambos veamos si la siguiente merece una hora.
  2. Una conversación con ingenieros senior en los que confiamos. Gente que ha llevado producción a escala real, con sus propias preguntas, y tú con las tuyas, incluidas las que preferirías no hacerle a quien te está contratando.

Cómo presentarse

El botón «Presentarme» lleva a la oferta de esta plaza. Trae lo que este anuncio pide al final: lo leemos, y es buena parte de la primera conversación.