Continuous Engineering: a manifesto for software factories
Coding agents are expanding the range of engineering work that software can perform. They can investigate failures, implement changes, review code, and carry out releases within defined boundaries. As these capabilities improve, more of the process through which we build software becomes executable.
I believe this changes what we need to engineer.
Alongside the software we deliver, we need to design the system that delivers it: how work enters, how it moves, how it is checked, where people intervene, and how we learn from the result.
That is what I believe a software factory should be. And the discipline of building and improving it is what I call Continuous Engineering.
The machines are finally on the floor
Software engineering has spent years learning from manufacturing. Lean gave us ways to think about flow, waste, quality, and continuous improvement. Small batches shorten feedback loops. Limiting work in progress exposes bottlenecks. Finding defects at their source saves the work of carrying them downstream.
Agile reinforced the importance of the people doing that work. Its manifesto explicitly put individuals and interactions first. Engineering depended on people interpreting problems, negotiating tradeoffs, and adapting their approach as they learned. The Agile Manifesto.
We already had machines on this factory floor. Compilers, test runners, build systems, and deployment pipelines performed increasingly large parts of the work. Agents extend automation into activities that require interpretation: investigating a vague bug report, navigating an unfamiliar codebase, or deciding how to implement a change.
This makes lean thinking more consequential.
An agent can produce changes faster than a team can review them. A fleet of agents can fill a backlog with plausible fixes that nobody has time to validate. Increasing output at one stage can leave the rest of the system overwhelmed.
Toyota’s production system offers a useful principle here. Jidoka combines automation with the ability to detect abnormalities and stop the process. Quality is built into the work, and people respond where their judgment is needed. Toyota Production System.
A software factory needs that discipline. It must recognize when to continue, when to repair, and when to stop and ask for help.
The engineering process itself becomes something we can describe, run, measure, and improve.
The factory is the whole lifecycle
A software factory is the collection of automated processes through which a team delivers its work, together with the checks and human decisions that connect them.
Turning a ticket into a pull request is one of those processes. Reviewing a change is another. So are investigating an incident, designing a system, running quality assurance, preparing a release, updating documentation, and answering a support request.
A factory can begin with any one of them. Its scope grows as the team learns which work it can formalize and automate.
Today, there are several ways to build these processes.
A skill on a laptop is a useful starting point. It captures knowledge close to the engineer using it and makes experimentation cheap. On its own, though, it depends on that person’s environment and availability. Shared measurement, unattended execution, and reactions to external events require additional infrastructure.
CI systems provide a foundation for running work remotely. They already offer jobs, logs, secrets, and triggers. But a process that needs to wait for a conversation, resume an investigation, repair its own execution, or coordinate several agents requires more machinery around the job runner.
Some companies build that machinery themselves. Uber describes managed agents handling code review, CI repair, end-to-end pull requests, on-call triage, debugging, and maintenance. It also routes tool access through a shared gateway for authentication and policy enforcement. That breadth represents a substantial engineering system. Uber’s software factory.
These approaches often coexist inside one organization. Each can produce excellent results. The difficulty appears between them.
Consider a customer reporting a broken export. A support bot gathers details. An investigation script searches logs. A coding agent prepares a patch. CI validates it. A reviewer requests changes. A release process deploys the fix. Someone returns to the customer with an answer.
Each part may work well, while passing context, tracking progress, recovering from failures, and measuring the complete outcome remain manual.
There is also an organizational tension. Central ownership can become a queue that every team must pass through. Independent ownership can leave each team rebuilding execution, integrations, permissions, and measurement.
Across these processes, much of the underlying engineering problem is repeated.
Continuous Engineering
Continuous delivery gave us a practical way to improve fragile integration and release processes.
Make the work repeatable. Reduce batch sizes. Shorten feedback loops. Build quality into the process. Automate repetitive operations and keep improving the system. These remain central principles of continuous delivery. Continuous delivery principles.
The same discipline applies more broadly.
A difficult review process benefits from explicit criteria and earlier feedback. An unreliable investigation benefits from consistent access to evidence. A support handoff benefits from clear ownership and a record of what has already been tried.
This ambition has a history. Brian Fitzgerald and Klaas-Jan Stol’s work on Continuous Software Engineering argued for continuity across business strategy, development, and operations. The disconnects between those activities were already visible long before coding agents. Continuous software engineering: A roadmap and agenda.
AI expands how much of that connected process we can execute automatically. Activities that previously needed a person to interpret every input can now, in suitable conditions, be delegated to an agent.
I use Continuous Engineering to describe the practice of making engineering processes explicit, executable, observable, and continuously improvable, from intent through production and back through user feedback.
Building the factory begins with describing the process.
What starts the work? What context does it need? What outcome should it produce? How do we establish that the outcome is acceptable? What happens when it fails?
We do not need to prescribe every action an agent will take. We need to describe enough of the surrounding process to operate it deliberately.
That description becomes an engineering artifact. It can be versioned, reviewed, tested, and changed alongside the software it helps produce.
Workflows and agents
I find it useful to distinguish two responsibilities inside a software factory: executing a process and interacting with the people who use it.
Workflows provide the execution structure.
A workflow describes how a piece of work proceeds: its stages, inputs, checks, possible routes, and conditions for completion. Some steps invoke conventional software, such as a test runner or deployment tool. Others ask an agent to investigate, design, implement, or review.
The workflow can branch. It can return a failed change for repair. It can wait for approval or escalate after a bounded number of attempts. Its structure makes the work understandable even when individual steps involve uncertain reasoning.
It produces an outcome: a pull request, a design document, a support response, or a verified change to a running system.
Interactive agents provide a way for people to reach and steer that work.
They help clarify a request, gather missing context, explain progress, and decide how to proceed. They may handle a small task directly or delegate to a workflow or another agent.
In the factory analogy, workflows resemble production lines, while interactive agents resemble floor managers. The distinction concerns their responsibility. Agents can also operate inside workflows, and events can start workflows without a conversation.
Return to the broken export. A support agent asks the customer for an example and establishes the impact. It starts an investigation workflow that gathers logs and reproduces the failure. A fix workflow implements a change, validates it, and prepares it for review.
The support agent remains available to answer questions and receive new information while that work proceeds.
Workflows make execution legible. Agents make the factory accessible. Both should contribute to the same record of what happened.
Measure, then improve
An explicit process gives us something we can investigate systematically.
Suppose we believe a different model will produce better fixes. Or that an additional validation step will reduce review failures. Or that a shorter prompt will lower cost without affecting quality.
Each change is a hypothesis. We should be able to test it.
That requires evidence from execution. Every run should preserve the relevant workflow version, inputs, environment, actions, tool results, artifacts, checks, and human interventions. We need enough context to understand a result and make a meaningful comparison later.
A conversation transcript alone cannot tell us whether a fix worked. We need to know what it changed, what verification passed, whether a reviewer accepted it, and what happened after release.
The measures should follow the outcome:
- Did the work solve the intended problem?
- How much correction or rework did it require?
- How long did it take, including time spent waiting?
- What did execution cost?
- How much human attention did it consume?
For the export bug, producing a pull request is an intermediate result. The useful outcome is a working export and a customer whose problem has been resolved.
This matters because local improvements can conceal downstream costs. A faster implementation step may create a longer review queue. A cheaper model may require more repair attempts. An additional check may consume time while preventing an expensive failure.
Comparisons need representative tasks, consistent acceptance criteria, and a baseline. Agent behavior varies between runs, so important decisions require more evidence than one successful attempt. Production feedback must then tell us whether the improvement holds outside the benchmark.
Once this exists, the factory can assist in improving itself.
Recovery happens within a run. A workflow retries a transient failure, repairs a broken environment, or asks for help when it cannot proceed.
Improvement happens across runs. The system identifies a recurring failure and proposes a change to the process.
Suppose fixes for export bugs repeatedly pass unit tests but fail review because they overlook malformed input. An agent examining those runs might propose a reproduction step or a new validation requirement. We can evaluate that proposal against past failures and a separate set of representative tasks, then observe its effect in production.
The proposed improvement becomes a reviewed change to the factory. Its evidence should be available to the people deciding whether to adopt it.
Self-improvement becomes an engineering practice with hypotheses, tests, and accountable decisions.
Keep the lights on
Human involvement belongs in the design of the factory.
People decide which problems matter. They interpret conflicting needs, make architectural tradeoffs, and judge whether an outcome serves its purpose. They also build, observe, and improve the factory itself.
Some work remains exploratory. A developer working locally with an agent may learn more through a few minutes of experimentation than through a formal workflow. A team discussing a design may need room to change the question entirely.
The factory should support that work and provide clear ways to hand it off when a repeatable process becomes useful.
Different organizations will also choose different boundaries for autonomy. A documentation update, an internal maintenance task, and a production infrastructure change carry different consequences. Each team needs to decide where verification is sufficient and where explicit approval is required.
Those decisions should be visible in the process. People should be able to inspect progress, pause further actions, provide new context, and take over the work.
A human checkpoint also needs to be usable. It should present the decision, the relevant evidence, and the consequences of proceeding. Asking someone to approve a change without giving them the means to judge it creates little control.
I expect this work to become an increasingly important engineering responsibility: factory engineering.
It grows naturally from platform engineering and developer experience. Its subject is the system that performs engineering work, including the quality of its outputs and the effort required to operate it.
Some organizations will have dedicated teams. Others will distribute the responsibility among existing engineers. Either way, improving the factory requires deliberate ownership.
Describe the process, standardize the engine
A team’s processes contain its knowledge.
They express how the team investigates failures, what it considers a good design, which checks establish confidence, who can approve a change, and what customers need to hear.
That is where teams should be able to invest their effort.
Underneath those processes sits a recurring set of infrastructure needs. Work must execute in a suitable environment. It must survive interruptions, connect to tools, respect permissions, preserve evidence, and support evaluation. People need ways to interact with it and understand its state.
I believe these foundations should become reusable infrastructure.
CI/CD made an important separation practical: teams could describe their automation in code while adopting a system that handled execution. A new pipeline inherited capabilities that its author did not have to build again.
The broader software lifecycle needs the same opportunity.
A common engine can support independently owned workflows and agents. A support team can change its investigation process. A product team can improve its implementation workflow. A platform team can maintain shared execution and policy. Each can work within an agreed set of interfaces and guarantees.
A new workflow would inherit execution records, access controls, recovery mechanisms, and evaluation tools. Its domain logic and acceptance criteria would still require care.
This also gives us a more useful meaning of a unified factory. Existing tools can remain part of the system. Work can begin in chat, a ticket, an alert, or a local development session. The connections between those surfaces should preserve context, ownership, and evidence.
Teams gain autonomy because they can change their own processes quickly. They gain control because execution remains visible and governed across the factory.
The factory can grow one process at a time, with each addition building on foundations that are already there.
Principles
These are the principles I would use to build a software factory:
- Treat the whole lifecycle as the system. Implementation, review, investigation, release, and feedback all contribute to the outcome.
- Make processes explicit. Describe their objectives, boundaries, checks, and handoffs so they can be operated and improved deliberately.
- Give workflows structure and agents room to act. Combine defined execution with interpretation and interaction where they are useful.
- Make every run leave evidence. Preserve enough context to understand the outcome and evaluate future changes.
- Treat process changes as experiments. Establish a baseline, test the hypothesis, and follow the result into production.
- Measure what reaches people. Include quality, rework, elapsed time, cost, and human attention.
- Keep the lights on. Humans own intent, judgment, and the boundaries of acceptable risk.
- Share the foundations and own the processes. Give teams the means to shape how they work on infrastructure they can trust.
The factory should become more capable with use. Each completed task, failed attempt, and human intervention gives us something to learn from. Continuous Engineering is the practice of turning that evidence into a better way of working.