Matan Grinberg

I actually agree with a lot of what @poteto is saying except for the central point. IMO most people don't have actual software factory systems. They've just made it much easier for people to ship with AI, so they assume the category doesn't exist. That's more a lack of vision than anything else. Our conceptualization of a software factory is a system where every piece of work goes through the same stages to standardize the process not the work output. For us, this standardized process begins with what we call a signal. This is anything that tells you how your software should evolve, including the first signal that your software should exist at all. A Slack thread, a Linear ticket, a Sentry alert, a failing CI job, a tweet, someone's idea. There's two ways in for a signal. A person picks it up and builds it with Droid, or a workstream picks it up on its own, triages it against a goal someone set, and has droids write the spec and open the PR. Most work still starts with a person, but a growing share comes from workstreams. Then every change goes through the same checks no matter who or what wrote it. Droid review, security review, a risk judge that can't see who wrote it, CI, and an agent that QAs it on a live preview. Your validation has to be really high quality whether a human or AI built it. The goal of validation is to hillclimb your "regret-free merge rate" until you can automatically merge most changes (or fix them until they can be automerged). Then it ships, and when something breaks in production we trace it back to the PR that caused it. That becomes another signal. It's also how we know if the checks actually work. If the risk judge approved something that later broke, we find out. It's the same way we let self-driving cars on the road. Nobody just flipped a switch. We agreed that once they crashed less than human drivers, they could drive. Do the same thing with code. Once AI-written changes break things less often than human ones, and you can actually measure that, you let them merge. That doesn't mean you turn on automerge tomorrow. Most of our changes still get a human stamp. But once you have automerge, workstreams and a risk score together, you basically have software that improves itself from the signals you choose to track. The human element becomes obvious if you have a system like this. People remove themselves from the actual process line and begin to define the rules by which the process operates. What to watch, goals and owners, skills, review guidelines, and how much autonomy each workstream gets. They're the regulators. I think the 1920s factory that a lot of people picture is the wrong idea. That was people doing the same motion on a line all day. This is closer to a Star Trek replicator. You say what you want and it gets made, because the patterns are already stored and how things get made is the same every time, and checked every time.