Big Idea

The argument in one line.

A working AI software factory is just an orchestrator skill plus four subagent roles, spec-writer, builder, reviewer, approver, wired into a loop and backed by plain markdown files instead of conversation memory.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You already use Claude Code daily and want a repeatable system instead of re-prompting from scratch for every feature.
You're comfortable defining Claude subagents and want a concrete, working orchestrator-loop example to copy into your own repo.
You run a small codebase or side project where you're the sole reviewer and want AI to handle a first-draft review pass before you look.

SKIP IF…

You need enterprise compliance, audit trails, or multi-team governance — this is a single-developer, single-repo demo with no access controls.
You're not yet comfortable giving Claude Code bypass-permissions and autonomous commit access, which this whole setup depends on.

TL;DR

The full version, fast.

A developer live-builds a small AI software factory inside his real website repo using Claude Code. One prompt creates an orchestrator skill plus five subagents (spec-writer, builder, four parallel reviewers, and an approver) that turn a plain-English feature request into a reviewed pull request, auto-merging clean low-risk changes and escalating business-judgment calls to a human. State lives entirely in markdown files, not agent memory. He then adds git worktrees so multiple features build in parallel, fixes a live bug where an unrelated dirty file silently blocked an approved merge, and closes with what's still missing: issue-tracker intake, application metrics, and infrastructure observability.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 03:48

01 · Why build a software factory

He previews the finished pipeline (spec-writer, builder, reviewers, approver, merge), then traces the term back to Bob Bemer's 1968 proposal and Hitachi's 1969 factory before landing on 'agentic factories' as the next stage after CI/CD.

03:48 – 10:20

02 · Building the factory inside a real repo

He pastes one prompt into Claude Code (Opus, high effort) asking it to build the whole system as a project skill, subagents, and markdown job files, directly inside his own live website codebase.

10:20 – 16:16

03 · Running the first feature through the loop

He submits a real feature request (course pages shouldn't be paywalled), watches spec-writer, builder, and four review agents fire in sequence, then approves the escalated job and confirms the merge landed as real commits.

16:16 – 23:57

04 · Running three features in parallel with git worktrees

He adds git-worktree isolation so multiple jobs can build at once, races an Opus-orchestrated session against a Sonnet one, and fixes a live bug where a dirty backlog file was blocking auto-merge.

23:57 – 28:02

05 · What's missing and what's next

He lists the gaps (GitHub issues as intake, application metrics like Sentry, infrastructure observability), reflects on token cost under a flat-rate plan, and closes on a 1992 quote about software factories and reused experience.

Atomic Insights

Lines worth screenshotting.

The term 'software factory' predates AI by 57 years: Bob Bemer proposed it in 1968, and Hitachi opened one in 1969.
What's actually new about AI-era software factories isn't the trigger-to-merge loop, it's automating the unstructured cognitive work between the deterministic stages.
A functioning Claude Code factory can be four subagent roles, spec-writer, builder, reviewers, approver, wired into one orchestrator skill, with no external framework required.
The approver agent escalated a fully-passing, four-review-clean feature to a human anyway, because it touched paywall logic, a business call rather than a code-quality one.
An auto-merge can get silently blocked by an unrelated dirty file, like an uncommitted backlog.md, with no error that points at the real cause.
Git worktrees let the same repo run multiple agent-built features on separate branches in parallel without them colliding.
Swapping the orchestrator from Opus to Sonnet didn't meaningfully speed up a job, because the Opus-run review subagents were already the bottleneck.
Given a vague 'build what's useful' prompt, the system proposed its own backlog: a reading-time estimate, a code-block copy button, and a 404 page.
All of the factory's state lives in plain markdown files in the repo, not in any agent's conversation history, so any session can pick up a job mid-flight.
Sub-agent pipelines multiply token cost because context gets re-passed between agents at every stage, but that cost disappears on a flat-rate plan instead of metered API billing.

Takeaway

What a working Claude Code factory loop needs

WHAT TO LEARN

A software factory is four subagent roles and a markdown job board wired into a loop, not a framework, and most of what breaks it is file hygiene, not agent intelligence.

A software factory is just four roles wired into a loop: a spec writer, a builder, a bank of reviewers, and an approver that decides merge-or-escalate.
Keeping agent state in plain markdown files instead of conversation memory means any agent, or the human, can inspect or resume a job at any point.
The approver's job isn't code quality, it's business judgment: four clean reviews can still get escalated to a human when the change touches billing, access, or pricing.
A merge should only fire on a clean working tree; leaving an unrelated file dirty, like an uncommitted backlog, can silently block an otherwise-approved feature.
Git worktrees let multiple agent sessions build unrelated features against the same repo at the same time without fighting over branches.
The orchestrator should run on the smartest available model; routing it to a cheaper model doesn't speed anything up if the subagents doing the real work are still the bottleneck.
Letting the system propose its own backlog turns a blank 'what should I build next' into a running list you only have to curate, not generate.
None of this requires a framework: one markdown skill file, a handful of subagent definitions, and a loop you fully own and can edit yourself.

Glossary

Terms worth knowing.

Software factory: A development pipeline, human-run or AI-run, that takes a feature from request to shipped code through a standardized, repeatable set of stages.
Orchestrator (agent): The top-level Claude Code session that reads the factory's job board and spawns every other agent in sequence; it writes no code or specs itself.
Subagent: A separate, narrowly-scoped Claude Code agent, such as a spec-writer, builder, reviewer, or approver, that does only its one job and writes to its own file.
Approver agent: The subagent that reads a finished feature's reviews and decides whether to merge it to main automatically or escalate it for human sign-off.
Git worktree: A second working copy of the same repository checked out to a different branch in its own folder, letting multiple agents build different features in parallel without touching each other's files.
Bypass permissions: A Claude Code setting that lets an agent run commands and edit files without asking for confirmation each time; used throughout this demo.
MCP (Model Context Protocol): The standard Claude Code uses to pull in live data from outside tools, for example feeding a Sentry incident straight into an agent's context.
Needs-human / escalate: The state an approver agent puts a job into when its risk or judgment call exceeds what it's willing to decide on its own, parking it for manual review.

Resources

Things they pointed at.

00:00productClaude Code Max plan ↗

01:10channelZazenCodes newsletter (agentic workflows guide) ↗

03:31channelAgentic Coding Club (Skool community) ↗

08:45toolLazyGit (terminal git UI, referred to on camera as "LazyGet")

25:00toolSentry

28:02linkSoftware factory source code (GitHub) ↗

Quotables

Lines you could clip.

03:03

“What's new is the automation of relatively unstructured cognitive work between the deterministic stages, including, of course, writing the entire code itself.”

tight, quotable definition of what's actually new about agentic coding→ newsletter pull-quote↗ Tweet quote

19:06

“Sonnet is flying though. We're already on the builder phase for that. Oh, this is like a race, dude.”

genuine excitement during a live parallel-agent demo→ TikTok hook↗ Tweet quote

19:42

“This is your own very simple skill for your own software factory. And you know exactly how it works, right?”

the own-your-tools thesis stated in one breath→ IG reel cold open↗ Tweet quote

27:51

“There is no improvement that is not based on reuse of prior experience.”

sourced 1992 quote, strong closer for a clip→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphorstory

Today we're building a software factory with Claude Code. Thank you to Anthropic for sponsoring today's video. I love using Claude Code.

Of course we're going to be building Claude into our software factory. We'll be using a mix of Opus and Sonnet and we're on 5 .5 as time of filming. Everybody agrees that these models are incredible so I want to show you what these can do.

This is going to be a very simple factory but as you'll see it will still be very effective. The idea is that you can build one for yourself inside of an existing project so I'd encourage to follow along with the video this video will be very hands -on i'm going to explain exactly what we're building with our software factory what our approach is going to be and we'll do a quick introduction of what software factories actually are here's the mind map for today's video so over here on the right is the demo and i'm going to explain this diagram first for anybody who already knows what a software factory is then we'll go through this left side and i'll sort of explain a little bit of a history on these things but if you want to review this you can get this full thing as a high quality image if you subscribe to my newsletter.

I'll just send it right to your inbox right away. You can look through it with me. Let's actually jump over here.

This is what we're going to build. It's a simple agentic software factory where a team of agents take a feature and pull that into the main code base by the end of our factory. So we input some feature request and then the rest is handled autonomously except for this last step, this human approval step.

Let's walk through this. First thing we do is write a spec and I'm going to use Opus for that. Then we're gonna go to a building agent, which is actually gonna build our feature.

This will build the full working feature for us. Then we're gonna hand this feature off to various review agents. We're gonna do a security review, a UX review, a UI design review, and a code review.

And these are all done with separate agents. Some of them are Opus, there's Sonnet in here, and then this gets fed back into the builder agent. And this happens in a loop until we're happy, satisfied with the code.

And then we go to an approval step. This runs with another agent, which is Opus and then Opus decides, this agent says, either we merge to main automatically or we hand it off for human review.

And this is all managed through our. factory that I'm gonna build today. So if you're ready to go you can use the timestamps in the video description to skip right to where we start building this.

Otherwise stick with me and I'm gonna walk through the rest of this mind map. Software factories were first described by Bob Beamer at GE in 1968. Essentially they're a computer -controlled programming environment containing standardized development tools along with historical information for management and measurement.

And... The short history of that is from there, we saw a lot of stuff going on in Japan. And I'm sure this was happening in Europe and America as well, to some extent, but that's what was characterized the early stage of software factories.

Then in the 2000s, we didn't quite have the CI CD stuff going on, but it was like, how can we have reusable patterns, models, and frameworks to be building software? Then in the 2010s, 2020s, this is where we got CI CD. So proper continuous integration pipelines, GitHub actions.

And now we have agentic factories. So here's what a soft. factory looks like in the age of AI.

And I love this quote. What's new is the automation of relatively unstructured cognitive work between the deterministic stages, including, of course, writing the entire code itself. So this is the basic loop.

We have a trigger. which goes to an agent, which submits a PR, which is merged by a human. And inside of here, we have all sorts of clever stuff going on with the agent, pulling in information.

And this is where the interesting graphs come about with software factories. There's a lot more details I skimmed over in here. I'm gonna cover this in my school community on my weekly calls.

And I record all of these and post them back to the community. So if you wanna keep hearing me discuss software factories, you can join my school community and check that out. Now, let me get onto the build with Cloud Code.

And we're gonna start here, and I'm gonna paste this prompt into Claw to start building things. And this is the whole prompt we're gonna use. So I've got this prompt in the source code for this video.

You can find that in the video description, and you can reference that if you want. At this point, if you're following along with me, you wanna start working in an existing project that you have. This is the source code for my website.

It's a real ugly project. There is a lot of stuff going on in here. We're gonna build a software factory right inside of my website, and I'm gonna I'm going to start by spinning up Claude code and you'll notice that I've got bypass permissions on.

So this is going to let Claude do whatever it wants, but you can set this to your level of comfort. And the first thing I'm going to do is change my model. And I want to use Opus 5 .5.

I'm also going to set the effort. And for this task, I want to use high effort because I want it to produce a very high quality result. and I want it to follow all of the details in this prompt.

Let me paste the prompt in, and I'm gonna press Control -G, and I can open this prompt up in my sort of default editor. And so I can also get out of this and see it in Claude. Here's the sort of one -sentence description of our spec.

We wanna build a simple visual software factory in this repo using Claude's skills, subagents, and markdown files. The markdown files are gonna control the state of our application. Now, the orchestrator is very important for my software factory.

orchestrator is going to be Claude code using whatever model I choose at the time and then I'll run this Factory skill in order to spin it up now from there the factory works in this loop which I described or earlier a feature comes through the spec writer which goes into the Builder which then gets verified by various review agents and Once those are done if we need changes this happens in a loop and then we go to the approver which either Merges to main the feature or we get a human review And this is a system we can use repeatedly every time we want to build a new feature for our project.

That's the power of a software factory. And this is why everybody's so excited about these things right now. And we could imagine in the future, we want, you know, we can bring in data sources from the outside world.

And we can also have other things like we can have stuff that triggers this instead of a feature. So this is still my prompt, by the way. Let me come down and continue talking through this.

You can see we're setting this up as a skill. And this is the convention for how agent skills should look. And we've also got this factory folder.

So we'll live right inside of the app that I'm working in. And then we have some example files just. to give the right style.

So this is how Cloud Subagent syntax should look. So I have some examples of what this should look like, but we're mostly gonna leave this up to the agent to build all of these things. And then here's the commands that I wanna have.

I wanna be able to start a new job through the loop. That's done here, like just using factory and then describing my feature. And then lastly, I've got a dashboard and this is gonna give us some visibility into this whole system so we can kind of tell what's happening while everything's running.

So let's kick this off. check out this the orchestrator skill looks like this i feel confident that with a long -running agentic task like this we can really nail all of the little details in this and if you've used opus you know exactly what i'm talking about you can throw any little small detail and it's extremely good at picking these up and propagating them through the code as it builds everything out now it's building out the reviewer agents so these all live as clawed sub -agents and these are going to be the guys in our software factory doing all of our work.

Here's the reviewer UI agent. Claude has just finished up. The last thing it was working on was the dashboard for our factory.

That's what it created right here. So let's look at these decisions. Max two rounds.

That works for me. Your checkout. The builder works on factory.

Okay, so this is the branch that we check out to build our feature. That's cool. That works.

And then we have this rework method. If it didn't work, we can just like spin it through again. So there's some discussion about what the approver should escalate.

If we're doing anything, with billing let's make sure we escalate that anything with course access this is stuff that's specific to my own repo so you know the agent will be specific to yours too that's another cool point like this prompt that i wrote this will be general for any anything this will work for your project just as well as it did for mine because it's not at all adapted to my project uh really cool so let's restart clod code so it loads the new agents and then run factory next All right now I have a question though When I run factory next what would that do?

I don't think I have anything next yet, right? In other words like I don't have any features that I'm expecting to build so I don't think that would work what I want to do is run factory and then describe the feature that I want to build also go ahead and spin up the dashboard Oh, what?

The backlog actually has some stuff in it. I put three starter items. So Opus just figured out what I should be building next.

That is hilarious. And here's where the dashboard's running. So there's nothing going on yet.

Everything's empty. Let's spin up our first job. Before we test it, though, let me show you exactly what we just built.

So let me go to my project. And I'm going to open up this tool I have called LazyGet. And this way we can see all the changes.

So we built out a bunch of agents. These are all of our sub -agents, the things that are doing the work. inside of our factory.

This is our approval agent, builder agent, reviewer agent. Let's go back down. Here's the skill.

This to me is like the main thing that's controlling the factory. It's the agent skill that we're gonna use to like spin it up. It's the orchestrator skill, effectively.

That's how we can think of this one. And then we've got a bit of code in the factory itself, but very little. We have this backlog markdown file, and this is just gonna track our jobs, like the stuff that we haven't built yet that we wanna build out later.

And then we have a dashboard. And this will give us observability. I showed you that already.

And then just a few modifications to the agent's file. Get ignoring some stuff. That's it.

That's it, you guys. I can also show you this in Vim. and let's just look so this is kind of basically our factory this is the orchestration scale and it just documents like different ways that we can use this so this is what i'm talking about right here we have factory slash feature so now inside of cloud if i was to type backslash and start typing factory here it is this is my skill which has been indexed by cloud code and i can call it directly i can also look at skills and i'll see this in the list of skills if i just search factory.

And this is it. You can see it's a project skill. just for this project available because it's in that .cloud slash skills.

So let me just quickly hop back. We're on this step right now, running the factory. We're going to watch how this actually proceeds.

And I've got this kind of feature that I want to build. So my Obsidian agent setup course pages should not be paywalled. Only the videos are paywalled.

Let's see if our factory can handle this feature inside my actual website. This is my production site that we're working in right now. So it didn't start the job.

The factory's first precondition, a clean working... isn't met. I never committed any of this code.

I'm actually going to commit this myself, like old school. Add cloud code software factory. Push that.

All right, now I'm going to start this again, but I want to clear it. And from here, I can run factory. and submit my feature.

It's creating the job, obsidian course unpaywall, and now we can see we're starting to use our subagents. Here's the first one. We're creating a spec using the spec writer background agent.

Let me hop over, and now I'm in the agent itself. So I'm looking at the subagent, and I'm seeing what it's doing. It's creating a spec for me.

So now the spec is done. We can see here we've written to a spec file, and I can see our builder has just started working on this. So let me go back to the orchestrator and check out what happened.

It was like, okay, our sub -agent finished. It kind of picked this up, and then it opened the builder. And the builder down here is now down here.

And this is now our sub -agent that's building this out. And by the way, I want to look at this in a dashboard. Let me go over here and spin up the Software Factory dashboard.

Yeah, it's making edits to the code. All right, so this is where we're at. So this is really neat because you could actually imagine we could be doing other stuff like at the same time I'll also note up here.

We have a needs human phase. So anything that gets like stuck in here We know that we would need human review at this point So this is a like a real functional way that we could be using the dashboard. Oh nice.

Check this out It just wrote a build file right here. It wrote this file to our factory. Okay.

Now we're back in maine and our agent okay sweet we just went to review and we just kicked off all of our review sub agents so these guys are representing our review they're doing it okay the ux round finished the ui round finished and they passed so both of those passed but we're doing the security over here considering okay that's done code review this is this is epic oh look at this you guys we can even see the little icons oh my god that is so cool it's deciding if this feature should be pulled in or not i'm actually blown away this is uh this is how i want to develop features now um why have i not done this yet so uh what's opus deciding escalating it's escalating so i think it'll go to the human review there it is so it's sitting in the human review phase and now i need to approve this what happens if i click on this Okay.

I can get all sorts of information from the dashboard. That is very cool. Escalate.

Why? The build is clean. Every acceptance criteria for the human.

For the human. So here's how I would approve it. I would need to know the ID of this feature and then I could run factory approve.

Let me do that in a new session. So I'm going to clear this and I'm going to say factory approve and then this. And we're done.

It has merged it into my actual code. Now I can have a look at that. So down here, this Claude guy was just running my...

Okay, I'm going to come down here. Okay, this is my source code. And if I look at the git status, I'm ahead by four commits.

That's because... I've just committed this. Merge factory one obsidian course on paywall.

This is the thing that was done by the agent. And I can look at that guy. If I look at the previous commits, this is what it did.

So it went off onto a branch. It did a few different commits. It kind of built out our feature.

And then it merged it back. And that merge was done when I approved it. Very cool.

Now I want to stress one thing if I come up here. When I said factory approve, what's actually happening here is I have a skill, an agent skill called factory. And when I run that, we trigger the agent skill.

Then all of this other stuff in here, this is just free form. So this is not actually like a strict schema or a strict spec for saying approve. Now let me show you where the metadata for this system lives.

And this metadata is responsible for populating all of the information we're seeing down here. These just live as markdown files in our project. If I go into factory and then I look, all the files inside of here this was the feature we just built and all of these files are the metadata that we're populating inside of our dashboard down here i love how simple this is i can just like look at this stuff in vim myself and review this agents can use this future agents other systems this is so cool for me the one thing i'll say is we probably don't want all of this stuff committed to git of course they're just text files there's nothing wrong with committing them all to Git, but it just kind of might mess up your fuzzy searching as you start doing file searching and stuff like that.

It's something you can decide what you wanna do. For my part, I don't think I would want these committed to Git. So if I look in my Git ignore at the factory, you can see we're not committing any of this.

So Claude already decided we shouldn't commit this stuff. So these things are transient and they'll be deleted if you were to reclone the repo elsewhere, unless you were to back them up with like some custom process, which by the way, is exactly what I would do.

I would just throw them into cloud storage somewhere and I would get the agent to manage that. If you wanna learn more about what I'm talking about there, you should join my school community. You can ask me or just join my weekly calls.

I talk about these types of things all the time. This is how developers are building with coding agents now. And speaking of building with coding agents, let's keep developing this with Cloud Code.

What I wanna do is be able to support running multiple things through the software factory at once. Right now, that won't work too well because... We're not using git work trees.

So let's build this in right now. Have a look at my software factory I want to be able to run multiple features through the factory at once and in order to do that I think we'll need some sort of git work tree integration You know, I just realized I could have used the software factory to build itself. That would have been awesome anyway we got this done now let me start a new session so what features should we build let's go into our factory and i've got this backlog here let's have a look at that estimated reading time next to the date on the blog post okay let's do that add a copy button to code blocks sure let's do that add a four four four this is great these are all things i should have on my site that's nuts that opus just came up with those on the fly as it built like the dude These things always just blow my mind.

All right, let's go factory next. Are we ready? Let's go.

Now, the point of this is to do multiple of these in parallel. And we just ticked this off, so we picked that one up. Let's do it.

I'm going to start a new session down here. And I want to start these in separate Tmux areas just so that I can watch all of these go. Let's start up Claude.

and let's say factory next all right now we've established in our top agent we've started doing some spec writing and stuff um what's going on down here oh here they are so they've just two of them have entered we have two new features that have entered the factory and let's do a third one why not All right. Now one thing I should show you is, you know, the orchestrator will be whatever agent we've spun up here.

So I've got Claude Opus 5 -5. Just for fun, let's use Sonnet here. I'm going to say model, and we're going to go to Sonnet 5 -5.

And let's see what happens if I put it on low effort. Why not? Let's try it.

Factory, next. What feature is this one? This is my last remaining feature, which will be the 404 page.

should be very fast so i would expect that this feature might finish fast but on the other hand the orchestrator is not necessarily the limiting agent right what's going to limit this are the the sub agents and right now we're in the spec writer phase and you know this sonnet session is still going to be limited by the speed of the sub agents which we're still using opus for and in fact we might want to use a small model to to actually do the orchestration i don't think so though my intuition is that we want a really smart model to be the orchestrator.

And then some of the sub -agents can use lower models, faster models that aren't as good. And that's been the approach for my software factory. That's how I approach this.

Sonnet is flying though. We're already on the builder phase for that. Oh, this is like a race, dude.

And this is all just, this is just working with get work trees, right? Like it's... It's just working.

I don't really need to worry about it. I don't need to be messing around and switching work trees. Also, we just built this ourselves.

This is your own thing. You just built it. You can change it.

You can do whatever you want. You're not relying on some dude's factory skill that is all hyped and you found it and it does a million things. This is your own very simple skill for your own software factory.

And you know exactly how it works, right? And when you want to change it, you know how you can change it. I think this is so important.

And I think people are just totally missing the point right now with just following big things and starring everything on... on GitHub and thinking they have to keep up and be trying everything. Really what you have to do is understand the core concepts and how we can use coding agents to be doing the things that everyone's so excited about.

And then just making it work for you to give you actual productivity. And I will argue that what I've done here is actual productivity. Like I'm watching three agents crush through features on my website, working in their software factory.

Damn. What a world we live in. Okay, our Sonnet agent is in review, and it just kicked off all of the reviews.

And I think this is probably my favorite part of the UI, how we can actually watch these results come in. Oh, okay, our blog reading time feature is getting pushed through as well. Now the blog reading feature actually does have a UI and a UX component to it, whereas these other features didn't so much.

So I'm curious if maybe it will get rejected. I doubt it. I mean, we'd used Opus to build it.

What would be kind of crazy is if we tested out like a really dumb agent as the builder and then got Opus to keep like fixing and judging the dumb agent. That would be pretty fun. Oh, okay.

Needs human. The 404 one needs human. I have a feeling we're going to need to lax the guardrails.

I think like all of these things, Claude is going to figure out some reason to get me to look at them. So that's something we could work on. That would be a way to work on our factory, make it more efficient.

The approver agent's taking a long time. Okay. It needs human as well for that one.

This is actually legit. Claude doesn't want to invalidate my blog render cache. That'll take a little while to run when it...

when we merge this feature. So that's fair. As for the 404 reading block, I'm a little confused.

We seem to have approved this, but there's nothing for the human. But it still needs a human call. So I'm going to investigate that.

Why did this not get automatically approved and merged? Merge only runs when the main checkout is clean. And on main here, we have some stuff.

So that failed. Okay, so the software factory is kind of being dumped. We have changes to the backlog, so it couldn't commit that.

those changes are inevitable whenever we're using the software factory therefore they should not be blockers now of course it's unfortunate that i'm talking to sonnet to do this i mean sonnet's certainly quite capable but i would want to use my best agent to be working on my factory it's like the most important thing in my code base right yeah so it's specifically saying this file is okay if there's changes in it so that's cool so hopefully that would work properly next time but let me bring these in so I've got two things to approve and I can do that now there's this factory approved command but I could just be like okay merge it in now so you know if I'm being real like that's how I would you know that's how I would do this But in the idea of the factory is that we've actually got inputs coming from things I don't control.

Like I'm not necessarily spinning up an agent in a software factory. Maybe it's starting from other triggers. I'm going to talk about that in just a moment in my closing thought.

But let me finish this up. So I've merged this in. So we actually updated the metadata.

So I can see that that was merged in over here. And meanwhile, this other guy is actually still working. So adding a copy button in code blocks.

Yeah, that's a little bit, maybe a bit of it. tricky feature, clearly. Oh, this is hilarious.

So this one won't merge because of the changes that I just got Sonnet to make. Okay, yeah, update and commit, like add those separately and then merge this in. Oh my God, I can barely speak.

Opus got me. There we go. That one's done.

What a beautiful thing. Now let me go back to the mind map and I'm just gonna finish everything up by having sort of a look at what we would wanna do in the future going forward for this. Here's four things that we could do now to get our basic software factory running better for us, to be more effective.

And the first thing we already did. We added Git Worktree support so that we can run several jobs in parallel, and we just demoed that. Sick, right?

Next thing we can do is GitHub issues as the intake or other things. For example, maybe we can trigger this from Slack. GitHub issues are a really great sort of way to do this because the issue could be submitted by many different people.

It's tracked inside of GitHub, and we can sort of integrate naturally with GitHub in this way. So you see a lot of people doing this. There's a lot of videos on YouTube to do that.

we could easily extend our system to use that as an input source for our system. Next would be to connect to application metrics. For example, we could connect to Sentry.

This is like a monitoring platform for applications and then we can pull direct bugs like from our app in production and just pull these into the software factory to get the relevant context about what feature we're trying to push through it. This is like really critical for software factories and it sort of reminds, it sort of brings to mind these original ideas software factories that were proposed like all the way back in the 60s, like I talked about earlier in the video, how we want access to like monitoring and metrics.

And other metrics that we might want are infrastructure metrics like CPU and memory. And the reason we might want those is so we can keep an eye on things after the deployment. The software factory can actually handle the post deployment as well and keep watching things because if we build a feature that wrecks our software, we can undo it as part of the software.

factory. It can be still in the loop even after it's published, right? It's not done once it's been pushed to production.

This is the future we're going to. This is the future we're already in. Wow.

I kind of got goosebumps like actually saying that right now. Thank you to Anthropic for sponsoring today's video. If you aren't using cloud code, then you can click the link in the video description to sign up now.

I hope you followed along with me though. I hope you were doing this as we went and I hope you have your own software factory now for your own project. Now, here's a few things that I think we should consider.

Stuff I haven't talked about yet in the video. The first one is, I guess the elephant in the room and that's around cost. Like, yes, I think this system is probably building.

out really effective features for me. I've got good observability. I can go into the sub -agents.

I can see the logs. From a data and quality perspective, I think it's really good. I think it's top -notch, but it's going to cost more money.

there's no way around it anytime we're using sub -agents that's could incur extra costs because the agent has to pass contacts back and forth so the question is is this token cost worth it for quality now all of this was on my plan this is all part of my clawed plan i'm not using api tokens for any of this that's something to consider i think that's hugely beneficial right so uh yeah so these are like just a couple considerations uh despite these things this is absolutely what I'm going to do.

Like I'm going to be building a lot more of these. And so that brings me finally back around to the channel. I'm going to end this video now, but I want to keep building stuff like this.

And I've got a few more videos about cloud code coming your way. So I'll link these here when I'm finished. If there's anything you'd like to see, leave me a comment to let me know.

Thanks for watching.

The Hook

The bait, then the rug-pull.

The cold open doubles as the sponsor read: a software factory built from spec-writer, builder, reviewer, and approver subagents, wired into one orchestrator skill, that takes a feature request from idea to merged pull request with a single human click.

Frameworks

Named ideas worth stealing.

03:10model

Agentic Software Factory 101 loop

trigger
sandbox
agent
checks
PR
human merge

The classic CI loop extended for agents: triggers (GitHub issues, Linear/Jira tickets, Slack commands, schedules, incidents) start a fresh per-run sandbox; diagnostics like stack traces and metrics are pulled in automatically; the agent's own checks (tests, code review, secret scanning) gate a PR that a human merges.

Steal forany repo that wants a repeatable, auditable AI-assisted PR pipeline

05:41model

The factory review-and-approve loop

feature
spec-writer (Opus)
builder (Opus)
security/ux/ui/code review (mixed Opus+Sonnet)
approver
merge to main or needs-human

A feature request goes to a spec-writer, then a builder, then four parallel review agents; the builder reworks the change until all four reviews pass (max two rounds), and an approver agent makes the final merge-or-escalate call.

Steal forany team wanting AI gatekeeping in front of a merge button

02:33list

Short history of software factories

1968 - Bob Bemer proposes the idea
1969 - Hitachi opens the first software factory
2000s - apps as an assembly kit of reusable patterns and frameworks
2010s-2020s - factory as a delivery pipeline (CI/CD, automated tests, security checks)
Now - agentic factories (AI plans, writes, tests, and reviews the code)

A five-era timeline framing today's AI coding agents as the latest stage of an idea that's been evolving since 1968, not a brand-new invention.

Steal fora talk-track for why AI dev tooling is evolution, not novelty

CTA Breakdown

How they asked for the click.

VERBAL ASK

00:00product

“Get started with Claude Code on the Max plan — this video is sponsored by Anthropic.”

Delivered as the opening line before any content (a classic pre-roll sponsor read), then repeated at the very end with the same link, plus a push to the Skool community and newsletter.

MENTIONED ON CAMERA

00:00productClaude Code Max plan ↗

01:10channelZazenCodes newsletter (agentic workflows guide) ↗

03:31channelAgentic Coding Club (Skool community) ↗

28:02linkSoftware factory source code (GitHub) ↗

FROM THE DESCRIPTION

PRIMARY CTAWhere the creator wants you to go next.

OTHER LINKSAlso linked in the description.