This new role is called Software Factory Engineer, but it may just be your job with a new name

Itamar Friedman, CEO of Qodo AI, recently published an article giving software engineers a new title: Software Factory Engineer. It's not a joke—he wrote a complete job description, covering everything from factory architecture, context engineering, and independent verification to autonomy boundaries and factory economics.

The backdrop is this: software development is moving from AI-assisted programming toward L4 autonomous software factories. L4 means the system can independently execute, verify, and deliver defined software changes, and escalate high-risk or beyond-authorization matters to humans. This role is responsible for designing, building, operating, and continuously improving that "system that produces software." Note: it is not about writing code; it is about building the machine that produces code.

There is a direct statement in the article: your primary engineering artifact is the factory itself. It needs to be designed, tested, observed, maintained, and continuously improved, just like any production system.

In the replies, some people pushed this idea further. One commenter said the factory needs its own failure log—for example, recording changes where "an agent marked it complete but a human later reopened it." This reopen rate, counted by change category, can tell you which work is actually suitable for L4. Itamar responded that yes, each agent or group of agents should be treated as a microservice, some with a small blast radius and some with a very large one.

Context engineering is another major part. The factory needs organizational knowledge, but not just indexed code. Architecture, cross-repository dependencies, ownership, business requirements, historical decisions, production behavior, and the original intent behind changes must all be accessible. The hard part is distinguishing verified knowledge from assumptions, outdated documentation, and unverified agent conclusions. Mechanisms are needed to discover knowledge gaps, find authoritative sources, have owners validate them, and then turn knowledge into reusable engineering infrastructure: versioned knowledge records, executable rules, investigation skills, architectural constraints, test cases, and evaluations. Domain experts retain authority over business definitions and operational constraints; factory engineers are responsible for making that validated knowledge available and executable where it affects software production.

On verification, the article has a key line: the author cannot self-approve. The verification system must be able to challenge assumptions, using authoritative context and observable behavior. The author agent cannot redefine the criteria by which its own output is accepted. Verification is not just about looking at the code diff; it also needs to reconstruct the intent of the change, assess the potential blast radius, determine the business criticality of affected systems, identify unverified assumptions, and gather evidence to support release decisions. Blast radius, criticality, and change risk are related but distinct concepts. Verification must produce inspectable evidence, not merely an agent's claim of confidence.

Human decision rights are not default exception handling. Not all changes need the same level of oversight. Documentation updates, isolated bug fixes, database migrations, and authentication changes have different consequences. The factory must be able to judge when there is enough evidence and authority to proceed, when additional verification is needed, and when to escalate to a human. It must also know when to stop safely. Humans should not become the default exception handler for every agent workflow. But increasing autonomy cannot come at the expense of accountability, nor can it transfer business authority to agents. Engineering leaders, security leads, domain experts, and service owners retain their respective decision rights. Software factory engineers are responsible for translating those rights into factory behavior.

On production feedback, the factory's responsibility should not end when code is merged. It should observe deployment results, detect regressions, investigate incidents, understand failures, and decide when to roll back, fix, or escalate. When the factory repeatedly makes the same mistake, the answer is not simply to fix the latest output, but to understand why the production system keeps producing that class of error. Is context missing? Are requirements ambiguous? Is the agent relying on outdated guidance? Is the verification system insufficient? Does the orchestration process allow invalid transitions? Is the problem outside the approved autonomy domain? Different failures require different improvements. Feedback loops should be established that connect observed failures to changes in factory components, and then evaluate whether those changes actually improve future outcomes.

Factory performance and economics also have their own metrics. Traditional engineering metrics are not enough. You need to measure the cost per accepted change, the time from intent to verified production outcome, escaped defects, verification quality, human intervention, recovery time, and work completed autonomously within approved boundaries. You also need to measure human verification effort and cognitive load, not just intervention frequency: fewer interventions may hide longer, harder investigations. Increased code output or agent activity is not necessarily progress. A faster factory that produces more incidents, consumes more human attention, or creates poorly understood software may be less productive than the system it replaced. Conversely, a highly governed factory that requires human intervention for every consequential decision may be very compliant but fail to achieve economic benefits.

There are different voices in the comments. One commenter said this is not a new role—it is today's engineering work: you no longer build the product; you build the environment in which agents build the product. Itamar responded: agreed, factories have always existed, but a larger share of time is now shifting toward building the factory itself, so the role has evolved.

Another commenter was sarcastic: a software factory engineer is just someone who reviews AI code all day—a new title with no raise. Itamar said: No, no, no, please read the article.

One commenter said the core skill of this role is writing specifications and evaluations that the factory can check against. Code review shifts from lines to outcomes.

Another added: write down the rules the factory must never violate, and check them on every change. Agents write code quickly but are not good at spotting conflicts between two changes. Itamar agreed, saying this is about organizing rules, skills, and policies.

Someone also emphasized that you cannot buy a generic factory-in-a-box; it needs to work with your system, otherwise you will spend more time fighting Conway's Law.

The interesting thing about this role is that it acknowledges one thing: once AI can write code, an engineer's job is no longer to write code, but to design the system that reliably produces code. But the more complex the system becomes, the more humans need to understand. In the replies, Itamar said human judgment becomes more critical, and more engineering time will be spent on key business and engineering decisions.

One commenter said this is just giving code reviewers a new title. Both views are correct, depending on which layer you look from. If you are writing prompts, coordinating agents, maintaining documentation, and managing engineering processes, this job is not for you. If you are building machines, knowledge infrastructure, and control systems that make software production reliable, then you may already be doing this work—you just haven't given yourself a name for it yet.