Imagine a development task that appears almost finished. The code has been written. The assistant has produced a confident summary. Somewhere behind that summary, a test has failed, a dependency is missing, and the wrong version of a file has been reviewed.
The gap between those two pictures is where much of the work on autonomous software factories begins. Producing a plausible change is only one stage. A working factory has to know which change was made, whether it passed the right checks, who can approve it, and what should happen next.
In agent development, the machinery around the model is often called a harness. The word sounds modest, like an accessory. Its responsibilities are anything but: supplying context, making tools available, limiting permissions, keeping records, and deciding when work should continue or stop.
The intelligence needs somewhere to work
Consider the difference between asking an assistant to suggest a fix and allowing it to make one. The second task requires access to a repository, a place to work, a way to run tests, and a record of the result. Each connection introduces a decision that the model alone cannot settle.
Should the assistant be allowed to install a dependency? Can it change a test? What happens if the test runner hangs? Can it publish the result, or only prepare it for review? These decisions shape the system’s behaviour before the first line of code is written.
For a manager, the harness is where responsibility becomes concrete. A budget has to become a limit the system can enforce. A release policy has to become a checkpoint. A request for evidence has to produce something more durable than a conversation.
The factory needs to remember what happened after the assistant stops talking.
Follow one change all the way through
A useful starting point is an ordinary maintenance task. Give the system a bounded issue, a known version of the code, and an isolated workspace. Ask it to propose a change and run the existing checks. Keep the result attached to that version of the code.
Then introduce an interruption. A test fails. A reviewer asks for a different approach. The task resumes the following day. Can the system recover the actual state of the work, or does it reconstruct a convincing story from fragments?
This is a proposed test of the surrounding system. A successful run would need reviewable changes, recorded checks, and a clear account of any intervention. A polished final answer would contribute little on its own.
What survives the upgrade?
Models will change, and some changes will be worth adopting. That makes the surrounding machinery more valuable. A stable set of tools and checks gives researchers a way to compare models without rebuilding the entire experiment.
The next useful question is therefore architectural: how much of the factory’s competence belongs to the model, and how much belongs to the conditions in which it works? We need a system that lets us tell the difference.
Continue the inquiry
Which parts of the factory would remain useful if its model changed tomorrow?
Send a perspective ↗