The New Engineering Job: Building a Software Factory That Never Sleeps

From writing software to building an autonomous extension of engineering capacity.

In short

A software engineer’s job is becoming the creation and continuous improvement of a software factory that extends their own engineering capacity, ideally around the clock and at their own standard of quality.
The factory needs more than coding agents: persistent context, an execution engine, independent verification, and a feedback loop that learns from the engineer’s corrections.
Quality, not code generation, is the real constraint. A good factory optimizes for reliable outcomes per unit of human attention and total cost.
Continuous availability is not continuous useful work. A factory that knows when not to act may be worth more than one optimized for activity.
The durable career skill may be designing a reliable engineering production system, and the engineer’s main deliverable a capability rather than only a product.

For decades, the primary output of a software engineer was software. We measured their contribution through the systems they designed, the code they wrote, the problems they solved, and the services they maintained.

AI is changing that relationship.

We are moving through several stages of engineering evolution: from writing code manually, to writing code with AI assistance, to delegating implementation to agents, and eventually to building autonomous systems capable of executing significant portions of the engineering lifecycle. But I think the next transition is more fundamental than simply learning how to use coding agents.

A software engineer’s job is becoming the creation and continuous improvement of a software factory that extends their own engineering capacity (ideally operating 24/7) while maintaining or exceeding the quality they could deliver themselves.

The engineer doesn’t disappear. Their expertise becomes embedded in a system capable of applying it repeatedly, across tasks, without requiring their continuous attention.

And the most interesting measure of their contribution may no longer be how much work they personally complete, but how much reliable engineering capacity they can create.

1. From Engineering Productivity to Engineering Capacity

Most discussions about AI-assisted software development focus on productivity. How much faster can an engineer write code? How many more pull requests can they produce? How quickly can an agent complete a task?

These are useful questions, but they still assume that the engineer is the operational center of the development process.

Consider the difference between three models.

Model 1: The engineer writes software.

The engineer directly handles implementation, tests, debugging, integration, and much of the surrounding development work. Their available time is the primary capacity constraint.

Model 2: The engineer works with AI agents.

The engineer delegates implementation and other tasks to AI tools, reviews the results, and directs the next steps. Productivity improves, but the process still depends heavily on the engineer being present to orchestrate each task.

Model 3: The engineer builds a software factory.

The engineer develops a persistent system that understands the product, architecture, development standards, and operational environment. It can accept work, plan execution, implement changes, validate results, investigate failures, and prepare meaningful outcomes for human decisions.

The difference between Model 2 and Model 3 is particularly important.

Model 2: working with AI agents

Model 3: building a software factory

Who orchestrates

Who orchestrates: The engineer, present for each task

Who orchestrates: A persistent system that accepts, plans, implements, and validates work

What AI does

What AI does: Makes the engineer faster

What AI does: Keeps producing value independently of the engineer's immediate availability

What grows

What grows: Productivity

What grows: Effective engineering capacity

In Model 2, AI makes the engineer faster. In Model 3, the engineer creates a system that continues producing value independently of their immediate availability.

This is not simply a productivity improvement. It is an expansion of effective engineering capacity.

2. Your Engineering Capacity Shouldn’t Stop When You Close Your Laptop

Imagine an engineer finishing their workday.

In the traditional model, their contribution to active development largely stops. CI pipelines might continue running, production systems keep operating, and scheduled automation executes, but the actual engineering process largely waits for the next human interaction.

In an AI-assisted model, the engineer may leave several agents working on individual assignments. But what if we go further?

An engineer could leave behind an autonomous engineering system that continues to:

Investigate incoming bugs and production anomalies.
Implement well-defined tasks from the prioritized backlog.
Create and execute tests, including integration and end-to-end tests.
Review proposed changes against architectural and quality requirements.
Improve documentation and identify inconsistencies.
Resolve certain CI failures and routine maintenance issues.
Collect evidence about completed work.
Prepare decisions, findings, and recommendations for the next human review.

The next morning, the engineer doesn’t start from where they stopped. They start from where their software factory reached.

Their job becomes evaluating outcomes, making decisions, adjusting priorities, addressing unexpected problems, and improving the system for the next cycle.

This resembles the 24-hour model described in McKinsey’s May 2026 analysis of agentic software delivery, in which humans and agents collaborate around the clock and humans step in at defined review gates.

But the goal shouldn’t be to keep agents busy all night. The goal is to ensure that useful work can progress whenever the engineer’s direct involvement isn’t required.

An engineer’s workday can end without their engineering capacity going to zero.

3. The Software Factory Is More Than a Collection of Coding Agents

A collection of agents executing tasks is not necessarily a software factory. A factory needs a production system.

In his talk Software Engineering Is Becoming Factory Engineering, published by AI Engineer in September 2026, Warp CEO Zach Lloyd describes a shift toward automating the complete software development lifecycle, including triage, specifications, implementation, review, verification, and monitoring, with humans approving at defined checkpoints.

I agree with the direction. But I think an important additional dimension is ownership of the resulting capacity.

The factory should become an extension of an engineer’s expertise rather than merely a centralized system for distributing prompts to models.

It needs several interconnected capabilities.

Persistent engineering context

Agents must understand more than the immediate task. They need architecture, service boundaries, implementation patterns, business requirements, quality expectations, operational history, and previous engineering decisions.

This is where hierarchical context systems become important.

Where the factory's context livesEach level adds narrower, more specific knowledge to the shared foundation.

Global

Company context hubGlobal engineering standards and strategic constraints
Organizational and team hubsArchitecture, ownership, and domain knowledge
Service repositoriesImplementation details, runbooks, tests, and operational behavior

Local

A company-level context hub can contain global engineering standards and strategic constraints. Organizational and team hubs can provide architecture, ownership, and domain knowledge. Service repositories can contribute implementation details, runbooks, tests, and operational behavior.

The result is a shared knowledge foundation that helps agents behave more consistently with the engineering organization.

An autonomous execution engine

The factory needs a mechanism for selecting appropriate work, decomposing complex tasks, coordinating specialized agents, managing dependencies, and persisting progress across sessions.

It should distinguish between tasks that can execute autonomously and tasks requiring human input. Not everything should wait for an engineer. But not everything should proceed without one, either.

An independent verification system

Implementation is only one step. A factory capable of generating code rapidly but unable to verify its behavior is simply manufacturing uncertainty at scale.

Verification must include deterministic tests, security checks, architectural constraints, behavioral validation, and production evidence where appropriate.

For more complex changes, the system should be able to explain not only what it changed, but why there is sufficient evidence to trust the result.

A feedback and learning loop

The factory should learn from its own operation.

When an engineer rejects a design, corrects an implementation, modifies a test, or disagrees with a review finding, that feedback should become an opportunity to improve the system.

How the factory learns from its engineerNo retraining of the underlying model required.

Results closer to the engineer's expectations

01 · ProduceThe factory produces workDesigns, implementations, tests, and review findings
02 · RespondThe engineer respondsRejects a design, corrects an implementation, modifies a test, or disagrees
03 · ImproveThe feedback becomes an improvementAgent instructions, skills, evaluation datasets, repository context, or automated checks
04 · RepeatThe next cycle runs on the improved system

Back to step 01

This may mean updating agent instructions, skills, evaluation datasets, repository context, or automated checks. It doesn’t necessarily require retraining the underlying model.

Over time, the factory should become better at producing results consistent with the engineer’s expectations. That is the transition from automation to continuously improving engineering capability.

4. The Engineer Becomes the Architect of Their Own Capacity

One of the most interesting consequences is how engineering expertise changes form.

Today, a highly experienced engineer is valuable because they can solve difficult problems, make sound architectural decisions, recognize failure patterns, and deliver reliable systems. In a software factory model, much of that expertise can also be expressed through reusable mechanisms.

An experienced engineer might create:

Architectural evaluation rules that agents apply repeatedly.
Testing strategies that go beyond happy-path validation.
Domain-specific implementation skills.
Operational investigation workflows.
Automated quality gates based on lessons from previous incidents.
Task decomposition strategies optimized for particular systems.

Instead of applying their judgment manually to every instance, the engineer teaches the production system to apply that judgment wherever feasible.

This introduces an important concept:

The engineer’s expertise becomes a reusable production asset.

A less experienced engineer might operate a powerful generic coding agent. A more experienced engineer might operate a carefully designed factory that consistently generates better solutions because its workflows incorporate years of accumulated engineering knowledge.

Of course, not all judgment can be encoded. Architectural tradeoffs, ambiguous requirements, and decisions involving people or business priorities still require human reasoning.

But every repeatable engineering decision represents an opportunity to extend capacity.

5. Quality Is the Real Constraint, Not Code Generation

There is a tempting assumption that if AI can generate code faster, engineering productivity will automatically increase.

That assumption is wrong. Code generation is only one component of delivering software. When implementation becomes cheaper, the constraint moves elsewhere: specifications, verification, integration, production operations, or the human decisions required to approve changes.

This is already visible in real-world examples.

In September 2026, Augment described its software factory, reporting a 4.5× increase in size-adjusted output per active developer between November 2025 and July 2026, while median time to merge fell from 11.2 to 3.1 hours and the 14-day revert rate from 1.9% to 0.4%.

These are company-reported results rather than independent proof of a general productivity multiplier. Still, they demonstrate why optimizing the lifecycle beyond code generation matters.

Similarly, Uber’s August 2026 engineering report describes managed agents handling code review, failing-CI recovery, on-call alert triage, bug investigation, and code maintenance, with explicit attention to cost and quality.

The lesson is that a successful factory doesn’t optimize for the amount of code produced. It optimizes for reliable outcomes delivered per unit of human attention and total cost.

This creates a much more demanding engineering objective. It is relatively easy to build something that writes code continuously. It is much harder to build something that consistently makes correct engineering decisions, recognizes uncertainty, and knows when to stop and involve a human.

The most valuable factories may therefore spend a surprisingly large portion of their effort verifying, challenging, and rejecting their own output.

6. A Factory Should Aim to Be Better Than the Engineer at Repeatable Work

There is another subtle but important distinction.

If the factory merely reproduces the engineer’s current behavior, the benefit is additional capacity. But perhaps the ambition should be higher.

Humans have limitations. They become tired, overlook familiar edge cases, forget previous incidents, and sometimes skip validation under delivery pressure.

A well-engineered factory could systematically apply checks that humans don’t always perform consistently. It could examine every relevant architectural rule, execute comprehensive automated tests, verify dependency changes, compare implementations against historical failures, and independently inspect the resulting behavior.

In repeatable, verifiable domains, the factory could eventually deliver more consistent quality than its human owner would achieve manually.

But this only works if verification is genuinely effective. Multiple agents agreeing with one another is not proof of correctness, particularly when their failures are correlated.

A high-quality factory needs objective evidence, diverse verification methods, and human escalation when confidence is insufficient.

The target is not AI-generated code that looks as good as human-written code. The target is software whose correctness and reliability are supported by stronger evidence than the traditional process routinely provides.

That’s a much more meaningful quality standard.

7. Not Every Factory Should Be Running All the Time

The phrase “24/7 software factory” is compelling, but it can also be misleading.

There is no inherent value in keeping agents busy. An autonomous system that spends the entire night generating speculative pull requests, repeatedly failing tests, or consuming large amounts of compute may actually decrease engineering productivity.

Continuous availability is different from continuous useful work.

The factory should operate based on available work, expected value, cost, risk, and the availability of meaningful verification. Sometimes the best decision is to:

execute immediately;
investigate and prepare a proposal;
stop and wait for a human decision.

A factory that understands when not to act may be more valuable than one optimized for maximum activity.

This also suggests that the factory’s operating model should vary by domain. A documentation update can usually tolerate much more autonomy than a database migration, security-sensitive authentication change, or modification to a financial transaction system.

The appropriate degree of autonomy should emerge from the nature of the work and the quality of available verification, not from an organizational mandate to automate everything.

8. How Should We Measure an Engineer’s New Capacity?

Traditional engineering metrics become increasingly inadequate when the engineer owns an autonomous production system. Counting code commits, pull requests, or even completed tasks can encourage exactly the wrong behavior.

Instead, we should evaluate the system as an engineering capability.

One useful conceptual measure is:

Effective engineering capacity = accepted, reliable engineering outcomes / total human attention required

This isn’t a universal mathematical formula. It is a way of reframing what we optimize.

The denominator should include not only the engineer’s initial instructions, but also review, corrections, escalations, supervision, and rework. The numerator should exclude work that never produces useful outcomes or creates avoidable downstream problems.

Other dimensions matter too:

Quality: escaped defects, incident rates, verification coverage, and rollback frequency.
Autonomy: proportion of appropriate work completed without unnecessary human intervention.
Efficiency: compute, infrastructure, and model costs per accepted outcome.
Learning: whether recurring failure patterns become less common.
Delivery: time from an accepted requirement to a verified result.

Most importantly, factory performance should be compared against the human-centered workflow it replaces:

Did we actually free engineering capacity?
Did we maintain or improve reliability?
Did we reduce the amount of human effort needed to produce the same result?
And did we create a system that becomes more capable over time?

If the answer is yes, we have created meaningful engineering leverage.

9. What Happens to Engineering Teams?

If individual engineers can operate increasingly capable software factories, traditional engineering team structures may also need to evolve.

Historically, teams have served as relatively permanent units of delivery and operational expertise. A group of engineers collectively possessed the knowledge and capacity required to build, maintain, and operate a set of systems.

But when engineering context becomes more accessible, execution capacity becomes more elastic, and autonomous agents handle larger portions of implementation and operations, the relationship between team size and delivery capacity changes.

An engineer might temporarily assemble a production capability around a particular initiative, combining shared organizational infrastructure with specialized agents and domain-specific workflows. Other engineers could contribute expertise, verification mechanisms, or architectural guidance without necessarily joining a permanently assigned delivery team.

The work becomes the organizing principle, while engineering knowledge and execution capabilities become increasingly reusable.

This does not eliminate the need for collaboration, team identity, or human support. In fact, it may strengthen the argument for separating delivery coordination from people development and organizational support.

Engineering leaders could focus more on establishing effective delivery systems, allocating human and agent capacity, maintaining accountability, and ensuring that engineering expertise is continually developed.

The organization becomes less dependent on manually reshuffling people to match every change in priorities. Instead, it can reconfigure the capabilities available to execute the work.

10. The New Engineering Career Question

For engineers, this shift presents a significant career challenge.

Learning to prompt a coding model is useful, but it is unlikely to remain a lasting competitive advantage. Even orchestrating a handful of agents may become a relatively standard capability.

The more durable expertise may lie in knowing how to design a reliable engineering production system:

How do you structure a complex task so agents can execute it effectively?
How do you make architectural knowledge available without overwhelming model context?
How do you validate results when the implementation itself is probabilistic?
How do you establish appropriate autonomy boundaries?
How do you build feedback loops that improve performance rather than simply accumulate more instructions?
How do you balance capacity, quality, cost, and engineering risk?

And perhaps most importantly, how do you decide what is worth building in the first place?

These questions require deep engineering knowledge, product understanding, systems thinking, and operational judgment.

AI doesn’t remove the need for engineering expertise. It changes the ways that expertise creates value.

11. The Next Engineering Deliverable Is a Capability, Not Just a Product

There is a useful analogy with the evolution of software infrastructure.

Activity	Once	Then
Deployment	A manual activity	Deployment pipelines became a standard engineering capability
Infrastructure	Operated mostly manually	Infrastructure as code and automation transformed provisioning and management
The engineering process	Now in transition	Becoming something we can design, automate, observe, and continuously improve

Now a similar transition may be happening to software engineering itself.

But unlike a deployment pipeline, a software factory spans a much broader set of activities, including parts of the reasoning and decision-making that traditionally defined software engineering. That makes the opportunity substantially more powerful, and the responsibility considerably greater.

The future engineer may still write code when doing so is the best way to solve a problem. But writing code won’t necessarily be the center of their job.

Their most important deliverable might be a system that can repeatedly produce high-quality software, preserve engineering knowledge, respond to operational feedback, and continue improving between human interactions. A system they can trust enough to delegate meaningful work to, and inspect closely enough to remain accountable for its outcomes.

The engineer of the future won’t just build software. They’ll build the capability to build software, and make that capability more reliable, more autonomous, and more effective every day.