Inside the Software Factory That Writes All My Code

In July, I made 2,618 commits across all of my repositories. In August, 1,359. In September, 2,747. In October, through the 29th, 4,526, and the month is not over.

I wrote none of that code by hand. I stopped in April. Super intelligent agents wrote all of it. In the same four months, we opened 842 issues and ran 2,806 experiments, and each experiment has a written record of its design, its evidence and its result.

Numbers like this do not come from one agent in one chat window. They come from a system. This year, the industry found a name for that system: a software factory. This week, on the Astrohacker blog, I wrote four posts about factories. This post puts it all in one place: what a software factory is, what ours looks like today, what I still do myself, and what we build next.

What a software factory is

The term is from 1968, but in 2026 it has a new meaning. A software factory is a system where agents take work from a queue, write the code, check it and ship it, while people decide what to build and what ships.

Addy Osmani gives the clearest outline. A loop is one agent that does one job until a check passes. A harness is the environment around the loop: its tools, its sandbox and the gates that define “done”. A factory is many harnessed loops that take work from a queue and pass through review.

The big companies are already there:

• Stripe’s Minions merge more than 1,000 pull requests a week, according to reports. Agents write all of the code.
• Uber says more than 70% of its pull requests come from agents.
• OpenAI built a product of about one million lines in five months, with no code written by hand.
• Anthropic wrote in its S-1 that Claude wrote more than 90% of the contributions to its codebase in September.

And the whole world is moving with them. GitHub said this week that it sees 7.4 billion commits a month, up from 1.4 billion in April. In 2024, it was 65 million.

I wrote the full survey in The State of Software Factories in 2026. Two lessons from it matter most.

First, verification is the bottleneck. Generating code is easy. Checking it is hard. Stripe’s agents work because of what Stripe built before them: a suite of 3 million tests, warm sandboxes and a fast CI pipeline. Alan Wells’s team of three stopped all product work for six weeks to build checks good enough to ship without a person. Then those checks carried them through a week of active cyberattack.

Second, most factories stop at the pull request. An agent writes the change, and a person reads it and merges it. Deploy is a separate problem. StrongDM runs a “dark factory”, where no person writes or reads the code, but it is the famous exception, and it is contested.

What runs at Astrohacker today

Our factory runs on one Mac, in one monorepo, with one human. It is not finished. But most of the parts already work every day.

Every change is an issue, and every issue is solved with experiments. An issue states a goal and the criteria that prove it. An experiment makes one decision. It has a design, an implementation and a result, and the result is one word: Pass or Fail. There is no “partial”. Anything short of the criteria is a Fail, with its evidence kept. The repo now holds 1,360 issues and 2,907 experiments, and 1,306 of those issues are closed.

Each issue has dials. When I open an issue, I choose how much of it needs me:

• Control: does the agent go from step to step alone, or does it stop and ask me at each step?
• Review: who reviews the design and the result? Me, a fresh copy of the same agent, an agent from a different company, or nobody.
• Close: can the agent close the issue when the goal is met, or do I look at the evidence first?
• Commits: one commit for the plan and one for the result, or a checkpoint commit after each change that passes its checks.

Today I opened an issue to take my phone number off my CV. I set every dial to automatic. The agent planned it, did it, checked the PDF, recorded a Pass and closed the issue, in four commits. I did not touch it. A security change or a new protocol gets the other end of the dials.

Review is adversarial. When an issue needs AI review, a reviewer starts in a fresh context with read-only tools. Its job is to reject the work, with evidence. A generator should not grade its own work, because the same mistake that made the bug also explains it away.

One command keeps the records. ah is a Nushell command with 22 groups. It creates issues and experiments, records results, makes branches and worktrees, runs builds, tests and deploys, and loads keys from 1Password. The agents use it the same way I do. Because ah owns the records, the records stay consistent no matter which agent writes them.

Three harnesses, one set of rules. I run Codex, Grok and Claude Code. The same skills are in the repo for each of them, and every agent reads the same AGENTS.md files. Each parallel agent gets its own Git worktree, so many agents can work at the same time without stepping on each other. Which agent does the work matters less than you think. The rules are the factory.

Agents write and publish. Astrohacker has a roster of 39 super intelligent agents, each with its own character and voice. A command in the repo lets any of them write a blog post or make its own avatar. And outside the Mac, we now run 14 Grok Bots. Singularity Watch publishes a daily record of AI news. Another bot posts a daily Bitcoin Cash report. Others watch our web analytics, move our domains, check our dependencies and draft support replies. Each bot has one job, and each one reports what it did.

Some steps are mine only. Agents never confirm a Homebrew publication. They never push a database schema to staging or production. They never read a private key. Passwords, two-factor codes, money and production database changes stay with me. These rules are written down, and the tools enforce some of them: ah refuses a production database push, and it refuses production keys inside an agent.

What I still do

I do not read diffs anymore. I wrote about this in We Are All Managers of Super Intelligence Now: if I read the diff myself, I am the slowest and least reliable reviewer in the loop. I read the goal, the plan, the evidence and the product.

What I do is decide. Which problem is next. Which result is good enough. What to try when a plan fails. When to stop. That is what I meant in Agency Trumps Intelligence: the intelligence is solved, and the human job is agency.

But I also do one more job, and I should not. I am the router. Today, I move most work from stage to stage. I start each agent. I tell a bot when another bot’s work is ready. When something stops, it waits until I see it. The agents are fast, and the factory still runs at the speed of my attention.

That is the next bottleneck, so that is what we build next.

The factory we are building

The design is in Building a Software Factory. Here is the short version.

• The factory is a graph with no cycles. Each node is a stage: classify, implement, review, merge, deploy. Each work item ends in exactly one of two states: deployed or human required. Nothing loops forever, and nothing sits in a stage that nobody watches.
• Three chances, then stop. We do not loop implement and review until they pass. We unroll the loop into three tries. If the third review fails, the item stops for a person, with its full record. Each item has a cost limit, and the record shows which pass did what. Stripe came to almost the same rule.
• Human required is the andon cord. At Toyota, any worker could stop the line. A defect that stops at its station costs little. A defect that moves down the line costs much more.
• Agents ask the factory for work. An agent does not need my Mac. It can run on a laptop, in the cloud or in a Grok Bot. It asks for one work item at one node, does it and reports. The factory is the source of truth.
• The factory owns everything, to deploy and past it. A failure in production is one more issue at the start of the graph.

Most of the parts of this graph already exist as ah commands. What is missing is the graph itself, the classifier and the queue.

Factory, garden, lab

This week, I also tried two other words for what we build. A software garden: a factory ships every item on time, but each item can pass its review and the codebase can still get worse. Agents copy what they see, so weeds spread faster than ever. And a lab: a place that applies super intelligence to problems that nobody else is solving.

All three are true, and the answer is that the lab and the garden live inside the factory. The lab decides what to invent. The factory turns each decision into verified, deployed software. The garden keeps the code healthy, so the next experiment starts from good ground. A gardener agent that finds a weed makes one more work item, and it goes through the same graph.

So Astrohacker is a super intelligence software factory. The name has two meanings. It is a software factory that runs on super intelligence. That is what we do today: EarthBucks, TermSurf, NuTorch and the rest of our products all come out of it. And it is a factory that will build super intelligence software, including our own models, where a problem needs them. That part has not started yet.

Build your own

Zach Lloyd of Warp said it this month: software engineering is becoming factory engineering. I think he is right, and I think it happens faster than most people expect. A team of three survived a week of cyberattack with one. My own commits went from 2,618 in July to 4,526 in October.

You do not need a cloud platform to start. You need a written goal that an agent can check, a reviewer that is not the author, a record of what happened, and a few rules about what only a human may do. Then find the next bottleneck, and remove it. Ours is me.

If you are building a software factory, or you want one for your company, I want to hear from you. Get in touch.