YT YouTube2Text

YouTube2Text → Transcripts → 7 Months of Claude Code Lessons in 19 Minutes

7 Months of Claude Code Lessons in 19 Minutes — Transcript

by Sabrina Ramonov 🍄 · 5,390 words · 774 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00The ultimate AI coding guide for
0:02engineers who are building realworld
0:04production apps for thousands of users.
0:06In this tutorial, I'm going to walk you
0:08through everything from setting up cloud
0:10code, my extensive AI coding rules file,
0:13how I actually use this file to code
0:15each part of the process, and I'm going
0:17to walk through real example
0:18implementing a feature in my codebase,
0:20which is an existing codebase with many
0:23users that I support. This video is for
0:25software engineers who want to learn
0:26best practices using AI for everyday
0:30coding. This is not vibe coding. This is
0:32not building MVPs. And real quick, my
0:34name is Sabrina Ramanov. My background
0:36is in computer science and physics from
0:38UC Berkeley. And I previously sold an AI
0:40company for millions of dollars. The
0:42first step is to download your AI coding
0:44tool. Many of you probably use Cursor AI
0:46or Windsurf AI. I did too for a very
0:49long time. In fact, I built the MVP of
0:52my product entirely with Cursor AI back
0:55in early September. But nowadays, I've
0:57switched to Claude Code. I found it to
0:59be much more powerful than both Cursor
1:01and Windsurf. Super easy to install.
1:03Just do npm install here. Okay. Then
1:05open a terminal and run Claude. Or if
1:08you use Visual Studio Code, you can
1:10download their extension and they have
1:12instructions on the website. There'll be
1:13a little Claude icon here. Okay. And
1:15then it'll run Claude. The nice thing
1:17about the extension is that it is aware
1:19of what files you have open in your ID.
1:21If you type / ID connect to an IDE for
1:23integrated development features run.
1:25Okay. The other thing I'll point out is
1:27choosing the model. I actually prefer
1:29Opus for everything as much as possible.
1:31So, Opus and then if you do like Vim
1:34mode, you can toggle between Vim or
1:36normal mode. Before we start coding, I'm
1:37going to walk you through my AI coding
1:39rules file. In Claude Code, it's called
1:41claude.md. In Cursor AI, it's called
1:44cursor rules. starts off with
1:46implementation best practices. The
1:48purpose of these rules is to ensure
1:50maintainability, safety, and developer
1:52velocity. Before coding, ask me
1:55clarifying questions. Draft and confirm
1:57an approach. If multiple good approaches
1:59exist, list the pros and cons. While
2:01coding, we're going to follow
2:02test-driven development. Okay. Name
2:05functions with your existing domain
2:07vocabulary for consistency. Really
2:09important if you have a large codebase.
2:11Introduce classes when small testable
2:13functions suffice. Prefer simple
2:15composable testable functions. If you're
2:17using TypeScript, prefer branded types
2:20for your IDs, etc., etc. Rely on
2:22self-explanatory code. Don't just litter
2:25the codebase with comments everywhere.
2:27Default to type, not interface. And this
2:29is important for refactoring. Don't
2:31extract a new function unless it will be
2:33reused elsewhere or it's the only way to
2:35unit test, otherwise untestable logic or
2:38drastically improve readability. Um cuz
2:40I notice often times when I tell AI to
2:42refactor something or come up with a
2:44better plan, it'll extract all of these
2:46functions, but it's not really
2:48refactoring unless it hits some of these
2:50criteria. By the way, I should have
2:51mentioned this earlier. You might notice
2:53like the tags here. Must, should, should
2:56not, BP1, BP2, BB3. This is really handy
3:00because when Claude goes over and checks
3:02your codebase, it can point out like,
3:04oh, this code change fails rule C3. it
3:08introduced a class instead of using a
3:10small testable function or this code
3:13changed failed rule C6. It used import
3:15type for something else. So I find this
3:17really handy and the codes are organized
3:20by section. So like C1 C2 is related to
3:22coding. T1 T2 related to testing. So
3:25here's testing colllocate unit tests in
3:28the same directory as source file. For
3:30any API change, add or extend
3:32integration tests over here. Always
3:34separate pure logic unit tests from
3:36database touching integration tests etc.
3:39Database I mean for the database section
3:41you'll probably want to update this so
3:43that it's customized to your repo
3:45similar to code organization and tooling
3:47gates. And then I have a little section
3:49down here for git as well. Use
3:50conventional commits format when writing
3:53messages. Obviously you're going to want
3:54to tweak this so that it makes sense for
3:56your codebase and cloud code can help
3:58you. So if you copy this file, import it
4:01into your project and then ask cloud
4:02code how should I update this cloud MD
4:05so that it is specifically tailored to
4:07my codebase that should mostly do the
4:08trick. Okay, so this first part is just
4:10implementation best practices. And every
4:12time I start something new with cloud
4:15code, I clear the context and then tell
4:17it to read and analyze these
4:20implementation best practices. And I'll
4:21show you all of that in a sec. Right now
4:23I'm just walking through this really
4:25long file. Okay, so the next section is
4:27writing functions best practices. So
4:29when I asked Claude like look at the
4:31function you implemented is it good or
4:33not? It's supposed to use this
4:35checklist. Uh I'm not going to read it
4:37step by step. You can read it but
4:39basically it's best practices for
4:41writing functions. Here's writing test
4:43best practices and you're going to see
4:44how I use these checklists in a bit but
4:47it's pretty similar. Like for each test
4:49you want to go through these best
4:51practices. Code organization. You'll
4:53want to customize this obviously
4:54according to your project. And then this
4:56section here is one of my favorite
4:58remember shortcuts. And basically what
5:00it means is when I type Q new for
5:02example, this means understand all of
5:04these best practices in this file and
5:06your code should always follow these
5:08best practices. So I will run this
5:09shortcut q new. When I start a new
5:12session, I clear the context type q new.
5:15It forces claude code to read the claud
5:18file and so it has it kind of in
5:20immediate context. And then what I
5:22typically do is discuss the user story
5:24with Claude. And then when we come up
5:26with a decent plan, I tell it Q plan.
5:28And what that means is it looks at
5:30similar parts of the codebase and
5:32determines whether the plan is pretty
5:33consistent with how I do things like
5:35everywhere else. Introduces minimal
5:37changes and reuses existing code. For
5:40example, if you can do the same thing
5:41with a function I've already
5:42implemented. When we're happy with a
5:44plan, so this is where I spend a lot of
5:45time kind of back and forth. When we're
5:47happy with a plan, then I type Q code.
5:50That means implement your plan ensuring
5:52the new tests pass because test driven
5:54development is really important. Always
5:56run these things turbo type check. Uh
5:58these two you'll probably want to swap
6:00out so it's makes sense for your
6:01project. When it's done coding I have
6:03this other command q check which tells
6:05cloud you are a skeptical senior
6:07software engineer. Perform this analysis
6:09for every major change you introduced.
6:11So now it's going to go through those
6:13checklists the writing functions
6:14checklist writing tests checklist and
6:17the implementation best practices. And
6:19it's pretty cool because it's going to
6:20output what looks like a checklist. Like
6:22you'll see the things where it thinks it
6:24kind of went wrong according to the
6:25checklist. The problem with this though
6:28is like sometimes it's too much context,
6:30too many code changes and then the
6:32checklists are pretty long as well. So
6:34I'll also break it down here. Q check.
6:37This will analyze each major function
6:39according to the checklist that I showed
6:41you earlier. This is Q check. So it'll
6:43do the same thing but for every major
6:45test I added. And honestly, I find that
6:48these work a lot better by focusing
6:50Claude on just functions or just tests
6:53rather than trying to do everything at
6:55once. Okay. Then once I'm happy with the
6:58quality of the code, it's introduced and
7:00I'm testing it out. I have this command
7:02qx claude. Imagine you're a human UX
7:05tester of this feature. Output a list of
7:07scenarios you would test sorted by
7:09highest priority. And this is just nice
7:10for me so that I don't get too lazy with
7:13testing, you know, when you want to just
7:14like wrap up a feature. But this is
7:16really neat because Claude Code will
7:18like output a really long list and
7:20there's always stuff there that I
7:22honestly probably wouldn't have tested
7:24myself unless Claude reminded me. And
7:26then the last thing here is just best
7:28practices for git. Qit means add
7:31everything to staging create a commit
7:33and push to remote and then use this
7:36best practices for writing your commit
7:38message. I'm basically using
7:39conventional commits format. This is
7:42sample structures for the commit
7:44message. This is literally copy pasted
7:46right from the conventional commits
7:47website. Okay, so that's pretty much the
7:49entire claude file and now we're going
7:51to put it into practice. So the first
7:53thing I'll do is make sure you branch
7:55out to your new branch feature/prompt-
7:57selection and then clear the context. So
7:59type /cle double check which model
8:02you're using is opus. If you want vim
8:04mode, type /v make sure it's connected
8:06to your IDE/ IDE, right? Okay. And then
8:09I type q new tells claude to read the
8:12claud file and understand all the best
8:14practices there. By the way, if you want
8:16to shift modes, you can do shift tab.
8:18This will auto accept all edits. This is
8:20plan mode and this is normal mode. I
8:22usually will keep it in normal mode or
8:25accept all edits mode. Okay. So now
8:27claude reviewed our cloud MD file.
8:30Great. Awesome. And then I will say
8:32create a plan for this user story. You
8:36are improving the remix screen. Okay.
8:39And you can actually drop screenshots by
8:41the way. So here I'm going to take a
8:42screenshot of this screen and then drop
8:45it into my claw MD file. And basically
8:48what we want to do is this is my app
8:50running locally by the way. So after a
8:52user adds a source that they want to
8:53remix. For example, I want to take my
8:55Tik Tok video and convert it to a
8:57LinkedIn post or Facebook post. I
8:59basically want to have drop- down
9:00selectors right here so I can select
9:02which prompt to use when repurposing
9:05that content. Right now, it's just set
9:07to use like default prompts in your
9:09prompts library, but users can create
9:12and edit prompts. So, I want them to be
9:13able to choose like their own custom
9:15prompts here. Let me just clean this up
9:17to each selected platform. And the drop
9:20down allows users to select which prompt
9:22to use to create postdrafts. Okay. Then
9:25click enter. And now it's going to
9:27analyze the remix screen and create a
9:28plan for adding prompt selection
9:30dropdowns. And one thing you might
9:32notice is I didn't actually tag any
9:33files. So when I used to use cursor and
9:36windsurf, I mean you'd absolutely have
9:38to tag which files you wanted to include
9:40as context. I typically find that I
9:42don't have to do that with cloud code.
9:44Certainly you can do that. Certainly you
9:46can do that. So if you type at you can
9:49tag files and stuff but I just generally
9:51find that I don't have to do that. As
9:52you start working on the feature cloud
9:54code is aware of what files you have
9:56open. And this is also why I like to
9:58clear the context every time I work on
10:00something different because initially
10:01Claude will go through this like
10:03planning phase understanding how the
10:05current codebase works and which files
10:06would be relevant to this feature and
10:09that's already in the context for the
10:11session. And I know it's really tempting
10:13when cloud code is running to just like
10:15leave and come back when it's done. And
10:17I definitely do that. But I found my
10:19sessions to be much more productive if I
10:22force myself to sit here and read what
10:24it's doing, follow along, and most
10:26importantly stop it if it looks like
10:28it's going down the wrong rabbit hole
10:30because you could literally save 10
10:32minutes of cloud code kind of going down
10:34the wrong rabbit hole. So I do read what
10:36is its plan, what is it doing at each of
10:38these steps. And if you've tried any
10:40coding tool, I mean, they all sound very
10:43confident and correct in what they're
10:44doing, but you know, in many cases
10:46they're absolutely wrong. And so that's
10:48why it's important to pay attention to
10:50what it's doing. Cut it short before you
10:52waste a lot of time going down the wrong
10:54rabbit hole. Oops, I accidentally
10:55clicked to escape there. I just click
10:57continue. My escape is rebound to my
11:00caps lock. So I'll accidentally hit it
11:03sometimes, but usually if I say
11:04continue, it's fine. And yeah, if you
11:06don't have an ergonomic keyboard like
11:08Kinesis or the other one I'm trying out
11:10right now is Glove 80, highly, highly
11:12recommend. It's amazing. Finally, it's
11:13creating its implementation plan. And
11:16yeah, it would have gone faster honestly
11:18if I tagged the right files in context.
11:21But I also really like that that I don't
11:23have to do that most of the time. And it
11:25eventually does find like the most
11:27relevant files to analyze. Okay, so
11:30here's its first draft plan. Almost
11:32never proceed with a plan like this.
11:34I'll almost always say no, keep
11:36planning. Even if I decide to proceed
11:38with a plan, I would rather use my
11:40shortcut Q code which tells Claude to
11:42implement the plan but make sure you
11:44know tests pass and run lint checks and
11:47all these things. Okay, so let's read
11:48its plan. Create this new component that
11:51fetches and displays users prompts
11:53search fun include search functionality.
11:55Show prompt title with description on
11:58hover. Okay, maybe add default option
12:00that uses platforms default. Yeah, that
12:03all makes sense. Modify platform state.
12:05Okay. Add prompt dropdown next to post
12:08count controls. It's talking about these
12:09post counts controls. Okay. Ensure
12:12spacing sounds pretty good actually. I'm
12:14not sure we really need this one. Going
12:16to give it feedback. Update the plan as
12:19follows. Okay. Everything on the same
12:23row. Okay. So here, just update the
12:25plan. Just remove stuff we don't need.
12:27At this phase, I also like to question
12:29things like do we really need that? I'm
12:31like mixed on the search functionality.
12:33I mean it would be nice to have the
12:34source of functionality right away but
12:36realistically people don't have hundreds
12:39of prompts they have dozens of prompts
12:41so always click no keep planning and
12:43then now what I do here is I type qplan
12:45and let's go back to our um claude MD
12:48file right so remember qplan tells
12:50claude to analyze similar parts of the
12:52codebase and determine whether this plan
12:54so far is consistent with how I do
12:56things in the rest of the codebase it
12:58introduces minimal changes and most
13:00importantly reuse existing code where
13:02possible And so I almost never just like
13:04accept the plan and move on. You know, I
13:06I really encourage you to question it.
13:08If something doesn't make sense, if
13:10you're not sure if it's worth it to
13:12include something, if stuff seems
13:14unnecessary, just remove it for now. You
13:16could add it later, right? If it's
13:18critical. Once the plan looks good, I
13:20run this shortcut Q plan to update it so
13:23that it's more consistent with the code
13:25base and a quality check for the plan.
13:27And then once I'm super happy with a
13:30plan, then I'll run Q code which is over
13:32here. Right? These shortcuts are
13:34actually in order of how I use them.
13:36Right? So when I start a new feature,
13:38chore, bug fix, I clear the context,
13:40then type Q new. I tell it like the user
13:43story will go back and forth a bit. If
13:45the plan looks pretty good, then I type
13:47Q plan as a quality check. Okay. And
13:50then when I'm happy with the plan and
13:52ready for cloud code to start coding, I
13:54type Q code. Okay. Then after it codes,
13:56I want to do a quality check. So this
13:58will do a quality check for everything.
14:00But I find it more effective to
14:02separately check functions first and
14:04then separately check tests. Then you'll
14:06see towards the end I'll do qx to output
14:09a list of the things that I should test
14:12and then qit at the very end to create a
14:15commit and push. And I do find cute plan
14:17is actually really helpful because often
14:19times cloud code will produce a plan and
14:21when you dig into it it's like why
14:23wouldn't you just do it this way? I have
14:24an example in the codebase or something
14:27similar in the codebase and qplan is
14:29really good at telling cloud code oh hey
14:32use this pattern that is already in the
14:34codebase for this new feature okay
14:36here's its updated plan okay
14:38implementation steps okay so here
14:40towards the end it summarized it minimal
14:42changes approach so this reuses the
14:45existing combo box pattern okay
14:47leverages existing prompt fetching
14:49maintains current UI structure these two
14:51are kind of generic so not super helpful
14:53but you You can see you can see now the
14:56plan is a lot more detailed in terms of
14:58what it's going to use and most
14:59importantly reuse from our existing
15:01codebase. And again this is where you
15:03want to push back and really question
15:04stuff like if you don't understand why
15:06are you suggesting this just ask right
15:08and then claude will either justify it
15:11or remove it from the plan. I'll say
15:13will any of these changes break existing
15:16functionality. I'm just giving you an
15:18example of stuff you can ask, right? In
15:20fact, this is probably a really good
15:22question to add to Q plan like summarize
15:25potentially breaking changes. Okay? And
15:27here's its analysis of breaking changes.
15:29Of course, AI would say there are no
15:31breaking changes if implemented
15:32carefully. But again, this is stuff that
15:34you really want to think through,
15:36question it, make sure you're happy with
15:38the answer. And once you're happy with
15:39everything, I just type cute code. And
15:42like I said, and and you can see over
15:44here on the left what that corresponds
15:45to. It's really neat because I can just
15:47open this cloud MD file and it basically
15:49reminds me the process step by step and
15:52while it's making all of these changes,
15:54so now it's coding. What I like to do is
15:55personally have this source control or
15:58work tree open and then any files that
16:00it modifies or creates, I like to
16:03literally look at what it's doing. And
16:05like I said earlier, this is the point
16:06when you're tempted to just let cloud
16:08code do its thing. But it's honestly
16:11incredibly important to pay attention to
16:13what it's changing because it can
16:15introduce all kinds of stuff that
16:17impacts or significantly bloat your
16:20codebase. It could leave things in there
16:21that are unused, implement questionable
16:24things and it is really important to pay
16:26attention to what it's doing. I like to
16:27read the summary of what it's doing on
16:29the right hand side and also open the
16:31files that it's changing and kind of
16:32follow along. And again, if it's going
16:34down a pretty sketchy rabbit hole for
16:37some reason, just stop it early. Ask it
16:40why are you doing this and change its
16:42approach so it doesn't go down the wrong
16:44rabbit hole. And if you prefer this view
16:46where you have like the old version and
16:48then new version on the right hand side,
16:49you can do that as well obviously in
16:51Visual Studio Code. Okay, now it's
16:52running prettier and doing the type
16:54check and then it's going to test the
16:55implementation. Okay, the other thing
16:57I'll point out is that these checklists
16:59also serve as reminders for me. Can you
17:02read the function and honestly follow
17:04what it's doing? That's a great tanning
17:06check. Like even for us as humans, when
17:09I look at this, is it clear what it's
17:11doing? Is it clear that it's necessary?
17:13Like this to me slightly questionable.
17:16This looks okay so far. Post draft
17:18multiform. This little sloppy like is
17:21there a better way that it could have
17:23done this? Right? And so I also
17:24personally like to go just down these
17:26checklists. Another handy thing when you
17:28select stuff in this editor, similar to
17:31cursor or windsurf, claude code is aware
17:34of it. So let's say I wanted to just
17:36improve this or question this. I would
17:38just select it like this and tell cloud
17:40code, is there a better way to do this?
17:42It looks a little bit sloppy or is this
17:44really necessary? And you can see on the
17:46right hand side when it ran prettier and
17:48type checking a bunch of stuff failed
17:50and so now it has to go fix that. Okay,
17:52type checks pass and now it's just
17:54fixing these minor lint errors. And even
17:57though claude is still running, I can go
17:58ahead and like start testing it out,
18:00right? So here I clicked Twitter and
18:02then here I clicked Instagram. There is
18:04a loading spinner. That's kind of a
18:06minor bug, right? It's still stuck. I
18:08only have a couple prompts in this
18:09example, but this is pretty cool. The
18:11names are kind of confusing here, but in
18:13production, users have prompts that are
18:16geared towards all kinds of different
18:18copywriting styles. So rather than
18:20Facebook, LinkedIn, Twitter, you could
18:21have a prompt that's like write a
18:23technical tutorial in this format or
18:26write a micro essay. But this is pretty
18:28much exactly what I want, right? So the
18:30default will default to the platform
18:32default. I also want to test creating a
18:34new prompt. My new prompt, write the
18:37following content in a 10point bullet
18:40point list. Okay, so here I'm creating a
18:43new prompt and then let's see if I can
18:45select it. Yeah. So here my new prompt.
18:48my new prompt. We have to fix that
18:49spinner though. And then click generate
18:51post. So if this worked then it should
18:54generate basically a 10point bullet
18:56point list. Okay. And there we go. That
18:58was our new prompt. You can run Q check
19:00which will run which will like kind of
19:01check everything. So let's do that
19:03first. However, I find it generally more
19:05effective to separate run Q check F to
19:08check the functions and then Q check T
19:10to check the tests. Okay. And you can
19:12see it's already reviewing prompt select
19:14and you can see this bullet point list.
19:16Here's one thing where it could be
19:18improved. Now, you'll notice Cloud Code
19:20and other AI tools like often will say,
19:23"Oh, you should extract this into a
19:25separate function." But the reason why I
19:27had to add this whole section over here
19:30in CloudMD, you should not refactor out
19:32a separate function until there's a
19:33compelling need is precisely because it
19:35would be a little bit too trigger-happy
19:38and like moving everything to a separate
19:39function. And here you can see like the
19:41beauty of implementation best practices
19:43and the coding of each item. BP1, BP2,
19:46BB3, C1, TDD not followed. Yeah, I
19:50noticed that there were like absolutely
19:51no tests written. Usually, it actually
19:53does write tests first. And so that
19:55definitely would have been a candidate
19:56of me kind of stopping it early and be
19:58like make sure to do TDD first. And then
20:00here are its recommendation. I'm going
20:02to implement 1 3 1 2 and four. We don't
20:06want to extract it into a separate
20:08logic. And also remove the loading
20:10spinner. It's removing the loading
20:12spinner. and it decided to keep the
20:14platform parameter just to display it
20:16for default platform prompts. And funny
20:19enough, cloud code is kind of correct
20:21here. I don't really have a lot of
20:22tests. Most of my tests do focus on
20:25functions rather than like complex
20:27mocked integrations. So that is
20:28something I need to improve in my own
20:30codebase. But for this particular
20:32feature, yeah, it's not going to be like
20:34a ton of going on. Next, let's run q
20:36check f. And this will force cloud to
20:38look at the code changes that it has
20:40introduced and make sure that it follows
20:42our best practices checklists. So even
20:45though I specify function like cloud
20:47will generally look at all major
20:49non-esting code changes that were
20:51introduced. And you can see the
20:52checklist here. So it's reviewing first
20:54the prompt select components. Now it's
20:56now it's reviewing postdraft multipost
20:59form state management. Slight
21:00duplication functionality but it says
21:02it's acceptable. So that's why it's in
21:04yellow. However, custom prompt fetching
21:06has high complexity, difficult to test,
21:08could be extracted. So, you may have
21:10noticed Claude has been suggesting that
21:12for a while, but again, I don't really
21:14want to do this unless there's a very
21:15compelling need. Even Claude agrees that
21:18this is not really critical as the
21:20current implementation already works.
21:21Okay, so I'm still a little sketched out
21:24by this though. So, I'm going to
21:26highlight this and you can see 10 lines
21:28selected. Cloud code is aware of what
21:30I've highlighted. I'll say this looks a
21:33bit messy. Let's see what it does. Okay.
21:35And this is much closer to what we
21:37originally had, right? Record here,
21:39string, and then number. Number actually
21:41refers to the count. I can remix my Tik
21:43Tok video into three Twitter posts. And
21:46then prompt ID is use this prompt for
21:49those three Twitter posts. So, this
21:51looks much better. There was something
21:52else that was sketchy as well. Yeah,
21:54like this looks really sketchy. This is
21:56why I like to visualize the working tree
21:58version because I can eyeball this. Is
22:01it super clear at a first glance what is
22:03going on? If not, then I just highlight
22:06this code block and either ask Claude
22:08like why is this necessary or tell
22:10Claude to clean it up. And of course,
22:11the feature you're implementing and
22:13which parts of the codebase it touches
22:15will definitely influence how
22:17extensively Cloud Code tests stuff. For
22:20this particular feature, it's pretty
22:21light on testing, right? Like we're not
22:24making major changes. We just are
22:26introducing a drop-own selector on the
22:28front end so people can choose which
22:30prompt will be used. And this also looks
22:33a little sketchy. So this looks a bit
22:36messy. Okay, so I changed this whole
22:38mess to one line, right? This is general
22:41best practice. The first shot version of
22:43cloud code will produce working code,
22:46right? Like you saw me test it. It was
22:48basically working within 10 minutes,
22:50right? But in terms of the code quality
22:52that was introduced, a lot of room for
22:55improvement. And that's why it's
22:57important to just pay attention to what
22:59it's doing because all of that stuff
23:01piles up over time and you will be left
23:04with massive piece of spaghetti code if
23:07you don't pay attention and deliberately
23:09clean some of that stuff up. Okay, so
23:11we're almost done. I'm just going to
23:13change the name of this one to be the
23:15coin. Write the following. Okay, and
23:17let's create another prompt. quotes.
23:20Extract the top three most controversial
23:24quotes for source. Okay, I just want a
23:27couple different prompts so we can test
23:29all different kinds of prompts for the
23:30platforms. Call this one like blog.
23:32Rewrite the following content in a blog
23:35post with emojis everywhere. Okay, so
23:38now we have three custom prompts that
23:39we're going to test. Here I ran the qx
23:41command which in the cloud MD file just
23:44means that claude is imagining it's a
23:46user experience tester of the feature we
23:48just implemented. Output a comprehensive
23:50list of testing scenarios sorted by
23:52priority. And this is really handy
23:54because you know towards the end of
23:56implementing a feature. I kind of get
23:58lazy and don't necessarily think through
24:00all the possible edge cases and
24:02scenarios. So this is nice to just kind
24:04of go down through the list. Now it is
24:06pretty comprehensive. As you go further
24:09down the list, you might say, "This
24:11doesn't really apply or like this would
24:12never happen." What I like to do is have
24:14the app open here on the left hand side,
24:16the testing list on the right hand side.
24:18And then just go down the list in
24:19priority order. So here, add a source.
24:22Okay, we already have Tik Tok as a
24:24source. Select one platform, LinkedIn.
24:27Choose a prompt. Say bullet points, and
24:29then generate post. Verify that the
24:31generated content follows the custom
24:33prompt format, which it does because
24:35this is a list of 10 bullet points. and
24:38verify that the content is based on the
24:40source material which is correct. Next
24:42one is default prompt behavior. Let's
24:44just do Facebook. We're just leaving it
24:46as default and then generate post. So
24:48this will use default prompt, write a
24:50viral Facebook post or something. Yeah,
24:53this looks pretty good. So again, this
24:54is really nice to go down the list. The
24:57next scenario I would test would be
24:58multiple platforms with different
25:00prompts. If I don't add any sources,
25:02etc., etc. So you just go down the list
25:04and and test the ones that you believe
25:06are relevant. If you're pretty happy
25:08with the feature, the very last step is
25:10to type qit. And on the lefth hand side,
25:12you can see this will basically just add
25:14all stages to changing create a commit
25:17using the conventional commits format
25:18and then push to your remote branch.
25:21This does not create a pull request. So
25:23if I want to do that as a last step, I
25:25would just say create a pull request and
25:27it's following the format specified.
25:29Feet means feature add prompt selection
25:31dropdown. Now it's pushing to GitHub.
25:34Okay. And it's summarized the changes
25:35here. If you want to create a pull
25:37request, you can also just tell cloud
25:39code create a pull request. That's
25:41pretty much it. My entire process from
25:42start to finish, where I spend the most
25:44time pushing back on the plan,
25:46questioning what it's done after it
25:48produces its first draft of code, really
25:50questioning things that look sloppy.
25:52Even when you run these best practices
25:54checklist, it's still not going to be
25:56perfect. There's still going to be
25:57sloppy pieces of code, unnecessary
25:59pieces of code. And if code quality is
26:01important to you, as it probably should
26:03be, if you have like a bunch of users in
26:05a complex codebase, then you are
26:07definitely going to want to stay on top
26:09of each change that it's making. But
26:11overall, this process is much better
26:14than not having any rules or best
26:16practices in place. So, I found this AI
26:18coding rules file to significantly save
26:21me a lot of time. It's ordered in such a
26:23way that makes it easy for me to follow,
26:25right? like start a new session, plan it
26:27out, make sure it's similar to other
26:29parts of the codebase and reusing
26:30existing code, implement the plan using
26:33test-driven development, check the
26:34quality of your code with these
26:36checklists, output a list of things that
26:38I need to test as the human UX tester,
26:40then commit and push to GitHub. I
26:42guarantee that if you follow the
26:43step-by-step process, your AI coding
26:45experience will be better. Again, you
26:48still need to be the senior engineer
26:50telling Claude like, "Don't go down this
26:52rabbit hole driving everything and
26:54architecting it, especially if you have
26:56an existing complex codebase." But these
26:58tips will definitely ensure that you are
26:59much more productive AI coding tools. If
27:01you like this video, hit like, hit
27:03subscribe, and drop a comment below.
27:05would love to hear from you.

About this transcript

This page contains the full transcript of 7 Months of Claude Code Lessons in 19 Minutes by Sabrina Ramonov 🍄, generated from the public captions YouTube serves with the video. The transcript has 5,390 words across 774 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 translate the transcript into 100+ languages.

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, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.