Continuous Engineering: when code is cheap, the factory is the asset

Every software team will soon engineer two systems: the software it delivers, and the factory that delivers it.

Agents now handle the work in between: investigating, implementing, reviewing, releasing. Once that work can run, the way a team works becomes software too.

That factory is where a team’s knowledge will live. As code gets cheaper to produce, it’s also where its leverage will be.

Building and improving it is a discipline of its own. I call it Continuous Engineering.

Your process is becoming code

Every team already has a factory. It’s just mostly invisible.

It lives in how the team triages a bug report, in the checks a senior reviewer runs in their head, in the release checklist on a wiki page, in the Slack thread where someone remembers how the last incident was fixed. It’s real and valuable, and almost none of it can be run.

Agents change that. They can now do work that requires interpretation, so the process connecting that work can be executed too. Once it can run, it can be engineered.

So the process becomes code. It gets versioned, reviewed, tested, and deployed. Changing how your team investigates a failure becomes a pull request.

This continues a familiar path. We turned servers into infrastructure as code. We turned release checklists into pipelines as code. Next, the engineering process itself becomes code.

Code is cheap. Your standards aren’t.

Agents write code, refactor it, migrate it, and rewrite it, faster every month.

What stays scarce is knowing what good looks like on your team: how you investigate a failure, what makes a design acceptable, which checks you trust before shipping. Agents can’t guess that. Someone has to make it explicit.

Today that knowledge is fragile. It depends on someone remembering it, and it leaves when people do. In a factory, it becomes part of how the work runs: the same checks, applied to every change, whether a person or an agent made it.

Your codebase still matters. But more and more, it’s the output. The factory is what produces it.

The risk is just as real. A bad process, once executable, repeats its mistakes consistently and at scale. A factory is never finished. Like any production system, it has to be observed, measured, and corrected.

Faster agents, bigger pile-ups

Manufacturing learned long ago that making one machine faster doesn’t make the factory faster. It just moves the pile-up to the next station.

Agents bring that lesson to software. An agent can write changes faster than a team can review them. A fleet of agents can fill a backlog with plausible fixes nobody has time to check.

Making people the checkpoint for everything doesn’t scale. Verification has to become part of the factory too: reproducing the problem, testing the fix, applying the team’s review criteria.

A factory that checks its own work needs one more ability: knowing when to stop.

Toyota calls this jidoka. Sakichi Toyoda’s looms stopped themselves when a thread broke. Workers no longer had to watch every machine; they stepped in only when one stopped. The idea became a pillar of the Toyota Production System: automation that detects a problem, halts the line, and calls a person to fix the cause.

A software factory needs the same reflex: continue when the work is sound, repair what it can, and stop to ask for help when it can’t.

Every step works. The handoffs don’t.

Turning a ticket into a pull request is one process. So are reviewing a change, investigating an incident, designing a system, running QA, preparing a release, updating documentation, and answering a support request. The factory is all of them, plus the checks and human decisions that connect 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 goes back to the customer with an answer.

Each step may work well on its own. But passing context between them, tracking progress, and measuring the result are still done by hand.

Today, teams build pieces of this factory in three ways:

• Skills on a laptop. Quick to create, but they only run when that engineer is around.
• CI jobs. They run unattended, but they’re built for short tasks, not work that waits for a reply, picks up later, or coordinates several agents.
• In-house platforms. Uber, for example, runs agents for code review, CI repair, on-call triage, and more. Powerful, but a major engineering investment.

Most organizations end up with a mix. Each piece can work. The trouble is between them: context gets lost, nobody owns the handoffs, and nobody measures the whole.

Workflows run the work. Agents talk to people.

Workflows define the steps of a task, the checks between them, and what to do when something fails. Some steps run tools, like a test suite. Others give a task to an agent. You can see exactly where the work stands at any moment, even while an agent improvises inside a step.

Interactive agents take requests from people, ask for missing details, report progress, and start the right workflow.

Back to the broken export. A support agent asks the customer for an example. It starts a workflow that reproduces the bug, then another that writes and tests the fix. Meanwhile, the agent keeps answering the customer, and every step goes into the same record.

Output is not the outcome

For the export bug, a pull request is only a step along the way. The outcome is a working export and a customer whose problem is solved.

Most teams count agent output: PRs opened, tasks closed, lines written. Agents make output cheap, so those counts say less and less about whether the work mattered. Measure the outcome instead:

• Did it solve the problem?
• How much rework did it need?
• How long did it take, waiting included?
• What did it cost?
• How much human attention did it use?

Measure the whole line, not one step. A faster implementation step can create a longer review queue. A cheaper model can need more repair attempts. You only see these tradeoffs end to end.

That takes evidence. Every run should record what it did: the workflow version, the inputs, the actions, the checks, and every human intervention. Then follow the change past the merge. Did review accept it? Did it hold up in production?

With that record, every change to the factory becomes an experiment. A new model, an extra check, or a shorter prompt is a hypothesis. Compare it to a baseline on real tasks, run it enough times to rule out luck, and confirm the result in production.

The factory improves with use

Once runs leave evidence, the factory can help improve itself. Two different things happen here.

Recovery happens within a run. A workflow retries a transient failure, repairs a broken environment, or stops and asks for help.

Improvement happens across runs. The system notices a recurring failure and proposes a change to the process.

Say export fixes keep passing their tests but failing review, because they break on malformed input.

An agent reviews those runs and spots the pattern. It proposes a fix to the process: test malformed input before writing the patch.

The proposal is tested against the past failures. If it would have caught them, it becomes a pull request to the factory, with the evidence attached. A person decides whether to merge it.

This is self-improvement as an engineering practice: hypotheses, tests, and accountable decisions, not an unsupervised loop. Every completed task, failed attempt, and human correction becomes material for a better process.

People own the factory

Agile put individuals and interactions first, and it was right to. The factory doesn’t change that. It takes repeatable work off people’s plates so their judgment goes where it matters.

People decide which problems matter, make the tradeoffs, and judge whether the result is good. Some work stays exploratory, like an engineer experimenting with an agent or a team rethinking a design. When a pattern repeats, it can become part of the factory.

Each team decides how much autonomy to give. A docs update and a production infrastructure change don’t carry the same risk. Those limits belong in the process, written down and versioned. At any point, people can check progress, pause the work, add context, or take over.

When the factory asks someone to approve a change, it must show them what they’re deciding, the evidence behind it, and what happens if they say yes. Otherwise the approval is a signature, not control.

Factory engineering becomes a job

Someone has to build, run, and improve the factory. That’s a new responsibility: factory engineering.

It grows out of platform engineering and developer experience. Its subject is the system that performs engineering work: the quality of what it produces, and the effort it takes to run.

I expect it to become a recognized role, the way platform engineering did. Some organizations will have dedicated factory teams. Others will spread the role across engineers. Either way, the factory needs an owner.

Own your processes. Share an open engine.

Under every team’s processes sits the same set of infrastructure needs. Work has to run in a suitable environment, survive interruptions, connect to tools, respect permissions, keep evidence, and support evaluation. People need ways to interact with it and see its state.

Teams shouldn’t have to rebuild that from scratch. CI/CD made a key separation practical: teams describe their automation in code while a shared system handles execution. Every new pipeline gets capabilities its author never had to build.

The whole engineering lifecycle needs the same separation. On a common engine, a support team changes its investigation process, a product team improves its implementation workflow, and a platform team maintains shared execution and policy, each within agreed interfaces and guarantees. A new workflow automatically gets execution records, access controls, recovery, and evaluation. Its domain logic and acceptance criteria still need care, and that’s where teams should spend their effort.

I expect that engine to become standard infrastructure, the way CI/CD did. And it should be open. If your processes hold your team’s knowledge, the system that runs them is the foundation of that knowledge. You should be able to read it, run it where you need it, and extend it, not rent it as a black box.

Principles

1. Make the process explicit and executable. What your team knows should run, not just be remembered.
2. Treat the whole lifecycle as the system. Speeding up one stage just moves the pile-up.
3. Build verification and stopping conditions into execution. A factory must know when to halt and ask for help.
4. Make every run leave evidence. A run you can’t inspect is a run you can’t improve.
5. Measure the complete outcome. Quality, rework, elapsed time, cost, and human attention.
6. Evaluate every change to the factory. Each one is a hypothesis with a baseline.
7. Give people informed control. People own intent, risk, and the final call, with the evidence to make it.
8. Share an open engine; own your processes.

This is the future I’m building Shipfox for: an open-source, MIT-licensed engine on which teams can build, operate, and improve their own software factories.