I Built the Simplest Software Factory (You Can Copy It)

Author: Leon van Zyl · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: I Built the Simplest Software Factory (You Can Copy It) · Channel: Leon van Zyl · 27:12 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI developer tools

Summary

Leon van Zyl demonstrates a GitHub-based software factory that routes issues to a swarm of Claude Code and Codex agents running in Upstash virtual machines. The factory handles task assignment and status updates, while agents implement changes and open pull requests for human review. The tutorial walks through creating the factory with an agent skill, configuring GitHub and Upstash credentials, connecting repositories, and testing the workflow. It also explains how to use reusable snapshots to configure worker environments and how to scale the agent pool or add repositories.

Key points

A software factory is the workflow system that receives task signals, assigns work to available coding agents, and monitors progress; it is not itself a coding agent.
GitHub issues and labels trigger the factory, which can assign tasks to specific agents or distribute them across available workers.
Agents run in separate Upstash Linux virtual machines, providing isolated environments and allowing work to continue when the developer’s computer is offline.
Agents can test and implement changes, then create pull requests or comment on issues when they need input.
Human review remains part of the workflow: developers can review, comment on, close, or merge pull requests.
The tutorial uses a reusable agent skill to scaffold and deploy the factory without manually writing its code.
The setup requires an Upstash box API key, a GitHub fine-grained personal access token, and a Claude Code OAuth token for the demonstrated subscription-based setup.
Upstash snapshots provide reusable worker environments that can include tools, skills, MCP servers, or AGENTS.md instructions.
The worker pool can be scaled, and new repositories can be connected by updating token access and merging the factory’s integration pull request.

Chapters

Start	Chapter	Summary
00:00	Factory demo and the software factory concept	The video previews issue assignment and pull request review, then defines a software factory as a system that manages a swarm of coding agents.
02:02	The factory workflow and agent sandboxing	The workflow moves from a task signal through triage and implementation to validation and release, with isolated VPS environments for agents.
06:09	Requirements and building the factory with a skill	The presenter introduces the GitHub repositories and Upstash boxes, then uses a reusable agent skill to generate the factory.
09:46	Configuring repositories, agents, and worker boxes	The agent collects the repositories, coding-agent choices, factory repository settings, worker count, and browser-tool preference.
13:23	Adding credentials and deploying the factory	The tutorial configures Upstash, GitHub, and Claude credentials, tests worker boxes, and applies the factory triggers.
18:00	Connecting repositories and testing an issue	The presenter merges integration pull requests, creates a labeled test issue, and verifies the factory’s dry run and agent execution.
21:35	Reviewing changes and customizing snapshots	After merging a test pull request, the presenter explains how snapshots can preload reusable tools and skills into worker environments.
24:08	Scaling workers and adding repositories	The tutorial recreates boxes from updated snapshots, scales the pool, and connects another repository before assigning it a Codex task.
26:41	Final status and closing	The presenter confirms that Codex has picked up the new issue, then closes with a community mention and thanks to the sponsor.

Quotes

The software factory itself is not a coding agent. — 01:31

Each agent runs in its own sandbox. — 05:06

We do not have to code a thing. — 07:43

Our agent should process this for real. — 20:34

Concepts and entities

software factory, Codex, Claude Code, Upstash, GitHub Actions, Context7, create Upstash software factory, Jev, Leon van Zyl, Upstash boxes

Full transcript (original language)

00:00 I’ve been playing around with software factories and I built this one that runs on GitHub. I do like the idea of having a swarm of coding agents, but I really didn’t want another CLI tool or app to manage. I wanted my software factory to live right next to my actual code. So this means all I have to do is create an issue, mark it as ready, and the factory will assign a task to an agent. And I’ve got about 10 agents in my swarm, and this is actually a mixture between Codex and Claude agents. And these agents can work across multiple projects. The factory will actually

00:30 change the labels as well. So we can see it’s currently working on this issue. Let’s try another one. So I can go to labels, we can set this to ready, and I can decide which agent I want to use as well. For this issue, let’s assign a Codex agent. And just to be sure, this is issue 34. And if we go back to the factory, we can see that issue 34 has been assigned to an agent. And if we refresh our agent list, this coding agent is now busy with that issue. Once the agent is done, it will create a pull request, which I can review.

01:00 So this does involve human in the loop. And if we’re happy with this change, we can go ahead and merge it. In this video, I’ll explain what a software factory is, and I’ll show you how to set up your very own software factory within GitHub. But what exactly is a software factory? For a lot of people, it’s kind of that next step with working with coding agents. Instead of you supervising specific agent sessions, software factories give you access to a swarm of agents that are all sort of on standby, waiting for tasks to process. This means we could set up an agent team with like maybe 10

01:31 different coding agents. And those agents are just waiting for tasks to process. Those agents will receive a task, test it, go through our guardrails, and eventually ship the change or create a pull request. The big software factories involve human review as well. This is not a dark factory where the agents are just kind of running by themselves, doing whatever they want. The software factory itself is not a coding agent. The factory is kind of the system or the program or the harness that we develop that will receive some kind of task from a signal.

02:02 This could be a Slack message, a Telegram message, a GitHub issue, something will trigger it. It will then do a review of that change and assign it to an available coding agent. It’s kind of the system that’s responsible for managing the entire workflow. This is a very common factory loop. Like I mentioned, there could be some kind of signal. So there’s some kind of system where people report bugs. It could be GitHub issues. It could be a Slack message. Anything could be a signal that triggers the software factory.

02:32 And then we’ve got this triage step. Now this could be triage. It could be orchestration. It could be a delegation step, whatever you want to call it. Simply see it as in this step, we receive the task. We could, if we want to, run an LLM to classify that step. For example, if you are using Jev, you could use that to maybe classify the change as being a bug, a new feature or documentation. And then that could drive which coding agent the change should be assigned to. Or in my example, I didn’t even include an LLM at all.

03:03 It’s simply a piece of code that runs that will grab the task and assign it to one of the available coding agents. Then one of the coding agents will implement the change. It could validate it by running reviews, unit tests, et cetera. And finally, it will release that change by creating a pull request or maybe even shipping the code. And then the software factory will keep monitoring for any new signals. And you can include as many human gates as you want, like architectural decisions, breaking changes, active incidents, or just reviewing

03:34 and merging pull requests. And this is how we will implement this. Our signal will be a GitHub issue. Our triage step will actually be a dispatcher, which will receive that issue and assign it to one of the available agents. If an agent is not yet ready, it will just keep retrying until an agent becomes ready. Also, if the user assigned the label to assign the agent to Codex or Claude Code, or by the way, you can use any other agent you want. I’m just using Claude or Codex as an example in this tutorial. It will then assign the task to the correct agent.

04:05 Once this agent’s complete, they will actually create pull requests or they would update the original issues with any comments if they run into any issues or they need a design decision. And of course, we will add human in the loop. So you can review the pull requests and decide if you just want to close it, add more comments, or merge the pull request. So why might we want a mix of different agents? Why not just go with Claude for everything, right? Well, the cool thing about a software factory is you can lean into the strengths of different agents. Like Claude Fable is really good at

04:36 writing complex code. And then models like GPT-6 Astra is really good at 3D work. So one example is in your triage step or in orchestration step, you could use an LLM to maybe scan the incident. If it involves any 3D work, it could assign a task to a Codex model. Or if it involves complex coding, assign it to a Claude Fable agent. Or if the change involves a super simple documentation update, it could use a very simple and quick and cheap model. Now, this is really important.

05:06 Each agent runs in its own sandbox. And you might be wondering, why would we want to do that? Firstly, it’s safer to run models in a sandbox. That way they can’t access secrets on your machine, run harmful commands, et cetera. Remember that issues could contain harmful instructions through prompt injection. And if the agent is only running in a contained sandbox, the damage is completely limited. The agents can’t access your laptop, files, your secrets, nothing. Another thing is that each of these agents actually run on their own little VPS.

05:38 This means they’ve got their own hardware allocation, like this one’s got two CPUs and four gig of RAM, which means that these agents are not fighting over resources on your machine. Imagine running 10 or 20 or 100 agents at the same time, all fighting for the same resources. Although please let me know down in the comments if you would ever need that many agents. And another benefit of obviously running these agents on a VPS is that they are always online. So if I close my laptop, the work will continue as per usual. I can go away, I can

06:09 open up GitHub on my phone, log an issue, and one of these agents will create the pull request. All right, enough theory, let’s build our software factory. To get started, we will need at least one GitHub repo for the software factory to manage. So just use one of your existing GitHub repos, or if you just want to be safe, just deploy a really simple to-do app. These repos can be private or public, it’s totally up to you. But just keep in mind if the repo is public, other people could assign issues, and that could trigger your software factory as well. You could always update your triage step

06:41 to only process GitHub issues that were assigned by you. For this video, I am going to use two different repos, so it’s the RTS demo and the to-do app. Then we also need to run our agents in the cloud. For software factories, I don’t really like running agents on my local machine for the reasons mentioned earlier, and one of the easiest ways I found to run agents in the cloud is with Upstash. You will be able to follow along with their free tier. So simply create your Upstash account and go to the box option over here. And if you go to boxes, you

07:12 will notice that we currently don’t have any boxes running. A box is simply a little Linux virtual machine, and our agents like Claude Code and Codex will run in those machines. And then finally, all we have to do is create our software factory. As I mentioned earlier, the software factory itself is not the coding agent. It’s basically the environment or the program or the wrapper that’s responsible for receiving those triggers, so receiving the issues and assigning them to the coding agents and then managing the entire process. So what we’re going to do is get our coding agent

07:43 to build a factory for us. We do not have to code a thing. And then we’ll deploy our factory to GitHub. And what’s really cool is the software factory’s code will run within GitHub itself. You’ll see it’s actually really, really cool. Now setting all of this up can be quite tricky, and I had to reference multiple articles to get this to work. A really good article is this one from Upstash themselves, where they discuss the need to have a separate sandbox per agent in a software factory. There was a ton of valuable insight in this article,

08:14 and I also had to reference a whole bunch of other articles to understand how boxes work, GitHub Actions, and everything we need to build this factory. So instead of boring you with all the technical details, I decided to create a reusable agent skill, which you can install and just get your agent to build the factory for you. In the description of this video, you’ll find a link to this GitHub repo with all of my different skills. And within the skills folder, you’ll find this create Upstash software factory skill. This gives the agent a ton of references of everything that I use to build this software factory.

08:45 So if you really want a deep understanding of how all of this works, you can actually just ask your agent to look at this repo, look at the skill, and just break everything down in detail for you. I didn’t want to waste your time, so I’m just going to show you how to use this skill. But just at a very high level, this is just going to explain to the agent how it can programmatically create these boxes and set up the Claude and Codex agents on those boxes using the different effort levels, the different model names, et cetera. It also tells the agent how to set up that factory loop that

09:16 we had a look at earlier, where we’ll process issues from GitHub, triage them, send them off to coding agents, and eventually get those pull requests back. It also explains to the agent how GitHub Actions work and how GitHub Actions will trigger those events to the factory and will get the factory to update the issues within those original repos. But if this is all too technical, again, you can just ask your agent to explain how the skill works. But if you just want to build the factory, then let’s do that now. Simply copy the link to this GitHub repo, then back in your coding agent,

09:46 just create a new folder for your software factory, and then you can ask your agent, please install the software factory skill, then paste in that URL, and done. So our agent just installed the skill, and all we have to do now is ask the agent to use the skill, or we can just trigger it using forward slash, create Upstash software factory, and let’s send this. So I do want to mention at this point that the agent is going to try to retrieve documentation related to building software factories

10:18 and using Upstash boxes. To help the agent find up-to-date documentation, I do recommend using Context7. So at this point, the agent might actually ask you if it can go ahead and set up Context7. You can just say yes at that point. I’ve already set it up, so the agent knew exactly what to do. If you say no to Context7, everything will still work. The agent will just go online to retrieve documentation using web search. And our agent is just going to ask us which repos we want to link it to. So at this point, you can just take one of your existing

10:48 GitHub repos and give it to the agent. This is simply showing the last few repos that I created, so I’m going to select these two. And let’s click on next. Which coding agents should the workers run, and how do they sign in? But this is where you can tell the agent which coding agents it should use. So if you only want Claude Code, that’s perfectly fine. Just select Claude Code, or if you want to use Claude Code with your API key, you can do that as well. I’ll just use Claude Code with my subscription. I’m also going to use Codex. And by the way, if

11:19 you have other providers that you would like to use, feel free to tell the agent to use those providers as well. Then let’s click on next. What should the new factory repo be? It must be owned by me and Upstash software factory, and those two have already been taken because I’ve obviously practised a few times. I’ll just call this one software factory, and it will be private. I do recommend making your software factory private as well, as there’s really no need for the public to see your software factory. What is your Upstash plan’s box limit?

11:51 How many workers do you want? So I am going to use the free plan, and by the way, you can follow along for free as well. And this is going to propose 10 boxes. I’m actually going to say four boxes, two Codex and two Claude. You definitely don’t have to create 10 boxes. It’s simply suggesting 10 because the free plan with Upstash goes up to 10 boxes. All right, so when an issue has no agent label, which agent type should it take first? Like I showed you sort of in the intro of this video,

12:22 we can assign labels to assign a task to Claude or Codex or whatever coding agent we want to assign it to. So this is simply asking if we don’t assign a label, how should it allocate tasks to those agents? So should we go with Claude first or Codex first, or just spread evenly? I’ll just choose that option. Should the workers get a worker image with a browser tool? Both of these apps are browser apps, and every box gets Upstash’s Chromium by default, but the agent needs a tool such as agent-browser

12:52 in the image to drive it and actually look at its work. So yes, I would just recommend enabling agent-browser. What is the boxes limit on your Upstash account? If you are on the free plan, the limit is 10. If you’re enjoying this video so far, please hit the like button and subscribe to my channel for more agentic coding tutorials. Right, so the agent just scaffolded the factory and it actually pushed it to GitHub as well. We can view it over here. So we’ve got our software factory with a bunch of files. So now the agent is asking us to supply

13:23 these three secrets. I am going to show you how to generate those in a second, but I do want to mention that the agent is asking us to put those secrets in this .env file. This is the most secure way to do it, but if you just want to be lazy, you can just paste those into the chat, but I would actually recommend just updating the .env file directly. So usually that simply means clicking on this file. If you are using Claude Code, you can just kind of click on this link and that will bring up the .env file. And all we have to do is paste in those values

13:54 and this will automatically save any of these changes. For the first one, let’s get our Upstash box API key. Just go to Upstash, then go to box, overview, and under API keys, let’s create a new key. I’ll just call this software factory, just like that. Let’s copy the key and let’s paste it into this file and I’ll press control and S to save these changes. This Upstash box API key will allow our software factory

14:24 to interact with the agents on Upstash. We also need our software factory to be able to interact with GitHub. This will give our factory access to the repositories and it will allow it to pull the contents, create pull requests and issues. In order to create this GitHub token, go to your profile, go to settings, scroll down to developer settings, go to personal access tokens, go to fine-grained tokens, let’s generate a new token. Let’s give our token a

14:55 name like software factory. You can give a description if you want. You can also set an expiration date. I’ll just make it seven days. Then we can also select the repositories that can be accessed through this key. We can select public repositories, all repositories or what I would recommend are the selected repositories only. So this is how we can control which repositories our software factory will have access to. So let’s click on this dropdown. Then let’s select our software factory itself.

15:27 And then any repos we want to give our software factory access to. So if you ever want to include more repositories in your software factory, remember just to select it from this list. But starting out, I probably don’t recommend selecting all repositories. Then under permissions, let’s add a permission. From this list, let’s search for contents. And let’s set this to read and write. Let’s add another permission. Let’s search for issues. Let’s change this to read and write as well. And finally, let’s also add

15:58 permissions for pull requests. And we should be able to read and write pull requests. So your permission should look something like this. Let’s click on generate token. Let’s click on generate token again. Let’s copy the token. And let’s add it to our .env file. And finally, let’s also get our Claude Code OAuth token. This will allow the agents to run Claude Code on our subscription instead of us paying for API keys. To get that token, all we have to do is run this command.

16:28 So in Claude Code, that’s really easy. You can just click on play. And all I’m going to do now is just paste in the key and close the .env file. I am going to delete all of these tokens after the recording, so please do not use my tokens. And now we can just tell Claude. I’ve updated .env. And now we’re getting a few more questions. For Claude Code workers, which model and reasoning effort should be stored in the boxes? We could just go with the defaults, Sonnet, Opus, or whatever we want. I’ll just go with Opus with high effort.

17:00 For the Codex workers, which model and reasoning should we use? I’ll say GPT-6 Astra with high reasoning. All right, so this is really cool. What your agent is going to do now is create two sample boxes within Upstash just to test the connections and to ensure that these agents actually work. We can actually go to the boxes in Upstash and here we can see that smoke-test Codex box. And afterwards, the agent will automatically delete those boxes. And our agent has confirmed that it can create boxes

17:30 and run coding agents within those boxes. It’s going to set up the software factory on GitHub. Now, this message is really loaded. It’s asking if it can go ahead and set up like all the different triggers in the factory itself. So at this point, all you have to do is just say, “Yes, apply both.” Right, our agent’s made very good progress and it is going to get to this point, stage five, where it’s going to ask you to merge pull requests. So just to kind of explain how this works, the software factory will be able to update issues

18:00 and create pull requests on the different repos that it’s managing. But the actual project repos themselves also need some way to fire off triggers to the software factory. So maybe just to give you a quick example, if I go into the project itself and to issues, when we create an issue and we assign a label to trigger the software factory, this repository should be able to inform or signal the software factory that, “Hey, there’s a new issue,” and you need to assign it to an agent and work on it. Now, in order for this

18:31 repo to have that awareness of the software factory, we do have to merge a pull request. So the agent would have created these types of pull requests in those existing repos. So all you have to do is open up this repo, and this clearly says it’s to send ready issues to the software factory. All we have to do is click on merge and merge this pull request. Let me just go to my second repo as well. I’ve got the exact same pull request over here. I’m just going to merge it.

19:01 And this will now allow these repos to send instructions to the software factory. Right, so I’ve now merged those two pull requests, and now we can run a small test. Create a small test issue in one of the repos and add the ready label, for example, that. All right, let’s actually do that. So I’ll go to one of these repos. Let’s create a new issue. Let’s just call this create light and dark modes. I’ll just put that in the description as well. Then under labels, let’s grab our ready label,

19:32 which says factory start work on this issue. So I’ll just highlight that label. Let’s click off it. Let’s create this issue. And if we go back to the software factory repo, we can see what it’s doing by going to actions. And here we can see that issue that we just created. And this ran really quickly because it doesn’t actually use the coding agent yet. It’s just testing that integration between our project repo and the software factory. So let’s just tell the agent. I’ve created the issue, set the label to ready,

20:04 and I could see the action running in the software factory. Let’s send this. You don’t have to provide all of these details. You could just tell the agent that you created the issue. It will automatically monitor for all of these things. And it’s saying the dry run passed. So it’s now going to disable the dry run and get the agent to actually make the changes. But it couldn’t execute a certain command because it was blocked by the permission system. So if you get these messages, don’t worry. All you have to do in Claude Code

20:34 is just click on this little button to execute these commands. And now we can run this for real by removing this label. So let’s actually do that. Let’s re-add the label, like so. And our agent should process this for real. On the software factory side, I can see that issue was pulled in. And if we go to our Upstash boxes, we can see this agent is indeed busy. What’s really cool is if we go back to the issue, we can see the label change from ready to factory running. This is such a convenient way to see

21:05 which issues are currently being processed by the factory. And in fact, the factory just completed and changed the label to factory review. Before we move away from the issue, there are other useful things as well. If we look at the comments, the factory told us that worker Claude02 was assigned to work on this task. And we can also see that this pull request was created. Let’s go to our pull requests. Let’s open up this one. This pull request is telling us that it will close issue 52 if we merge it with all the details

21:35 related to this change. Let’s go ahead and merge this pull request. Now this is working, but we’re not done yet. First, let’s just tell our agent, I re-added the ready label, the agent created the PR and I merged it. But the agent just kind of looked at the logs and ensured that everything worked correctly. It is proposing that we kind of test this en masse now. So we could create multiple issues and see how all of this actually works. Now, of course, if this is your software factory,

22:06 please go ahead and do this. Test this using the different repos that you connected and try to kick off as many coding agents as you want. But I want to show you a really important concept that you need to understand with Upstash boxes. These boxes are very simple. These are virtual machines running Linux. We’ve set up Claude or Codex on these boxes and nothing else. Let’s just assume that you want your boxes to be set up in a very specific way. So for each and every one of these agents, irrespective of what coding agent you’re using, certain skills or certain

22:37 guardrails need to be in place. That is very easy as well. And instead of defining these per box, what we can do is create a snapshot. So what a snapshot does is we can define an environment and then when we create our boxes, we can create those boxes from that environment. That’s kind of like setting up a reusable template. Now, in this instance, our agent already created two snapshots, one for Codex and one for Claude. Now, I’m pretty sure these are very simple. This simply installs Codex on the one and Claude on the other.

23:08 But let’s say we wanted to create a snapshot that already includes a whole bunch of agent skills that we want all of our agents to have access to. What we can simply do is ask our agent, please create new snapshots for the Claude and Codex boxes that have the following skills preloaded. And for argument’s sake, let’s say I wanted the frontend-design skill to create these agents. I can just paste that in here. Maybe I also want the agent-browser to be available so I can add it in here. Whatever, I think you get the idea. So at this point,

23:38 you can just pass in any skills or MCP servers or your AGENTS.md file. Whatever you want to be available on that box, just tell your agent to create a reusable snapshot. So this will now create or update our snapshots and deploy them to Upstash. So when we create new boxes going forward, these will inherit all of these skills and whatever we want from the template or snapshots. All right, Claude just created these new boxes. And what’s very important is Claude is not able to delete boxes. So Upstash does not

24:08 allow agents to delete boxes or snapshots. So you do have to do that yourself. I’ll just grab these old images. Let’s delete them. What I’m also going to do is actually delete all of our existing boxes. So let’s do that. And let’s go back to Claude. I’ve just deleted the old snapshots and all of the available boxes. Please recreate the boxes using the new snapshots. Right, let’s see this. And cool, we can see that Claude is now creating these new boxes. So every time we refresh, we can see a new box coming in.

24:39 In fact, this might be a good time to show you how to create more boxes. So let’s say, in fact, I want 10 boxes split between Codex and Claude. Let’s do that. And that’s how easy it is to scale up our agent swarm. Claude is now creating six additional boxes. And if we refresh Upstash, we can see the new boxes are already being added. How easy is that? Now, finally, you might be wondering, well, what do you do when you want to add a new repository? Well, the process is the same, whether or not you want to add or remove repositories.

25:10 So let’s assume I want to add this little repo as well. Well, the first thing we have to do is go back to our settings. Let’s go back to developer settings. Let’s find that fine-grained token, which we called Software Factory. Let’s go to Edit and under Select Repositories, I’ll select that new repository. And let’s click on Update. Cool. Of course, if you selected all repositories, this step wasn’t needed. Then we can simply open up our Software Factory using Claude Code or whatever we were using.

25:41 And let’s simply say, please add this repo to the Software Factory as well. And let’s paste it in there. Claude is saying that the token can reach that repo. If you do run into issues here, just ensure that you’ve updated that personal access token. And just like before, our agent will open up a pull request and this will allow this repo to send those instructions to the Software Factory. So all we have to do is go ahead and merge this pull request. Let’s then try to create a

26:11 new issue for this project. And I’m not sure what change can we make to this app. Maybe we can just add dark mode. So let’s say, Add Support for both light and dark modes like so. Let’s create the issue. Then under labels, let’s set this to ready. But let’s also assign this to Codex as Codex is really good with 3D work. And this app is highly reliant on 3D stuff, right? And let’s see if the Software Factory actually picks this up. The Software Factory is processing this.

26:41 This label, Factory Running, has been added. And we can see this comment saying that Codex01 has picked this up. How cool is that? Let’s go back to your Upstash boxes. And here we can see Codex01 is indeed working on this task. And if we go to the actions on the Software Factory itself, this is indeed running. How cool is that? If you really want to learn how to work with coding agents, then consider joining my Skool community, Agentic Labs. This will give you access to more exclusive courses like the Agentic Coding Masterclass. This is where I teach you all the fundamentals

27:12 of using coding agents. And we build full applications that include payment processing, user authentication, and a lot, lot more. This also gives you access to live sessions like our Tuesday Coffee sessions and the Thursday Deep Dive sessions. I also want to thank Upstash for sponsoring this video and I highly recommend checking this out. I’ll see you in the next one. Bye-bye.