Architecting a Software Factory: Introduction

Every way of building software is a way of organizing a team. The software development lifecycle, or SDLC, is the way a team turns user challenges into software that solves them. It covers deciding what to build, designing it, building it, checking it, shipping it and keeping it alive. The history of the SDLC is largely a history of how people have organized and coordinated the team doing that work.

Waterfall, an early, widely recognized SDLC methodology, coordinated the team in advance.¹ Requirements were specified, phases followed one another, and the work passed between specialists through formal handoffs. Agile methods, which became popular in the 2000s, coordinated people in shorter cycles.² In Scrum, a team worked from a backlog, committed to a sprint, met each day in a Daily Scrum, often called a "stand-up", demonstrated the result and reflected on how to improve.³ In the 2010s, lessons from Lean Startup methodology became part of the mix. Minimum Viable Products (MVPs) helped teams try to learn from running software sooner and iterating on customer feedback.⁴ At the same time, with the emergence of hyperscalers in the 2000s and 2010s, infrastructure moved from server racks on-prem into the cloud and became programmable. DevOps and continuous delivery automated the final stretch from a merged change to production.

These approaches differ in cadence, artifacts and philosophy, but they share one assumption: the team is made of people, and the process exists to coordinate them. The goal is to ship software.

That assumption is changing. From 2023 through 2026, as large language models (LLMs), trained on large corpora of code and online forums, became increasingly capable of understanding, writing and changing code, engineers handed more of their work to agents. At first, the result was a person made faster by a model. Then the boundary moved. Agents began reading repositories, running commands, fixing their own mistakes, using other agents and carrying work across several stages of the lifecycle. The team came to include people working with agents, then people supervising groups of agents. As each new task became delegable, a larger question arose: what would happen if the software development lifecycle could run autonomously?

A software factory takes that possibility seriously. In the factory, the operating team is mostly agents and people remain at the helm. Interestingly, putting a human "in the loop" actually leads to downtime: they are not always present to answer questions the agents might have. Sometimes the wait is warranted. If you had not checked the spec or plan up front, you'd want to review a critical change. But for the long tail of smaller tasks, the agents are blocked while they wait for the user to answer questions, approve their plans or give an update. Downtime slows velocity. Instead, the development lifecycle has to be designed to let humans guide from the helm. We have to reconsider what starts work, how intent is recorded, how a plan is made, who or what checks the result, how changes reach production, and how many such workstreams across the team or org stay consistent. That rebuilt lifecycle is increasingly called the agentic SDLC, or the software factory. It is the subject of this book.

Outside of the software sense, defining a factory as a room containing multiple powerful machines and people operating them is reductive. It is a system that decides what should be made first, organizes and automates the machines to do the work, supplies them with materials, checks the result, moves it through the line, keeps related products consistent, observes failures and improves the process. Raw material flows through the factory and comes out at the other end as a finished packaged product ready for delivery. Sophisticated factories with automations have humans that guide and program the machines, not operate them; humans do the work that machines cannot. A team of humans runs the operations, but they don't do the work themselves. In fact, in cases where machines are highly automated and move fast, humans are not even allowed on the floor. If we use the metaphor seriously, a software factory has to include all of those functions along with the human operator at the helm and in the critical places where the work cannot be delegated to the factory.

The best level of automation we currently have for writing code is a coding agent: an agent harness dedicated to writing code with a human controlling it. Even if you had a team of humans using such agent harnesses, using more than one agent harness at the same time does not, by itself, make a factory. The coding model matters, but the harness, at best, is just a machine on the floor. In a factory, such agents are organized as a fleet to code interdependent repositories based on user requirements. Tokens are the electricity the factory runs on.

Let's look at what such a factory produces. The output of the entire factory taken together is not just the code committed to the repo. It is a working change in a deployed software system. Code that never ships is inventory that piles up. A pull request that passes its checks but destabilizes production is a defect. A security fix that reaches one repository while its siblings remain vulnerable is unfinished work. Once software production is treated as the lifecycle of producing it rather than an act of typing, the manufacturing ideas become useful: flow, waiting, defects, quality, inventory, rework and continuous improvement.

Seen this way, the factory is not one process but five flows that run alongside each other, from deciding what to build to improving the factory itself. I introduce each one later in this chapter with the question it answers.

Because the current state of the art in building software with agents is the coding agent, most accounts of agentic development concentrate on the flow that writes the code. It might be tempting to only focus on making agents write code faster or better. But the other flows are equally important, if not more. Together, these flows determine whether the result creates value.

From March to 1st of October 2026, mostly during a sabbatical that began in May, I built a factory incrementally and studied the different flows. This book compiles my learnings and presents them as one way to think about it if you're building one yourself. Treat this as an informed opinion built on the experience of someone studying how to build a factory while building multiple apps. It's one opinion alongside multiple other equally interesting viewpoints you can find elsewhere. The data I present is based on incrementally improved record keeping and in many cases anecdotal, based on my personal experience building one factory. I do not claim it as scientific proof. In my defense, it's hard for one person to do an empirical study. After all, how many factories does one need to build?

This chapter explains where the factory idea came from, what I mean by it, and the fleet of applications I built in order to study it. The fleet and its measurements come later in the chapter on purpose. The questions are meant to apply to anyone’s factory, so I begin with the general idea and only then introduce mine.

There is a wide range of coding automation between a human using autocomplete in their IDE to write code and a truly autonomous software factory. Most software teams sit somewhere in between. Coding with models becomes more automated incrementally as teams take a more mature stance on their level of comfort and trust. A brief history of the different styles of agentic coding is in order here. Each style was named for what practitioners learned to engineer: prompts, context, harnesses and then loops, graphs and stacks (Diagram 1.1).

The earliest approach involved automating coding using a conversational assistant. A person asked their favorite AI-powered chat assistant for changes to their code, pasted the answer into an IDE, ran it and copied the error into the assistant until it worked as expected.

IDEs also started shipping with a really compelling feature: the embedded agent would try to understand what you're typing, recommend the completion of that line or few lines based on common patterns in gray, which you could accept by hitting tab. It took the typing away.

The chat approach quickly got replaced with dedicated interfaces where you could prompt the agent for your repeated coding tasks. Prompt engineering meant choosing words, examples and a format that produced a useful answer. For example, you could have a prompt specifying your role in the team, the tech stack, and the style of coding the team expects. The person still selected the files, judged and applied the result, tested it and decided what came next. Andrej Karpathy coined vibe coding in February 2025 for the opposite habit: giving in to the model and ceasing to read the code closely.⁵

These two ideas fueled the imagination of the innovators. As models gained larger context windows and tools connecting them to the software people use in their workflow (such as Linear and GitHub), the answer would depend less on clever wording than on what the model could see: the right files, documentation, conventions and task history. As long as you could fit all the relevant information in the LLM's context window, the agent should in principle automate routine coding tasks, even across multiple files at a time. But now you needed to decide what went in the context. In June 2025, the practice gained attention under the name context engineering, which Karpathy, among others, favored over prompt engineering.⁶ Context became something to design and maintain. Files such as CLAUDE.md and AGENTS.md, scoped instructions, design records, plans and agent memories keep a person from assembling it by hand each time.

The next shift was the harness. As context started including memory, tools, skills and more, you needed a way to organize the control in an easily delegable way. An LLM became just one component inside a program that manages a coding task: reading and editing files, executing commands, managing the context window, delegating and requesting permission at a boundary. By 2026, shaping that surrounding setup was called harness engineering.⁷ Mitchell Hashimoto summarized the practice as a rule: whenever the agent makes a mistake, change the setup so that mistake is harder to repeat.⁸

Another style emerged by leaning into the agent's ability to choose the next action while you're away from it so it could finish your task backlog for you, and you could do things that matter, like sleep. A person gives the harness an objective and lets it continue until the work satisfies its checks. Geoffrey Huntley’s “Ralph” loop expresses the idea simply: a script repeatedly gives an agent the same goal, while files and git preserve progress outside temporary model memory.⁹ More sophisticated approaches emerged soon: a Learn OpenClaw tutorial describes a related pattern, with one agent planning and another implementing in short iterations.¹⁰

The hard challenge in this style is knowing when to stop. That requires a plan, tests, verifiers and an evaluable condition. The person’s attention moves to the two ends: clarify the outcome before the run and examine the evidence after it. Peter Steinberger, who built OpenClaw largely by himself, described running five to ten agents concurrently and shipping code he did not read. He concentrates on plans and architecture and challenges weak decisions before implementation.¹¹

Loop engineering goes beyond one repeated prompt. Practitioners design plan-act-observe cycles, triggers, schedules, verifiers and termination conditions. A control plane decides whether an agent continues, retries, asks for help or stops, and one loop can trigger another. Karpathy's autoresearch, released in March 2026, demonstrated how far a loop with a clear stopping rule can run on its own.¹² An agent edits a single training script, trains a small language model for a fixed five minutes and keeps the change only if a validation score improves; otherwise it discards the change and tries something else. The metric decides when each experiment stops, and the log is the evidence to examine in the morning.

By 2026, Karpathy called the professional version agentic engineering: people set the architecture, divide the work and verify the result. Thinking can be outsourced, he argues, but understanding cannot.⁵ Boris Cherny, the creator of Claude Code, said in June 2026 that he had not written code by hand in eight months and sometimes managed hundreds or thousands of agents.¹³ Individual agentic engineering begins to become a factory.

Even then, a developer with an excellent harness remained one member of a conventional human team. Tickets, sprints, stand-ups and a colleague’s pull-request review remained exactly where they were. Teams perhaps needed fewer people and could crunch through their previously insurmountable backlogs, but while the individual became faster, the surrounding organization did not necessarily change.

Karpathy, Steinberger and Cherny all move the person away from typing and toward intent, architecture, planning and verification. Their accounts say less about what happens over the long run: what this mode of development costs, which failures recur, how much work still waits for a person, and how one operator keeps many concurrent streams consistent.

Those longer-running questions are where the software factory emerges as a subject of its own.

Imagine a software factory from its control room: robotic 'coding' arms changing one application, grouped into cells working across the fleet. Together they turn what the organization needs into running systems with as little unnecessary human intervention as possible.

Overseeing from that control room, the operator studies customers, shapes the work, confirms the result matches the intent and sees that it reaches production. More importantly, the operator improves the factory: removing bad handoffs, waiting and rework, controlling cost and preventing recurring mistakes across the cells.

The phrase software factory itself is much older than the current generation of AI. In 1968, Bob Bemer at General Electric proposed a software factory that would make programmer output less variable through standard tools and a database of prior work that managers could use to steer production.¹⁴ Hitachi opened its Software Works in 1969, followed by Toshiba, NEC and Fujitsu in the 1970s. Michael Cusumano’s study of those organizations found standard processes, reuse and quality control being applied to programming, with genuine improvements in productivity and quality.¹⁴

The idea did not become the dominant model. The common objection was that software is design rather than manufacturing. Each important program is new, so there is no repeatable object to place on an assembly line. Agents weaken, but do not eliminate, that objection. The purpose and design still require human understanding. Yet the step from a sufficiently clear design to working, tested code is increasingly work a machine can perform, many times and in parallel. The old factory concerns return: standard processes, quality controls, reusable knowledge, measurable records and continuous improvement based on observing the line.

This means overseeing agentic processes across interdependent applications, from design through production. Work may begin with a person, issue, schedule, failed test, alert or another agent. The SDLC becomes the design of the factory: what may initiate work, what evidence a change must produce, where work proceeds autonomously and which decisions remain human (Diagram 1.2). At this scale, the harder problems are handoffs, coordination, defects, downtime, security, cost and improving the process while its models and harnesses keep changing. Their capabilities are moving fast, so each builder has to grapple with pacing development so that the features they build are not made obsolete by the next version.

Giving someone a coding agent changes how they write code, but it doesn't necessarily change how the team works together. In a factory, you can reconsider some of the routines built around a team of people. Written progress that others can check can replace some stand-ups. Automated checks and review agents can take on some of the review a colleague would do. Triggers and policies can replace parts of sprint planning. A conventional team is often limited by how much engineering work its people can do. In a factory, you may be limited instead by how much attention the operator can give it.

That shift invites uncomfortable questions. Why should every change wait for a person to review it? Why are pull requests kept small? Do agents need IDEs? Why should an agent care about commits, which help people preserve progress, reason about history and roll back work, and which are commonly sized around the time and attention of human reviewers? Which of those practices protect software quality, and which merely coordinate a human workforce? A factory may keep some of them, discard others and introduce new units such as logical change sets that better describe the work agents perform.

When most of the team consists of agents, the lifecycle has to be designed around them: how work is defined, what starts it, how it is planned, who checks it, and how multiple streams remain consistent.

As agents take on more of the work of turning an idea into running software, we may need to rethink how that work is organized. The factory comparison helps us do that, even though building software is different from manufacturing a physical product.

During 2026, software factory became a product category, approached from several starting points. The platforms and the practitioners differ mostly in where they leave the person.

Factory (the company; note the capitalization) describes an agent-native system spanning intake, planning, implementation, review, delivery and monitoring.¹⁵ Warp offers a fleet of agents started by issues, Slack messages or schedules, with the factory configured in the repository.¹⁶ Harness approaches from software delivery, placing agents after implementation and letting organizations set autonomy levels.¹⁷ Cortex defines a factory as an organizational system for turning customer needs into reliable software, while warning that it can also ship defects faster than anyone can catch them.¹⁸ 8090 organizes its factory around component blueprints that agents translate into code.¹⁹

Practitioners publish their own patterns. HumanLayer emphasizes work before code: agents produce a design and plan, people challenge both, and only then does implementation begin.²⁰ Its 12-Factor Agents informed much of the control-plane thinking in Chapter Seven.²¹ StrongDM’s two rules are that humans neither write nor review code; people write specifications and scenarios, and agents build until they pass.²² Matt Pocock’s Sandcastle runs agents in isolated environments; his workflow divides work into a day shift of human planning and review and a night shift of agent building.²³ His AI Coding Dictionary defines a software factory by its triggers: agent sessions begin because an event occurs, not because a person starts them. Kiro, Spec Kit and Tessl make the spec the lasting artifact, and Birgitta Böckeler's comparison explains the differences between them.²⁴

All relocate the person from coding toward designing and operating the system that produces code. They use written plans, automated checks, agent reviewers, isolated work and non-human triggers. They disagree on the human boundary: StrongDM removes people from code review, HumanLayer keeps them at design and planning, Pocock at planning and final review, and the commercial platforms make autonomy configurable.

Not everyone is a fan of the industrial metaphor. Lauren Tan, reporting two thousand pull requests shipped with agents in a month, prefers a Michelin kitchen: the output is not mass-produced, and a person remains responsible for every plate.²⁵ Her trust is layered: make bad patterns impossible, then detect them with static analysis, rules and skills, rather than relying on human review alone. Agents imitate the repository, so bad patterns can spread faster than written rules can stop them.

The measured studies keep these accounts, including mine, in perspective. METR's 2025 trial found that experienced open-source developers took longer with AI tools while believing they were faster.²⁶ Faros found individual output rising without the organization delivering more.²⁷ Watanabe and colleagues, and Li, Zhang and Hassan, studied agent pull requests across many more repositories than one fleet can offer.²⁸²⁹

Most public accounts describe an architecture, a workflow or an early result. Much less has been published about operating one factory over months: what it actually ships, where it waits, what it costs, what it gets wrong, which safeguards matter, and what the person running it spends their day doing. This book attempts to fill that gap for one factory. One case can show how the parts of a factory work together; studies across many repositories can test whether similar results appear elsewhere.

In this book, a software factory is a collection of agentic processes that work together to build and ship software from designs, needs and insights supplied by people or systems rather than from humans taking part in the coding. The agents implement changes across one or more applications that depend on each other. The process runs from understanding those inputs to placing working software in production. How much of it runs without a person is a design choice, not part of the definition.

Three parts of the definition do most of the work.

First, the input is not a human doing the coding (agentic or otherwise), reviewing pull requests and so on. The input to the factory is a user need, a design, an observation or a decision about how the software should behave. The factory needs to understand what people want the software to do and work out how to build it.

Second, the output is not code or a pull request. It is running software. A change that never leaves a branch is inventory, not a finished product. The delivery path and the state of production therefore belong inside the factory boundary.

Third, the scope is not one isolated application. It is a set of applications, services and shared systems that depend on one another. The agents working in one repository need a way to understand changes elsewhere, request work from the appropriate owner and keep shared decisions consistent.

The definition intentionally leaves open how work starts. Pocock’s definition makes triggers the defining feature. I use a broader boundary. A factory may run autonomously from triggers, or semi-autonomously with a person initiating each unit of work. From time to time, people may roll up their sleeves to ship a critical piece of code. But for the most part, they are interested in making the factory run smoothly. How much the factory runs on its own is something you decide when building it. It can still be a factory with people involved.

Where a person intervenes is a choice made when designing the factory. What makes it a factory is the input, the output and the scope.

Five questions determine the shape of a factory built to that definition. Each one names a flow (Diagram 1.7), and Chapters Two to Six take them in order.

Who guides the work? This is the direction flow, which turns signals into authorized work. A person does not have to originate every task. Agents can discover security weaknesses, defects, duplicated code, gaps in test coverage or inconsistencies across applications. They may be able to order work already present on a roadmap and plan how to validate it. What they cannot be allowed to do is substitute their local judgment for the organization’s purpose. Focus, importance, guidance, policy, explicit delegation boundaries and the like all remain with the human. For example, an agent cannot be lax about user data and casually wire it into code, especially in regulated industries where agent carelessness can have large consequences. The factory must remain bound to what people want the software to accomplish, direct effort toward what matters and keep cost and risk inside agreed limits.

How is the work done? This is the production flow, which gives agents enough context to plan, build, test and record what they are directed to do. Consider one factory agent responsible for building and shipping a change. It needs the design, the reason behind the request and the decisions the organization has already made. It needs context from nearby work because a change to one application or shared service can affect another. What it does not inherently need is an IDE. An editor is a visual tool for a person reading and writing code a screen at a time. The agent needs tools and context, but not necessarily the interface designed for a human typist (Diagram 1.3).

An agent that builds and ships software needs to know what to build and what nearby agents are changing. It does not need an IDE.

How does the work ship? This is the delivery flow, which reviews, merges, deploys and observes the change in production. Shipping starts with deciding what unit gets shipped. Much of the familiar lifecycle reflects the cognitive and social limits of people. Commits preserve progress in pieces a person can reason about. Pull requests create a place for a colleague to review. Epics and stories divide work into units a team can estimate and hold in mind. These practices are useful for human organizations, but they are not natural laws. Agents may be able to inspect a larger change while remaining focused on one outcome. The factory must decide which existing units continue to protect quality and which should be replaced. For this reason, the book counts logical change sets rather than treating commits or pull requests as direct measures of work.

The same limits shape approval. Whenever an agent must wait for a person to approve the next step, the line experiences downtime. In the best case, the factory redirects capacity elsewhere. In the worst case, interdependent work accumulates, branches age, deployments wait and the operator returns to a backlog of approvals. The answer is to reserve people's attention for decisions in which human judgment changes the outcome, and to give routine decisions reliable automated evidence.

How do the applications stay consistent? This is the consistency flow, which carries shared fixes, components and policies across the fleet. A factory builds a set of applications that share templates, services, infrastructure and design. A security fix has to reach every repository that needs it, a shared component has to behave the same wherever it is used, and a decision made in one repository should not be quietly contradicted in the next. Left alone, each application drifts. The factory has to treat consistency as ongoing work, not as an audit someone runs once a quarter.

How is the factory run? This is the improvement flow, which measures waiting, cost, defects and drift, then changes the factory itself. Someone has to watch the line, notice where work waits or fails, and change the guides and checks so the same failure does not recur. Today that someone is usually a person. For the factory to improve, that loop has to be observable first and automated later.

All five questions lead to one operational concern: how can people stay at the helm without having to stay on the factory floor?

The working definition for the rest of the book is therefore:

A software factory is a system of agentic processes that turns designs, needs and insights into running software in production across applications that depend on one another. People guide what gets built; they do not approve every step required to build it.

The same debates recur across nearly every component of an agentic SDLC, and they cut across the flows rather than following them. For the ones that matter most here, I note where this factory stands and which chapters take them up.

Who reads the code? StrongDM says no person should write or review it. HumanLayer places the person at the design and plan. GitHub’s Copilot coding agent retains a person at merge. In my factory, agents and the automated approval check review almost every pull request. Chapters Two and Four examine the consequence of that choice: how often I intervene, what the reviewers catch, what they miss and what that checking costs.

Should one agent work, or many? Anthropic’s research system divides focused work among subagents.³⁰ Cognition argues that multiple agents create coordination problems when they make changes without seeing one another’s decisions, and favors a single writer.³¹ Practitioners who run many agents isolate them through separate sandboxes, worktrees or projects. I often keep sessions open in several repositories; a median of two were active at once, and four at the ninetieth percentile. Chapters Three and Six examine concurrency, delegation and the way context is shared.

How much should be written down? Spec-driven methods place a detailed document before implementation. Critics observe that agents generate more prose than people review and do not always follow it. Instruction-file practice divides between recording every lesson and moving important lessons into executable checks. This factory uses work items, goals, repository instructions and design records. Chapters Two and Three ask whether those artifacts are actually used, whether they remain true and when a rule needs to become a sensor.

What starts the work? Commercial factory systems ingest external signals, and Pocock imagines a night shift of agents beginning from an approved queue. In my system, I still start every session. Chapters Two and Six measure what that human initiation costs in waiting and what would be required to remove it safely.

Should the code live in one repository or many? Most descriptions of coding agents assume a single repository. The monorepo debate was developed around human organizations. The least documented part of my problem is how a fleet of repository-owning agents propagates a change, shares context and avoids inconsistent decisions. Chapters Three and Five develop that question through messages, drift, conformance and eventual consistency.

In spirit, my factory is closest to HumanLayer and Pocock: people settle the intent and plan; agents carry out most of the implementation. The important differences are that work does not yet start on its own, while review is performed almost entirely by agents and the approval check rather than by me.

Since May 2026, I have been on sabbatical, trying to understand what software development looks like for me, a principal architect and engineer, in an era when models can build an increasing share of a software system. Two reasons follow, one commercial and one about the engineering itself, and the commercial one is a hypothesis rather than a result.

Traditionally, software consulting has been resource-heavy: for each customer you staff the necessary near-shore or off-shore software engineers who do the work. Projects are scoped to understand customer requirements and deliver code. In the last couple of years, the model has changed slightly: the role of a forward-deployed engineer, who sits adjacent to the customer’s real workflow and builds in context, has emerged. They're often cited as having a shared arsenal of blueprints and cookbooks that would help them deliver faster, but staffing is still limited by how fast you can slot in people.

With the help of a software factory we can now deliver software without the same staffing constraints. As coding agents become increasingly competent, a new model has emerged where we can build custom software at scale. It sits between consulting, where a human team delivers code that the customer takes over, and pure SaaS, where one common product serves many customers.

At A.I. Hero, Inc., our aim is to shape software around a customer’s actual business processes and workflows. With the factory built, a small team is optimized to define what is to be built for each customer, while agents perform the repeatable design, engineering, checking and delivery. As such a studio adds customers, it adds operators at a lower rate than a traditional consulting project adds staff. The factory scales agents that take common blueprints and build software while people understand each customer and make the decisions that guide them.

Every application can differ while the way it is designed, built, checked, shipped and operated stays consistent. Sam Altman predicted in 2025 that, as datacenter production becomes automated, the cost of intelligence should approach the cost of electricity.³² If software cost follows AI cost, building any one application becomes cheap and the scarce resource shifts to deciding what to build for each customer, so the central design problem becomes the studio’s focus rather than any one application. The output sits between a product for everyone and a custom project built from nothing.

I am also interested in the factory as an engineering discipline. Builders such as Lovable use agents to generate and deploy software, but customers use their factory rather than build it.³³ My subject is the inside: how work is defined and checked, how agents share context, how applications stay aligned, what the operator does and how the factory improves. Those are the mechanisms I studied.

It is important to note here that this is not a book about how you can build such a consulting business with a software factory. This book focuses on the engineering production and operation of the factory. It does not get into the usage: customer task success, adoption, retention or revenue. I do not go into the business case: the potential revenue against the cash costs and human effort needed to make the studio profitable.

For both reasons, I'm interested in how work is organized for agents working across multiple repos in a factory: how it starts, how it gets checked, how it reaches production and how the agents work together across the fleet. The next section describes the fleet I built to try this out.

One application and one agent create a productivity question: how much faster can one developer build? Factory questions appear when several applications and shared systems are active. A fix must reach related repositories, template descendants drift, agents share services, and a rule learned in one repository can be forgotten in the next.

To explore those questions, I ran a fleet: a template, applications created from it, shared identity and design services, infrastructure, and the skills plugin that operates the process. I wanted to understand how agents could coordinate work across those repos without me having to keep track of everything myself. I ran the fleet alone with one exception: an infrastructure contractor moved the infrastructure off AWS onto DigitalOcean and built the factory's automated deployment.

My fleet contains fifteen repositories of five kinds: shared services, applications, the template, the plugin and infrastructure (Diagram 1.5). On a busy day six repositories were open with separate Claude Code sessions: more state than one person can hold comfortably.

To work inside each repo, the factory agents need to know about coding practices that they should follow. I give them skills to write code as expected, grouped together in a plugin. The agent working on the plugin repo is also a member of the fleet: it is designed, changed, reviewed and repaired by the same factory it helps to run.

The applications are not independent, nor should they be. They authenticate through the same identity service, use components from the same design system, begin from the same template and deploy through shared infrastructure. Those relationships distinguish a fleet from a list of projects. A change in one location has to propagate to others or be prevented from breaking them.

To work across the fleet, agents need a 'floor plan'. In my factory, for example, FLEET.md lists the repositories, describes what each is for, records its category and reserves the local port used by its development stack. Agents use these skills and consult that floor plan jointly before acting across repositories.

The fifteen repositories appear under the plain names this book uses, with the original repository name beside each so a reader who meets it in the data can find it (Table 1.1).

The full fleet did not exist in March. I started with one repository, Claude Code and a small collection of skills. Each time the work exposed a missing capability, I added a piece. When a problem recurred across repositories, I tried to solve it once in the plugin, template or shared system so that the remedy could spread.

Before July, only a handful of repositories were active; the template and its first descendants arrived during the middle of the year (Figure 1.1; evidence).

Only seven repositories show work before July, which explains the low volume in the early months. Six of the eight developed applications are still active, and four of them deploy to production: observability-app has stopped and voice-assistant-app is winding down. The applications without features were all created from the template in early August, but feature development has paused so that I can focus on the core services and some customer use cases.

The factory evolved as I worked on these repos. What went into the factory can be traced through a series of milestones.

• In March, skills that had previously lived in individual repositories were collected into one plugin, and repositories began receiving a single HERO.md file describing their local configuration; half the fleet had one by mid-July.
• In late April, the review stage arrived: reviewer agents examine a change before its pull request, and an automated approval check used by every repository either approves the work or sends it back.
• In July, conversations used to clarify an idea began producing written work items.
• In late July, those items gained a standard folder inside each repository, with a roadmap above them.
• In early August, a register of rules that every repository should follow was introduced; its checking engine moved into the plugin in mid-September.
• In mid-August, separate design repositories were replaced by Claude Design projects that agents could read through a tool.
• By the end of August, goals appeared: groups of related work items implemented in successive rounds.
• In mid-September, repositories gained a mailbox through which they could ask one another for changes.
• Soon after, a goal became one branch and one pull request, with a commit for each feature.
• At the end of September, the plugin was refactored for the current harness, the Opus 5.5 model and the best practices then available.³⁴

The sequence is revealing. Context came first, through HERO.md, DESIGN.md (the architecture record) and AGENTS.md. The harness expanded through skills and review. Persistent loops emerged with work items and goals. Fleet-level behavior arrived later, first through a register of rules that every repository should follow and then through inter-repository messages (Diagram 1.6).

The chart of active repositories above shows that observed output growth came from more repositories being active; output per active repository changed much less. (Active means the repositories I was working on at the time.) As a result, I cannot attribute the increase in code delivered to the factory's integration alone. New repositories, changing models, different work and my choices about when to introduce practices all changed at the same time.

The factory is not yet fully autonomous. It is still limited by how many repos I can work on at the same time. The missing part is the trigger. Agents can plan, implement, review and ship within an initiated task, but I still begin every session. Some of that limitation is economic and operational. The factory runs where tokens are plentiful and inexpensive: on my local machine under a subscription. It therefore operates on my schedule. Moving the control plane into the cloud is the next step, provided it can be done without losing the favorable token economics or weakening the security boundary.

By the definition I'm using here, what I have so far is a semi-autonomous factory under construction. I've deliberately put myself on the factory floor, doing some steps by hand even though they could easily be automated. That lets me see what's going on and form a stronger opinion about how those processes should work. The account includes that involvement, so you can see how the factory works with me in it.

Every number in the book comes from traces the factory created while operating: git history, pull requests, CI runs, planning files, design records and agent logs. The study covers March to 1st of October 2026, mostly the sabbatical that began in May, and the data ends on 1st of October 2026. The factory continued to evolve, but the analysis needs a boundary, so all results describe the system as it existed within that period.

It's important to note that the records used in this analysis came from building and running the factory. I analyzed them afterward; I hadn't set up a controlled research project. Git and GitHub cover the whole period, but work items, goals, mailbox events and detailed agent logs only begin later (Diagram 1.8). That means I sometimes have to piece together how things were connected. And I'm interpreting records from a factory I built myself.

This is a case study of one factory and how it changed while I was building and running it. To understand what it produced, I needed to look beyond commits. Commits help you save the code you've written and give you a point to roll back to, but one logical change can be spread across several commits. I use change sets to group the edits into the smallest unit that represents one logical change. The repos started using different parts of the factory at different times, so I compare them based on what they were using when the work was done. I don't assume the factory got better just because time passed, or that a particular change caused a result simply because it came first.

The same rate can mean different things depending on what it counts, so each rate in the book names its measure from this short list:

• Change set: the smallest group of edits that makes one logical change. Counts leave out Dependabot unless they say otherwise.
• Population: a count covers all fifteen repositories unless it says application (the applications only, without the plugin, template and infrastructure), and it says whether Dependabot's pull requests are in it.
• Window: the whole study runs from March to 1st of October 2026; since July starts with week 27; the session-log window runs from late August to 1st of October.
• Human involvement: a pull request counts as reviewed by a person only when I wrote the review myself; reviews my agents posted under my account count as agent reviews, and starting a session or authorizing work is not review.
• Attributable fix (14 days): a later fix or revert on main, sharing at least half of a merged agent pull request's files, judged to repair what that pull request shipped within 14 days.
• Fix within 7 days: a merged pull request whose lines a later fix change set repaired within seven days, traced back through the code's history.
• Rework rate: fixes within 7 days plus the times review or CI sent work back, per 100 change sets.

None of these is customer-facing quality; they are the closest proxies the records allow.

To understand how the factory works, you need to be able to follow a piece of work from the request to what happens in production. That means connecting the work item to its goal, the goal to the agent sessions and change sets, each change to its review and pull request, and the merge to deployment and production health. If you can't tell where a change came from, what it cost or what it did, it's hard to know what to improve. Looking back through these records helped me understand how the factory worked. It also showed me what I should have been recording along the way.

To show that a particular part of the factory made a difference, with the same level of empirical evidence I would expect in an academic journal, I would need more independent applications and a way to compare them while keeping other things from changing at the same time. What I can do here is look at repos that started using the same capability at different times, compare what happened before and after each one started, and see whether their results changed in the same direction. That doesn't tell us how much difference the capability would make in someone else's factory. What I have is a detailed account of one factory as it changed, built and run by me.

Three findings recur through the book. Most of the growth in output came from having more active repositories, not from more work per repository. Agents planned, built, reviewed and shipped within work that I started, but I still began every session. A fleet-wide fix wasn't done when the source repository merged; it was done when every consumer had updated or recorded an exception. The measurements cover the engineering work and the operation of the factory, not whether customers benefited or whether the studio is commercially viable.

The rest of the book follows the factory’s work and then steps back to reconstruct the system (Diagram 1.4).

Chapter Two asks who guides the work. It covers how work is defined, what agents discover for themselves, how related items become a plan and where trust places the person.

Chapter Three examines how work is done. Its subject is the context surrounding the model: the harness, instructions, memory, design, architecture, external connections and messages between repositories.

Chapter Four asks how the work ships, following it into production. It defines the unit the book counts, examines tests and review, considers the boundaries of autonomy and follows a change through deployment.

Chapter Five addresses the problem added by the fleet: how applications that share templates, services, infrastructure and design remain consistent. It treats drift, conformance and eventual consistency as observable work.

Chapter Six enters the control room. It covers observability, infrastructure and cost, the method used to analyze a changing factory, and the improvement flow through which failures alter guides and checks.

Chapter Seven puts the pieces together as an architecture, proposes an order in which to build them, and describes what I am building next: a system of record for the factory, and moving its work off one workstation. Chapter Eight pulls the book together: how to think about a software factory, some of the insights, how far the evidence goes and what is likely to transfer to another factory.

Where I had a clear expectation before looking at what happened, I say what it was, and where the data went against it, that's part of what I learned. I describe the questions in terms of templates, work items, automated checks and apps built from other apps. That way, you can ask the same questions about your own factory, even if you're using different products and models.

Chapter Two begins where all software work begins: with the decision about what should be built, and with the boundary between the person who wants it and the agents that make it real.