The Craft That Comes Next: What Engineers Become When the Factory Takes Over

There is a question we hear more and more often at the end of a demo, asked quietly, sometimes by the most experienced developer in the room: "If the factory builds, fixes and remediates, what is left for me to do?"

It is a fair question. For two years now, every new generation of models has written a little better the code we thought was reserved for seniors. Dependency fixes ship on their own. Tests generate themselves. Migrations get proposed. And many engineers watch this shift with an unease that no enthusiastic talk about "AI that augments humans" has truly dispelled.

We want to answer it honestly, without brushing it aside with a slogan. The work does not disappear. It changes scale, and it changes place. And what takes its place is not a spectator role watching machines run: it is a profession in its own right, more demanding than the previous one, which we are structuring today with schools and customer companies.

The real shift: from writing the change to judging what is acceptable

Look honestly at a week in the life of a senior developer. Most of the time goes into writing the change: understanding the ticket, finding the right file, following the convention, writing the test, fixing the regression introduced by the previous fix, re-running CI. It is mechanics, often very good mechanics. But that is not where their rarest value lies.

Their rarest value is what they do in thirty seconds at the end of a code review, when they reject a pull request that "passes every test" because they know it will break billing at month end. It is their instinct about the migration that will not survive production volume. It is their ability to say no, and to explain why.

In a governed delivery factory, that balance flips. The mechanics are handled, under control: the factory writes the change, proves it through TDD, runs the checkpoints, and assembles an evidence pack documenting what was done, verified and decided. Human time then concentrates on what cannot be automated without risk:

It starts with defining the rules of the company, policies, checkpoints, standards, and making them executable rather than decorative. It means setting objectives for a scope instead of writing every fix one by one. It means arbitrating escalations, those moments when the factory stops by itself because a decision goes beyond what it has been authorized to settle. It means approving deliveries by reviewing their evidence pack. And above all, it means codifying deviations: every manual correction becomes a permanent rule of the factory, so that the same mistake never comes back.

That last point changes everything. In a traditional model, a senior's expertise evaporates with every departure, every end of engagement, every change of vendor. In a governed factory, it compounds. Every arbitration enriches the reference framework, every codified rule protects every scope that follows. This is what we call the Capital Token: your organization's intelligence, made durable because it is no longer locked in a single head nor rented from a single model provider.

In other words, the core skill of the craft that comes next is one you already have. It is judgment about what is acceptable in production. It simply moves from the end of the chain to the center of the work.

Why that judgment becomes the company's most valuable resource

One might think a more autonomous factory reduces the need for human judgment. It is exactly the opposite. The higher the throughput of changes, the higher the cost of an undetected bad decision, and the more pressing the question of accountability becomes.

Regulators understood this before many engineering teams did. DORA requires financial entities to demonstrate control over their changes and their digital risks. NIS2 extends comparable requirements to many essential sectors. The AI Act mandates effective human oversight of the AI systems that require it. None of these texts is satisfied with "the agent did it". They ask for a name, a traced decision, enforceable evidence.

This is where the profession takes on its full meaning. The engineer is no longer the person who types the code; they are the person who answers for the code. They are the sovereign guarantor of what the factory delivers in their name. And that responsibility cannot be delegated to a model, however powerful.

The career track: three levels and an entry door

A governed factory is not run with a single profile. It requires an organization, and that organization builds on roles your teams already hold. Nobody has to learn a profession from scratch: everyone reinvests what they do best, at a different scale.

The senior developer becomes a Software Factory Engineer

The Software Factory Engineer (SFE) operates a scope. They no longer code every fix; they set the objectives, approve deliveries, arbitrate escalations and answer for the evidence pack of what goes to production. What they reuse is precisely what made them senior: their review capability and their judgment about what is acceptable. Where they used to review a handful of pull requests a day, they now guarantee the quality of an entire flow, with evidence in hand rather than intuition.

The tech lead becomes a team architect

The team architect (SFA) owns the reference framework. The team standards they used to defend through repeated reviews and wiki pages nobody re-read become policies as code, checkpoints executed on every change, rules the factory applies without fatigue and without exception. Their influence stops being proportional to the number of reviews they can fit into a day. This is the role that shapes the factory's governance and extensibility: what it is allowed to do, how, and under which conditions.

The maintenance manager becomes a team lead

The team lead (SFL) steers throughput, service commitments (SLOs, SLAs) and above all the autonomy levels: which scope the factory can handle on its own, which one still requires systematic human approval, and on which written criteria a scope moves from one to the other. It is the natural continuation of the service-commitment and capacity management that application maintenance managers and team leads already know. The difference is that they now steer a measurable, traceable capacity rather than headcount on site.

Testers, QA and L3 support enter as junior SFEs

This is the entry door to the track, and it is no consolation prize. Testing, QA and level-3 support profiles often have the most reliable instinct for what breaks in production. They have lived through on-call rotations, 2 a.m. incidents, regressions nobody saw coming. In a governed factory, that instinct is valuable from day one: in supervision, in co-validation, then progressively with full responsibility for a scope.

This is not a hiring plan. It is an evolution. The people who will run your factory tomorrow are already on your teams.

A personal certification that belongs to the engineer

A profession without recognition remains a job description. That is why we deliberately separate two things.

The professional certification covers the Software Factory Engineer role, independently of any tool. It is built with schools and customer companies, and designed to be recognized beyond Argy. The product certification, on the other hand, attests to mastery of Argy itself.

The decisive point lies elsewhere: the certification is personal and nominative. Whether you are an employee of the company or working for a partner, it stays yours. It depends neither on a contract, nor on a scope, nor on an employer. It is a skill in a profession, not a badge on a tool. For an engineer worried about seeing their value erode, it is the most concrete answer we can give: what they learn belongs to them.

The competency framework is being written now, and the feedback from those who operate the factory every day weighs more than anything else. We detail it on the Craft page.

What the transition really requires

We would rather be clear about the conditions for success, because the failures we observe almost always share the same origin.

The first condition is dedicated time. Supervising a factory on top of a full development workload does not work. It is the first failure factor we observe: the engineer approves in a hurry, between two tickets, and supervision becomes a formality. The role needs identified time, owned by management, written into the schedule.

The second is progressiveness. You do not switch a scope to autonomy on a Monday morning. The factory proposes and the human approves everything; then autonomy opens scope by scope, on written criteria, and remains reversible. An autonomy level is earned with evidence, and can be withdrawn if the evidence weakens.

The third is co-validation at the start. The first weeks are done in pairs: the new SFE gives their opinion before seeing the experienced engineer's, then the two compare. It is by far the most effective learning mechanism of the journey, because it trains judgment rather than mere knowledge of the tool.

What this changes for a CTO or CIO

For an engineering leadership team, the stakes go beyond career management. The question is who, tomorrow, will be able to sign off on what the factory delivers. An organization that industrializes its software production without training the people who will answer for it builds a throughput it will not be able to defend before an auditor, a regulator or a risk committee.

Conversely, an organization that structures this track keeps what matters most: control over its decisions, the memory of its arbitrations, and engineers who know why they stay. It turns a source of anxiety into a readable career path, and a dependency on external services into internal capability.

In short

A governed delivery factory does not reduce the need for engineers. It moves their added value, from writing the change to deciding what is acceptable, and it makes that decision traceable, enforceable and cumulative. The developer who feared becoming useless discovers they are becoming the guarantor of what the company values most.

The craft that comes next is not smaller than today's. It is bigger.

If you want to prepare your teams rather than endure the transition, start by exploring the track, the roles and the certification path, see how the factory produces its evidence, then let's talk about your trajectory.