YT YouTube2Text

YouTube2Text → Transcripts → I Built an Agentic Software Factory with Codex and Claude Code

I Built an Agentic Software Factory with Codex and Claude Code — Transcript

by Owain Lewis · 4,773 words · 698 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00There's a lot of hype online around AI
0:01software factories, and people are
0:02skeptical for good reason. But, what I
0:04found is applying these ideas in my own
0:06workflow has completely changed the way
0:08I think about building software with AI
0:10agents. [music] So, this video is going
0:11to be a complete guide to building an AI
0:13software factory. We're going to look at
0:14what a software factory is, how to build
0:17one, and how to think about applying
0:18[music] this in your own workflow,
0:19whether you're a solo developer looking
0:21to be more productive or an engineering
0:23leader in a large enterprise
0:24organization looking to raise the
0:26quality bar.
0:27This is one [music] of the most exciting
0:28topics in AI and software engineering
0:30right now. In my opinion, software
0:32engineering has always been about
0:34systems thinking [music] and systems
0:35design, and that's exactly what this
0:37video is going to be all about. If
0:39[music] you stick around to the end of
0:40the video, I'll give away all of the
0:41code, the resources, the prompts, and
0:42everything you need to build your own
0:44software factory. So, let's get into it.
0:46>> [music]
0:46>> So, the first question is what is a
0:48software factory? And it's basically
0:49just an extension of everything we've
0:50already been doing as developers. We're
0:52just applying AI to the systems and the
0:54processes we're already following. So,
0:56if you think about the typical
0:56development process, it's pretty
0:57straightforward. And so, what happens in
0:59any software engineering team, whether
1:01you're working at Google, or Netflix, or
1:03Amazon, or just whether you're working
1:04on your own as a solo developer, it's
1:06pretty much the same thing, right? We
1:07have
1:08intent. So, we have customer issues. We
1:11have things from our PMs or
1:13stakeholders. We have, you know, things
1:15that we decide we want to build as
1:17developers. We put these into some kind
1:19of ticketing queue, and then they go
1:21into the backlog. We refine them a
1:23little bit, and then we do some kind of
1:24design phase where we'll take those
1:25ideas, we'll design them in some way,
1:28we'll figure out how we're going to
1:29build these things. What are we
1:30building? Why are we building it? How
1:32are we going to build it? Then we do
1:34some kind of planning where we break
1:35that work down into a number of smaller
1:37tasks or tickets. We give those tasks to
1:40developers who then do, obviously, the
1:42the typical development cycle, right? We
1:43write the code, we do some local and
1:45manual testing, we do some code review,
1:48then we open a pull request on something
1:50like GitHub, and then we'll have like a
1:52human review the code, or we'll have
1:54some kind of automated checks to look
1:56for problems, bugs. We'll run a bunch of
1:58other checks and tests as well. Then if
2:01there are any errors, we go back through
2:02the cycle. So we're doing a loop here.
2:04So this is our first development loop.
2:06We write the code.
2:07We iterate a couple of times until we
2:10get the quality high enough. Then
2:11finally, we merge that code in and then
2:13we deploy it. And if you think about
2:15CI/CD, it's a good analogy to a software
2:17factory, right? This is an automated
2:19process. You push your change in and
2:22then the system or the process will then
2:23take that into production. Typically in
2:25the best software engineering teams,
2:27you're not manually deploying. You have
2:28the system that will deploy for you. It
2:31will take care of, you know, checking
2:32that all of the code is working, it's
2:34well tested. It will deploy it to
2:36production. If If there are any errors,
2:37it will even roll back the code for you.
2:40So this is the CI/CD system. Deploy your
2:42code into production. Then we have a
2:44bunch of user feedback. We have customer
2:46feedback. We have, you know, monitoring
2:48agents that look for problems in our
2:49code and then we'll feed all of that
2:51information back into the the kind of
2:54starting point here. So this is really
2:56just a loop or a cycle.
2:59And when it comes to AI agents, we're
3:00basically following a similar process.
3:02We're just applying agents to different
3:04parts of the process. So this is the
3:05pipeline we're going to be building. It
3:06has a bunch of steps. So the first thing
3:08is we put work into the pipeline. So
3:10this is stuff we want to do. So I could
3:12add an item here like I could say
3:13improve
3:15the readme. So this is something I might
3:17want to do, right? Let's create a new
3:18issue.
3:20And let's just use a blank issue.
3:22So this is a really badly defined
3:24ticket. This is the example of something
3:25you might find in a typical engineering
3:27organization, sadly. You might have a
3:29ticket that looks like this, right?
3:30There's no way an agent can do anything
3:32with this ticket. It has no description,
3:34no acceptance criteria. If you give this
3:37to an agent, it's going to try and do
3:38the work, but it has no idea what it's
3:40actually meant to be doing. So what we
3:42want to do is refine these tickets using
3:45some kind of automated process. Once we
3:47give this to an agent, the agent will
3:49then improve the ticket. Then we have a
3:51ticket that is then ready to implement,
3:53and then we can kind of run it through
3:54the pipeline. The agent will then move
3:56it into implementing. The agent will be
3:58writing the code. We're going to spawn
4:00up an agent using a sandbox on a virtual
4:02machine or some remote location. The
4:04agent will write the code. It will run
4:06all of the tests. It'll run your
4:07pipeline. Then finally, you'll have a
4:09pull request that you can review, and
4:11then finally, we have a change that is
4:13done. So, essentially, what we're doing
4:15is just running all of our tickets or
4:16our tasks through this pipeline, and
4:19we're going to use agents every single
4:20step.
4:22All right. So, what we're going to do is
4:23go into the terminal, and this is the
4:25code base we're working on. So, this is
4:27the factory code base. And what I'm
4:29going to do is spin up a coding agent.
4:31You can use any coding agent here. I'm
4:32going to use Neo, which is my own coding
4:34agent. But honestly, it doesn't really
4:36matter. You could use any coding agent.
4:38So, what I'm going to say is something
4:40like um task to PR.
4:43So, this will basically take one task or
4:45ticket, and then it will open a pull
4:46request. This is going to run the entire
4:48pipeline. [music]
4:49I'm going to do nothing else other than
4:51pass the ticket in.
4:53So, within the Neo coding agent, you can
4:54see here that it's running what I call a
4:55workflow.
4:56>> [music]
4:56>> So, we're not just randomly prompting
4:58the agent. We're actually just defining
5:00the entire step-by-step process up
5:02front, and letting the agent work
5:03through this. This means we can be very,
5:05very consistent in our dev process.
5:07[music] You can see here we're resolving
5:08the ticket. We're now creating an
5:10isolated Git work tree. Then we're
5:12reading the ticket, and we're outlining
5:14the change. We're making [music] a
5:15little plan. We're doing the work. You
5:17can see here now the agent is doing the
5:19code change. Then we're going to do the
5:20tests, the reviews. We're going to wait
5:22for any feedback. We're going to address
5:24those findings, and then finally, we're
5:25going to kind of finish this off
5:27essentially.
5:28>> [music]
5:29>> So, this is why I really like the
5:30workflow approach to agentic coding.
5:33We're just giving the agent a task.
5:34We're defining the workflow or the steps
5:37the agent needs to run through, and then
5:38we're just letting it run. This is it.
5:40This is my entire development process
5:41right now. So, what you'll see here is
5:43this is the skill that we're using to
5:44transform our task into a pull request.
5:46This is really a workflow definition
5:47more than the skill. If you look at any
5:49company, if you go and work at Amazon or
5:51Google, or you look at any engineering
5:53team,
5:53>> [music]
5:53>> every developer is basically following
5:55the same series of steps, right? We read
5:56the task, we make a bit of a plan, we
5:59implement the code change, we run some
6:00tests, we review the code, maybe we even
6:03use some browser testing for any UI
6:05work, then we address any findings we
6:07get on GitHub, then we publish a change
6:10using a commercial commit, we wait for
6:12any other feedback or any testing to
6:14happen,
6:15we address the feedback and then we give
6:17the results over to a human to kind of
6:19review and make a decision about merging
6:20the change. This is a really simple
6:22skill, but it's what I use for 99% of
6:25all of my development work now. I spend
6:27the time planning and designing, then
6:29when it comes to actual implementation,
6:30it's just a case of handing off those
6:31tasks to an agent. When it comes to
6:33actually planning out my work, I use a
6:35really simple skill called plan. This
6:36will take a take a spec and it will turn
6:38it into a well-defined ticket. And you
6:40can see here that it's again really
6:42really simple. We're just defining the
6:44template we want for our tickets. We
6:45have an outcome, we have some context,
6:48we have some acceptance criteria to
6:49test, and any other information that the
6:52agent might need to complete the task.
6:53So, you can see here we take a spec. So,
6:56this takes a brief or a spec and breaks
6:59it into a number of tickets or optional
7:00milestones. We're basically just
7:02planning out our work into a number of
7:03tasks.
7:05So, this would be exactly the same
7:06process whether I was using Claude Code
7:08or Codex or Pi. The agents you're using
7:11don't matter as much as everyone thinks
7:12they do. Ultimately, the workflow is
7:14what matters. All of the agents are
7:15equally capable at this point. So, if
7:17you go back into our browser, you can
7:18see now that we've finished this task
7:20and it is fully ready. You can see here
7:21we've been given a thumbs up from Codex.
7:24So, everything is good to go and then we
7:26can just literally just kind of squash
7:28merge this
7:29and we're good to go. So, that was a
7:31change that we did following a manual
7:34factory process. What I mean by that is
7:35we didn't do a single thing. We just
7:37gave the agent a task. The agent did all
7:39of the work. We could have gone away,
7:41come back 20 minutes later and have the
7:43pull request ready to go. So, the next
7:45thing we want to do is take this manual
7:46process and then figure out a way to
7:48scale this to a more automated system.
7:51All right. So, what I want to show you
7:52now is Factory. This is a project that
7:54I've been building. It's an open-source
7:55project written in Rust, but it
7:56essentially [music] encodes all of the
7:58ideas behind building a software
7:59factory. So, we're going to use this to
8:01now build our automated software
8:02factory. This is the process we're going
8:04to be following. We're going to take an
8:05idea. This is the intake step. We're
8:07then going to run it through a an agent
8:09to write the specification and create
8:11[music] the task. We're then going to
8:12run it through a build step. We'll do
8:14some testing, review, and then finally
8:17we'll merge. We're just going to run
8:18this as a cycle.
8:20So, if we look at the workflow, there
8:22are two stages to [music] this. So, the
8:23first stage we're going to do is the
8:24task refinement step. And then the
8:26second step is the actual build
8:28pipeline. So, this [music] project is
8:31just running on your local machine, but
8:33you can also deploy it to a virtual
8:34machine as well. So, you could deploy
8:35this to the cloud. And [music] it's
8:37basically going to run on a loop looking
8:38for tickets or looking for work to do,
8:41uh updating all of your tasks,
8:42implementing all of your code for you.
8:43The only thing you need to do is kind of
8:45plan out the work and assign it to
8:46[music] Factory. All right. So, what
8:48we're going to do is just run the
8:49project so you can type factory to list
8:51all of the commands you can run. Let's
8:52clear this out and let's just run the
8:54agent. So, this is going to run on a
8:56loop basically monitoring your ticket
8:58queue and for any automated jobs you
9:00have, you can then run this on a virtual
9:02machine. You can run it on your local
9:03computer if you want to. I'm using work
9:06tree-based isolation, which means every
9:07time we run an agent, we're going to
9:09spawn a new get work tree and run it
9:11there to keep the code isolated. But, if
9:13you were running this in production, you
9:15could also use something like a Docker
9:16sandbox if you wanted to.
9:18Okay. So, we're going to go ahead and
9:19create a new issue. What we're going to
9:20do is click up here to create a new
9:22issue. I'm just going to do a regular
9:23blank issue here. So, Factory demon
9:28dies overnight. So, we have a problem
9:30where I've noticed a behavior. And so,
9:33what I'm going to do is put in a rough
9:35description of what happens. Again, I'm
9:37not explaining to the agent how to solve
9:38this. I'm just describing the problem or
9:40the intent I've got.
9:42And then, we're going to go ahead and
9:43create this task.
9:45All right, so what we're going to do is
9:46add a label called factory ready for
9:48spec. And when we have this label, the
9:50agent should then pick this up. So, if
9:52we go and check this ticket now,
9:53it has the factory ready and factory
9:55ready for spec labels. And if we were to
9:58go back into the terminal, what you
10:00should see is that the agent will then
10:02actually pick up that task.
10:05Okay, so what you can see now is that
10:06factory has picked up this task. So,
10:07this demon has now found that we have a
10:09label ready for spec. It's found the
10:11task. And what it's going to do is spawn
10:14a new agent. So, you can see here that
10:16it's delegated it to codex. And it's
10:18spawned up a new git work tree. What I
10:21want to quickly show you is how this is
10:22configured. So, you can see here that we
10:24have a source, which is GitHub issues,
10:26and then we have a trigger. So, anytime
10:28we have a label factory ready for spec,
10:30we're basically going to run this
10:31particular workflow. And if you go
10:32through this triage workflow, this is
10:34essentially what the agent is now
10:36running. It says, "Your goal is to turn
10:38the GitHub issue into a clear
10:40implementation ready task for a human or
10:42the agent." And then, firstly, we
10:44understand the work. We then create the
10:46ticket specification. We're basically
10:48following a template. And then, we kind
10:50of move the ticket into ready to
10:52implement. So, essentially, this is the
10:54triage workflow. This is just a simple
10:56prompt. You could have this do anything
10:57you like. It's absolutely fine.
11:00And then, the other implement workflow
11:02that we're running is this. So, this is
11:04what we do when we want to actually
11:05implement the task. So, "Your goal is to
11:07implement the GitHub issue supplied to
11:09you. Do not merge or auto merge. Use the
11:12GitHub CLI to pull the issue.
11:14We're then going to implement the code.
11:16We're going to kind of just run through
11:17this massive prompt, essentially. Um but
11:20this could be a simple step-by-step
11:22workflow, anything you want, basically.
11:24This describes to the agent how to
11:25actually execute the work when it's
11:27given a task. So, factory will move
11:29stuff through the pipeline without us
11:31doing anything. It's working on the
11:33ticket. It's picked it up. It's moved it
11:34into this status. As it works on it, it
11:37should move it into the next status as
11:38well. So, you can see here that the
11:40agent has now updated our task. It was a
11:42very vague, ill-described problem, and
11:45the agent has now reviewed all of our
11:47code, has inspected everything, has
11:48actually found the bug, has reproduced
11:50the bug, and then it's updated our
11:52ticket with all of the information we
11:53need to hand this off to either a human
11:55or an agent to go and fix the problem.
11:57The The way this works is it's
11:59completely customizable. So, you could
12:01imagine if you are a public-facing team
12:04where users or customers are reporting
12:06bugs, you could run this automation
12:08workflow over the inputs, the customer
12:10requests, and take their vague ideas and
12:13turn them into actionable tickets that a
12:14developer could then pick up and work
12:16on. This is really useful cuz often when
12:18you get a ticket from a customer, there
12:20may be missing information, the problem
12:22may not be valid. So, you can use an
12:25agent to triage any of the work that
12:26comes into your queue. All right. So,
12:28this ticket is now ready to go. What I'm
12:30going to do is just add this factory
12:31ready to implement label. I'm happy with
12:33this ticket. I want the agent to work on
12:35it. Again, I could be working on maybe
12:3710, 20 tickets at a time here. This is
12:40kind of just a single ticket, but the
12:41idea of the factory is that you can run
12:43lots and lots of things all at the same
12:45time.
12:46So, what you can see is that the agent
12:47has now picked this up. So, you can see
12:49it's detected we have this ready to
12:50implement label. And again, we're not
12:52doing anything. We're just moving the
12:53tasks through the task board. We're
12:55coordinating the work. But the factory
12:57system is running the entire pipeline
12:59for us. This could be running hundreds
13:01and hundreds of tickets at the same
13:02time. If you work in a team, obviously,
13:04this will be coordinating all of your
13:06team's work.
13:08And we just need to now wait for the
13:09agent to kind of run through and fix the
13:11issue for us. There's nothing else to it
13:13than this.
13:14Another really important concept to
13:15think about is sandboxing. So, when we
13:17run these kind of systems in production,
13:19you want to be a bit careful about
13:21sandboxing the workers to make sure
13:22they're not destroying anything. So, one
13:25A to this problem is using something
13:26like Docker sandboxes. So, Docker
13:28recently released a sandboxing feature
13:30which I've been experimenting with.
13:32I'll be honest, I'm still new to
13:33sandboxing and still figuring out the
13:35right approach myself, but this is the
13:37current implementation strategy I'm
13:39using at the moment.
13:41Locally, what I will typically do is use
13:42Git worktrees.
13:44But when working on a VM or like in a
13:46team environment, you definitely want
13:48some kind of good sandboxing solution.
13:51So, Docker sandboxes are one solution,
13:53regular Docker containers, there are a
13:55whole bunch of different solutions. And
13:57I'll probably do a video on this topic
13:59because it's quite an interesting and
14:00important one for for any developer
14:02right now. So, whenever we talk about
14:03automated systems or things like this,
14:05there are always the same objections
14:07that come up. The first one is cost.
14:09Yes, if you're automating your system or
14:11running agents, it will cost you money.
14:13I'm not using this to do work that I
14:15wouldn't do otherwise anyway, though.
14:17This is kind of the key point. This is
14:18not necessarily something that's aimed
14:20at like solo developers necessarily.
14:22This is more of a thing you would run at
14:24scale in an engineering organization.
14:26So, if you're if you're using any kind
14:28of automated flow, it will use tokens.
14:30But the way Factory is designed is to be
14:32largely deterministic. So, when we're
14:33polling GitHub looking for work to do,
14:36we're not wasting any tokens. We're only
14:38executing agents or using tokens when
14:40there's actually work to do. So, this is
14:42actually very very token efficient. You
14:44could run this running 24/7 every single
14:47day
14:48and it's only going to use tokens when
14:50there's actual work to do. So, if
14:51there's a genuine ticket to work on,
14:53it's going to use tokens. Otherwise,
14:55it's going to sit there polling using
14:57largely deterministic code. So, it's not
14:59going to burn a load of tokens. The
15:01other objection that comes up is that AI
15:02isn't smart enough and I definitely
15:04agree with this. There are some tasks
15:05you don't want to hand off fully to an
15:07agent. You sometimes want to be in the
15:09loop on certain tasks. And then the
15:11other objection is that sometimes you
15:12want to work interactively, right? So,
15:14sometimes you still want to be in the
15:15mix. You still want to be involved in
15:17the process, but you can still do that,
15:19right? You you can use this sometimes.
15:21Sometimes you'll want to be iterating
15:22with your agents, and that's totally
15:24fine. This pipeline isn't for every
15:25single situation. So, as agents get more
15:28capable, I think these pipelines become
15:29even more important because the typical
15:31task in my development workflow, an
15:33agent will run on it for maybe 20
15:35minutes to even up to an hour. The
15:37agents are doing extensive code review.
15:39They're doing a lot of CI checks.
15:41They're doing a lot of work. And so,
15:43it's very painful to be sitting in the
15:44terminal watching hundreds of different
15:47tasks or working on many things at once.
15:49It's very very painful.
15:51So, by offloading this process to a
15:53virtual machine or a system like this,
15:56you can just basically hand off the
15:57work. You can go do something else. You
15:59can kind of come back 2 hours later and
16:01find that all of the work is done. You
16:02can then review the code changes,
16:04obviously, make any adjustments you
16:06want, but basically, you don't have to
16:07be tied to your keyboard anymore.
16:10So, this project is currently open
16:11source, and I don't think it's suitable
16:13for everyone right now. It's still very
16:14early stages, but the main thing to
16:16think about are the principles and the
16:17ideas. It's not all that difficult to
16:20build your own version of something like
16:22this. You could use GitHub actions, for
16:24example, which allows you to run an
16:26automation. So, for example, with GitHub
16:27actions, every time a customer raises a
16:30ticket, you could run an agent to triage
16:32the ticket. And every time we add a
16:34label to a ticket, you could have an
16:35agent that will run. So, GitHub actions
16:37is another great solution for this kind
16:39of problem as well.
16:41All right. So, the next concept we're
16:42going to look at is one of my favorites,
16:43which is this concept of a scheduled
16:45job. So, we have a bug finder job here.
16:47You could add any workflows you want.
16:50These are useful for a couple of
16:52reasons. So, if you go into our
16:53config.toml, what you can see here is
16:55I've got this scheduled bug finder.
16:57Obviously, you can do this with
16:58something like Claude routines or Codex
17:01automations, but what I like about this
17:03is keeping all of these automations
17:05version controlled. If you work in a
17:06team, you can keep these version
17:08controlled, and you can also run them
17:10manually as well very very easily. Okay.
17:12So, we're going to go into the terminal.
17:14We're going to type factory. So, we're
17:15going to type factory
17:17workflows,
17:19which is going to list out the workflows
17:20we have. You can see here we have this
17:22bug finder workflow.
17:24So, let me go ahead and run that. Again,
17:26you can run this on a schedule, but you
17:28can also trigger them manually, and I
17:30find triggering things like this
17:31manually is very, very useful. So, say I
17:33want to find any bugs in my code, I can
17:35just run factory run bug finder.
17:39And then just kind of wait for that. So,
17:40you can see here it's running the
17:41workflow bug finder. It spawned a new
17:44get work tree. It's now going to go
17:45ahead and find bugs in our code base,
17:47find a bug, and then it's going to open
17:49a ticket that we can review later. So,
17:51this is a bug that the agent found. You
17:53could actually make this more automated
17:54and have the agent open the pull request
17:56at the end. It already clearly knows
17:57what the bug is, and it looks like it's
17:59well reasoned as well.
18:01So, as you begin to trust these agent
18:03systems more and more, you can let them
18:04run for longer. You can allow them to
18:06open pull requests. You could even allow
18:08this to merge if it is a, you know,
18:10personal project. If you're confident in
18:12your system, you can kind of delegate
18:14more and more trust to the system over
18:16time. So, there's nothing stopping you
18:18here having this as a fully automated
18:20system.
18:21Okay, so finally our implementation
18:22agent has finished. So, this task ran
18:24for, I think it was about 35 minutes.
18:27So, this is obviously quite a big
18:28change, and one of the reasons why this
18:30ran for so long is because we're
18:31actually running a long pipeline. So,
18:33we're not just changing the code, we're
18:35writing, you know, sub agent tests,
18:37we're doing code reviews, we're waiting
18:40for feedback on CI infrastructure as
18:42well. So, this is why using something
18:44like a factory pipeline is so valuable,
18:47because I don't want to be wasting in my
18:48terminal for 34 minutes. As these agents
18:50get way more capable and powerful,
18:52you're going to be delegating much
18:53longer running work to these agents.
18:55They're doing a better job of the code
18:56implementation, but they're also just
18:58running for much, much longer. And so,
19:00this is why I pretty much prefer this
19:02factory approach. Just delegate your
19:04tasks to the system,
19:06and let them run for like 30 minutes to
19:08an hour to work on your code base, do a
19:10really good job, and then review the
19:11changes at the end. If you're a senior
19:13engineer, you've probably got many
19:14objections to this topic and I think
19:17[music] those objections are somewhat
19:18founded. You do need to be very very
19:20careful. If you're introducing these
19:22concepts into a team, you need to have
19:24the culture [music] such that people
19:25don't abuse these pipelines and what I
19:27mean by that is you don't want to use
19:29[music] these kind of pipelines for
19:30every single task. You still need humans
19:32to think critically.
19:33>> [music]
19:34>> You still need human judgment. You still
19:35need engineering thinking at every
19:37single step of the process. [music]
19:38It's just there's a percentage of
19:40tickets that we can now just give to
19:42agents, mechanical things, security
19:44upgrades, [music] bug fixes, really
19:46trivial tedious work that developers
19:48don't like doing anyway. All of those
19:50can largely just be handed off to agents
19:52now. Run it [music] in a pipeline, build
19:54more consistency and a good analogy to
19:56this process is CICD. If you remember
19:59back in the day,
19:59>> [music]
20:00>> we used to manually deploy our software.
20:01It was very error-prone, inconsistent.
20:04Deployments were stressful. They would
20:05often break or go wrong.
20:07>> [music]
20:07>> And we would struggle to get software
20:09into production at a speed that was
20:11valuable [music] to our customers. And
20:13then when we introduced CICD, we built
20:14systems and automation and processes
20:16around [music] the release process and
20:18how we got software into production and
20:20what that led to was a massive increase
20:22in quality. We were able to essentially
20:24deploy software [music] almost daily
20:26without worrying about whether things
20:28were going to be breaking because the
20:30[music] system would be taking care of
20:31the deployment. It would be running all
20:32of the automated checks for us. And this
20:34means whether you're a junior developer
20:36or the most senior engineer, you're
20:37using the same pipeline to deploy
20:40software which just massively raises the
20:41quality bar within a team. Anyone can
20:43have
20:44>> [music]
20:44>> the perfect deployment process no matter
20:46where you are in the company or how
20:48experienced you are.

About this transcript

This page contains the full transcript of I Built an Agentic Software Factory with Codex and Claude Code by Owain Lewis, generated from the public captions YouTube serves with the video. The transcript has 4,773 words across 698 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.