Should every engineer operate their own autonomous software factory, or should the factory become a shared capability of the engineering team?

In short

  • As agents take on more of implementation, testing, and review, organizations must choose the unit of autonomy: the individual engineer, the team, or something in between.
  • Personal factories give clear ownership and fast experimentation, but in isolation they recreate individually owned knowledge at machine speed: duplicated investigations, divergent quality, incompatible changes.
  • The key distinction is between execution isolation and knowledge isolation. Isolate the work so agents cannot damage each other’s changes; share the intelligence so they stop rediscovering the same constraints.
  • Shared context must be curated, not merely accumulated, and over-centralizing a team factory can reproduce one mistake everywhere and suppress useful diversity.
  • The direction I would pursue is a federated model: isolate execution, share verified knowledge, federate orchestration, and preserve human accountability. Whether it beats the alternatives is a hypothesis to measure.

As AI agents become capable of implementing, testing, reviewing, and maintaining software with decreasing human involvement, engineering organizations face a new architectural decision.

What should be the unit of autonomy in software engineering?

Should each engineer operate an independent software factory, capable of working continuously on their behalf? Or should engineering teams build shared software factories, combining context, compute, autonomous agents, and human oversight into a collective delivery system?

This is more than a tooling decision. It determines how engineering knowledge accumulates, how software quality is maintained, where accountability lives, and ultimately, what an engineering team means in the age of AI.

My hypothesis is that neither complete isolation nor unrestricted sharing represents the ideal architecture.

We should isolate execution, share intelligence, and coordinate around outcomes.

But the organizational implications of this seemingly simple principle are significant.

1. The Rise of the Personal Software Factory

Consider an engineer who has access to a collection of autonomous AI agents. These agents can explore a codebase, investigate failures, implement features, run tests, create pull requests, and monitor the results of their work.

Instead of manually completing each step, the engineer becomes the operator of a miniature software factory (the model I described in The New Engineering Job). The engineer defines objectives, provides context, establishes quality expectations, and reviews the results. The factory can continue working while the engineer is in meetings, sleeping, or focusing on more important problems.

This creates an attractive model: every engineer becomes a multiplier of engineering capacity.

There are several natural advantages:

  • Clear ownership. An engineer knows which agents are working on their behalf and remains responsible for their output.
  • Independent experimentation. Engineers can develop their own agent configurations, workflows, and techniques without requiring team-wide agreement.
  • Reduced coordination overhead. Individual factories can operate independently when tasks are sufficiently isolated.
  • Personalized context. Agents may learn an engineer’s preferences, recurring decisions, domain expertise, and working patterns.

In many ways, this model is a continuation of the developer workstation: the workstation is simply becoming an autonomous engineering environment.

However, this approach also introduces a problem that becomes more significant as AI-generated output scales. We may end up recreating the limitations of individually owned engineering knowledge, only at machine speed.

2. The Hidden Cost of Factory Isolation

Imagine a team of eight engineers, each operating their own software factory. Every factory maintains its own agent instructions, repository context, learned patterns, test strategies, and understanding of the system.

  • One factory discovers a recurring production failure. Another independently investigates the same issue two days later.
  • One engineer improves their agent’s debugging workflow. Others continue using less effective approaches.
  • Two factories implement changes that are individually reasonable but architecturally incompatible.

Each factory may be productive in isolation, while the overall engineering system becomes less efficient. This creates several challenges.

Fragmented intelligence

Software factories produce more than code. They accumulate knowledge about why systems behave as they do, which approaches fail, what architectural constraints exist, and which implementation patterns are effective.

If that information remains trapped inside individual factory environments, the organization repeatedly pays to rediscover it.

Duplicated agent infrastructure

Individual engineers may independently construct similar workflows for incident investigation, code review, testing, and delivery. The organization ends up maintaining many variations of essentially the same production machinery.

Inconsistent quality

Different factories may apply different standards for tests, security, observability, and architectural compliance. As throughput increases, inconsistencies become harder to detect through conventional code review alone.

Coordination at machine speed

Traditional engineering teams already face merge conflicts, duplicated effort, and competing architectural decisions. Autonomous factories can magnify these problems because several agents may produce substantial changes simultaneously.

The bottleneck shifts from implementation toward integration, evaluation, and decision-making.

Increasing local productivity does not automatically increase organizational productivity.

This is the first reason to consider the team software factory.

3. The Team Software Factory

Instead of treating AI agents as private extensions of individual engineers, we can treat them as a shared engineering capability.

The team owns a persistent software factory. It contains shared technical context, specialized agents, delivery workflows, test infrastructure, operational knowledge, and a continuously updated understanding of the software it maintains.

Engineers interact with the factory by defining objectives, making architectural decisions, reviewing results, and improving its ability to deliver.

The team software factoryHumans direct the factory through shared context; agents execute in isolated environments.

Direction

  1. Human engineersGoals, constraints, decisions, reviews
  2. Shared Team Context HubArchitecture, history, policies, backlog
  3. Factory OrchestratorPrioritization, delegation, dependencies
  4. Build, Verify, and Operate agents
  5. Isolated task execution environments

Execution

The most important difference is not the number of agents. It is that the factory becomes a persistent organizational asset rather than a collection of independently configured personal tools.

When one agent discovers something useful, that knowledge can become available to the entire team. When an engineer improves a workflow, the improvement can benefit every future task. When an incident occurs overnight, the factory can investigate it using the same architectural context and operational history that engineers use during the day.

The shared factory becomes a mechanism for accumulating engineering intelligence.

4. Isolation Is Still Essential

A shared software factory should not mean that every agent operates inside one unrestricted environment. That would introduce substantial risks.

Agents could modify overlapping files, interfere with each other’s experiments, consume shared resources unpredictably, or accidentally access systems outside their intended scope. Isolation is essential for reliable parallel execution.

However, we should distinguish several forms of isolation.

Dimension Recommended boundary
Execution environment Isolate per task or agent
Code changes Independent branches or worktrees
Credentials and permissions Least privilege, scoped to the task
Working memory Isolate temporary reasoning and task state
Architectural knowledge Share through governed team context
Quality standards Shared and enforced consistently
Task coordination Team or cross-team orchestration
Accountability Named human owners and explicit approval gates

The important distinction is between execution isolation and knowledge isolation.

We want agents to work independently without damaging each other’s work. We do not want them to independently rediscover the same system constraints, repeat the same investigations, or make incompatible decisions because their understanding of the system has diverged.

Isolation should protect the work, not fragment the intelligence.

5. Shared Context Is the Foundation, Not an Implementation Detail

A shared software factory cannot succeed merely by pointing multiple agents at the same repository.

The repository explains what the system does today, but it rarely captures all the reasons behind its design. A factory also needs access to engineering decisions, operational history, previous failed approaches, conventions, deployment procedures, dependencies, and priorities.

This is where the concept of hierarchical context becomes important. Rather than giving every agent the entire organization’s context, we can structure knowledge into layers.

Layers of factory contextEach task receives the context it needs, without carrying everything the organization has ever learned.

Organization

  1. Organization HubPrinciples, standards, policies
  2. Team HubObjectives, decisions, architecture, operations
  3. Service / Domain ContextInterfaces, dependencies, runbooks
  4. Task ContextGoal, relevant code, acceptance criteria

Task

Each task receives the context it needs, without carrying everything the organization has ever learned.

This also creates an important feedback loop. The factory consumes organizational knowledge, but it should also contribute to it.

Every significant investigation, architectural decision, production incident, and successful implementation can produce a potential context update. Those updates should be verified, deduplicated, and incorporated into the appropriate layer. Otherwise, a shared context hub will eventually become a repository of stale information and unverified agent assumptions.

The team’s shared intelligence must be curated, not merely accumulated.

6. A Continuously Operating Team Factory

A particularly interesting possibility emerges when the factory is no longer tied to the working hours of individual engineers.

Imagine the following scenario. On Friday afternoon, a team identifies several important objectives for the following week. The team software factory receives those objectives, along with acceptance criteria, priorities, permissions, and limits on autonomous execution.

Over the weekend, agents can independently investigate feasible implementations, propose changes, execute tests, identify architectural conflicts, and prepare evidence for review. They can also perform approved low-risk operational activities, such as identifying flaky tests, analyzing reliability trends, and preparing incident investigations.

On Monday morning, instead of starting with a backlog of untouched work, engineers return to a set of evaluated options and validated proposals. They can spend more time deciding what is correct, valuable, or worth pursuing.

The team has effectively expanded its productive capacity beyond the hours during which its members are actively working.

However, there is an important constraint: not every task should continue autonomously. Some operations require human judgment, production access, or decisions involving significant business risk.

A mature factory needs explicit authority boundaries that define which tasks may proceed independently, which require review, and which must stop for human approval.

Continuous operation is valuable only when the factory’s output is trustworthy.

7. The Danger of Over-Centralization

So far, the shared team factory sounds superior. But there is a counterargument worth taking seriously.

What if sharing everything creates a new organizational bottleneck?

A centrally managed factory may require engineers to agree on agent tooling, workflow conventions, evaluation policies, resource allocation, and context management. Every improvement might need coordination. Experiments that an individual engineer could complete in an afternoon might become team-level decisions.

Additionally, shared context can introduce errors at scale. If an inaccurate architectural assumption enters the team context, multiple agents may act on it simultaneously.

A shared factory can become a mechanism for systematically reproducing the same mistake. This is particularly dangerous because a shared factory’s output may appear consistent even when its foundational assumptions are incorrect.

There is also a risk of suppressing useful diversity. Independent factories may explore different architectures, challenge established practices, or discover better agent configurations. A team factory that always operates from the same context and assumptions could converge prematurely on one approach.

Therefore, the goal should not be to eliminate independent factories. It should be to enable independent experimentation while preserving shared knowledge and integration standards.

8. The Federated Software Factory Model

My preferred direction is a federated architecture.

Individual engineers, teams, and potentially entire organizations operate factories with different scopes of autonomy. They share infrastructure, reusable capabilities, and relevant knowledge without forcing all execution through one centralized orchestrator.

The federated software factoryShared infrastructure and governance above, isolated execution below, without one central orchestrator.

Shared

  1. Organization Factory PlatformSecurity, identity, tooling, evaluation, knowledge standards
  2. Team Factories A and BDomain context and shared agents
  3. Personal FactoriesA1 and A2 under team A; B1 and B2 under team B
  4. Isolated Task ExecutionWorkspaces, permissions, controlled integration

Isolated

In this model, the organization provides common infrastructure and governance. Teams maintain the contextual knowledge and specialized workflows relevant to their domain. Individual engineers remain free to experiment and operate personal agents or factories.

Successful innovations can be promoted from personal workflows into reusable team capabilities, and eventually into organization-wide patterns.

The reverse is also true: teams should be able to extend or override shared capabilities where their domain requires different behavior, within established safety constraints.

This architecture resembles a platform engineering model, but with a crucial distinction. The platform is no longer just providing infrastructure for human developers. It is providing infrastructure for autonomous software production.

9. What Should Be Shared, and What Should Remain Local?

The best boundary is not necessarily the traditional engineering team boundary.

We should share capabilities when there is a meaningful benefit from collective knowledge, standardization, or coordination. We should preserve isolation when it improves safety, exploration, or independent execution.

A practical operating model might look like this:

Capability Best default scope
Personal agent preferences Engineer
Experimental agent workflows Engineer
Task execution Isolated task
Service knowledge and operational history Domain / Team
Backlog and delivery coordination Team or initiative
Architecture validation Domain / Organization
Reusable engineering skills Organization, with local extensions
Infrastructure and security policies Organization
Cross-service integration Initiative / Platform
Production authorization Explicitly assigned owner

The boundaries should also be dynamic:

  • An engineer working on an isolated feature might use a personal factory with shared organizational context.
  • A complex cross-service migration might require a temporary factory spanning multiple teams.
  • A mature service with significant operational history might benefit from a persistent domain factory, even if the people working on it change.

This leads to another hypothesis:

The factory’s natural boundary may increasingly become the domain or outcome, rather than the manager’s reporting structure.

10. A New Role for Engineering Managers

This also changes the responsibilities of engineering leadership.

Today, engineering managers spend substantial time organizing people into teams, coordinating priorities, resolving dependencies, and ensuring that work moves through the development process.

With shared software factories, some of this coordination can be performed by automated systems. But a new set of responsibilities emerges:

  • Who determines which kinds of work can be delegated autonomously?
  • Who ensures that the factory has the right context and evaluation mechanisms?
  • Who evaluates whether the factory is becoming more effective over time?
  • Who prevents improvements in local agent throughput from creating downstream operational problems?
  • Who decides when a factory’s architecture should change?

The engineering manager, technical leader, or designated factory owner may increasingly be accountable for the effectiveness of an entire delivery system, rather than only the activities of a fixed group of engineers.

The human development and support function remains important, but it does not necessarily need to have exactly the same organizational boundaries as software delivery. (I explored some of this in What About Teams?.)

This creates an interesting possibility: engineering organizations may eventually separate the management of human growth and performance from the management of autonomous delivery capacity.

It would not eliminate human leadership. It would change what human leadership is optimizing.

11. Measuring Factory Performance

If factories become an organizational capability, we need a way to evaluate them.

Counting generated code, agent sessions, or pull requests is insufficient. A factory that generates ten times more pull requests but requires ten times more human review effort has not necessarily improved engineering productivity.

I would evaluate factories across five dimensions.

Dimension Example metrics
Delivery effectiveness Accepted outcomes per unit of human effort
Quality Escaped defects, regression rate, change failure rate
Autonomy Tasks completed within approved boundaries without intervention
Knowledge efficiency Repeated investigations, context reuse, rediscovery rate
Economic efficiency Total compute, model, infrastructure, and human review cost per accepted outcome

We should also compare personal and shared factories on equivalent classes of tasks.

For example, take a set of similar maintenance issues and evaluate three approaches:

  1. Independent engineer-owned factories with isolated context.
  2. Independent execution with shared team context and quality gates.
  3. Fully coordinated team factories with shared context and orchestration.

Measure how often work is accepted, how much human effort is required, what it costs, and whether the outcomes remain correct in production.

My hypothesis is that the second model would outperform complete isolation on many tasks, while the third would provide additional benefits primarily when work requires significant coordination.

But that is a hypothesis that needs empirical validation. Shared orchestration introduces costs of its own, and those costs should be justified by measurable improvements.

12. What Current Industry Developments Suggest

Several developments in 2026 support parts of this direction.

In August 2026, Uber described its software factory approach, reporting that more than 70% of its pull requests involve local or cloud agents, along with more than 3,600 agent skills and increasing use of managed agents for lifecycle activities such as CI repair, review, and on-call triage (all self-reported). This suggests the factory concept is already moving beyond individual coding assistance. See Uber’s software factory article.

In June 2026, Microsoft described a transition from a software factory toward an agent factory, with shared engineering capabilities and agents collaborating throughout the development lifecycle. See Microsoft’s agentic platform discussion.

Meanwhile, Google’s Agent Compute Engine, which gives each agent session its own isolated microVM that persists working state across sessions, and the Kubernetes Agent Sandbox project illustrate the importance of providing isolated, persistent execution environments for increasingly autonomous agents.

There is also direct experimentation with collaborative agent teams. Qodo’s discussion of its Dark Factory explores agents exchanging evidence, challenging each other’s plans, and working with shared context instead of merely executing independent tasks.

These examples do not establish that team factories are universally superior. They do suggest that the industry is developing the ingredients required for a federated model: shared agent capabilities, orchestration, accumulated context, and isolated execution.

The organizational architecture remains an open question.

13. The Next Engineering Productivity Challenge

For years, engineering organizations have focused on improving the productivity of individual engineers. Better IDEs, faster builds, automated testing, CI/CD, and now AI coding assistants have all expanded what an individual can accomplish.

But once every engineer can operate multiple autonomous agents, the next bottleneck may no longer be individual execution capacity. It may become the ability to coordinate that capacity effectively.

An organization with 100 engineers, each operating five agents, does not automatically gain the equivalent of 500 productive engineers. It gains a much larger number of simultaneous execution processes, each capable of producing work that must align with the same product, architecture, and operational constraints.

Without shared intelligence, coordination, and quality mechanisms, this additional capacity can create as many problems as it solves.

The next major engineering productivity improvement may therefore come less from making individual agents better, and more from designing the systems in which agents collaborate.

Conclusion: Build Factories That Learn Together

I expect personal software factories to remain important. Engineers will continue to benefit from specialized agents, individualized workflows, and independent experimentation.

But I believe the more consequential opportunity lies in building factories that retain and improve the collective intelligence of engineering organizations.

The architecture I would pursue is straightforward in principle:

Isolate execution. Share verified knowledge. Federate orchestration. Preserve human accountability.

This model can allow engineers to operate autonomously while enabling teams to accumulate capabilities that survive individual tasks, personnel changes, and organizational restructuring.

And perhaps the most important shift is not the introduction of autonomous agents themselves. It is the realization that an engineering team’s greatest asset may no longer be only what its members know and can accomplish. It may increasingly be the persistent software factory they collectively build, improve, and operate.

The goal is not simply to give every engineer a software factory. It is to make every factory more effective because the others exist.

Further Reading