YT YouTube2Text

YouTube2Text → Transcripts → Agentic Design Skills For Claude Code and Codex

Agentic Design Skills For Claude Code and Codex — Transcript

by Owain Lewis · 3,705 words · 541 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Today we're talking about the two most
0:01important skills for AI engineers,
0:02design and planning. Most content online
0:05is focused on the wrong things,
0:06optimizing your cloud code setup, the
0:07latest agent harness tips and tricks,
0:09>> [music]
0:09>> or even choosing the best model, but
0:11none of that will really help you build
0:12better software. So, in this video I'm
0:14going to show you how to think about
0:15design and planning as an agentic
0:16engineer. We're going to design and
0:17build a feature together. I've been
0:19building software professionally for the
0:21last 20 years, and all of the ideas and
0:23techniques I'm going to show you today
0:24are the same ones that the best
0:25engineering teams in [music] the world
0:27have been using for decades. If you
0:28stick around to the end, I'll give away
0:29the four skills that I use every single
0:31my personal and professional [music]
0:32projects. So, let's get into it. So, an
0:35obvious question is why do I think
0:36design and planning matters so much when
0:38it comes to agentic development? So, if
0:40you think about software development,
0:41there are five phases. The design phase
0:43is where we think about what are we
0:44building, why are we building it, and
0:46then how are we going to build it? So,
0:48this is about understanding the problem
0:50and making decisions or choices about
0:52how to solve that problem. Then we break
0:54our work down into a number of tasks, we
0:56give those tasks to agents to write the
0:58code, we do some kind of verification
1:00step, and then finally we deploy to
1:02production. But, if you think about
1:04these last three phases, largely agents
1:07can do most of them or the entire thing.
1:10So, pretty much you should be able to
1:11give a task to an agent and have it open
1:13a change request for you to review.
1:15Humans aren't writing the code anymore
1:16if we're honest about it. And so, really
1:19there's very little to do in the build
1:21process. If you're still manually
1:22prompting or you're doing things
1:23differently every time you have a piece
1:25of work, that's not going to scale very
1:27well. So, typically you want to get to a
1:29point where you can give an agent a
1:30well-defined task
1:32and be confident that you've built your
1:34process in such a way that the agent
1:36will then open a pull request that is
1:37just ready to go, pretty much.
1:39Verification will depend on what you're
1:41doing. A controversial thing to say here
1:43is it really depends on what you're
1:45doing. I've worked on mission-critical
1:47systems with millions of users. You're
1:49obviously going to do a lot more human
1:50review, human testing in those
1:52situations, but equally I work on side
1:55projects where I'm quite happy for
1:56agents to do a lot of the code
1:57reviewing, a lot of the verification and
1:59testing cuz this is really about
2:00building the verification systems,
2:03automated code review, automated browser
2:05testing, automated checking, automated
2:08everything basically at this stage. But
2:10if you're working on something like a
2:11design, you still want to have a human
2:13in the loop. You don't want to trust
2:14agents to evaluate a design, for
2:16example. And then deployment to
2:17production has been automated for a
2:18really long time. Humans don't really
2:20deploy software anymore. We merge our
2:22code changes in and then the this system
2:24will deploy that to production. So
2:26really the only things left for us to
2:28focus on as developers are design, where
2:31we decide what to build and how to build
2:32it. This is really on us because these
2:35decisions are really, really critical
2:36and important. Planning is about
2:38breaking the work down and then
2:40verification. Again, depending on what
2:42you're doing, you still need to do some
2:44level of verification and checking of
2:45the quality and to make sure everything
2:47is good. So I like to think about design
2:49as two phases. The requirements phase is
2:51where we think about what are we
2:52building, why, and then for who. Then
2:54the technical design is the stuff we all
2:56think about when it comes to design.
2:57It's about making the the choices around
3:00the stack, the database, the
3:01architecture, thinking about edge cases,
3:03security, operations, metrics,
3:06monitoring, alerting. How are you going
3:08to support this feature in production?
3:10All of those things are part of the
3:12technical design process. You can
3:14definitely use an agent to help you a
3:15lot here and that's what we're going to
3:16be doing throughout the process. But
3:18really if you work in a large company,
3:20you'll find that the most senior
3:21engineers in that company spend most of
3:23their time focused on technical design
3:27because it's the highest leverage and
3:28the most important part of the process
3:29to really get right.
3:31So we're going to look at four skills in
3:32this video. The design skill is going to
3:34allow us to build a technical design doc
3:36that we're then going to use to break
3:38down into tasks. We're going to use the
3:40architecture review skill to find edge
3:42cases, flaws, mistakes in the original
3:44design and basically improve the the
3:46original design.
3:48Then I'm going to show you the HTML doc
3:50skill which will allow you to visualize
3:52your designs much more elegantly. It's
3:54very difficult to read markdown
3:55documents sometimes as humans. And then
3:58finally the planning skill will allow
4:00you to break your design down into tasks
4:01automatically.
4:03One technique I really like to use right
4:05now when I'm building any project is to
4:07have an architecture.md file. The
4:10architecture.md file is an overall
4:12high-level architecture for the entire
4:14system. So if you imagine you're
4:16building a project from scratch like a
4:17new web application or any new project,
4:20[music] having this architecture.md file
4:22is a really great reference both for you
4:24and also for agents working on your
4:26project. So again, this is the same
4:29design doc skill that we're using
4:31elsewhere in the video. But this is
4:33focused on the high-level system design.
4:35It's the you know the highest level.
4:37Here's the moving pieces, the database
4:39choice. So this is talking about the
4:41architecture where we have a you know a
4:43server using React. We have a worker
4:47that dispatches to these you know
4:48different coding agents. So these
4:50documents can be really detailed. So you
4:52can see here this is the API definition.
4:54So we have a health check endpoint. We
4:56have a separate API for our worker. You
4:59can kind of just see there's just a ton
5:00of detail. We also have limits detail as
5:02well. These are the little things that
5:04get missed most of the time when
5:06developers build software. They forget
5:08about you know what are the edge cases,
5:10what are the limitations, what are the
5:11controls, what are the rate limits. All
5:14of these little things will protect your
5:16application and make it really really
5:17high quality.
5:19If for example you're building a SaaS
5:20application and you forget to add
5:22limits, a customer could you know
5:24generate a thousand resources and cost
5:26you a load of money. So these kind of
5:28things are actually really really
5:29critical when it comes to building
5:30software. Thinking about limits,
5:32thinking about you know edge cases, rate
5:34limiting. All of these kind of
5:36protections will really help you when
5:38you build out any real software. So for
5:41this video we're going to pick a random
5:42application I happen to be working on
5:44that we can build a feature in. So let's
5:46run the server. So we're going to type
5:47just serve.
5:49And now we're going to start the
5:50application and then go into the browser
5:51and take a look at what this looks like.
5:53So, for this demo, we're going to be
5:54building a feature in an existing
5:55application I've got here called Slate.
5:58This is just a project I happen to be
6:00working on at the time. The idea here is
6:02it allows you to manage your tasks and
6:04assign those tasks to agents. Pretty
6:07standard stuff. It looks pretty similar
6:08to many apps you're probably familiar
6:10with. We have an idea of a board and we
6:12have tasks on the board. We can create
6:14lists of things we're focused on. We
6:16have like a Kanban view. We have a table
6:19view and then we obviously have a
6:20calendar view as well.
6:22So, the idea here is that we can add
6:23tasks to our queue that we want to work
6:25on. Let's say I want to write an email
6:28draft response to, I don't know, Tim.
6:32And then we want to have the agent
6:34basically pick up that task and do it
6:36for us.
6:37So, in order for us to do that, we need
6:39to connect our agents. So, you can
6:40define an agent over here.
6:43But, in order for us to assign work to
6:44the agent, the agents need to be
6:45listening and watching these tasks. So,
6:47that's the feature we're going to be
6:48building today. So, the first thing we
6:50want to do is think about the feature we
6:51want to build. So, the idea here is that
6:53we want to build a feature that allows
6:55an agent to listen, monitor the task
6:58board, and then basically automatically
6:59pick up the work. So, what I'm going to
7:01do is use the design skill
7:03that I have written and I'll link all of
7:05this in the description. We're going to
7:06say something like, "I want to build a
7:08feature that allows me to adapt the CLI
7:10tool that we have so that it listens and
7:13watches the board for tasks to pick up.
7:15A task is suitable for an agent if it
7:17matches the agent's name and it's in a
7:20ready state. Any tasks that match those
7:22criteria, we want the CLI to
7:24automatically pick up and then delegate
7:26to an agent to implement the task and
7:28then we want the agent to update
7:30the task board once it's finished,
7:32comment back on the ticket, and move it
7:33into a review state. So, before we use
7:36the design skill, I'm just going to
7:37basically brainstorm first to help me
7:40ideate
7:41this feature.
7:44So, before we even move into writing
7:45this down into the document, I think
7:47it's helpful to get clear about what it
7:48is we're building. While I think you can
7:50get away with using a cheaper model for
7:52the implementation, the design is such
7:54an important part of the process. You
7:56need the agent to really think about all
7:57of the different conditions, the edge
7:58cases. So, typically I will use the
8:01higher reasoning settings or like the
8:03best model available to do the initial
8:05design, whether that's, you know, Claude
8:07or whether that's GPT. So, this is an
8:09example of where the agent's opinion and
8:11my opinion may be different on the
8:12implementation details and you want to
8:14go in a different direction. So, you
8:16don't want to always accept the agent's
8:17opinion. You may be want to challenge it
8:19a little bit. So, in this example, we're
8:21deterministically updating the state of
8:23the ticket after we've updated it, which
8:26seems pretty reasonable.
8:27But, what I found is that this actually
8:29adds a lot of complexity and I would
8:32rather the agent to do the update
8:34because agents are pretty capable today.
8:36So, I'm going to make the change so that
8:37it's the agent that is responsible for
8:39updating the task
8:40using the CLI tool.
8:42So, what you'll find is as you go
8:43through this process, the agent will
8:45make a decision and you might disagree
8:47with that decision or challenge it or
8:49think about something in a different way
8:50and you want to constantly kind of go
8:51back and forth with the agent on these
8:53design decisions. Okay, so Codex is now
8:55finished doing the initial design and
8:57what we have here is like a clean
8:58executive summary basically describing
9:00what this feature is, what the goal of
9:03what we're trying to do is in a really
9:04sort of simple and understandable way.
9:07Then, we have some context about the
9:08system and we have a diagram of how this
9:11is going to look. And we've got a
9:13proposal on the design. I like to spend
9:15a lot of time thinking about the user
9:17experience when it comes to these kind
9:18of things. So, what does the the user
9:20experience as they use this product?
9:22Like, what are the commands that they
9:24actually run? Do they make sense? Are
9:26they intuitive? Things like that,
9:28basically. You'll also notice we have a
9:30ton of detail in this document. Some of
9:32this is important because when you think
9:34about a task like this, there are kind
9:36of all of these little edge cases and
9:38race conditions that might happen. An
9:40agent might claim a task, but then what
9:41if two agents are competing to claim the
9:44same task at the same time. So, there's
9:46kind of these weird edge cases that you
9:47might not have even considered when you
9:49first started thinking about this
9:51particular feature. And really, the
9:53design phase is a chance for you to kind
9:54of surface these hidden like things that
9:57you might not have been thinking about
9:59in the original design phase.
10:01So, one of the things you might notice
10:02is how big and detailed this design doc
10:04is. And this is one of the reasons why I
10:06always break things down into smaller
10:08tasks, because this is just too much
10:09information, in my opinion, for an agent
10:12to handle generally in one shot.
10:15There's far too much going on here.
10:16There are so many different edge cases,
10:18task conditions, uh like implementation
10:20details we need to get right. So, we're
10:22going to have a much better result if we
10:24can kind of break this down into smaller
10:26tasks. Okay, so now we have the initial
10:28design, but it's quite hard to read
10:29through that design initially. So, what
10:31we're going to do is use the HTML doc
10:33skill. I'm going to say, "Use the HTML
10:37doc skill to make this more readable."
10:42So, this is the document that was
10:43generated by our skill. It's taken the
10:45initial design and turned it into a
10:47slightly more readable HTML version of
10:49that design doc, essentially. We have
10:52all of the same information, just maybe
10:54presented in a more readable format. We
10:56have a diagram which is easier to read.
10:58So, we have this kind of slate watching
11:00CLI tool that is watching
11:05the API.
11:06We've got the database over here.
11:08So, these diagrams are really, really
11:09important for understanding. If you're
11:11like me, maybe a a visual learner, then
11:14having diagrams here can really, really
11:16help you understand what's actually
11:18going on. What might be interesting is
11:20to use a different model to critique
11:22this design. I typically would use the
11:24existing Codex model, but it might be
11:26interesting to spin up Claude and see if
11:29we can get Claude to review the design
11:32as well. So, I'm going to ask Claude to
11:34review this. So, review the at docs/
11:39Let's find the actual document.
11:41Agent task watcher design MD file
11:45using the architecture review skill.
11:50All right, so we're going to ask Claude
11:51now to review this using the
11:53architecture review. You can see here
11:54we've loaded this architecture review
11:56skill.
11:57And we're going to see what Claude
11:59thinks about our design that was done in
12:01Codex. Like I said, I wouldn't always
12:03use a second model. I don't think it's
12:04necessary. But it can be quite
12:06interesting to see if you get a
12:08different result or different feedback.
12:10I think it's worth using the best models
12:12and spending more tokens on design
12:14because this is going to save you money
12:16in the long run. If you make mistakes or
12:18you implement the wrong design, you're
12:19going to have to go back and correct
12:21those things. And it's much more
12:22expensive to correct mistakes both in
12:24terms of token usage, but realistically
12:27in terms of, you know, customer impact,
12:29development time, it's far better to
12:31spend a bit of time early on in the
12:32process getting this right than it is to
12:34kind of, you know, take shortcuts at
12:36this stage. If you're going to spend
12:37tokens, spend your tokens on design.
12:40When it comes to reviewing a design,
12:41there are lots of things you need to
12:42think about, which is what makes design
12:44somewhat challenging in general because
12:46there are all of these different edge
12:47cases that you probably haven't
12:48considered. Things like rate limits to
12:51protect, you know, against the number of
12:52requests a customer can make in a given
12:54time period. You also want to think
12:56about, you know, scalability. Does this
12:59design scale well? If I have 10 users,
13:02it might work great, which is the
13:03problem with live coding, right? You
13:05have something that looks great on a
13:06demo, but as soon as you put it into
13:08production, it completely falls over
13:09because it's not scalable. It wasn't
13:10designed very well. So, what I'm going
13:12to do now is simply ask the agent to
13:14break this down into a number of tasks
13:16and then store them in an issue tracker.
13:18The The reason I think you can largely
13:20just let agents do this because it's
13:21mostly mechanical. So, I would
13:23definitely recommend using agents to do
13:25the task breakdown. Having worked in
13:27software for a long time, I can tell you
13:28for certain that humans are not very
13:30good at this kind of work because it's
13:32incredibly complex, incredibly
13:34mechanically detailed. So, for example,
13:36you can see that the agent is now, you
13:38know, making sure that all of the the
13:40invariants and the task conditions are
13:42captured within a task. This stuff is
13:45very time-consuming for a human to do.
13:47I generally don't bother writing the
13:49tasks by hand anymore. I'll always use
13:51an agent to do the task breakdown. I
13:52just feel it leads to a higher quality
13:54result. The agents are just much better
13:56at keeping the the detail. Okay, so what
13:58you can see is that we've now broken
14:00this down into five discrete tasks. So,
14:02we're adding the run contract.
14:05All right, this seems reasonable. You
14:07can obviously review the tasks and make
14:08sure they make sense to you. Maybe
14:10there's something the agent has missed,
14:11but generally I will take the output of
14:13the agent.
14:15And you can see here we have a very
14:16clear summary of what the task is,
14:18the outcome that we want,
14:20and any kind of constraints,
14:23and yeah, what's in scope, what's out of
14:25scope, things like that. So, I'm pretty
14:27happy with these tasks. They seem
14:28reasonable to me.
14:30So, what I'm going to do now is just ask
14:31the agent to create the tasks for us.
14:33Create
14:34these as GitHub issues. What I didn't do
14:37here is link them all to a parent
14:39ticket. So, it can be quite confusing if
14:41you have a large number of tasks or
14:42tickets in a task manager, it's very
14:44easy to get confused. So, all of these
14:46tasks relate to the same unit of work.
14:48So, I'm going to ask the agent to
14:49correct itself. Link these tasks to one
14:53parent ticket. Okay, so you can now see
14:56that we have these five tasks. As I said
14:58before, the the level of granularity in
15:00your tasks will depend on what you're
15:01doing. Some people might just want to
15:03vibe code the whole design, like just
15:05run through it in one shot.
15:07If it's a simple design, you can
15:08probably do that, capture it in one
15:10task. But if it's anything more complex
15:12where you need to kind of test and
15:13iterate as you go through the cycle,
15:16it's just helpful to break things down
15:17into smaller number of tasks. So, we
15:19have one parent ticket here, which we
15:21can take a look at. This is what it
15:22looks like in the browser. We have this
15:24one task, so build the agent task
15:26watcher, which is what we've been
15:28planning out. And you can see here we
15:30have linked all of these, you know, sub
15:32issues that need to be done. And we also
15:35have the delivery order. So we have an
15:37acceptance criteria that all of the
15:39issues are complete. We have, you know,
15:41a rollout plan to deploy this.
15:44So a pretty detailed ticket. And at this
15:46point, you can just hand this off to an
15:47agent and let the agent work through all
15:50of these tasks.
15:51So what I would typically do is just use
15:52Codex to build out the rest of the
15:54tasks, but there's nothing stopping you
15:55using a different agent if you wanted
15:57to. So I'm going to go ahead and just
15:58use Claude to build out these tasks
16:01because all of the tickets are really
16:02detailed. We have, you know, the design
16:04document, all of the details in the
16:05ticket. There's really nothing else that
16:08the agent needs to know at this point.
16:09So let's go ahead and build these out.
16:11So I'm going to use the task to PR
16:13skill.
16:16And then I'm just going to pass it in
16:17the parent ticket.
16:20And then that's pretty much it. I'm just
16:21going to wait now for the agent to work
16:23through these tasks, sequence them. This
16:26skill is going to make sure that all of
16:27the changes are tested. They've got code
16:29review. And it's pretty much just a case
16:31of now waiting for the agent to burn
16:33through these. Thanks for watching the
16:34video. I hope you found it useful and
16:36valuable. If you did, please remember to
16:37like and subscribe because it massively
16:38helps out this small channel.
16:40And I'll link all of the resources for
16:42free in the description below. I'll link
16:44the, you know, the the skills that we
16:45talked about as well, so you can
16:47download those,
16:48>> [music]
16:48>> use them in any way you want. You're
16:49free to adapt them. Whatever you want to
16:50do with them is totally fine.
16:52Thanks again for watching and I will see
16:54you in the next one. Take care.

About this transcript

This page contains the full transcript of Agentic Design Skills For Claude Code and Codex by Owain Lewis, generated from the public captions YouTube serves with the video. The transcript has 3,705 words across 541 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.