October 2026

A Factory That Learns

For most of this year I thought the hard part of building with AI was getting it to write good code. It isn’t. The models are already good enough to write most of the code I need. The hard part is everything around them.

Here’s what I mean. When you work with a coding agent in a chat window, every session starts from zero. It doesn’t know what you decided last week. It doesn’t know about the mistake it made yesterday, or the one you corrected three times before that. You explain, it works, you correct it, the window closes, and all of that is gone. Tomorrow you explain the same things again.

That’s fine for small jobs. But I’m building a company, making the websites and tools for a recording studio, and building things for myself, mostly on my own. At that scale the forgetting becomes the main cost. I wasn’t spending my time on the work. I was spending it re-teaching.

So I stopped thinking of AI as an assistant and started building what people have started calling a software factory: a loop that takes in work, runs it through a few well-defined stations, keeps a record of everything, and gets better over time.^[1]

That last part is the one that matters. A factory that doesn’t learn is just a lot of agents. A factory that learns compounds.

I’ll describe mine piece by piece, and then explain why I think something like it is going to matter to almost everyone who does knowledge work, not just programmers.

The shape is simple. I set the intent: what I want built, and what’s off limits. An orchestrator takes requests and routes them. Each project has a lead that plans the work and starts workers. Each worker does one job in its own copy of the code, and then stops. Under all of it is something I call DJM OS, which is really just a big folder of plain-text notes: what each project is, what’s been decided, what’s true right now, and the rules every agent follows.

None of the agents are special. Any of them can be Claude or Codex. Right now the orchestrator and the leads are usually Claude and the hands-on work usually goes to Codex, mostly because of cost. But that’s a setting, not a design. The roles are seats, and either family of model can sit in them.

That matters more than it sounds. Models change every few months. The best one in the spring isn’t the best one now. If your way of working is tied to one tool, you start over every time the frontier moves. If every agent reads the same contract first, with the same rules, the same skills and the same short list of things it must never do, you can swap the model underneath and keep everything you’ve learned. The knowledge lives in the notes, not in the model.

The same idea keeps the cost down. Not every job needs the best model. Sweeping through a pile of files to find one answer goes to the cheapest model that can do it. Review goes to a careful one that isn’t allowed to change anything. Anything a person will see or touch gets the strongest. Picking the model per job instead of per project is a big part of what keeps all this affordable.

Then there are the machines.

For a while all of this ran on one MacBook. That was a mistake, though it took me a while to see why. The laptop was doing four jobs at once. It was my everyday computer, the machine that built the code, the server that ran the tests, and the screen the app tests clicked around on. Whenever two of those collided, everything slowed down or froze. And when I took the laptop out of the house, the whole factory stopped. I used to pause every agent before I left.

Now the agents live on a Linux cloud server that’s always on. It never sleeps, never gets closed, and doesn’t care where I am. It runs the agents themselves, the web apps, the test suites and the Android emulators. My Mac became a test bench for the things only a Mac can do, like building the iPhone and Mac apps and clicking through them. My Windows PC became the same thing for Windows. The laptop and phone are just screens now. I steer from T3 Code, which shows the same threads on both, so I can start something on my laptop at home and check on it from my phone at work.^[2]

Everything talks over a private network, and all the code lives in Git, so no single machine is precious. If one drops out, its work falls back to the others.

If I could only tell someone to set up one piece, it would be the cloud server. Not because it’s powerful, though it is. It’s because of what “always on” does to how you work. When the factory only runs while you’re at your desk, it’s a tool. When it runs while you sleep, it starts to feel like a team. You come back to finished work, or at least to good questions.

A team needs to know who owns what. Every request in my system goes to exactly one owner, either a project or one area of the notes, and every owner keeps a short file I call a NOW card. It holds the current state, the decisions in force, the open questions and the next three actions. Every agent reads it before doing anything and rewrites it whenever something changes. It sounds bureaucratic. In practice it’s what keeps agents from confidently working off last month’s plan.

Behind the notes is a search index the agents can ask questions. The interesting part is what it does when it doesn’t know. Every answer comes with the notes it came from, and if the sources are missing or disagree, it says so instead of guessing. An agent that says “I don’t know” is far more useful than one that’s confidently wrong, and it turns out you have to build that in on purpose.

Then there’s the line itself: the path a piece of work takes from request to done.

A lead writes a short spec saying what to build, what not to touch, and how we’ll know it worked. A worker builds it in its own copy of the code, and the checks run. Then someone reviews it, and here’s the rule I’d keep even if I dropped everything else: the reviewer always comes from the other model family. Claude reviews Codex’s work and Codex reviews Claude’s. Models have blind spots, and they tend to share them with their relatives. A reviewer from another family sees what the author’s family can’t.

Even the review gets checked. Every finding is verified before anyone fixes it, because reviewers are wrong too, and fixing a false alarm can break something that worked. Only then does the work merge, with proof attached. For anything visual that means screenshots, so I can see what changed from my phone in thirty seconds instead of reading code.

Some things never happen without me: deploys, anything that costs money, anything that touches a password, anything that gets sent to another person. The agents get those ready, and I make the call. The plumbing can run on its own. The decisions that matter shouldn’t.

The part people find strangest is the guards. Before an agent runs a command, a small script looks at it first, and some commands get stopped, with a note explaining how to do it properly.

Every guard exists because something went wrong once. One day an agent cleaned up a few stuck processes by matching their names, and the pattern matched every other agent on the machine. One line stopped every session I had running. Now there’s a guard that won’t let anything stop processes by name at all. You have to find the exact one, check that it’s yours, and stop only that.

While an agent was building this website, the guards stopped it seven times. Once it tried to stage every file in the folder at once, which can sweep up another agent’s unfinished work. Twice it wrote a command where a failing test would have been hidden and the commit would have gone through anyway. Each time it was stopped, told why, and did it the right way. Nobody had to be watching.

All of this would be useful even if it stayed the same. But the reason I call it a factory is that it doesn’t stay the same.

Every session, from every agent on every machine, goes into a private journal. A separate process strips out anything private and publishes the rest as a history and a daily work log. Visual work gets logged with a screenshot, so the record shows what was actually built, not just what an agent said it built. You’d be surprised how often those are different.

Once a week, the factory grades itself. A scorer goes through the week’s runs and counts things: how many tokens and hours each finished piece of work took, how often an agent had to stop and ask me something, how often I had to step in and steer, how many times the same command failed, how long things sat stuck. Then it looks for failures that repeat. One failure is noise. The same failure in three different runs is a pattern, and patterns are what it’s hunting for.

When it finds one, it proposes a fix, and a specific one: a change to a particular file, with links to the runs where things went wrong, a test that fails now and should pass afterward, and a prediction of how much the failure should drop. It can propose at most three a week, worst first. Each fix goes down the same line as everything else, including review by the other model family. And there’s a short list of things it’s never allowed to touch, starting with the guards. A system that improves itself shouldn’t be able to remove its own brakes.

Two weeks after a fix lands, the scorer checks whether the failure actually went down. If it didn’t fall by at least half, the factory proposes undoing it. A fix has to earn its place.^[3]

That weekly loop catches patterns. A faster loop catches corrections. When I correct an agent, or an agent catches its own mistake, it gets written down once in a running list of lessons. Then the lesson gets moved to where it belongs: the rule, the skill or the check that would have prevented it. Once it’s there, every future session starts with it already in place. Every finished task also leaves a small receipt that says what it learned, or why there was nothing to learn.

This is the part I think most people miss when they talk about AI tools. Paul Graham has an essay about superlinear returns where he writes, “Whenever how well you do depends on how well you’ve done, you’ll get exponential growth.”^[4] A loop like this sets up exactly that. Without one, your hundredth week of working with AI looks like your first: the same explanations, the same corrections, the same mistakes. With one, every correction makes the next week a little cheaper, and the savings stack. The work you did last month quietly makes this month’s work easier.

I don’t want to oversell it. Most weeks the improvements are small: a rule rewritten, a check added, a step moved earlier. But small changes that stick add up in a way that big changes that don’t stick never will.

So far I’ve talked about code, because that’s where I built it. But almost none of this is really about code.

Look at the pieces again. Notes that every helper reads first. One owner for every area. A record of what actually happened. Rules that block known mistakes. A weekly look at what went wrong, and the habit of writing each lesson where the next attempt will see it. None of that needs a compiler. It works for anyone whose job is mostly thinking, writing, deciding and making things on a computer.

A designer could run the same loop on feedback, so that every note that comes up twice becomes a rule the next draft gets checked against. A writer could do it with edits. A small business could do it with bookings, posts and follow-ups. The studio’s daily availability posts are made by an automation that runs through the same kind of notes and checks. And this essay was drafted with the factory’s help, by an agent that read my notes before it wrote a word.

The reason this matters now, and didn’t five years ago, is that the cost of doing the work has fallen much faster than the cost of directing it. An agent can write in an afternoon what used to take a week. But it still has to know what you want, what you’ve already decided, and what good looks like. That knowledge is the new bottleneck, and it’s exactly what a chat window throws away.

Which means the people who get the most out of these tools won’t be the ones with the cleverest prompts. They’ll be the ones whose tools remember.

You don’t need four machines to start. I didn’t. Start with a folder of notes that every agent reads first: what you’re working on, what you’ve decided, and what it should never do. Keep a record of what happens. Once a week, look at what went wrong and write each lesson somewhere the next session will see it. When your laptop starts doing four jobs at once, move the agents to a cloud server so they keep working when you close it. Add the other pieces when you feel them missing.

The order matters less than the loop. The loop is the factory.

Everyone gets the new models on the same day. No one else gets what your factory learned last week.