Full-Stack Engineer - Mainloop

Full-Stack Engineer Own products for years rather than weeks - build them properly, keep them alive, and make the agentic build method something a team can rely on. Mainloop is a new engineering team inside an established international group . We are in Barcelona, we are being built from scratch this year, and we have the backing, the customers and the product portfolio of a company that has been around for decades. You get the interesting part of a new team without the part where you check whether payroll clears. Two more things about where this comes from and where it goes. The group has been running a tech lab in Casablanca for more than eight years - Barcelona is its second, built to sit closer to the teams we build for, and AI-native from the first commit, because it starts from a blank page. And the plan does not stop at internal work: within about a year and a half we intend to externalise - external clients, our products sold on the market, products developed for it. The first eighteen months are deliberately spent building as much as possible for the group while the machine gets set up. You would arrive at the start of that curve, not after it. What we build is the software that automates professional-services work - across roughly fifteen countries, for businesses that are drowning in process. We work in two halves. One half goes into a business, works out what actually happens there, and builds a prototype fast enough to prove it is worth having. The other half - this half - takes that prototype and turns it into something a company depends on . Most automation teams only have the first half, which is why most of them have a drawer full of demos and nothing in production. We are hiring the engineers for the second half. We are hiring at two levels, and we would rather say so than let you guess . There are four junior seats and one senior seat . The junior seats are open to people coming out of university and to young engineers generally - what we are looking for there is not a track record, it is appetite : you want to get very good very fast, and you have already been building with coding agents (Claude Code, Cursor, Codex or similar) because you found them interesting rather than because someone told you to. The senior seat is for someone who has owned production software for years and is ready to set the architecture others build inside. Every product we own is run by two people: a Product Owner and you . The PO holds the relationship with the business, the needs and the roadmap. You hold the build, the architecture, the quality and the release. That is real ownership - your name on something people use, with the authority to decide how it is built. And you will not be doing it on one thing forever. Our portfolio is deliberately varied: platforms used daily by consultants across roughly fifteen countries, agent-native products we are inventing as we go, and the internal tooling that makes the whole method work. New projects arrive continuously from the other half of the team. You will move between them, and the range is one of the best things about the job - you get depth on something you own and the variety of a team that starts something new every quarter. In a typical year you will: Take over a product and make it yours. It arrives documented, hardened and ready - from a colleague who has moved on to the next thing. And you are not left to read 40,000 lines on your own: every repo ships the context files our agents read, we run code search and navigation across the whole estate, and you have Claude Code pointed at it. Getting oriented in an unfamiliar system is a skill you will get very good at here, and we give you the tools that make it a day rather than a month. Keep it moving. A product that stops evolving stops being used. You and your PO decide what is next and you ship it. Design more than you type. More on that below - it is the part of this job most different from your last one. Start something new. New products land regularly, and the person who owns them is whoever is ready for the next one. You will get seriously good at building with AI agents This is the part we would underline. We are an AI-native engineering team, genuinely - not a team that added a Copilot licence . Every engineer gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel, each in its own branch. You will learn to drive that properly: how to get quality and speed out of it at the same time, where it fails, and how to sit down with a diff and work out whether it is actually right - which is a skill, and one worth taking your time over. Which changes what the job feels like. Far less of your week is spent typing implementation. Far more is spent on the things that actually decide whether software is good: what should be built, how it should be shaped, where the hard edges are - and then dropping into the detail precisely where the detail matters. It is a more architectural, more strategic job than the same title was three years ago, and that is the direction the whole profession is moving. You will be ahead of it, not catching up. Some specifics, so you know how we keep the quality up: Every merge is reviewed by an agent, in a find-fix-re-review loop that runs until clean. It means fast feedback and no waiting on a colleague to get to your PR. Every build ships tests, and the gate is 100% pass. Unit, smoke against the real running thing, and Playwright end-to-end. This one we are strict about - it is what lets a small team ship quickly without breaking things. Anything AI-powered ships with evals - a scored set of inputs, not "it looked right when I tried it". Model choice goes through a gateway, so nobody is stranded on a deprecated model. Judgement is what we value. Agents make writing code cheap, which makes judging code the valuable thing. Seniority here is measured in the quality of your decisions, not your output volume. If you have been using agents seriously and have opinions about where they break, we want to hear them. If you are curious but not yet deep in it, that is fine too - teaching this well is something we intend to be known for. "If agents write the code, what am I for?" It is the fair question to ask of an ad like this one, so here is our answer plainly: the agents are the fastest part of the team and the least trustworthy one, and that is not a problem we expect to go away . Everything that makes software actually good still runs through a person. What stays yours, permanently: Turning a need into a specification that is actually right. Your PO brings what the business needs; how it gets built is yours. An agent will build exactly what you specify, beautifully, even when what you specified was the wrong shape - so the work is getting from "they need this" to a spec precise enough that the right thing comes out the other end. That is the hardest hour of your week and the one nothing automates. Architecture. Agents are excellent inside a well-shaped system and quietly destructive in an unshaped one. Someone has to decide the shape, hold the line across a codebase for years, and know which of today's shortcuts becomes next year's rewrite. Judging the output. Agent code is confident whether or not it is correct. It compiles, it passes the test it wrote for itself, and it is subtly wrong in ways only someone who understands the domain will catch. This is the single most valuable thing you do here, and it gets more valuable as the agents get faster, not less. Accountability. When something breaks in production, an agent does not get called, does not apologise to a user, and does not decide whether to roll back. A person owns that. Here, that person is you - and ownership is not something we intend to hand to a model. Everything human. Disagreeing with your PO well and being listened to, telling them a feature is a bad idea before it is built, mentoring whoever joins after you, and knowing when the honest answer is "this needs rewriting". Our honest position: we are AI-native because it makes a small team capable of far more than its size - not because we think engineers are the expendable part. We are hiring fewer, better engineers and giving each of them more leverage , which is the opposite of hiring fewer because we need them less. You will do less typing and considerably more of the work you probably went into engineering for. The Mainloop Barcelona certificate Something we are building alongside the team, and we think it is genuinely unusual. Over your first two to three years here you work through a defined body of knowledge - our architecture, the agentic build method, how to take a product from an idea to something a business depends on, and how to run it well. When you have covered it and can demonstrably run a project our way, you are awarded the Mainloop Barcelona certificate . It is yours. It goes on your CV, and we intend to make it mean something in this market - a signal that the person holding it knows how to build production software with AI agents to a standard, not just prompt their way to a demo. We are investing in making it prestigious , because a team whose alumni are sought after is a team good people want to join. How we build - and how the standard changes We have a settled stack, and it is the same in most repos, deliberately . Every project starts from the same scaffold, and shared code lives in shared packages everybody publishes to and everybody uses. The payoff is real: a two-person team can pick up a product they have never seen and be useful the same day, which is the only reason a team this size can own this many products - and it is what makes moving between projects painless rather than a month of ramp-up. It is a default, not a straitjacket. Some projects genuinely need something else - a workload that is properly Python ...