Software Factory: Manufacturing Discipline in the Age of AI

A manufacturer would not accept a production process in which every batch is assembled differently, inspection happens only at the end, and nobody can identify which revision was shipped. Yet software changes can feel exactly like that: a one-off installation, a last-minute integration fix, and an update that depends on one person remembering the right steps.

This is how we think about software development at VIAR: not as a succession of isolated coding tasks, but as a production process. The idea behind a software factory is to bring repeatability, traceability and feedback to that process. The comparison has limits. Software is not stamped out like identical components. Teams still need to understand users, make design decisions and solve new problems. What becomes repeatable is the path from a proposed change to a working, supported release.

Software factory: a practical definition

A software factory is an organized way of developing and delivering software that combines a team, shared tools, automated checks and a repeatable release process. It covers more than writing code: the team also needs a way to build it, test it, check its dependencies, deploy it and learn from its behavior in use.

The term appears prominently in defense and cloud-native software engineering. The U.S. Department of Defense Software Modernization Strategy puts software factories within a broader effort to deliver software iteratively through DevSecOps. In plain language, DevSecOps means bringing development, security and operations into the same delivery process rather than treating them as separate handovers.

You do not need to adopt a defense organization’s terminology or infrastructure to ask the underlying question: can your software team deliver a small change through a known, verifiable process?

Software factory vs. smart factory

These terms describe different things. A smart factory connects physical production, people and information. A software factory organizes the delivery of software that may support that operation.

A software factory is also not the same as a software-defined factory, which concerns using software to configure or control production capabilities. Nor is it simply another name for an outsourced development company: a supplier may use the label, but the label alone tells you little about how its releases are managed.

What happens inside a software factory?

Tools vary, but a useful delivery process answers six questions.

1. What problem are we solving? A change starts with an understood user need and acceptance criteria. Automating delivery cannot rescue a feature that solves the wrong problem.
2. What changed, and who reviewed it? Version control records changes; review gives another person a chance to challenge assumptions before those changes reach users.
3. Can we build and check it consistently? Continuous integration, or CI, runs builds and automated tests when changes are integrated. Tests should cover important behavior, not just whether the application starts.
4. Can we trust the release? Security checks, dependency review and identifiable release packages help establish what is being shipped and where it came from.
5. How will it reach the customer? The release follows a documented path through suitable test environments, approval steps and deployment procedures. Continuous delivery does not require every change to go directly into production.
6. What happens after deployment? Monitoring, support feedback and recovery procedures close the loop. Delivery is not finished simply because an installation succeeded.

The CNCF’s Secure Software Factory reference architecture emphasizes defense in depth, signing and verification, artifact metadata analytics, and automation. That is a useful reminder: speed is only one part of the model. Knowing what you released, and being able to verify it, matters too.

What manufacturing teaches us about developing software

A well-run plant does not measure success only by how fast a machine moves. It cares about whether the right product leaves the line, whether it meets requirements, and whether the process can sustain that quality. We apply that same mindset to software: writing code is one operation, not the finished product.

• A production specification becomes an understood requirement. Before making something, establish what it must do and what counts as an acceptable result.
• Quality gates become reviews and tests. Check the work along the way rather than asking the customer to discover every problem after delivery.
• Batch traceability becomes version and release history. Know what changed and what was delivered, so a problem can be investigated rather than guessed at.
• Standard work becomes a repeatable delivery process. Routine steps should not depend on someone remembering an undocumented sequence.
• Continuous improvement becomes a feedback loop. What happens in actual use should inform the next change, not disappear at the end of the project.

The analogy does not mean eliminating engineering creativity. Standardizing the repeatable work gives people more room to solve the problems that genuinely need judgment.

Why AI makes the software factory more important

AI coding tools can draft functions, suggest changes and help create tests. That changes how quickly a team can produce candidate code. It does not automatically establish that the code meets a customer’s requirements, fits the existing architecture or behaves safely in production.

Think of adding a faster machine to a plant. If inspection, material flow and downstream operations cannot keep up, increasing its output may simply create more work in progress or more rework. The same risk exists in software: faster code generation can move the bottleneck from writing to understanding, reviewing and validating.

GitHub’s guidance on reviewing AI-generated code emphasizes human oversight and testing. Its responsible-use guidance also warns that generated suggestions may be incorrect or contain vulnerabilities. Plausible code is not the same as verified code.

For us, the implication is straightforward: the more easily code can be produced, the more important the process around it becomes. An AI-assisted change should still have an understood purpose, an accountable reviewer, relevant tests and a controlled route to release. AI can help at those stages, but it should not be the sole judge of its own output.

This is not an argument against AI. It is an argument for putting AI inside an engineering process. The useful measure is not how much code was generated, but whether a working change reached users without creating avoidable problems. A software factory turns additional coding capacity into a delivery capability rather than just a larger queue of changes.

Why this matters on the shop floor

Manufacturing software operates within constraints that a generic feature demonstration may not reveal. A workstation might be shared across shifts. Network access might be limited. An integration may depend on a particular version of another system. A change that works in a developer’s environment can still disrupt a real workflow.

Consider a hypothetical update to a connected worker application. The change adds a required confirmation before an operator completes an instruction. The screen looks correct, but does it preserve an unfinished task? Does it behave correctly for different permissions? Does an existing integration still receive the expected completion event?

A controlled delivery process gives the team a place to test those questions before rollout, record the release version, and prepare a recovery plan. It does not guarantee zero defects. It makes the checks and responsibilities explicit instead of relying on memory.

There are also two distinct kinds of revision to manage: the application release and the work instruction content. Updating the software is not the same as approving a changed production procedure. Manufacturers need clear ownership for both.

Five questions to ask a manufacturing software supplier

• How do you test our critical workflows? Ask about permissions, integrations and interrupted work, not only a list of automated testing tools.
• What is the release and approval process? Establish who schedules changes, what notice you receive, and whether you can validate them before rollout.
• How are dependencies and security updates managed? Look for an explained process and clear responsibilities rather than a blanket promise that the system is secure.
• What happens if an update fails? Recovery may involve more than reverting code. Ask how configuration changes and database changes affect rollback or restoration.
• Who supports the system after go-live? Agree on ownership, escalation and the information needed to investigate an incident in your environment.

The right answers depend on your production risk, infrastructure and operating requirements. A cloud service and a locally hosted installation may need different release arrangements. The important point is that those arrangements are understood before they become urgent.

Start with one delivery path, not a shopping list

For manufacturers developing their own software, a practical first step is to map one application’s path from request to production. Identify the manual handovers, undocumented configuration and checks that only one person knows how to perform. Then improve that path incrementally.

Choose a representative change. Define how it will be reviewed, tested, packaged, deployed and supported. Automate the repetitive steps where doing so reduces mistakes. Keep human approval where the operational risk requires it. Measure outcomes such as failed releases, recovery time and the time a change spends waiting between steps.

Buying a collection of tools is not the same as establishing a software factory. Neither is adding AI-generated code. Both can assist a team, but neither replaces an understood workflow, meaningful tests or accountability for what reaches production.

Where VIAR and REWO fit

VIAR develops software for digitizing manufacturing knowledge and standardizing production processes. REWO, our connected worker and manufacturing knowledge platform, supports work instructions, knowledge transfer, training and operational guidance.

REWO is not a software factory tool: it helps manufacturers manage the knowledge used in production, rather than build and release application code. The connection is the principle of repeatability. Clear, maintained guidance matters for the people performing the work, just as a clear delivery process matters for the people maintaining the software.

If your immediate challenge is outdated paper procedures or expertise that is difficult to share, start with our guide to moving from paper to digital work instructions. If you are evaluating a broader manufacturing software project, put release management and support alongside the feature checklist.

Looking to make manufacturing knowledge more consistent and accessible? Talk to the VIAR team about your production workflows.