Software refineries

Every software factory ever built makes your code to order.

That's the part nobody questions, because it's been true since the term was coined at a NATO conference in 1968. A request arrives. Someone, or lately something, builds the thing that satisfies it. Then someone else checks the work. Change the builder from a person to an agent and the shape holds: request in, build, review, ship.

The factory has been a good idea for almost sixty years. It's worth being precise about what it promised, because the promise is still the right one. It's the manufacturing model underneath that's now optional.

What the factory was for

A factory is a machine for turning intent into working software repeatedly, without depending on who's on shift.

The aspiration was never speed alone. It was repeatability: the same request should produce work of the same quality on a Tuesday in March as on a Friday before a holiday. It was division of labor: someone decides what to build, someone builds it, someone checks it, and the handoffs are clean enough that the work doesn't depend on one person holding the whole system in their head. It was compounding: each pass through the line should leave the codebase in a state that makes the next pass cheaper, not more expensive.

Then agents arrived and the build step collapsed. What used to take days takes minutes. The teams who saw that first drew the obvious conclusion, that a factory where building is nearly free should be able to ship far more, and pushed it as far as it goes: nobody writes the code, nobody reads the code, just keep the queue full.

What came back was volume without the other three. Repeatability went first, because the same request twice gives you two different implementations and no way to say which one you're running. Then compounding inverted: instead of each pass leaving the system easier to change, changes started making the next change harder, and teams that shipped hard for a few months found themselves in codebases that fought back. Division of labor survived on paper only, since checking the work is only a real step if someone still does it.

The factories didn't fail because agents write bad code. They failed because making something to order gives you no evidence about what you made, and when building was slow, the review step quietly supplied that evidence. Remove it, keep the manufacturing model, and you're shipping artifacts nobody can vouch for, at a rate nobody can review.

That's the constraint worth attacking. Not "how do we check the code faster," but "why is the code being made fresh for every request in the first place."

Refineries

A refinery doesn't wait for your order to start working.

It processes raw input into a stocked catalog of known outputs, continuously, before anyone asks. When an order comes in, the refinery doesn't manufacture anything. It matches the order to what it already holds and delivers it, with the specification of what's being delivered already established, because it was established when the batch was made rather than after the order arrived.

That's the vision for software.

You describe what your system must do, and the implementation is something you select rather than something you commission. The work of stating your intent precisely, what the system must guarantee, what it must never do, what you'd trade away and what you wouldn't, becomes the work. The implementation that satisfies it is found, not built.

Here's what changes when you're selecting rather than commissioning.

You get evidence with the artifact, not after it. In a factory, what you know about a change comes from checking it once it exists, which is why review is the bottleneck and why removing review removes the knowledge. A refinery inverts the order. Evidence about an implementation is established before any request arrives, so it ships alongside the implementation rather than being reconstructed under deadline. You read what's established about the thing you're getting, not the thing itself.

The same request gives you the same system. Ask twice, get the same answer, indefinitely. When your system does change, it changes because you changed what you asked for or because the catalog moved, and both are things you can point at. That's repeatability restored as a property of the machine rather than a habit you have to maintain.

Your source of truth becomes the specification. Today your intent lives in tickets, docs, and comments, while the code is the only thing that's actually true, and the two drift apart from the day you start. When implementations are selected against a specification, the specification is the artifact you maintain and the code is what comes out of it. Which means the drift has nowhere to happen.

Your codebase stops accumulating. A factory's output is a sequence of edits, each one applied to the last one's output, which is exactly why systems get harder to change the longer they run. Selecting a different implementation isn't an edit. Nothing accretes, so the thing that made month six worse than month one doesn't have a mechanism to happen.

What doesn't change

Refineries don't remove people from software, and it's worth being exact about where they stay.

Somebody has to say what the system should do. That's the specification, and writing a good one is judgment work that no catalog contains: knowing what your users actually need, what you're willing to trade, what "correct" means for your problem in particular. A refinery makes that work more valuable, not less, because it's the input everything else is derived from.

And some questions have no verifier. Whether this product direction is the right one, whether last quarter's call was correct, whether this is the system your users want in two years. None of these can be scored against an observable outcome, and no catalog will ever hold answers to them. What a refinery can do is settle everything around them, so the questions that reach you are the ones that genuinely need you, arriving with the answerable parts already answered.

That's the division of labor the factory was reaching for and never quite got: the machine holds what can be established, people hold what can't, and the line between them is visible instead of assumed.

Where this goes

Noetive builds infrastructure for agent systems, and this is the direction we think software construction is heading. Not agents that build faster, agents that select from what's already known good.

We're not describing something you can buy today. We're describing where we think the constraint actually is, and we'd rather state the direction plainly now than dress up a smaller claim as a bigger one. The specifics of how a catalog like this gets built, and what it takes to establish what's in it, are the subject of the next post.

If you're building agent systems and this shape sounds like the problem you're actually having, we'd like to hear about it. Find us at noetive.io.