The Software Factory: From Infrastructure to Autonomous Development
I virtualized everything in 2024 and thought I had built the future. I had not. I had only poured a better concrete floor, and the factory was still missing.
TL;DR: My 2024 VMware migration upgraded the foundational compute hardware. A Software Factory is the automated assembly line running on top of that compute. OpenCode and Meta’s Muse Spark 1.3 are worker units and engines, while Warp is trying to build the cloud orchestration management suite that controls the workers.
VMware virtualization modernizes where code lives by pooling physical hardware into elastic virtual compute. A Software Factory automates how code is created, tested, secured, and shipped across that compute.
| Layer | Question it answers | Example | What I had in 2024 |
|---|---|---|---|
| Infrastructure virtualization | Where does code run? | Bare metal to VMware vSphere, shared hardware pool, dynamic allocation | Yes — modernized base layer |
| Software Factory | How is code built and shipped? | Git to automated testing to hardened deployable artefact | No — still manual handoffs |
| AI-Powered Factory | Who writes the code? | Human prompt to agent swarm to autonomous delivery | No — experiment stage |
What I Actually Did in 2024
I led infrastructure for a Singapore defence-adjacent organisation through a classic refresh. Rows of single-purpose physical servers became a VMware Cloud Foundation pool with dynamic resource allocation and modernized operations.
The win was real. Provisioning went from weeks of procurement to minutes of cloning. Patching became centralized. Utilization climbed because idle hosts could finally share load.
The confusion was also real. Stakeholders called it a software factory because everything looked modern. It was not. It was infrastructure virtualization, the concrete floor. No code moved faster because of it. No release became safer by default.
| Before: bare metal | After: VMware pool |
|---|---|
| Physical servers, one role per box | Shared hardware pool, many workloads per cluster |
| Manual provisioning and high maintenance | Template cloning and centralized lifecycle |
| Scaling means buying hardware | Scaling means carving allocations |
| Failure domain is the box | Failure domain is the cluster policy |
The lesson stuck with me. Modernized operations are not the same as automated production. One gives you somewhere to run. The other gives you a way to ship.
What a Software Factory Actually Is
The modern definition has been stable since about 2018. A Software Factory is an automated, repeatable, secure pipeline for software production. The key is process automation over infrastructure.
Think conveyor belt, not server rack. Code enters at one end. Tested, scanned, packaged artefacts exit at the other. Humans supervise gates. Machines do the carrying.
Inputs are boring on purpose. A Git repository, a repeatable build script, a test suite that actually runs. Boring inputs are what make outputs trustworthy.
The middle is where factories live or die. Deployment automation removes snowflake servers. Automated testing catches regressions in minutes. Build and package produce reusable software components instead of one-off zips. Security testing is a gate, not a memo.
| Stage | What it guarantees | What breaks without it |
|---|---|---|
| Code repository | Every change is tracked and reviewable | Mystery binaries nobody can rebuild |
| Deployment automation | Same steps in dev, staging, prod | Works on my machine releases |
| Automated testing | Regressions fail the line | Bugs discovered by users |
| Build and package | Immutable container images | Configuration drift per host |
| Security testing | Known CVEs block the conveyor | Vulnerable images shipped silently |
| Deployment automation | Rollouts are reversible | 2am manual restarts |
Outputs compound. Containers, microservices, and deployable applications stack into libraries the next team reuses. That compounding is the whole economic argument for the factory model.
Engine, Harness, and Factory Manager
Here is where my daily terminal stack meets the Panel 3 vision. Break the ecosystem into three roles. It stops the vendor noise fast.
| Role | Analogy | Examples | What it controls |
|---|---|---|---|
| Engine | Brain | Muse Spark 1.3, Gemini, Claude | Reasoning, tool-call decisions, 1M-context recall |
| Harness | Hands | OpenCode, Muse Code, Cursor | File reads, terminal commands, diffs, local loop |
| Manager | Foreman | Warp, Copilot Workspace, Devin | Fleet of agents, queues, cloud runners, PR flow |
| Floor | Concrete | VMware, bare metal | CPU, memory, network, sovereignty boundary |
Muse Spark 1.3 Is the Engine
Muse Spark 1.3 has no visual UI of its own in my workflow. It receives file contents, terminal logs, and prompts, then outputs structured tool-calling decisions like editing a policy file or running a test suite.
The power is context and reasoning. A 1M-context multimodal core can hold an entire service in working memory. That matters for cross-file refactors where a smaller model loses the plot halfway through.
The limit is also clear. An engine without a harness cannot touch anything. It proposes. It does not execute. That separation is a safety feature I want to keep.
OpenCode Is the Harness
OpenCode runs inside my terminal and gives the engine hands. It reads local Git files, executes shell commands, shows diffs, and loops until tests pass. I drive it from Kitty and Konsole on Linux.
The win is modularity. Today the engine is Muse Spark 1.3. Tomorrow it can be Claude or local weights. The harness stays constant. My muscle memory, keybindings, and audit trail survive the swap.
The win is locality. Code never has to leave the machine for the loop to work. For regulated or defence-adjacent work, that property alone keeps the local harness relevant even as cloud factories get louder.
Warp Wants to Be the Orchestrator
Warp Factories want to spin up dozens of headless agent loops in the cloud. A bug report lands in Jira. The orchestration engine triggers an agent using a frontier model, writes code, runs tests in CI, and opens a pull request.
The pitch is scale. Instead of one developer driving one OpenCode loop, you supervise a fleet. Humans move from typing code to reviewing agent output and owning architecture.
The incumbents see the same prize. Devin sells autonomous task completion. GitHub Copilot Workspace pushes from autocomplete toward task-level delivery. Cursor blends local speed with cloud agents. Panel 3 is a land grab for the entire development lifecycle, not just the editor.
Three Counter-Arguments I Have to Answer
An honest factory post needs its failure modes. These are the three I would demand from anyone pitching a 2026+ autonomous standard.
| Counter-argument | Panel 2 truth | Panel 3 risk | My mitigation |
|---|---|---|---|
| Data sovereignty versus cloud factories | Pipelines can run air-gapped | Warp and Devin backends want your AST and codebase | Keep harness local for sensitive repos, trial cloud loops only on public code |
| Determinism versus non-determinism | Same commit gives same artefact | Probabilistic agents rewrite the build chain | Pin agents behind deterministic gates: tests, SAST, signed images, human approve |
| Maintenance-debt trap | Humans write slowly, review carefully | Agents generate faster than teams can review | Treat review capacity as the bottleneck, throttle spawn rate, own architecture |
Sovereignty is non-negotiable. Defence and air-gapped environments cannot stream source to external orchestration backends. The local Engine plus Harness pattern is not nostalgia. It is the only compliant shape for that data class.
Determinism must be preserved. Classic CI gives reproducible builds. Agent output is probabilistic by nature. The fix is layering: let agents propose inside a deterministic factory that still signs, scans, and blocks.
Review is the new bottleneck. Autonomous output shifts toil from writing code to verifying architectural integrity. If you spawn fifty loops with two reviewers, you built a debt machine. Throttle concurrency to review bandwidth.
Where I Am and What Comes Next
I built the floor in 2024. The conveyor is the current gap. Autonomy is a controlled experiment, not a migration.
First, finish the classic factory. Versioned source, automated tests that gate merges, containerized packaging, security scans that block, progressive deployment with rollback. No agents needed for this payoff.
Second, run one local autonomous loop. OpenCode plus Muse Spark 1.3 on a non-sensitive repo. Measure review time, defect escape rate, and rollback frequency. Write down the numbers before scaling.
Third, evaluate Warp as orchestration, not magic. Ask where code executes, where logs persist, what leaves the boundary, and how you revoke a fleet. If a vendor cannot answer those plainly, they are not ready for regulated work.
I built the floor in 2024. The factory comes next.