Source, Sink, Drain: How to Build an AI Software Factory

An AI software factory is AI agents working through a queue of tickets that a person filled with what they want built. My name for the 3 parts is source, sink and drain: I’m the source of what gets built, the queue is the sink where it waits as tickets and the agents are the drain that empties it as fast as my token quota allows. That’s how I build Daiku, the startup that gives your AI its own browser. I write what I want in a file called GENESIS.md. An agent called pm writes it up as issues on a Linear board. Then pm starts as many coding agents as my quota allows to work through them.

I wrote about the levels of agentic coding 3 weeks ago, where the software factory was level 4 and “I lose track of my own project” was where it broke. I kept running it. Daiku’s board went from 475 tickets on 16 October to 921 this morning. And 210 of its commits since 13 October landed between midnight and 6 in the morning. What I didn’t have 3 weeks ago was a way to explain it in one sentence. Source, sink, drain is that sentence. It also says something about who’s left in the factory once the agents can do the rest.

What is an AI software factory?

An AI software factory is a team of AI agents that works through a queue of software work by itself, while a person decides what goes into the queue. The agents have roles (a product manager, a maintainer, engineers) and the queue is usually an issue tracker. The search results for it right now are mostly vendors: Cortex calls it “an organizational system that turns customer needs into shipped, reliable software” and LaunchDarkly “a repeatable development system where agents do most of the implementation and engineers decide what ships”. I’d sign both of those! Neither tells you what the thing is shaped like though, which is what you need when you’re the one wiring it up at 11 at night.

The phrase is way older than agents, by the way!! Hitachi called its Hitachi Software Works a software factory in 1969 and Michael Cusumano wrote a whole book on the idea, Japan’s Software Factories (1991). Those were factories full of people. Ours are full of agents and the vocabulary for them is still being made up as we go: Steve Yegge’s Gas Town has a Mayor, polecats and beads, Dan Shapiro has 5 levels ending in a black box and Addy Osmani has lit factories and dark ones.

Source, sink, drain

Here’s mine, in one picture:

1. The source is me. I describe what I want in GENESIS.md, at the root of the repository. And I talk to exactly one agent about it: pm.
2. The sink is a Linear board. pm reads the source and turns it into projects and issues through Linear’s official MCP server (MCP is the Model Context Protocol, the standard way to plug tools into an agent). Everything that’s going to happen waits there as a ticket.
3. The drain is the agents. pm starts as many coding agents as it needs to work the board, within my quota. And reviews what they bring back before it ships.

I didn’t make up the 3 words. They’re borrowed from 2 places where something flows. In a flow network, the math behind Lester Ford and Delbert Fulkerson’s max-flow paper (published in 1956), everything starts at a node called the source and ends at one called the sink, and the question is how much you can push between them. In a transistor, the tiny switch there are billions of in the phone you’re probably reading this on, “the source is so named because it is the source of the charge carriers” and the drain “is where the charge carriers leave”. A third terminal sits between them: the gate, whose voltage decides how much flows between source and drain.

That third terminal is the part I love!! pm is my gate. It doesn’t write code. It decides which ticket goes to which agent and when and it decides what comes back through it to me. A transistor with no voltage on its gate passes nothing and a factory with no pm is just 8 agents fighting over the same files.

The source is me, writing GENESIS.md

On 4 October I committed a file called GENESIS.md to an empty repository, titled “Coding Agent Prompt: Daiku”. Its first line is “You are a senior full-stack engineer building a consumer SaaS from scratch called Daiku.” Then come 7,000 words of what I want: who it’s for (“non-developers. Assume users have never heard of MCP”), the product principles in order (“Security first”, “Magic onboarding”, “Lowest cost per user”, “Agent-neutral”), the architecture, the stack and what each user is allowed to cost me per month.

That file is the source. And here’s what surprised me when I went back through git for this post: it barely changes.

02550751001255th13th21st29th6thDECISIONS 118.3GENESIS 7.4

Day	DECISIONS	GENESIS
5th	2.0	7.0
13th	48.7	7.0
21st	84.3	7.3
29th	110.8	7.3
6th	118.3	7.4

GENESIS.md went from 6,979 words to 7,378 in a month. DECISIONS.md, where the agents write down every call they make, went from 2,044 to 118,277!! So the source is about 6% of the writing in that repository and it steers all of it. The few changes it did get are mostly me: a commit on 1 November reads “No CI: the gates are verify, the box specs and the smoke test (Tejas, 2026-11-01)” and one on 2 November sets “the margin rule is at least 2x at full use and about 3x at typical use (Tejas, 2026-11-02)”. The agents put my name and the date on the decisions that came from me. They know where the source is.

I write the source the way I described spec driven development in the levels post: I describe what I want, the agent grills me until neither of us has a question left, and the answers go in the file. The only difference in a factory is that nobody reads the file to me afterwards. Every agent reads it before it starts and every agent after it reads it too.

The source is where taste goes in

This is the part of the factory that a model can’t supply. I wrote a long post on what good taste in software is: a trainable skill, where you tacitly judge quality against external standards. And in why AI can’t replace human taste I went through why a model left to itself drifts toward whatever is most common. Anthropic says it plainly: “Without direction, Claude samples from this high-probability center”. A sink with no source still fills up. It fills up with the most probable tickets, which are the ones everybody else’s factory is also making.

So “Lowest cost per user. Nothing runs when nobody is using it” is a sentence pm would never have written on its own. It’s a decision about what Daiku is. Every ticket on the board traces back to a sentence like it.

The sink is a Linear board

The sink is where intent waits until something can work on it. For me that’s Linear. A chat window ends when its session does. A ticket is still on the board after every agent that touched it is gone.

I learned this one the hard way on this very site. Agents kept telling me they’d check something later and then the session ended and later never came. The rule in this repository now is that anything promised for later goes into a file in tasks/ with a date on it, “never only in a session job, which dies with the session”. A Linear board is the same rule at factory scale. Every ticket sits outside any one agent’s context window (the text a model can see at once). So an agent can crash, run out of context or get replaced and the work is still sitting there, in order, with a priority. And I can open it on my phone in the line at the supermarket!!

Linear also leans into this. Its agents page says “Agents are full members of your Linear workspace” and when you delegate an issue to one, “the human user remains the primary assignee”. Even Linear’s data model keeps a person at the top of the ticket.

On 16 October, when I wrote the levels post, Daiku’s board had 475 tickets. This morning the newest one is DAI-921, opened at 04:41 Berlin time. 250 of them landed in the 12 days from 25 October alone: about 20 a day.

The sink is the queue in Little’s law

A board that keeps growing sounds like a factory that’s falling behind. It isn’t, necessarily, and there’s a 65 year old formula for why. Little’s law, which John Little proved in 1961, says that for any steady queue, L = λW: the number of things waiting equals the rate they arrive times how long each one waits. So the size of the sink tells you nothing until you know how fast the drain is. 921 tickets that each wait a day is a fast factory. 921 tickets that each wait a month is a graveyard.

That’s also why I measure the drain in tickets per day. Which brings me to the agents.

The drain is as wide as my quota

The drain is every agent pm has running. In Claude Code, which is what I use for all of this, those are subagents and peer sessions, and “Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions.” pm decides how many. I decide one thing: the quota. My Claude subscription has a weekly limit (Anthropic added weekly limits on 28 August 2025. And the reason it gave was people running Claude Code “continuously in the background, 24/7”, which is literally what a factory is). That limit is the diameter of the pipe.

It costs a lot of tokens. When Anthropic wrote up how it built its multi-agent research system, a lead agent with subagents “outperformed single-agent Claude Opus 4 by 90.2%” on its internal research eval, and multi-agent systems “use about 15× more tokens than chats”. 15×!! That’s why the drain is sized by the quota and not by how many tickets are waiting.

The drain also doesn’t sleep. Since pm took over on 13 October, Daiku’s repository has 1,130 commits. 210 of them landed between midnight and 6 in the morning, Berlin time:

00:00 to 06:00

210

06:00 to 12:00

249

12:00 to 18:00

387

18:00 to 24:00

284

A wider drain isn’t always a faster one

Fred Brooks wrote in 1975 that “Adding manpower to a late software project makes it later” (Brooks’s law). Agents skip the part Brooks was mostly worried about, the weeks it takes a new person to ramp up: a new agent reads GENESIS.md and the ticket and starts. They keep the other part. 2 agents on tickets that touch the same files will overwrite each other, which Claude Code’s own docs on agent teams warn about in so many words. Anthropic’s research write-up also says “most coding tasks involve fewer truly parallelizable tasks than research” and Walden Yan at Cognition went further in June 2025: “Actions carry implicit decisions, and conflicting decisions carry bad results”.

He’s right and the gate is my answer to it. pm sees every ticket on the board and decides what can run side by side. So the agents never have to negotiate with each other about who touches what. The factory still has one brain making the calls. It just has a lot of hands.

When something’s urgent, the drain grows

The part of this model I like most is that none of the 3 pieces is a fixed size. When something becomes super urgent, I tell pm to spin up another agent dedicated to that one thing and to wind it down when it’s done. The other agents keep going. Nothing in the queue gets reshuffled to make room:

The sink flexes the same way. On 30 October one of Daiku’s first testers went through signup and told me everything that confused them. pm turned that into 23 urgent tickets (DAI-755 to DAI-777) in 10 minutes, between 18:13 and 18:23 Berlin time:

Opened in 10 minutes

23

Done by 4 November

19

The first one was closed 5 hours later, at 23:22. Of the 4 that aren’t done, one was a duplicate, one was canceled and 2 are still open. The commit messages read like a conversation with them: “a site’s passkey request no longer freezes the Daiku browser”, “setup step 3 holds the browser’s wait where the person looks”. That burst started from a person telling me what they felt. No agent was going to file “the wait scrolled away” on its own.

How to build an AI software factory

If you want to try this yourself, here’s the setup, in the order I’d do it again:

1. Write the source first, in the repository. One file, GENESIS.md or whatever you like, that says who the product is for, what it must never do and what you’d trade for what. Have an agent grill you into it one question at a time. Put the principles in priority order: mine say “When a requirement below conflicts with these principles, follow the principles and flag the conflict”.
2. Give the factory a sink that outlives every session. Connect Linear’s MCP server (or any tracker your agent can write to) and have the pm agent turn the source into projects and tickets before anyone writes code. Put a ticket number in every commit so git log leads back to the ticket.
3. Make one agent the gate and talk only to it. pm never writes code. It hands out tickets, decides what runs in parallel, reviews what comes back and is the only agent you talk to. In Claude Code, cross-session messaging lets it @-mention the others.
4. Size the drain by your quota. Let pm start agents up to what your plan allows and no further. When something is urgent, ask for one extra agent dedicated to it and have it wound down after.
5. Decide how the source hears back. The dashed line in the diagram is the part I neglected the longest. Have pm send you one note a day in plain words: what shipped, what broke, what it decided without you and what it needs from you. My cognitive debt problem from the levels post was a factory with no wire back to its source.
6. Write down what has to come back through you. Money, people’s data, anything a user sees, anything you can’t undo. Daiku’s pm set its own bar of about 200 milliseconds of added startup time. Every decision with my name on it in that repository came from a rule like that.

Even a dark factory has a source

The obvious next question is whether the source could be an agent too. Let pm write GENESIS.md and take me out of it entirely?

A lot of smart people are running the experiment. StrongDM’s AI team published the rules of its factory in February: “Code must not be written by humans” and “Code must not be reviewed by humans”. Dan Shapiro’s level 5 is “a black box that turns specs into software”. Now read those again: specs go into the black box. Every dark factory I’ve found takes something in at the top that a person wrote, even the ones with no human at the keyboard or on the review.

The people writing about factories keep landing on the same spot from different directions. Addy Osmani describes his as “Intent flows from the vision of engineering leadership, and directly from engineers, into a queue of things to be done”. That’s source and sink in other words!! He wants human judgment moved “upstream, to the product, the design, and the architecture before an agent starts a loop”. Andrej Karpathy wrote in February that “coding agents basically didn’t work before December and basically work since” and that the work you hand them still needs “high-level direction, judgement, taste, oversight”. In Gas Town, the Mayor is “a Claude Code instance with full context about your workspace” (basically my pm) and beads are “Git-backed issue tracking” (basically my sink). And the Mayor still takes its orders from somebody!!

There’s a technical reason the source can’t loop back into itself. In 2024 Ilia Shumailov and colleagues showed in Nature that “indiscriminate use of model-generated content in training causes irreversible defects in the resulting models, in which tails of the original content distribution disappear”. They called it model collapse. A factory whose source is its own drain is that experiment run on a product: every lap through the loop, the unusual ideas (the tails) are the first thing to go. The small version of it already showed up in SkillsBench, where skills that agents wrote for themselves scored 8.1 to 11.5 points below having no skills at all.

So the drain can be as wide as the quota and the sink can be as deep as Linear allows. The source stays a person.

The source of the source

I named that file GENESIS.md because it’s where Daiku begins, before there’s a single line of code. And every agent reads it first. A thing that gets made needs somebody who said what it’s for before anything moved. That idea is so old it’s in the Bible, from the BC times!!

The Book of Genesis opens on nothing. “Now the earth was formless and void, and darkness was over the surface of the deep” (Genesis 1:2). Then God speaks and what He says happens: “And God said, ‘Let there be light,’ and there was light” (Genesis 1:3). God didn’t need a ticket or a queue: the word and the thing had nothing in between. Centuries later the Gospel of John opens with the same words on purpose: “In the beginning was the Word, and the Word was with God, and the Word was God” (John 1:1). “Through Him all things were made, and without Him nothing was made that has been made” (John 1:3). A few verses later John says who that Word is: “The Word became flesh and made His dwelling among us” (John 1:14). That’s Jesus.

And on the sixth day God makes the one thing in creation that makes things: “So God created man in His own image; in the image of God He created him” (Genesis 1:27). The Latin for that is imago Dei, the image of God. J. R. R. Tolkien, the man who gave us The Lord of the Rings, had a word for what we do with it: sub-creation. He thought we invent whole worlds, Middle-earth included because we were made by a Maker, and he put it in one line of his poem Mythopoeia: “We make still by the law in which we’re made.”

So when I sit down to write GENESIS.md I’m a source, but I’m not the first one. I’m a source with a source. That’s why I don’t think the top of the diagram ever becomes an agent. Agents are great at taking a word and making it a thing and on Daiku my sentences become about 20 tickets a day!! But the wanting, the “this is what it’s for”, comes from the only part of the factory that was made in somebody’s image. Paul put that flow into one sentence in Romans 11:36, a long time before anyone drew a diagram of it: “For from Him and through Him and to Him are all things. To Him be the glory forever! Amen.”