Full-Stack Engineer

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 procesos. Trabajamos en dos mitades. Una entra en una empresa, averigua qué pasa allí de verdad y construye un prototipo lo bastante rápido como para demostrar que merece la pena tenerlo. La otra —esta— coge ese prototipo y lo convierte en algo de lo que una empresa depende. Casi todos los equipos de automatización tienen solo la primera mitad, y por eso casi todos tienen un cajón lleno de demos y nada en producción.

Estamos contratando a los ingenieros de la segunda mitad.

Contratamos en dos niveles, y preferimos decirlo a dejar que lo adivines. Hay cuatro plazas junior y una plaza senior. Las junior están abiertas a gente que sale de la universidad y a ingenieros jóvenes en general: lo que buscamos ahí no es un historial, son ganas. Quieres ser muy bueno muy rápido, y ya has estado construyendo con agentes de código (Claude Code, Cursor, Codex o similares) porque te parecieron interesantes y no porque te lo dijera nadie. La plaza senior es para alguien que lleva años al cargo de software en producción y está listo para fijar la arquitectura dentro de la que construyen los demás. Preséntate al mismo anuncio en cualquiera de los dos casos: dinos cuál crees que eres y lo hablamos en la primera conversación.

En qué consiste el trabajo de verdad

Cada producto nuestro lo llevan dos personas: un Product Owner y tú. El PO sostiene la relación con el negocio, las necesidades y la hoja de ruta. Tú sostienes el desarrollo, la arquitectura, la calidad y la release. Eso es propiedad de verdad: tu nombre en algo que la gente usa, con autoridad para decidir cómo se construye.

Y no lo harás con una sola cosa para siempre. Nuestra cartera es deliberadamente variada: plataformas que usan a diario consultores de unos quince países, productos nativos en agentes que vamos inventando sobre la marcha, y las herramientas internas que hacen funcionar todo el método. Llegan proyectos nuevos de forma continua desde la otra mitad del equipo. Te moverás entre ellos, y esa variedad es una de las mejores cosas del trabajo: tienes profundidad en algo que es tuyo y la variedad de un equipo que empieza algo nuevo cada trimestre.

En un año normal vas a:

• Coger un producto y hacerlo tuyo. Llega documentado, endurecido y listo, de un compañero que ha pasado a lo siguiente. Y no te dejamos leyendo 40.000 líneas por tu cuenta: todos los repositorios incluyen los ficheros de contexto que leen nuestros agentes, tenemos búsqueda y navegación de código sobre todo el estado, y tienes Claude Code apuntando a ello. Orientarte en un sistema que no conoces es una habilidad en la que aquí llegarás a ser muy bueno, y te damos las herramientas que la convierten en un día en vez de un mes.
• Mantenerlo en movimiento. Un producto que deja de evolucionar deja de usarse. Tu PO y tú decidís qué viene después y lo entregáis.
• Diseñar más de lo que tecleas. Más sobre esto abajo: es la parte de este trabajo más distinta de tu anterior.
• Empezar algo nuevo. Llegan productos nuevos con regularidad, y quien se hace cargo es quien esté listo para el siguiente.

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

Esta es la parte que subrayaríamos. Somos un equipo de ingeniería nativo en IA de verdad, no un equipo que ha añadido una licencia de Copilot. Cada ingeniero tiene su propia suscripción a Claude Max y un orquestador de escritorio que ejecuta varios agentes de código en paralelo, cada uno en su rama. Aprenderás a manejar eso como es debido: cómo sacarle calidad y velocidad a la vez, dónde falla, y cómo sentarte con un diff y averiguar si de verdad está bien, que es una habilidad y de las que merece la pena tomarse tiempo.

Lo cual cambia cómo se siente el trabajo. Mucho menos de tu semana se va en teclear implementación. Mucho más se va en lo que de verdad decide si el software es bueno: qué debería construirse, qué forma debería tener, dónde están los bordes difíciles, y luego bajar al detalle exactamente donde el detalle importa. Es un trabajo más arquitectónico y más estratégico de lo que era el mismo título hace tres años, y esa es la dirección hacia la que se mueve toda la profesión. Estarás por delante, no corriendo detrás.

Algunos detalles, para que sepas cómo mantenemos el nivel:

• Cada cambio lo revisa un agente antes de que lo firme una persona. Eso da retroalimentación rápida, y nunca te quedas bloqueado esperando a que un compañero saque tiempo.
• Cada desarrollo lleva pruebas, y el listón es el 100 % superado. Unitarias, de humo contra la cosa real en marcha, y de extremo a extremo a nivel de navegador. En esto somos estrictos: es lo que permite a un equipo pequeño entregar rápido sin romper cosas.
• Todo lo que lleva IA se entrega con evaluaciones: un conjunto de entradas puntuado, no un «parecía correcto cuando lo probé». La elección de modelo se gestiona de forma centralizada, así que nadie se queda tirado en un modelo descatalogado.
• Lo que valoramos es el criterio. Los agentes abaratan escribir código, lo que encarece juzgarlo. Aquí la seniority se mide en la calidad de tus decisiones, no en tu volumen de producción.

Si llevas tiempo usando agentes en serio y tienes opiniones sobre dónde se rompen, queremos oírlas. Si tienes curiosidad pero aún no estás metido a fondo, también vale: enseñar esto bien es algo por lo que pretendemos ser conocidos.

«Si el código lo escriben los agentes, ¿para qué estoy yo?»

Es la pregunta justa ante un anuncio como este, así que aquí va nuestra respuesta claramente: los agentes son la parte más rápida del equipo y la menos fiable, y no es un problema que esperemos que desaparezca. Todo lo que hace que el software sea bueno de verdad sigue pasando por una persona.

Lo que sigue siendo tuyo, de forma permanente:

• Convertir una necesidad en una especificación que sea de verdad la correcta. Tu PO trae lo que el negocio necesita; cómo se construye es tuyo. Un agente construirá exactamente lo que especifiques, y muy bien, incluso cuando lo que especificaste tenía la forma equivocada. El trabajo está en llegar de «necesitan esto» a una especificación lo bastante precisa como para que salga lo correcto por el otro lado. Esa es la hora más difícil de tu semana y la única que no automatiza nada.
• La arquitectura. Los agentes son excelentes dentro de un sistema bien formado y silenciosamente destructivos dentro de uno informe. Alguien tiene que decidir la forma, sostener la línea a lo largo de un código durante años, y saber cuál de los atajos de hoy es la reescritura del año que viene.
• Juzgar lo que sale. El código de un agente es igual de seguro tanto si es correcto como si no. Compila, pasa la prueba que se escribió a sí mismo, y está sutilmente mal de formas que solo pilla quien entiende el dominio. Esto es lo más valioso que haces aquí, y se vuelve más valioso a medida que los agentes se vuelven más rápidos, no menos.
• La responsabilidad. Cuando algo se rompe en producción, a un agente no lo llaman, no se disculpa con un usuario y no decide si se hace rollback. De eso responde una persona. Aquí esa persona eres tú, y la propiedad no es algo que pensemos poner en manos de un modelo.
• Todo lo humano. Discrepar bien con tu PO y que te escuchen, decirle que una funcionalidad es mala idea antes de construirla, formar a quien entre después de ti, y saber cuándo la respuesta honesta es «esto hay que reescribirlo».

Nuestra postura honesta: somos nativos en IA porque hace a un equipo pequeño capaz de mucho más de lo que le corresponde por tamaño, no porque pensemos que los ingenieros son la parte prescindible. Contratamos a menos ingenieros y mejores, y le damos a cada uno más apalancamiento, que es lo contrario de contratar a menos porque los necesitemos menos. Teclearás menos y harás bastante más del trabajo por el que probablemente te metiste en ingeniería.

Cómo construimos, y cómo cambia el estándar

Tenemos un stack asentado, y es el mismo en casi todos los repositorios, a propósito. Todos los proyectos parten del mismo andamiaje, y el código compartido vive en paquetes compartidos que todo el mundo publica y todo el mundo usa. La recompensa es real: un equipo de dos personas puede coger un producto que no ha visto nunca y ser útil el mismo día, que es la única razón por la que un equipo de este tamaño puede llevar tantos productos, y es lo que hace que moverse entre proyectos sea indoloro en vez de un mes de arranque.

Es un valor por defecto, no una camisa de fuerza. Algunos proyectos necesitan genuinamente otra cosa: una carga que es propiamente de Python, un runtime que tiene que estar en el borde, una restricción de cliente que no habíamos previsto. Cuando es así, nos adaptamos, a propósito y con el razonamiento escrito. Lo que no hacemos es volver a decidir las mismas cinco preguntas en cada repositorio nuevo por costumbre.

Y tienes voz en cuál es el estándar. Cualquiera puede proponer un cambio: algo nuevo que sea genuinamente mejor, algo a lo que deberíamos actualizarnos, algo en lo que nos equivocamos. Una propuesta se investiga como es debido frente a las alternativas, recibe una respuesta, y si la respuesta es no te llevas el razonamiento. Varias de las decisiones de arriba serán distintas dentro de dos años, y quienes las cambien serán los ingenieros del equipo.

Cosas que conviene saber de entrada

• De las incidencias de tu producto respondes tú, en horario laboral. La otra cara de la misma moneda: el soporte no se despacha a un equipo aparte; es parte de ser dueño de la cosa, y es lo que te mantiene honesto sobre la calidad.

Qué buscamos

Lee esto como una descripción del ingeniero 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 a alguien con el instinto y formar lo demás; 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.

• Has sido dueño de algo y puedes llamarlo tuyo. Da genuinamente igual si fue en una empresa, en la universidad o en un proyecto que empezaste solo en la mesa de la cocina: lo que importa es que tomaste las decisiones, conviviste con ellas y sabes explicarnos las que te salieron mal.
• Te mueves con soltura por el front y el back de una aplicación web. No separamos esos roles. TypeScript sólido si lo tienes; si tu lenguaje ha sido otro y eres bueno, dilo.
• Pruebas como es debido: pruebas unitarias y de extremo a extremo o de humo contra la cosa real en marcha. La mayoría las escribirá un agente; asegurarte de que la cobertura está de verdad ahí es tu trabajo, y sabes mirar una batería que has heredado y decir por qué es mala.
• Usas agentes de código en tu trabajo y lees lo que producen como leerías lo de un compañero.
• Sabes coger un código que no escribiste y explicar qué hace antes de cambiarlo.
• 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. Este es un equipo que se sienta junto, sobre todo en su primer año.

Para las cuatro plazas junior en concreto, lee la lista de arriba como la dirección del viaje y no como el precio de entrada. Lo que necesitamos de verdad el primer día es más estrecho y lo decimos claro: sabes construir una aplicación web que funcione de principio a fin, has usado un agente de código lo bastante en serio como para tener opiniones sobre dónde se equivoca, y quieres llegar a ser bueno en esto más rápido de lo que te dejaría un trabajo normal. Una carrera, un bootcamp, una ruta autodidacta y una pila de proyectos propios valen todos. No se esperan años de producción a tus espaldas: para eso están la plaza senior y el certificado.

Nos da igual qué estudiaste. Nos importa qué has construido 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 una decisión técnica en la que te equivocaste.