The Factory That Builds The Software: Why setting up production lines is the new job for software engineers.

The most popular summary of what AI is doing to software engineering is that "engineers can now write code faster". That's technically a true statement. It's also a huge underselling of what's actually happening at the forefront of AI use in software engineering, and wider company building.

A more accurate summary is that AI is enabling a software production line. The best software engineers are no longer limited to just building software. They're designing, setting up, and maintaining the factory that builds it.

Whilst the people doing the job are software engineers by trade, the job function is new, and it will eventually have a new title to clearly define its separation from the role of a traditional software engineer.

Throughout this blog, I will call this new role the "Agentic Engineering Architect". I'd be amazed if it sticks, but I need to call it something other than "Software Engineer" to avoid confusion.

A small group of software engineers (currently less than 1%) are already making the jump to this new role, and a good deal more will follow - but most (perhaps 90% of all software engineers) never will, and will see their careers go the way of the switchboard operator.

The industrial engineer parallel

The easiest way to understand the shift is to look at how physical factories work.

When Ford built the modern car factory, two distinct levels of work emerged. Industrial engineers designed the production line, which effectively meant they owned decisions around how the factory was laid out, what each station did, how the line would adapt when next year's model required some changes, and so on.

Factory workers then operated that production line. The role of a factory worker wasn't irrelevant, but it mostly consisted of repetitive, lower-skilled work that could be trained quickly and did not require deep expertise developed over years or decades. Machinery had removed the need for high levels of human skill within the factory itself.

There's no doubt that, of the two, the industrial engineer was the more important role. They were better paid, more skilled, and much harder to replace. The factory workers were still essential to keep the factory moving, but the value for the company ultimately came from those who brought the factory to life in the first place.

At the forefront of AI in software building, the very same thing is happening. We now see examples of Agentic Engineering Architects who design, set up, and maintain the factory - establishing the AI nucleus, guardrails, harnesses, review processes, and so on - and we see software engineers (or software engineering agents) working within these factories.

But there's one key difference. Physical factories require human workers, because the work happens in a physical, 3D space. Software factories do not, meaning agents can execute all the work happening within. In a physical factory, when a machine jams, someone has to stick their hand in and physically clear the jam. In a software factory, 'clearing the jam' likely means running or tweaking some code to get it moving again, something a purpose-built maintenance agent can do just fine with little to no human intervention required.

Of course, the factory needs to be built with these agentic workers in mind, with guidance and rulesets around what they should do, when they should do it, and why. But this is exactly why the architect role, the industrial engineer of the software world, is becoming one of the most valuable roles in the company. And why the line worker role is being filled almost entirely by agents, not humans.

What the architect actually does

The role is heavily technical. It is not just "judgement and taste, with the agents doing all the work" - that would be a huge oversimplification. In practice, the architect does three things at once.

First, they design the factory. They make the architectural decisions about how work flows through the system, and what the overall process should look like. Some of this will have a best practice answer, but much of it will be specific to the company's needs.

Do you use an off-the-shelf orchestrator or build your own? Should multiple product lines have multiple factories, and if so, where does one factory end and another begin? How do orchestrator agents direct sub-agents without losing context between them? What level of human observability is required? What needs approval, what doesn't, and why?

These are all very real, quite technical, and highly consequential decisions that Agentic Engineering Architects are making today, and they must be made well.

Second, they maintain and upgrade the factory. Like a car production line, things change. A new model needs a new station, a part gets phased out, or an old process is no longer necessary. The difference is that physical factories rarely get re-tooled, because building custom machinery and moving things in 3D space is expensive.

Software factories don't face this problem, meaning they can be (and should be) re-tooled constantly to maintain optimal levels of output. The architect is the person spotting where the line is suboptimal and improving it on the fly, all without breaking things or slowing down the factory itself.

For a software company, how well the factory runs will have a direct impact on how well the company runs - if a 5% improvement can be found in the production line, missing it could be the difference between success and failure. You'll want the very best people on the job to ensure this doesn't happen.

Third, they teach the agents. Agents don't just turn up and work. They first need to be created, and then they need guardrails, harnesses, evaluation loops, skills, scripts, prompt design, and routing logic that decides which model handles which task. Fine margins can make or break a production line, and it's the architect's job to design and continually refine all of this.

Judgement isn't the whole story

There's a somewhat lazy reading of AI in engineering that goes something like "code is cheap now, judgement is what matters". Again, it is technically true depending on the context, but a huge oversimplification.

Judgement was, is, and will always be important (AI didn't suddenly create the need for it). But the architect's job isn't to be the judgement layer above an army of agents. Part of the architect's job is to actually remove the need for judgement and taste wherever possible.

The software factory enables very cheap, very fast experimentation. If you can build five internal versions of the same feature in an afternoon, test them in market, get real usage data, and let the data pick the winner, you really don't need to season to taste at all. Taste and judgement are relied upon when there's a lack of data, but with a software factory up and running, this should rarely be the case.

Of course, designing a factory that builds motorbikes when your customers all want cars is a judgement problem, but again, this was true before AI, and will be true long after this is all mainstream too.

Another example would be the cycle required to develop a new item of clothing. Because of the slow, multi-week turnaround time from designer to factory and back to designer, it's common to batch every change you can think of into each attempt in the hopes that you nail it and save time.

Now imagine a world where samples come back to you in five minutes for virtually no cost. You don't need to look at a picture, or a 3D render. You no longer need to use 'taste' or 'judgement' as a substitute for holding the real product in your hand. You'll iterate constantly until you have something genuinely great in front of you physically, removing almost all the guesswork.

That is exactly what these software factories do. They reduce the cost of being wrong, internally, to near zero, which changes how much human taste you actually need to lean on (it's less, not more). Taste still matters for very large decisions and questions like "what type of company should we be?" and "what problem should we solve?", but the day-to-day reliance on individual human judgement is actually far less than many currently believe.

The split is already here

The split between people making the jump to this new architect role and the people who aren't isn't a prediction. In companies furthest along the AI native curve, a small percentage of software engineers are showing the skills and level of initiative required to make the leap.

I have it on good authority that a scaleup in Sydney can attribute ~90% of all meaningful engineering impact over the past few months to 5 engineers, in an engineering team of ~50. The top engineers can take care of so much surface area on their own, with agents handling the execution, that there's no need to hand work to another human who may keep them waiting, so they don't. The remaining 45 engineers have "effectively nothing to do outside of basic maintenance and BAU work, but even that is becoming an agent's job now."

Over the coming years, the remaining engineers in most companies will either do work to look busy or build things that don't matter. The truth is that the job of a software engineer is being replaced by a machine, and the new job of Agentic Engineering Architect has such a significant, widespread impact that there simply isn't all that much room for many of them in any one company.

Team shapes are already changing with this, and will continue to. A Series-B scaleup in Sydney initially raised with the view to double headcount in a year, but they have since tripled revenue without growing headcount at all. We're seeing 4-person startup teams achieve far superior feats than 25-person Series-A teams of times gone by. Top people are leaving larger incumbents to effectively re-build AI-native competitors in a matter of weeks or months on a fraction of the budget and with much better underlying unit economics.

This really is not a prediction of the future. This is here today, and is very real - it's just distributed unevenly. Less innovative companies may hold out for 5 to 10 years, but they will feel it too eventually. When the meteor hit, most of the dinosaurs didn't die immediately - but there are certainly no T-Rexes running around today.

The risk of private kitchens

While a handful of engineers in a 50-person team can effectively be responsible for 90% of the impact, if each one is doing it in their own way, that's a problem. This would be similar to each chef having their own private kitchen in a restaurant.

But you don't want private kitchens. You want one commercial kitchen the company owns, designed by the architect at the top of the engineering org, with sub-leaders running specific production lines beneath them.

For this to be the case, the architect must sit near the very top of the business. Perhaps they hold a CTO or Technical Co-founder title, or a Founding Engineer title, but whatever you call them, the factory they build must be for the business, and not for themselves. When they leave, the factory needs to remain - this is currently the biggest risk for companies who are already employing these people today.

The impact of the role really is similar to that of C-suite level, not just because of the difficulty of the role, but because of what they decide and what their decisions create. A great C-suite executive makes a small number of crucial calls with outsized consequences, often with limited context, and they're expected to be right most of the time. The architect role is very similar.

The difference is that this role is still very hands-on and technical. It isn't limited to decision making - it spans implementation too. That's what makes this role an important hire as early as possible, whereas C-suite typically comes in as a company scales. Whatever your size or stage, if you are building software, you need this person in your company now.

Salary levels are beginning to reflect this huge level of impact. Founding and Principal engineer compensation in 2026 has hit numbers we have never seen, with some well-funded, ultra-early-stage startups paying double or triple what would be considered "normal". Given the impact the right person will have (10-100x depending on specific context), this is often a financially sound decision.

The factory that builds everything

Software is the first and most obvious floor of the factory, but it is not where the factory will end.

Engineering teams that have built a software factory are the most technically capable group in the business when it comes to automating anything else. Sales research and follow-up, marketing operations, first-pass legal review, finance reconciliation, support triage and more would all benefit massively from an AI-native production line.

Tools like n8n and Zapier are enabling this to an extent, but automation capability for non-technical people is limited. The Agentic Engineering Architect will ultimately become an Agentic Company Architect, and their job will be to build the factory that builds everything.

Software was the first thing to become a production line, because the people who build the production line are engineers automating their own jobs. It absolutely won't be the last.