A small software factory, with AI agents as the crew

Tue, 10 Nov 2026 00:00:00 +0100

Since Saturday, 7 November 2026, orgthread has grown from zero to twelve actions: read, write, list, patch, download, upload, version, delete, copy, move, new folders and search. I did not write the code. AI agents wrote it, in a small software factory. The factory started as steps that I ran by hand. On Monday, 9 November, I put those steps into one skill. From delete on, the last five actions went through the same 9 steps.

This post shows how the factory works. It also shows the four times when one of its checks caught a mistake.

A building site, not one long chat

One chat that does it all fills up fast. It asks about the software architecture, writes the code, runs the tests and explains the result. Soon the chat is full of code and test output, and my architecture choices are far up in it.

So I split the work into roles, as on a building site. I am the owner. I agree on the plan with a site manager. A trade does the work. The site manager checks it before I sign it off.

Each feature is its own building site. The factory is the line that every site follows: the same roles, the same steps and the same checks, feature after feature.

In the factory, each role is its own AI session:

The master chat keeps the plan of the whole project. It starts one feature master for each feature and reads its final report. It stays short.
The feature master is the site manager. It asks me the architecture questions, writes down my architecture choices, starts the code session, checks its work, and walks me through the code.
The code session is the trade. It writes the code and the tests on its own branch. A branch is a separate line of the code. The main line stays clean until I say yes.

Each session also runs with the model and the effort that fit its work. A quick check gets a fast model and a low effort. Code that is hard to undo, such as delete, gets the strongest model and the most effort.

The factory is part of a plugin of mine. A plugin is a package of skills and scripts that an agent can load. I start the factory with one skill, a set of written instructions that the agent follows when I type /org:implement.

Nine steps

Each feature goes through the same 9 steps. Every reply of the feature master starts with its place, for example “Step 3 of 9: grill both ways”. So I always know where the work stands, even when I come back after a day.

The 9 steps. I decide at the four orange marks. Step 3 repeats until I say yes to the architecture choices. From steps 6 to 9, the work can go back to the code session.

The diagram has two kinds of marks. The orange diamonds are the four points where I decide. No code is written before I approve the architecture choices. No code merges or goes live before I say yes.

The dashed lines show where the work can go back. That is not a failure. It is the reason the steps exist.

Grill both ways

Step 3 sets the shape of the feature. The feature master asks me one question at a time. Each question comes with a short trade-off and a recommendation.

For delete, there were seven questions. Can it delete folders? No, files only, for now. Where may it delete? Only in folders that I list in a setting. How do I undo a delete? With a restore command, decided but not built yet.

“Both ways” means that I can ask back at any time. When an answer is not clear, the feature master gives me an example from the real code.

I do not only answer. When the direction does not fit, I challenge it. I also bring my own ideas, and the feature master weighs them with the same trade-offs as its own. Then I decide.

The grill ends in a note of my architecture choices. The code session starts only after I approve it.

In step 7, the same thing happens with the code. The feature master walks me through it from the top down, one level at a time. I say yes only to code that I understand.

Four times the checks paid off

The builder found a gap in older code. The architecture choices for delete said that each delete needs a fingerprint. A fingerprint is a short code for one exact version of a file. While it built copy, the code session found that delete let an empty fingerprint through. The fix went into the next version, for both copy and delete. A second pair of eyes on old code is part of the work, not extra.

Green on the Mac, red on Linux. A test for a failed move used chflags to lock a folder. All tests passed on my Mac. The test run on GitHub, which runs on Linux, failed. chflags exists only on macOS. The test now uses a folder without the right to write, which works on both. The program itself was fine. Only the test was wrong. This is why tests run in more than one place.

A report is not proof. One session reported that orgthread had failed, so it used the old way to the files instead. The real cause was a wrong path that the session gave to orgthread. The tool itself worked. This is why the feature master checks each report against the branch and the facts, before it tells me that something is done or broken.

A yes must come from me. At one point, my yes for a push came to the session through another session. The safety check of the agent refused it. It wanted my own yes, in that session. This is slower, but right. A yes that travels from session to session is easy to copy, and hard to check.

What it costs

The factory is not free. A feature takes more steps and more questions than one quick chat. I answer each architecture question myself. On a busy day, several sessions run at once. Each session’s title starts with a sign that shows its state: working, waiting for me, or done.

A very small change, one file and a few lines, does not need the whole factory. It stays in a plain chat. But it still goes on a branch, and it still waits for my yes before it goes live.

For the last five actions, the cost was worth it to me. Each one went through the same steps and the same checks.

Two days in numbers

11 versions deployed, from 0.2.8 to 0.2.18.
36 commits to the main line.
176 more tests: from 267 to 443.
5 new actions through the factory: delete, copy, move, new folders and search.
6 actions improved: read, write, patch, download, upload and list.
4 mistakes caught by the checks, the ones above.

By my own estimate, the same work by hand would have taken me three to four weeks.

What you can take from it

You do not need my plugin to use the idea. Three rules carry most of it:

Split the roles. One session plans, one builds, one checks. Each chat stays short and keeps its focus.
Put a check between the steps. Each report is checked against the real branch, and each test runs in more than one place.
The owner says yes. No merge and no deploy without it, and the yes comes from the owner, not from another agent.

Where it stands

All twelve actions are live in orgthread version 0.2.18. Each of the last five, from delete to search, has its note of architecture choices, its tests and an entry in the changelog. I build orgthread with AI agents as the crew. I set the architecture, and nothing merges or goes live without my yes.

The code of orgthread is public on GitHub. To follow the build, subscribe to the Build log feed.

Posts tagged ai agents · Silviu Bojica