There is one metric that matters in software: did the idea ship as a live, running product?
Not a prototype. Not a demo. Not a repository with a promising README. A working system, deployed, used. Everything else is work in progress.
This sounds obvious. It isn’t. Most of the industry is optimizing for the wrong things — generating code faster, writing tests automatically, producing documentation on demand. These are useful. They are not the goal.
The goal is: IDEA → Live Product. A straight line… a factory line.
The Solo Agent Trap
There’s enormous excitement right now about AI coding tools. Agent loops. Computer-use models. One AI, one machine, one context window, building software end to end.
I respect the tools. I challenge the paradigm.
A single agent on a single machine doesn’t scale for complex software. Real projects have thousands of decisions, hundreds of files, multiple systems, weeks of coordinated work. You cannot fit that in a prompt. You cannot route that through one context window. And you cannot recover gracefully when it halts halfway through a migration at 2am.
Solo agents are remarkable for tasks. They are not a factory.
Process: Vibecoding Doesn’t Scale
The software industry learned — slowly, painfully — that discipline in the build process matters. Not bureaucracy. Discipline. Stages. Handoffs. Quality gates. A shared understanding of how the thing gets made.
“Vibecoding” — the practice of prompting an AI, accepting what it produces, and shipping it — works for a script, a side project, a quick prototype. It does not work for systems that need to be maintained, extended, or handed off. It produces output that no one fully understands, that breaks in non-obvious ways (or sometimes really obvious — if you know what to look for, operative word is KNOW), and that compounds technical debt at machine speed.
Understanding how software is manufactured — not just produced — is the baseline. The factory needs a process. The process needs to be understood by the people running it.
People: M-Shaped or Bust
You may need fewer people to build software now. That’s real.
But fewer people doesn’t mean less capability. It means more capability per person. The humans who remain in the loop need to be M-shaped — wide across domains, deep in multiple areas. Not a generalist who skims. Not a specialist who can’t zoom out. Both. The hybrid.
The M-shaped engineer understands the product and the infrastructure. They can write a prompt and read the diff. They can hand off to an agent swarm and catch what comes back. They know enough about each station in the factory to keep it running.
This is a new role. It requires deliberate development. The bar hasn’t lowered — it has shifted.
Technology: Know the Machine
There is a version of AI-assisted software development that looks like this: describe what you want, accept what the model gives you, repeat until something works.
That is not engineering. That is hoping.
A locomotive engineer in 1905 didn’t design the steam engine. They didn’t need a PhD in thermodynamics. But they knew how the machine worked — deeply enough to operate it safely, to maintain it, to notice when something was wrong before the boiler failed.
You don’t need to be a computer scientist to run a software factory. But you need to be an engineer in the original sense — someone who understands the system they’re operating. Other people’s tooling will only carry you so far. At some point you will need to know how the pieces fit together, how to debug what the agent produced, how to extend the pipeline when the edge case arrives.
Whispering pretty words into the magic box does not make you an expert operator.
No End-to-End Tooling Exists
Here is the current state of the industry: the pieces exist. LLMs that can write code. CI/CD systems that can deploy it. Issue trackers that can organize work. Infrastructure tools that can provision environments.
What doesn’t exist is the wire. The thing that connects intake to understanding to planning to building to deploying — as a coherent, repeatable system. Right now, that wire is either a team of humans stitching things together manually, or a bespoke internal platform someone built and owns and maintains.
That is the gap. And it is significant.
What a Software Factory Actually Is
A software factory is an end-to-end system. Inputs: ideas, specifications, knowledge. Output: live software.
It has stages — intake, understanding, planning, context, build, infrastructure, deployment. It has quality gates between them. It has agents doing the mechanical work and humans governing the outcome. It applies the same discipline to software production that physical manufacturing applied to making things at scale.
The factory metaphor is intentional. Factories don’t produce one-off items by hand. They have a process. They have throughput. They can be inspected, improved, and scaled.
Software can be built the same way. The technology is finally there. The process thinking is behind it. The people models are still catching up.
machinus (adj.) — from Latin machinarius: “of or belonging to machines.” The name is not accidental.
Telemetry-Driven Evolution
A factory that ships and disconnects is half a factory.
Software improves through live runtime signals, production feedback, and continuous system learning. The factory can remain connected to the software even after it’s shipped — monitoring it, learning from it, feeding that signal back into the next build cycle.
This closes the loop. IDEA → Live Product → Better Product. The line doesn’t end at deployment.
