Most large engineering teams are living a strange split reality.

On one side, they have hundreds of developers, years of code, and a backlog that never seems to shrink. On the other, they have AI tools on expense reports, internal decks about agents, and genuine ambition to see that capability show up in real output. At Lazer we are working with large enterprises and PE backed companies who want to close that gap by building software factories inside their existing engineering orgs.

The gap between the two is not another model or another chat surface. It is a production system.

That is what software factory really names. Not a metaphor, but a concrete way of wiring tgether code, context, people, and machines so that units of work come in one side and production changes come out the other.

This is what it looks like when it actually works.

The real problem – big teams, slow output, no AI operating model

If you sit in rooms with portfolio companies backed by large funds or with mature enterprise software firms, the pattern repeats.

Most have sizeable engineering teams and real product surface area. Leaders are interested in using AI to ship faster with leaner teams and to improve the quality of what gets built. Teams experiment with Copilot, maybe a helpdesk agent, maybe one prototype that calls an LLM against a staging database. Very few have anything you could call an AI native way of building software.

When people self assess privately, they tend to put themselves somewhere between

1. A few engineers are very good with AI tools, but everyone else is doing what they always did  
2. We have one or two agent experiments, but they are brittle and hard to trust

At the same time, the ask from the top is clear. Smaller teams. Faster shipping. A clearer connection between AI investment and output. Many executives can describe where they want to end up. Almost nobody has a map from the current state to that future. Fund leaders see this across their entire book, which is why software factory language now shows up in CXO summits and strategy offsites. It is one of the few frames that makes sense both to operators and to their capital partners.

The instinctive response is to shop for another tool. That usually changes very little. The underlying problem is that there is no shared production system that ties AI into how software is delivered.

From AI tools to software factory – a stepwise path

Most organizations cannot and should not jump from “we installed Copilot” to “we have a ticket to PR factory”. The factories that work tend to follow a sequence.

Stage 0 – Traditional delivery

This is the default state

1. Fragmented repos  
2. Inconsistent tests and CI  
3. Knowledge scattered across tickets, Slack, and people’s heads  
4. Little or no AI usage, or usage confined to a few enthusiasts

In this state, trying to install a factory is like trying to automate a warehouse with no inventory system. Agents spend all their time tripping over missing context and broken environments.

Stage 1 – AI enabled engineers

The first meaningful shift is to make AI a normal part of how individual engineers work.

On paper this looks mundane

1. Moving to modern git hosting that supports current AI tooling and more standard tooling in general  
2. Rolling out tools like Copilot, Cursor, or Claude Code  
3. Creating a learning path so that engineers understand prompts, patterns, and failure modes  
4. Coaching people on real tickets instead of giving them toy exercises
5. Creating repositories adjacent to others where things like claude.md files, MCPs, Skills, and more would all compound together and encourage others to engage

The effects add up. In one large digital consumer business, a focused enablement program took an engineering org from almost no AI usage to near universal adoption. Within weeks, pull request throughput increased, and the company could comfortably offboard a material number of external contractors while keeping roadmap velocity intact.

At this stage, humans are still at the center of the loop, but they are stronger and faster because they are pairing with models on real work.

Stage 2 – Agentic workflows

Next, teams start building agents or leveraging existing tools around specific workflows.

Examples

1. An agent that takes a written spec and proposes an implementation plan  
2. An agent that runs automated code review with architectural and security checks  
3. An agent that writes and maintains end to end tests for critical flows

These can be local or cloud based, and they often focus on a single repository or service at first. They may still depend on a person to orchestrate the overall work, but some steps move from manual to agent by default.

Stage 3 – Software factory

Only after those foundations are in place does it make sense to build a factory.

At this stage, the system

1. Ingests work directly from ticketing systems or structured intake forms  
2. Uses a common harness to coordinate multiple agents across repos and tools  
3. Performs its own context gathering and verification  
4. Produces code changes that engineers can treat as serious candidates, not curiosities

The factory does not remove humans. It removes unnecessary human glue work and concentrates attention where judgment and taste are required. The system will also have a baseline effectiveness but will need continual refinement to increase the max complexity it can take on.

Inside the factory – from ticket to merged PR

To make this concrete, consider a large digital business with a multi team engineering org that has decided to build an internal factory.
‍

4.1 Where work enters

Work arrives in a few standard forms

1. A ticket in Jira or Linear  
2. A PM spec in a product tool  
3. A request in Slack tagged for the factory
   ‍

The first design question is what valid work looks like. Most successful factories enforce a minimum intake template.

For example

1. Clear problem statement  
2. Links to relevant designs or docs  
3. Expected behavior and constraints  
4. Systems or surfaces likely involved

Early versions often restrict intake to a subset of backend tickets, where behavior is easier to verify and design changes are minimal. Only once the pattern is stable do they expand to more complex frontend or user facing work.

‍

4.2 The substrate – repos, environments, sessions

Underneath the intake, you need a substrate that is hospitable to agents.

At Shopify this led to two unfashionable moves. Pushing the company into a monorepo and standardizing everything on Nix. That meant one codebase, one model for environments, and a consistent way to build and test across teams. The motivation was explicit. Leadership believed that more code would be written with AI in the future, and that required a substrate the agents could understand and trust.

Many enterprises are not ready or willing to move to a single repo, but the factory still needs a coherent view of the world.

Typical patterns include

1. Virtual workspaces that join several repos into one logical unit for the agent  
2. Standardized dev containers or remote environments so agents do not depend on a particular laptop setup  
3. A central session store, often a database, that records every step an agent takes against a piece of work

The session concept is key. Every time the factory works on a ticket, it appends events to that ticket session. That history is the source of truth for what happened and why.

‍

4.3 Harness and sandbox – separating brain from hands

A second important pattern is the separation between the harness and the sandbox.

1. The harness is the control loop. It holds the session context, calls the model, chooses tools, and interprets results  
2. The sandbox is where code runs. It checks out repos, runs shells, builds binaries, executes tests, and talks to staging systems

Shopify’s Aquifer makes this split explicit. The harness lives outside the sandbox. Cells, sandboxes, and machines can die without losing the session. That design buys three properties at once. Safety, because the agent does not live where the code runs. Replaceability, because you can swap models and runtimes without breaking the session model. Observability, because every action routes through a common gateway.

Factories in other organizations are converging on similar shapes. Whether they are built on top of managed agents, third party orchestrators, or homegrown control planes, the harness and sandbox split tends to hold.

‍

4.4 Context enrichment – making tickets legible

Real tickets are messy. They refer to people, features, and incidents by local slang. They assume background knowledge that only a few engineers have. If you hand that text raw to an agent, you mostly get confusion.

Factories therefore invest in context enrichment before any planning or coding starts.

Typical steps include

1. Finding the code paths most likely to be involved, based on ownership files, past changes, or observability data  
2. Pulling in runbooks, design docs, specs, and intent documents related to the area  
3. Loading structured metadata from systems like commerce platforms, ERPs, or analytics warehouses  
4. Applying simple heuristics about risk, for example any change near payments may require stricter checks and narrower scopes

In some environments, there is a separate PM helper agent whose only job is to ask better questions up front. This agent comments on tickets or messages authors directly, asking about edge cases or constraints that matter to the system. That is often cheaper than letting a main agent thrash on an under specified task.

‍

4.5 Orchestration – clarifier, planner, codegen, tools

Once the context is in place, the factory moves into orchestration.

A simple but effective pattern is a three part loop

Clarifier 

Reads the ticket and context, then decides if the factory can proceed or needs more information. If it needs more, it writes back into the ticket or sends a Slack message with precise questions

Planner  

Breaks the work into steps, selects which tools and models to use, and decides what success looks like. This plan is itself logged into the session and can be inspected by humans

Implementer

Uses code editing tools to make changes, write tests, and push branches. It can work across multiple repos when the workspace supports that, though multi repo work is still significantly harder to get right at scale

Behind these roles sit adapters to systems that already exist in the org

1. CI pipelines and quality gates  
2. Test runners and coverage reporters  
3. Data warehouses and logging backends  
4. External APIs for billing, shipping, or identity

In some factories, this orchestration layer runs on top of managed agent services from model providers. In others, teams wire it directly against their own SDKs. In practice, the important part is not which orchestrator library you pick, but whether you keep the core loop simple enough that you can reason about it and evolve it. This is the current phase in the industry.

‍

4.6 Verification and self checks

Verification is where many factory efforts stall.

On paper, AI can write code. In practice, you only trust that code if it passes checks that are at least as strict as what a human would run.

Factories treat tests and checks as first class

1. They invest in agents that can generate and maintain unit and integration tests for common patterns  
2. They add end to end harnesses for key flows that are cheap to run but meaningful enough to catch user visible regressions  
3. They build domain specific validation layers that let agents inspect monitoring tools, error trackers, and other downstream systems to confirm behavior in realistic scenarios

Alongside this, many teams stand up internal benchmarks. For example, when evaluating different ways to hand design work to agents.

They may compare

1. Loom walkthroughs of behavior  
2. Static Figma files  
3. Structured text specs

They then measure which format yields the highest success rate for completed tasks or the lowest human correction time. Over time, the factory becomes opinionated about which inputs it will accept, because it has real data about what works.

‍

4.7 Human review and multiplayer by design

Even the best factories keep humans in the loop.

A common pattern is

1. The factory opens a pull request with clear notes about what it did and why  
2. A human reviewer, often the on call engineer for that area, checks the diff, asks questions, and either amends or approves  
3. For higher risk areas, a second approver or a feature flag rollout is required

The design question is how public this process is.

Shopify made a strong bet here. River cannot be messaged in a direct message. Every interaction happens in public Slack channels, and every session writes into a durable log. That means one person hard problem turns into a reusable artifact. The next time someone hits a similar issue, they start from a thread that already contains context, commands, and fixes, rather than from a blank prompt.

Factories in other companies that copy this multiplayer by default pattern get a similar compounding effect. They are not just building code. They are building a corpus.