Posts

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, ...
Post a Comment
Read more

Agents that don't know they're in a factory: the graph moves out of the agents' heads

Image
Everything I built before this post had one thing in common, and I only saw it once I had something to compare it with. In the mail-based factories the organization was free-form, and the agents knew it. They had roles. They knew the floor: who the lead was, whether the validator should write to the lead, what came after a push. The graph of activities that turns a need into delivered work lived in the agents' heads, and each agent's job included following it. When a thing went wrong, it went wrong in the graph: work duplicated, a verdict that never arrived, two agents thanking each other for six hours. The new experiment is the opposite at the highest level, and that is the whole point of it. The graph is outside the Agents, and they don't know they're part of it. Each Agent is created to do one piece of agentic work for one Task, with a cleanly built Run Context, and it only edits files. Everything algorithmic is done by the Factory outside the Agents. The goal behin...
Post a Comment
Read more

Thank you, you're welcome, thank you: the loop that ended my software factory's mail

Image
The previous post ended with a premise: one session per task, an agent that can work on several tasks, and learning that runs apart from the work. This post is about what happened when I built it, and why I ended up throwing most of it away, including the mail. I did this with Claude Code again. A fair number of my messages in these sessions are corrections. I'll leave those in where they matter. Starting blank On Oct 7 I told Claude to throw out all preconceptions: if one agent held several tasks, learnings would land in one place instead of splitting across two builders. I also wanted to fix how I experimented, because one experiment at a time was too slow. Along the way I rejected several of its ideas. A git worktree per task made the wake script know about repositories, and I said a builder decides itself whether to clone. Putting prompts inside .mjs files meant that changing a prompt looked like changing running code. A consolidation prompt...
Post a Comment
Read more

Short memories: what my software factory's agents did when I made them forget between mails

In my last post I said the next thing to test was whether the team's lessons stuck. I'd also said, near the end, that I would try to re-inject memory after compaction. What I did instead was step back and ask what the two weeks of proofs of concept had taught me, and the first answer was uncomfortable. On Oct 4 I asked Claude Code to list everything we had learned, reading the transcripts of both repositories. My own comment on the first list was: "either we learn a lot of shit or we didn't learn anything." I had never set up an experiment to learn about nspawn, for example, and several of the things on the list were bugs in my machinery, not findings about agents. So I fixed the frame before running anything else. As before, I did this with Claude Code, arguing each decision and reading what the agents produced. Fixing the frame first Fail loudly. A wrong address now fails when the mail is sent, with the reason, so the agent never believes a message went ...
Post a Comment
Read more

A validator, a manager and a job to finish: what my software factory's team did

Image
In my previous post I ran probes to find out what the model reaches for when it needs its team. The answer was plain: it has no team until it's told it has one; given a directory with a way to reach each person, 6 of 8 did, with no instructions; and mail was a tool it uses correctly if I stop wrapping it in mechanics. Then I ran four needs on a shared repository, and found that two agents who each held a fact only the other had, never asked. I ended on a probe about asking. I haven't run it yet. Instead I did something that turned out to matter more: I threw the factory away and rebuilt it, and then gave a team of five a job with a customer in sight, a validator who answers to me, and me in the seat I should have been in all along, the manager's. As before, I did this together with Claude Code, and I argued each decision in conversation and read what the agents produced. The code is public now: github.com/yeiniel/agentic-software-factory . What the runs showed, each wit...
Post a Comment
Read more

Nobody asked: what my software factory's agents do when they need each other

In my previous post my software factory met its first customer, me, with a real job: a shared chore list for my family, hosted on an old TV box. A frontend developer replaced its own page with a placeholder, a verifier approved it without looking, and a false PASS travelled three hops to me. I ended that post with five experiments: make the lead an actor like the rest, give the team a place for its own knowledge, add a runner that checks the repository's tests on every push, try a stronger model, and open a town square once there was a reason to believe peer traffic was the bottleneck. This post is about doing all five, and about what happened when I stopped guessing what the model needs and started asking it. It's two proofs of concept. The first, which I called mail-office , ran four times and didn't answer its question. The second is still going, and it gave me the first run in which two agents split a job between them and put it back together. It also gave me the clea...
Post a Comment
Read more

Verified, but not real: my software factory meets its first customer

In my previous post I built a team of blank actors: engineers that start with the same few lines of instructions and learn their jobs by email from an authority. A builder and a verifier came out of that, and a fizzbuzz went from request to signed push to PASS to report. I ended that post with three questions: what is the right size of thing for one agent to own, how does a factory add capacity, and how good must the starting point be. They were questions for a later run, on a real job. This post is about the fourth proof of concept, and that real job. I have a real problem at home: my family needs a shared list of chores, something my wife, my kid and I can all add to and tick off, and I want to host it myself on an old Android TV box I no longer use. The question for me was: can the factory, changed as little as possible, take that on, with me as the customer, more than one builder at once, and an AI in the lead's chair instead of me? As in the previous posts, I did this tog...
Post a Comment
Read more