Too human: what building a software factory out of colleagues taught me

This post is different from the last three. Those were reports on runs. This one is about me: what I believed when I started, how that changed over a few weeks of proofs of concept, and where I think I am now. It is a retrospective and a sketch of the architecture of my own thinking, so it has fewer numbers.

As before, I did the work and the thinking together with Claude Code, and the conversation we had after the last run is what this post is made of.

What I believed

I started from two words: evolvability and adaptability. They are what I admire in good human teams. People notice what went wrong, change how they work, and carry that forward. I thought I could emulate that in an agent with skill learning and context engineering: give it memory, give it skills, let it consolidate what it learned, and trust it to become as close as possible to a person doing the job.

So I built a factory the way you'd build a company. A graph of actors, flexible and adjustable: a lead, builders, a validator, each with a role, each knowing the floor, who to write to and what came next. Knowledge was built at the individual level. If the factory needed to improve, the people in it would improve.

The agents were funny, and that should have been the clue

In those first runs I kept laughing at how human the agents were. One said "I've reviewed the repository" having run no command that touched it. Two of them thanked each other for six hours. A validator was confidently wrong in exactly the way a tired colleague is, and a correction made in front of the whole team didn't reach the person it was about. They had opinions about conflicts and promised to do better next time, and then some of them kept the wrong lesson.

I enjoyed it. I'm not sure now that I should have. I'm also not sure "too human" is the right term for what I built. Maybe the better description is that I trusted them with the part that people are bad at and have built tools for.

How the model shifted

It didn't happen in one step, and I resisted it. Each experiment closed a door:

• Memory and skills carried some lessons, but one session per mail lost the thread of what had just happened.
• Reducing the mail machinery didn't remove the failures. It moved them: a loop of pleasantries, replies that landed in the wrong task, a mechanism I'd built the factory on that no run had ever used.
• At some point I stopped asking how to make the agents follow the flow and asked why they had to know the flow at all.

Humans don't rely on each other's discipline for everything. We trust a linter and a test runner, and we don't ask a colleague to remember to run the formatter. Whatever can be checked, we hand to something that can't be talked out of it. So I tried the same: take out of the agentic space everything that can be done algorithmically, and leave the agent with the work that needs judgment.

The result was a factory where the graph is fixed, outside the agents, and the agents don't know they're part of it. A Task goes in. An Agent receives it as a prompt with a repository, edits files, and is gone. If it fails, the Factory hands another Agent the same job with Feedback and more context. There was no reason for the agent to know where it fit. Once I'd decided to take the graph out of it, that followed.

What that did to learning

This is the part I'm still absorbing, because it is a paradigm change for me and I haven't finished thinking about it.

My idea of the factory that learns was agents that learn. In the old design the unit of improvement was an agent's memory and skills. In the new one the Agents are stateless on purpose. Skills and prompts still matter. But the work graph and its feedback loops now matter as much, or more, and a factory that learns may be one that also changes the shape of its graph. Two changes I've already made by hand fit that: Acceptance Test Validation became its own step because a run showed it was in the wrong place, and the retry budget became nested loops because two kinds of failure were being treated as one. Those were lessons, and they live in the Factory and not in anyone's memory.

I don't know yet how to make that learning happen without me. The signals that would drive it need a process graph worth learning about, and mine isn't there yet.

Did I ignore everyone else's work?

I asked myself that directly. Looking at what others publish about software factories, did I ignore prior art in pursuit of an ideal, or did everybody else go for practicality?

I had done the reading, but late. I gathered my notes on Oct 15, after the mail experiments and before the redesign. They say what I'd already found out the hard way, from sources I take to be mostly abstracts and write-ups of varying quality:

• Copying a company's org chart into the prompt (ChatDev, MetaGPT) shows up in a failure study of seven frameworks as coordination failures, like saying one thing and doing another.
• The production factories I could find use fixed flows, explicit gates and shared state, and let a check, not the agent's judgment, decide when work moves on.
• Some of what I built has a close cousin elsewhere. One team requires every review to confirm that the new tests fail without the change, which is my Acceptance Test Validation. Another keeps its scenarios outside the repository like a holdout set, which is how I think about a blind Acceptance Writer. Another contains the agent structurally, with no inbound network, which is what my internal network does.

So I didn't ignore them, and they weren't just being practical. The people who care about reliability and cost arrived at the same architecture as I did, from the other side. What I hadn't found in my notes is anyone measuring whether a factory can improve its own process. A fixed set of jobs, re-run before and after a change, doesn't seem to exist yet. That, not the architecture, may be the part worth working on.

The same notes warn me about what comes next: changes that win on the tasks they were evolved on and don't carry over, rules added after every incident and never removed, and process changes merged with no baseline. I had a small version of the first one already. The fixes that got a small Python library through didn't carry to a pnpm monorepo.

What I don't know

• The evidence is thin. Three small bugs, one local model. The model changed between the old design and the new one, so I can't separate the effect of the paradigm from the effect of better tool use.
• The graph only covers part of the job. I had started from a chain: idea, product, spec, code. What I've built is spec to code. That part has an oracle. A test suite either passes or it doesn't. The first half doesn't, and I already know from experiments that turning a need into a product idea is going to give me headaches. A factory made of algorithmic decisions needs somewhere for the judgment to live, and I don't yet know whether that is a person, a held-out scenario, or an earlier stage that produces something checkable.
• The process graph is hard-coded. On purpose, for simplicity. It is not the goal.

Where this goes

I still want a factory that learns from its mistakes. I just no longer think of it as a team of colleagues who get wiser. I think of it as a process that can be checked, whose workers are interchangeable and don't know the process, and that can eventually be improved by looking at its own records. The next step isn't learning. It's finishing the graph.

My family still doesn't have its chore list.