YT YouTube2Text

YouTube2Text → Transcripts → Build a Better Software Factory with Claude Code

Build a Better Software Factory with Claude Code — Transcript

by ZazenCodes · 6,956 words · 967 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Today we're building a better software
0:01factory with Claude code. Thank you to
0:04Anthropic for sponsoring today's video.
0:06In the last video we built a basic
0:08software factory that can live inside of
0:10your project. People really seem to like
0:13this, like a lot. And there was also a
0:16lot of great feedback about how I can
0:18make that software factory better. So in
0:20today's video I did that. It uses GitHub
0:23issues, it submits PRs, it does multiple
0:25jobs in parallel from a single
0:27orchestrator, it uses Fable and Haiku.
0:30And it also has some more deterministic
0:31steps so that we're producing higher
0:33quality code from our factory. In the
0:35hands-on section of the video I'll start
0:36by showing you how to install this
0:38inside of your own project. I'll be
0:40doing that for one of my projects and
0:42demonstrating how to use it. I would
0:44highly encourage you to follow along
0:45with me in that part of the video.
0:47Here's the full mind map from the video
0:49and you can get this if you sign up for
0:50my email newsletter. I'll send you this
0:52image that you can use as reference. The
0:54big things going on here is this is the
0:56factory. I'm going to explain this soon.
0:58This is the prompt that use to install
1:00this in your own project. Here is my
1:02previous video on software factories. If
1:04you didn't watch that, what I did was I
1:06built a modular software factory that
1:08can live inside of your project. This is
1:10driven by Claude code sub-agents. If you
1:12want to learn more about the historical
1:14context of software factories, I still
1:16recommend watching the start of that
1:18video. Otherwise, this video will have
1:20everything you need. Here's what's new
1:21in V2. We have an intake step which uses
1:24Fable. We've got better routing using
1:26Haiku agents and this is more dynamic.
1:29We have more determinism built in so
1:31that we're doing more tests throughout
1:33the pipeline so that our software
1:35factory is more reliable. It runs on
1:37GitHub issues. This is the input and the
1:39output is a PR that gets pushed to our
1:41GitHub project. And we have better
1:43observability and cost and time per job
1:46and stuff like that. So to really
1:47understand that, let's look at the
1:49factory flow diagram. The input to our
1:52factory is a GitHub issue or multiple.
1:54It can take in many GitHub issues at
1:56once and process them all together. And
1:59these come into an intake step, which is
2:01Fable. This is a new step in this
2:03version of the factory where Fable
2:04thinks about if this is worth building.
2:07It scopes it out within the context of
2:09the project. It assesses it for risk,
2:11and it could potentially reject the
2:13feature or ask for more information from
2:16a human. Next, we're going into the spec
2:18writing and building step, and these are
2:20still two distinct steps, but I'll talk
2:22about in my closing thoughts for the
2:23video how these could probably be merged
2:26into a single step. From here, we're
2:27going to push our code through a gate.
2:29This is a new deterministic step, and
2:31the idea here is that we're really
2:33wanting to validate that the software
2:34factory is correct. And so, this is a
2:36cheap step where we can run this on the
2:38build and make sure it's looking good.
2:40And if it's not, we can go back to the
2:42builder, and then eventually, when we
2:44get through the gate, then we go to some
2:46reviewers. And so, we're going to do a
2:47code review, and this will be done with
2:49Haiku or Sonnet if it's deemed risky.
2:52And the risk comes back to this
2:55assessment which was made by Fable at
2:56the start of the pipeline. And I did
2:58this because I wanted to demonstrate how
3:00we can use agents inside of our software
3:02factory to inform later steps and to
3:05potentially cost optimize our software
3:07factory. Uh we're also going to go to
3:08other reviewers, and we'll do this all
3:10in parallel, and depending on the
3:11results of these, we can push the job
3:13back to the builder to fix. And once we
3:15get through the code review, then we go
3:17to an approver step, which decides if
3:19this can be merged automatically or if
3:22this needs human review in order to
3:24close out the loop on our software
3:25factory and implement this feature into
3:27the codebase. Now, having seen this
3:29factory flowchart, there's a whole
3:31section of stuff over here, but I want
3:33to get to this later in the video. This
3:35is more details around the how the
3:36system works. Right now, I want to focus
3:38on this, which is how to actually use
3:41this system with Claud code. We start
3:43with an orchestrator, and the
3:44orchestrator is a Claud code session
3:46that I'm going to spin up, and inside of
3:48that session, I'm going to say factory
3:50run. From here, it will start spinning
3:52sub agents, background agents in Claud
3:54code that will be doing various tasks
3:56within our system. It also has a
3:58deterministic spine, and what this means
4:00is I have actual scripts, like
4:02checks.sh, this gate script, this route
4:05script. I have a jobs script. These are
4:08shell commands that are shipped with the
4:10factory. I'll show you these later in
4:12the video, and these are doing
4:13deterministic things to push our jobs
4:15through the the pipeline, through the
4:16actual factory. So, we have these
4:18commands: factory run, factory run n,
4:22where n is a number, like a specific
4:25GitHub issue that we want to process.
4:27And we can just pass anything we want in
4:29here. We can just pass any arbitrary
4:31string in order to do stuff within our
4:33factory context inside of our project.
4:36And this all comes with the skill that
4:38I'm going to show you how to install in
4:39the video. Another thing that comes
4:41along with this is a dashboard so that
4:43we can view everything as it moves
4:44through the factory. And the other
4:46important things to know are that we
4:48have concurrency built in here. So,
4:49we'll process up to three jobs at once,
4:51and this is a configuration setting,
4:53which you can change after you've
4:55installed the factory in your project.
4:57So, let's get started by installing the
4:59factory. So, this is the prompt that you
5:01can copy and paste into your own project
5:03in order to follow along with me in the
5:05demo. So, I'm just going to copy this,
5:07and I'm going to go over to my terminal.
5:08And I'm inside of a project called note
5:11wall app. Just a simple note
5:13application. I can sort of write stuff.
5:15That's it. I've also got this app on
5:17GitHub, and this is important for the
5:18issues and the pull requests, which will
5:20be a core component of our software
5:22factory. So, I'm going to spin up Claude
5:24Code, and we'll use Claude to install
5:26our software factory. And I'm just going
5:28to paste this in. So, it says, "Install
5:30this software factory in this project,
5:32and this is the reference repository."
5:34It's a link to my source code for this
5:36video. And here's that exact link. If
5:38you open it up, you'll see something
5:39like this, and you'll see that prompt is
5:41actually right in here in the source
5:43code. So, you can get this in the video
5:45description and find this link. You'll
5:46notice that we have this folder .claud.
5:48We also have this factory folder. Both
5:51of these are going to appear inside of
5:52your project after this is installed.
5:54Let me go ahead and run this.
5:56This just finished up, and let me show
5:58you what was installed. So, if I go into
5:59note wall app and look at this inside of
6:01Vim, the two main things we've added are
6:03this .claud folder, and inside of here I
6:06have a bunch of agents files. These are
6:08the sub agents, the descriptions of how
6:10our sub agents in the factory work. And
6:13we've got skills and inside of skills
6:14I've got one new skill installed which
6:16is factory and it has one file called
6:18skill dot MD which describes the entire
6:21behavior of the factory. But that's not
6:23all of the code that you just got. You
6:25also got this folder which is called
6:27factory and here's where we have all of
6:29the code dependency for the factory. The
6:31big things to pay attention to are the
6:33bin files. These are what are
6:35responsible for ingesting and pushing
6:37things through the factory as jobs. We
6:39have check dot SH which does
6:41deterministic checks like classic CICD
6:44stuff as stuff gets pushed through our
6:46factory. We have a configuration file
6:48where we can specify behavior of our
6:50factory and we have a dashboard file
6:51basically observe our factory. Now
6:53coming back up I want to show you this.
6:55So there's a bunch of stuff Claude says
6:58changed for NoteWall and there's a whole
6:59bunch of stuff of how the software
7:02factory that I provide the template was
7:03actually adapted to your project. And
7:05the big things are this one. Check dot
7:07SH is going to run your actual tests
7:10inside of your project. This line right
7:12here agents dot MD has a new software
7:14factory sections and let's look at that
7:16new section that was added. It looks
7:18like this. Software factory. So we're
7:19explicitly documenting how to use the
7:22software factory inside of our agents
7:24file. Now let's get out of this and I'm
7:26going to start a new session up here
7:27with Claude and I want to actually
7:29demonstrate our software factory in use.
7:31Now I'm on Opus 5.5 with low effort. And
7:34let's see what happens if I just try and
7:36run the factory right now. I'm going to
7:38say factory run. And we're checking.
7:40Factory bin job queue. We are running a
7:43script inside of our factory to see
7:45what's in the queue. And it says oh, it
7:47came back empty. There's nothing going
7:49on. So let's go over to GitHub and put
7:51something in our queue for the factory
7:53and you can see that I have a bunch of
7:54open issues. However, these don't have
7:57the right label on them. So they're not
7:58going to get picked up by the factory
8:00until we explicitly label them. This is
8:03just a safety measure that I shipped
8:05with the factory because the idea is
8:07many bit different people might be
8:08adding issues into your project, but you
8:10want to choose which ones get processed
8:12by your factory. Let's pick up just one
8:14issue to start with. I've got this one
8:16called dark mode, and I'm going to go to
8:17labels, and I'm going to add the factory
8:19label. If you don't see this, you can
8:21just create it. It won't exist for your
8:23project unless you create it yourself.
8:25And now that I've done that, I can see
8:27this label's been applied. So, I can go
8:29back to my factory, and if I run the
8:31exact same command again, now it'll pick
8:33that up and start processing it through
8:35the factory. And we can see it's
8:37creating a job, and it is in the intake
8:39stage now for this dark mode feature.
8:43That is now serving. So, we can see
8:45issue one, dark mode, is in the intake
8:48step. This is being processed by Fable,
8:51and I wanted Fable to do the first step
8:53of our factory because to me, that's
8:55just a really important step to
8:57understand what's happening in the
8:58context of our project. Next, we've
9:00moved into the spec writer. So, I can
9:03show you that if I click into this, we
9:04can get more information. We're going to
9:06see a bunch of different files being
9:07accumulated as the task gets pushed
9:10through the factory. We just saw spec
9:12got created, and this is what was
9:14created by the spec writer. But before
9:16that, we had Fable write this intake
9:18form, and Fable decided to accept it,
9:21and it decided it was low risk. It only
9:23touches the UI as a surface, and it has
9:26a little summary of all the sort of big
9:28things you'd want to know, and then a
9:29full agent log of like more information
9:32that Fable was thinking around this
9:34feature. And this is really important in
9:35a factory to understand what the agent
9:37was thinking as it pushed your thing
9:39through the factory. It's really
9:40important for debugging and analyzing
9:42the effectiveness of the factory over
9:44time just to keep all of this
9:45information around from your job. So,
9:47now we're in the builder phase. Let me
9:48come back to Claude, and let's see
9:50what's going on over here. I can
9:51actually see the builder as an agent
9:53down here, and this is a sub agent in
9:56Claude code. And what I can do is click
9:57enter and go into that. So, I can
9:59actually see what this sub agent is
10:01thinking, and I could steer it. What are
10:03you doing? Now, this level of
10:05interaction with the agent is kind of
10:07not really the point of the software
10:08factory. I'm going to talk more about
10:10that in my closing thoughts, but I just
10:12wanted to show you how you can do this
10:13with Cloud Code. Let's go back to the
10:15main agent. So, this is going to be our
10:17orchestrator, and in principle, this
10:19could spin up other jobs at the same
10:20time. Now, let's follow this one task
10:23all the way through. The build just
10:24finished, and we're seeing that now it's
10:26in the review phase. And this means that
10:28it passed the gate. The gate was this
10:31deterministic step that we had to go
10:33through, where we're running certain
10:34tests and linting and stuff like that.
10:36And I can show you that go back to
10:38Obsidian. This is the part that we just
10:40got through. So, we just went through
10:42the gate, and we're getting a green
10:43check mark on that. And now we're going
10:45through all of these guys. So, coming
10:47back to our terminal,
10:49and bringing this back up, we can see
10:51that's why the gate went green here.
10:53Now, we see the UX guy just approved, so
10:55this is done. We're just waiting on the
10:57code review and the UI review. And then
10:59we'll go through the rest of the
11:01pipeline. But, look at this, the code
11:03review just failed. We got orange for
11:06the code review. That means we're going
11:08to get kicked back to the builder phase.
11:10And let me just quickly show you that.
11:12So, now we're going to follow this
11:13route, and we're going to have to go
11:15back to the builder with some feedback,
11:17and then we'll have to get pushed
11:18through again. So, we're actually seeing
11:20this self-fixing recursive aspect of the
11:22pipeline now. And we can look at that.
11:25We can look at more information. So, let
11:26me come in here, and I'm going to click
11:28on the code, and the verdict was one
11:31readability gap. This reviewer was
11:33basically really being really picky
11:35about something, and it kicked it back
11:37because like how something was working.
11:39Now, notice how the code review is using
11:41haiku or only saw on it if it's
11:44determined to be risky. I'm going to
11:46come back to this later because it turns
11:48out that using models like haiku in this
11:51phase of the pipeline might not be such
11:53a good idea. These models aren't always
11:56able to understand the code as well as
11:58the builder. So, it can create an
11:59actually bad dynamic when you have code
12:01review happening by an agent that's not
12:04as intelligent as the builder agent. In
12:06any case, coming back here, we see that
12:08the UI has also failed. And so, now Now
12:10kicked back, and we're going to go
12:12through another round of reviews after
12:14we build pass our gate. We're going to
12:16have to get these guys to review it
12:18again based on the feedback that they've
12:20provided to the builder. And here they
12:21go. They're back into the next round of
12:23review. We can see this time the code is
12:25going green and hopefully the UI agent
12:27passes as well. Nice. It went green and
12:30we are in the approved phase. Now this
12:32approver is going to decide if it's can
12:34be automatically merged or if it needs
12:37human review before it merges. And I
12:39think this is a cool thing that our
12:40factory can do because it can allow for
12:43a lot more autonomous behavior. If it's
12:45a straightforward feature that can be
12:47merged without us looking, that saves
12:49human time. That's valuable and that's
12:51something I want my factory doing for
12:53me. And indeed it's done. So we can see
12:55we have a PR that was created for this
12:57and it's been merged. So this has
12:59actually been merged into our production
13:01code. Let me show you that over on
13:02GitHub. Here it is. It's called dark
13:05mode one. This was from the intake step.
13:07We actually just wrote some stuff in
13:08here 6 minutes ago. I opened a pull
13:11request and then I marked it as
13:12completed. So let me go to the PR. This
13:15is the one associated with that issue
13:17and I added a bunch of stuff. This is
13:19all the commits that our software
13:20factory was making and then down here
13:22we're saying pull request successfully
13:24merged and closed. Our system decided it
13:26didn't need my attention. It's something
13:27that could be automatically merged but
13:29we have the full history of how this
13:30worked inside of GitHub which I think is
13:32very powerful for observability. And if
13:34I go to the code, I can see that I
13:36merged a pull request. This was done a
13:38minute ago and that's now in the code
13:40base. Now let's pull these changes in
13:42from the remote. So if I say get status,
13:44I should see some files that have
13:46changed locally. And what we're seeing
13:48here are the files and folders that were
13:51added or modified when we installed the
13:52software factory itself. I never added
13:55and committed these. So let me do that
13:56now. All right. Adds as in code software
13:58factory and these are all the files that
14:00we were looking at earlier. You'll also
14:02notice that I'm on main right now. So
14:04I'm working on my main branch and now
14:06I'm going to pull in the remote changes
14:08from main. I'll just say get pull. I'm
14:10going to have to clean up some merges
14:12but okay, we did auto merging. So it's
14:13all good. There were some conflicts with
14:15the agents, but we handled it. So, now
14:17we pulled these changes in and you can
14:18see a bunch of changes to stuff like the
14:20style and the theme. This is for our
14:22dark mode feature. Now, let me show you
14:24that. I'll say npm run dev and let me
14:25show you this app again. So, here it is.
14:27Now, I have a dark mode going on by
14:29default. It's dark now. Okay. So, now
14:32that I've showed you how to take one
14:33issue and push it through our entire
14:35factory, I want to show you how to do
14:37this for many issues at once. Now, I've
14:39got four issues open in here. I'm going
14:41to grab all of them and I'm going to add
14:43the factory label to all of them at the
14:45same time. And now, all of these guys
14:47have the factory label. So, let me come
14:49back to Claude and we're going to
14:50process everything at once. Now, let me
14:52just come back here. If I run factory
14:54run, it's going to process everything
14:56together. But, I could also say factory
14:58run and then just give a single number
15:00and just process that issue. I want to
15:02demonstrate that right now. So, I'll
15:04just say factory run and let's just pick
15:06one issue. Issue number four is called
15:08different fonts. So, let me just say
15:10four. It's looking at the queue and
15:12that's reading all of these from GitHub
15:15and it's found the right one in take
15:16issue number four, different fonts. And
15:19now, it's processing that through our
15:20factory. I can check in on that and here
15:23it is. Different fonts is now in the
15:25intake step. So, Fables having a look at
15:27that. Now, let's process the rest. And
15:29because this session right here is the
15:31orchestrator, I can keep continuing
15:33using it and I can use this orchestrator
15:35to interact with existing jobs in our
15:37factory or I can use it to create new
15:39jobs. And that's what I want to do now.
15:41So, I'll just say factory run and this
15:44is going to process everything else.
15:46It's going to pull all of the issues and
15:48push them through our factory and we're
15:49going to see these all starting to
15:50appear in the intake step. There they
15:53are. Notice how we just have three
15:55things running. This is because we set
15:56our concurrency for our factory to
15:58three. What's the uh concurrency
16:01setting? Currency is three in
16:02factory.config.json.
16:04Now, let me show you some other new
16:06stuff that's in our factory. We're
16:08timing these jobs. So, I can see this
16:10dark mode job has a time of 8 minutes.
16:13That's how long it took to push through
16:14the whole factory. We're also providing
16:16a cost. So, this one says $3.40. It
16:19didn't actually cost me $3.40
16:22to push this through the factory. It was
16:23free for me. I just used my Claude plan.
16:25However, this gives us an idea of how
16:28expensive these jobs are when
16:29benchmarked against each other, and then
16:31we can use that to try and optimize our
16:33factory. We can try and make this more
16:34efficient by looking at the job cost and
16:36trying to push this down in certain
16:38ways. So, I thought that was an
16:39important addition to this factory. Now,
16:41let's look at what's going on. We have a
16:43job that's in the needs human. So, this
16:45thing is effectively unpaused. And
16:47because of that, we've now automatically
16:49started the intake for the final issue.
16:52This is called multiple walls. Now,
16:54let's focus on this step that needs
16:56human review. There's two ways that we
16:58can do this in our application. The
17:00first way is I could actually click on
17:01it, and now I can start to sort of look
17:03at it and examine these files which are
17:05being written durably to our factory.
17:08So, I can see that the build has been
17:09blocked, and there's this decision.md
17:11why the builder was blocked. This is not
17:13how I would inter- interface with the
17:15factory. I would just talk to Claude up
17:17here. This guy is the orchestrator. He's
17:19managing everything, but his chat is
17:21fairly free for me to talk to. Or what I
17:23could do is spin up a new Claude code
17:25instance inside the same project. And as
17:27long as I use the factory skill, I can
17:29just ask whatever I want. What happened
17:31with the different fonts task? I can see
17:33this needs a decision for me. What
17:35happened? Intake accepted the issue with
17:37a narrower scope. It doesn't really know
17:39what to do for font. Default to
17:41handwriting. It wants some input from
17:42me. Now, because this is a video and I
17:44don't really care, yeah, just do
17:45whatever you want. Let's get this going
17:47again. So, that should be able to push
17:48this task back along. I've basically
17:50made my decision, and now our software
17:52factory should pick this up, and you can
17:54see we've just added this feedback
17:56one.md. I can click in there, and it
17:59says, "Yeah, just do whatever you want.
18:01Let's get this going again." And now
18:02we'll see this job go somewhere, and
18:04here it is. It's back in the building
18:06phase. Meanwhile, our colored sticky
18:08notes is just waiting on the UI, and
18:10then this should This one should be
18:11built out, and the multiple walls has
18:14been called high. So, this is like a
18:16high-risk feature, and that's a label
18:18that Fable put on our features. These
18:20little labels are things that I added
18:23from the initial intake step. I'm
18:25getting Fable to decide and based on
18:26that information, it adapts the factory
18:28behavior as we push the job through.
18:30Check this out. For changing the display
18:32name, it has code, it has UX and UI, but
18:35there's no security reviewer on that.
18:37Whereas this guy does have a security
18:39reviewer and the reason was because this
18:41was a medium difficulty. Therefore, it
18:43was assigned a security review step.
18:46Whereas this guy was low, so he was not
18:48assigned a security review step. This is
18:51just a behavior because I wanted to
18:53illustrate how we can change and make
18:55our software factory dynamic.
18:57Effectively, a dynamic directed acyclic
18:59graph. And this can help with
19:01efficiencies of your factory. Again,
19:04I'll speak more about efficiencies and
19:05my thinking around that in my closing
19:07thoughts in the video. Now, let me clean
19:09up what's going on up here. I've got two
19:11Claude sessions going on. This guy on
19:13the right, I just used to interact with
19:15our factory, but I'm fine to spin that
19:17one down. I could just totally get rid
19:18of that. Nothing changes in our factory.
19:21But, if I was to try and kill this
19:23session, well, this has a bunch of sub
19:24agents associated with it. We also have
19:26a shell and this shell is the thing
19:28that's actually serving our dashboard.
19:30There's no reason Claude has to do that.
19:32I could have served it myself manually,
19:34but if I try and spin this guy down,
19:37see, I just pressed control C and
19:38actually all background agents stopped.
19:40So, all of these guys have now been just
19:43totally halted. That's not good. So,
19:46what I'm going to say is factory run.
19:48And what this should do is
19:50look at the current state. It's looking
19:52at the queue. So, it went back to
19:53GitHub. It's like, what's going on? It
19:55looks at the queue and now it should
19:57spin all these guys back up. So, in that
19:58sense, the factory is fairly durable.
20:01Now, I'm sure I just lost a little bit
20:03of work because whatever those sub
20:05agents were doing, we've now spun up new
20:07sub agents and you can see these guys
20:09all just started from scratch. So, any
20:11work that was currently in flight just
20:13got completely annihilated and we're
20:14we're restarting that. So, in
20:16particular, this UI step was currently
20:18ongoing and that got blown up and we
20:20restarted it. It's not a good idea to do
20:22that, but um the factory is pretty
20:24durable, right? I just showed you how we
20:26stopped it and we were able to spin it
20:27back up and now things are getting
20:29pushed through. And now I can see
20:30everything's accumulated here. It either
20:32needs review and then there's two that
20:33have finished. And looking at this in
20:35GitHub, now I can see we've got flag
20:37from our software factory on three
20:39issues. And if I go to the pull request,
20:41three open PRs for each of these and
20:44there's two closed ones. And in the
20:46source code itself, of course, we're
20:47going to see that that was pulled in.
20:49Merge pull request number seven, change
20:51display name. Now, coming back to our
20:53factory, and I just love this idea that
20:55we can come back to it with a very
20:57totally clean project and just run this
20:59factory command in order to get all the
21:01context from inside of here. What's
21:03going on with the different fonts? We
21:05need a call on this.
21:07So, let's see. The fonts is stuck in the
21:09factory rule, not the feature. It needs
21:11a call from you. All right, so this guy
21:13here, different fonts, this was blocked
21:16because of an issue with my software
21:18factory. So, I just fixed the factory. I
21:20told it hey, go fix yourself. This
21:22should have never been blocked. We
21:24should have been able to keep building
21:25this. When I wrote it up here,
21:27I just want to be real with you guys. I
21:28was like, also update V2 factory in
21:30Zazon code season 3. So, that means the
21:32factory you install will have this fix.
21:35Like, this should be fixed for you. So,
21:36this has got picked up and now it's
21:38getting tossed back to the builder
21:39phase. So, we will work through that
21:41one. Now, let's talk about the other
21:43ones. Now, since I've already loaded my
21:44factory, I'm just going to ask questions
21:46directly. How about issue number five?
21:48What's going on there? All right, now
21:49there's some noise going on because this
21:51other job's running, but this is what it
21:53said. There's a lot of stuff in here.
21:54I've got this skill. This is just my own
21:56skill. It's called TLDR. So, what my
21:58TLDR skill does is it just shortens the
22:01output of the agent. Okay, I trust you
22:03to handle this one properly. You can do
22:05that. Next, what's going on with issue
22:07number three, the colored sticky notes?
22:09The new color tester never runs because
22:11it skips server. May I send it back with
22:13move test and run color. Do that. Sounds
22:15good for issue number three. Now, these
22:18guys here appear to be needing human
22:20review, but I've already kicked these
22:22along. So, if I refresh this, I can see
22:24this one's actually changed. It's
22:25getting built now. The multiple walls is
22:28still here. What should we do about the
22:30multiple walls issue number five? Okay,
22:34so for issue number five, we're actually
22:35intentionally made it. We're waiting.
22:37We're waiting for these other tasks to
22:39finish. The orchestrator has some sort
22:41of shared understanding, right, of
22:42what's going on in the system and we're
22:44waiting on this until these guys have
22:46finished and then we're going to merge
22:48this PR in.
22:49That makes sense to me. And notice how
22:51we keep getting these TLDRs. That's from
22:53my skill, so I could just say this and
22:55I'll say, "Stop outputting TLDR." I'll
22:57leave a link to this and my other ones
22:59in the video description. If you like
23:01them, please leave me a star. Helps me
23:03out a lot on this channel and with my
23:04brand. And if you're enjoying this video
23:06on software factories, you can get my
23:08PDF guide if you sign up for my
23:10newsletter. This just has a structured
23:12summary of what we talked about in this
23:14video, along with links and installation
23:16commands. You can send this to your
23:17friends or use it yourself. This is my
23:19newsletter. I just send one email a
23:21week. And if you sign up for this, I'll
23:22also give you some other stuffs like my
23:24agentic engineer playbook. This just has
23:27my like philosophy on agentic
23:29engineering and basically this new age
23:32that we're going into as software
23:33engineers. Now, everything's done except
23:35for this last multiple wall. And what's
23:37going on with multiple walls? I'm going
23:39to get TLDR working on that. It's
23:42stalled. It waits on your sign-off for
23:44the wall format.
23:46One round to merge.
23:48Yep, let's do whatever you want and
23:49merge it in. We also have links here. I
23:51can click this link and open up the PR
23:54directly. Okay, I think it's worried
23:56about throwing out some data. This is
23:57just a test app, I don't care. Yeah,
23:59just get rid of the data right now. Just
24:01test data, it doesn't matter. I love
24:02this one. I love how it's like actually
24:04recording these. So, we have factory bin
24:06job feedback. This is a function in our
24:08factory that explicitly sets feedback
24:11from the user and we have tons of these
24:13functions. I want to show you these in
24:15in just a minute. We're about to get to
24:16this. Let me just show you the final
24:18version of the application. So, I'll
24:20pull all the changes in. So, here's our
24:22our thing. We can now change the color
24:25of the sticky notes. That's cool. This
24:27one will be red. Let's go with red.
24:31Yeah, nice. Okay. And there was also Oh,
24:34I can change my name. Okay, cool. Now,
24:36if I do new one, I'm talk now.
24:40Yeah, there he is. Okay. Go back to our
24:42mind map and sort of walk through these.
24:45So, the deterministic checks are handled
24:46by this checks.sh.
24:49This is something that checks and
24:50deterministically fails if we're not
24:53meeting the right
24:54things that we need in our project. If
24:56we're not passing the tests, and it's
24:58very simple. Look at this. It's a bash
25:00file, and it's going to run through, and
25:02it's going to run all these npm commands
25:04because we have an npm project. But if
25:06you have a different project, you'll be
25:07running different tests in here. So,
25:09we're doing a linting, we're doing a
25:11type check, we're doing npm test, and
25:13then we're running a build. We're
25:14actually building our project, making
25:15sure all of this works. If If something
25:17goes wrong here, we do not even get to
25:20the reviewers. It hasn't even made it
25:21that far because this gate is put in
25:23place right in front of them. So,
25:25job.json drives all of the stages. This
25:28is a file that's on your computer that
25:30lives and represents the job as it gets
25:32pushed through the factory. And this
25:34thing is only written It's only updated
25:37by factory bin job. This is not like a
25:41vibey thing that gets updated by Claude
25:44code. Claude code calls factory bin job
25:47in order to update this JSON file. And
25:50let me show you that. It'll be very
25:52obvious when you look at this. Let me
25:53look at job inside of here. And it says
25:55right at the top, "The only writer of
25:57factory jobs job ID job.json." We have
26:01all these different commands like job
26:03queue. This looks at the queue of what's
26:05going on. If I follow queue, we can kind
26:07of see
26:08probably This might be a bit messy, but
26:10we're going to be looking at GitHub. Do
26:11you see issues equals gh.json? This is
26:14looking at GitHub and seeing what's
26:17going on inside of GitHub. So, then
26:18there's job create, job advance, job
26:21merge. And this is what's responsible
26:22for pushing things through our pipeline,
26:24running this script. Let me show you the
26:26actual jobs. Now, we're not going to see
26:28those inside of here because they're
26:30being get ignored. If I go into factory
26:33and look at everything in here, we have
26:35a jobs folder. This is where the actual
26:37data of the stuff in our factory lives.
26:40You should know that this data just
26:42lives on your computer. This is being
26:44get ignored. It's not being got backed
26:46up to GitHub. So, if you wanted to
26:47persist this, you could build something
26:49in in order to persist this separately,
26:51and that's what I would do. I would
26:52build in something that saves this data
26:54to Google Cloud Storage, and I would
26:55just say, "Hey Claude, I want to save
26:57this stuff to Cloud Storage. Let's set
26:59up a workflow for doing that. It'll
27:01handle that for you." This is the data
27:02that we keep seeing in our factory,
27:04including round one, round two, round
27:05three. This is the data that if I look
27:07inside of here is populating all of
27:09these files right here. Um it's just
27:11coming from those markdown files that's
27:13on that's on my actual system. And I've
27:15got this job.json. So, this guy right
27:17here, this is the file that is being
27:19edited by those bin scripts. When it
27:22says only factory bin job writes it,
27:25this is the thing that is making our
27:27software factory durable and properly
27:29passing jobs through the life cycle of
27:32the factory. The big point is that this
27:34thing is worked on programmatically.
27:35Claude does not work on this itself.
27:38Claude runs functions in order to update
27:40this file. Hope that's clear. That's
27:42really important for how our factory is
27:44working. Right, we've pretty much
27:45covered everything. Thank you to
27:47Anthropic for sponsoring today's video.
27:49And if you're not using Claude Code yet,
27:51then you can click the link in the video
27:52description and sign up now. Let me
27:54share some closing thoughts on what
27:55we've built today and where I want to
27:57take this next. First of all, this is
27:59definitely an improvement on my software
28:02factory from the previous video. There's
28:04a lot of things that I thought through
28:05better, and I like how this one is
28:07working better than that previous one.
28:09However, it's also more complicated. And
28:11with complexity doesn't always come
28:13improvement. So, I would encourage you
28:15to look at this factory and say, "How
28:16could I actually simplify this a little
28:18bit for myself while still getting all
28:20the performance that that I want out of
28:22the factory?" Next thing I want to talk
28:23through is cost. So, we're tracking the
28:25cost or like the estimated cost if we
28:27were paying token prices. Again, we're
28:30not paying token prices, so that's
28:32something to keep in mind, but it's
28:33still a good benchmark that we can use
28:35to try and optimize the cost over time
28:37and compare the cost of different jobs.
28:39And what we might want to try and do is
28:41use cheaper models like Haiku at certain
28:43places in the pipeline. For example,
28:45maybe we could use Haiku in the reviewer
28:48phases. However, if we're doing this and
28:50now the reviewers are failing because
28:52they're using Haiku and they're just not
28:54really thinking very intelligently about
28:55the problem and then they're kicking
28:57work back to the builder, that could
28:59actually end us end up costing us more
29:01money. So, that's something I would I
29:03would be careful about doing. Um
29:05potentially the approver could be a
29:06Haiku agent. But, then as well, we're
29:09like, do we want to put the choice of
29:11approving this feature into our code
29:13base on Haiku? I don't know if I want to
29:15do that. And I really like how we're
29:16using GitHub issues and pull requests.
29:19And something cool that we could do
29:20would be to watch the performance
29:22metrics of our actual production system
29:24and then be pushing those things
29:26automatically into GitHub issues where
29:28they could then be ingested into the
29:29factory. So, if we wanted to basically
29:32bring in a layer of, you know,
29:34post-implementation monitoring, like
29:36post-production uh deployment monitoring
29:39in our actual system, we could do that
29:41through this exact factory, through the
29:43GitHub issues, like form factor. We can
29:46be getting other systems, any other
29:48system we have, to be pushing GitHub
29:50issues into our project, adding the
29:52factory label, and then it gets picked
29:54up here and pushed through our system.
29:56So, we don't actually need like extra
29:58layers in order to attach things like
30:00observability. That's pretty much
30:02already handled for us by the GitHub
30:04issues. Okay, the last thing I want to
30:05talk about is actually using this in
30:08production. So, this is the big
30:10complaint with software factories. It's
30:11like, okay, yeah, that's cool, but you'd
30:13be a a psycho to actually plug this into
30:15your real production system.
30:17And I would have to agree with you,
30:19right? This is a 30-minute video that
30:22you've watched about how software
30:24factories work, how you can build one
30:25for yourself. I'm not telling you that
30:28you should take the code that I've
30:29showed you in today and plug it into
30:31your production system and close your
30:33eyes and get your agents chugging
30:35through all of your all of your issues
30:37for you and building your application in
30:39in that [music] way. Um I do think it's
30:41something you could do in the way that I
30:43showed you how we're controlling it and
30:45we're sort of looking at it and we're
30:46checking how it goes. Yeah, sure. That's
30:49a that's a thing you could do. I think
30:51this is a thing you could start with and
30:53I think that actually software
30:55development in general will go to an
30:57abstraction layer that looks like this.
30:59That's less about coding agent harnesses
31:01like we're seeing them today like Claude
31:03um how Claude code works today but
31:05instead from a higher level like super
31:07Claude code where you're you're sort of
31:09managing above the agent harness level
31:12in the same type of way as we're seeing
31:13this video. So I think the concept of a
31:15software factory is very important to
31:17understand. I think what I'm showing you
31:19today could be the basis of something
31:20that would work in a production system
31:23um and I think that you just have to be
31:25very thoughtful about actually how that
31:26should should happen for you. Um and I
31:29and I'd love to hear your thoughts on
31:30that as well. So what's next for me with
31:32my software factory? Well, I'd love to
31:34hear in the comments ways that we you
31:36think this can be improved or modified
31:38but the big thing I'm thinking is how do
31:40we get this running in the cloud? Like I
31:43don't want to run this on my computer
31:44anymore. I want this just automatically
31:46running somewhere and I think the Claude
31:48agent SDK would be the way to go for
31:50this. So that's what I'm considering for
31:52my next video. Love to hear your
31:54thoughts on that and thank you for
31:56watching.

About this transcript

This page contains the full transcript of Build a Better Software Factory with Claude Code by ZazenCodes, generated from the public captions YouTube serves with the video. The transcript has 6,956 words across 967 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.