[00:00] (0.16s)
Cursor has become incredibly popular for
[00:02] (2.40s)
its AI agent, which lets you use
[00:04] (4.48s)
powerful models to write code. The agent
[00:06] (6.80s)
takes your prompt, understands the
[00:08] (8.48s)
context, and starts building by creating
[00:10] (10.64s)
files and implementing features
[00:12] (12.40s)
automatically. However, with that much
[00:14] (14.40s)
autogenerated code, errors are
[00:16] (16.24s)
inevitable. Cursor often throws random
[00:18] (18.40s)
errors, and you either have to prompt it
[00:20] (20.08s)
again or wait for it to recover and fix
[00:22] (22.08s)
them. Now, imagine if after each segment
[00:24] (24.16s)
of code it generates, you could run a
[00:26] (26.16s)
review that checks for issues such as
[00:28] (28.08s)
security leaks or flawed integrations.
[00:30] (30.56s)
This is especially important because AI
[00:32] (32.72s)
agents often leave major vulnerabilities
[00:35] (35.04s)
behind and catching them early is
[00:36] (36.96s)
absolutely critical. That is exactly
[00:39] (39.12s)
where Code Rabbit comes in. Code Rabbit
[00:41] (41.20s)
was originally built to review pull
[00:42] (42.88s)
requests and GitHub commits by offering
[00:45] (45.28s)
suggestions based on what you pushed.
[00:47] (47.28s)
But now they have launched a powerful
[00:48] (48.96s)
extension for VS Code, Cursor, and
[00:51] (51.20s)
Windsurf. You simply plug it in and
[00:53] (53.20s)
after every implementation step from
[00:55] (55.04s)
cursor you run the extension. It
[00:56] (56.96s)
analyzes the changes, identifies
[00:59] (59.04s)
important refactors, highlights security
[01:01] (61.20s)
concerns and suggests improvements. Then
[01:03] (63.44s)
you feed those suggestions back to the
[01:05] (65.28s)
agent and it handles the fixes. This
[01:07] (67.36s)
significantly tightens up your workflow,
[01:09] (69.60s)
improves your application security and
[01:11] (71.84s)
helps you reach a stable final product
[01:13] (73.92s)
with fewer bugs. Stick around because I
[01:16] (76.24s)
am going to walk you through how I use
[01:18] (78.00s)
Code Rabbit in my own workflow, starting
[01:20] (80.32s)
from an implementation plan, breaking it
[01:22] (82.40s)
into manageable chunks, reviewing after
[01:24] (84.56s)
each one and repeating the process to
[01:26] (86.64s)
build better and build faster.
[01:28] (88.56s)
Installation is simple. In cursor, open
[01:30] (90.88s)
your side panel and then go to
[01:32] (92.64s)
extensions. Search for Code Rabbit.
[01:35] (95.04s)
Locate the extension and install it.
[01:37] (97.36s)
When you launch it, you will be prompted
[01:39] (99.28s)
to sign in. Click to sign in. Complete
[01:41] (101.44s)
the GitHub authentication in your
[01:43] (103.12s)
browser and you are all set. The entire
[01:45] (105.44s)
process is straightforward and has no
[01:47] (107.56s)
complications. Okay, so just to show you
[01:49] (109.68s)
a live demo of how this actually works.
[01:51] (111.92s)
I am currently building an e-commerce
[01:53] (113.92s)
store, a full e-commerce store with the
[01:56] (116.16s)
admin panel and everything included. I
[01:58] (118.24s)
am not exactly sure how much of it I
[02:00] (120.24s)
have built in this video, but you will
[02:02] (122.00s)
get a pretty clear idea of the workflow
[02:04] (124.24s)
we are trying to achieve with this tool
[02:06] (126.40s)
and how it is going to assist us
[02:08] (128.16s)
throughout the process. Now what
[02:09] (129.76s)
actually happens with this tool is that
[02:11] (131.28s)
it reads the changes you have made
[02:12] (132.96s)
through GitHub. So first of all you need
[02:14] (134.88s)
to initialize git in the directory you
[02:17] (137.20s)
are working in. As you commit those
[02:18] (138.88s)
changes which means saving them.
[02:20] (140.72s)
Whenever you save anything code rabbit
[02:22] (142.72s)
will step in and say that it has
[02:24] (144.40s)
detected changes and ask if you want
[02:26] (146.48s)
those to be reviewed. You simply click
[02:28] (148.24s)
on yes and it will begin reviewing them
[02:30] (150.40s)
and providing suggestions. If you want
[02:32] (152.72s)
you can copy those suggestions back into
[02:34] (154.80s)
cursor and both tools continue working
[02:37] (157.12s)
together seamlessly. This is essentially
[02:39] (159.28s)
what the entire workflow is evolving
[02:41] (161.36s)
towards. You can see right here that
[02:43] (163.20s)
these are the changes I have made that
[02:45] (165.04s)
have not yet been committed. But before
[02:46] (166.80s)
we go into that, let me show you how to
[02:48] (168.72s)
initialize this setup. So first of all,
[02:50] (170.88s)
in a new directory, for instance, the
[02:52] (172.80s)
project directory where you have not
[02:54] (174.48s)
started anything yet. You simply type
[02:56] (176.48s)
git in it. This initializes the git
[02:58] (178.72s)
repository. After that, you add your
[03:00] (180.80s)
changes using the git add command and
[03:02] (182.88s)
the dot signifies that you are adding
[03:04] (184.72s)
the entire repository. Once that is
[03:06] (186.88s)
done, you use git commit and make sure
[03:09] (189.04s)
to include a message with the commit
[03:10] (190.96s)
describing what it is about. This is the
[03:13] (193.12s)
standard format. You do not need to
[03:14] (194.80s)
worry because there are also ways to
[03:16] (196.48s)
automate this which I will be showing
[03:18] (198.08s)
you. But it is important that you go
[03:19] (199.76s)
through these initial steps. For
[03:21] (201.44s)
example, you can simply write a message
[03:23] (203.28s)
like initial commit and this will commit
[03:25] (205.36s)
everything in the repository. Once you
[03:27] (207.12s)
do this, code rabbit will activate and
[03:29] (209.20s)
do its part. Every time you make a
[03:31] (211.04s)
change, you will need to use git add
[03:33] (213.04s)
followed by git commit. And this process
[03:35] (215.20s)
will save the changes. Each saved change
[03:37] (217.28s)
will be detected by code rabbit. It will
[03:39] (219.20s)
run a review and you can then pass those
[03:41] (221.20s)
results over to cursor to continue your
[03:43] (223.44s)
development process smoothly. So while
[03:45] (225.92s)
testing it out, I did encounter a big
[03:48] (228.00s)
issue. I spent a lot of time trying to
[03:49] (229.92s)
fix it and in the end I went into their
[03:52] (232.08s)
discord server. Someone had actually
[03:53] (233.84s)
posted a solution there because many
[03:55] (235.76s)
people were facing the same issue and it
[03:57] (237.68s)
seems that this is currently a known
[03:59] (239.36s)
bug. Apparently, you are supposed to
[04:00] (240.96s)
have your branch visible right here
[04:02] (242.64s)
where all your branches are listed. Once
[04:04] (244.48s)
that is done, you can commit locally and
[04:06] (246.56s)
continue working as needed. The tool
[04:08] (248.32s)
will focus on the selected branch and
[04:10] (250.40s)
every time you commit to that branch, it
[04:12] (252.16s)
will be able to review those changes.
[04:14] (254.16s)
This is the solution I ended up using.
[04:16] (256.16s)
You go to this area and you will see the
[04:18] (258.08s)
top menu appear. You simply select the
[04:20] (260.24s)
option to create a new branch. Since I
[04:22] (262.32s)
have already made a lot of progress, I
[04:24] (264.00s)
want to create a copy of the main
[04:25] (265.44s)
branch. So I create a new one and name
[04:27] (267.36s)
it the test branch. Now you can see that
[04:29] (269.36s)
the menu appears and any changes I make
[04:31] (271.84s)
will be shown right here. For example,
[04:33] (273.68s)
in this file, I just add a comment that
[04:36] (276.00s)
says this is a test. I add the comment
[04:38] (278.24s)
and save the file. Next, I open the
[04:40] (280.48s)
terminal and I am going to add this file
[04:42] (282.64s)
to the branch and commit it with the
[04:44] (284.48s)
message test. That is done. We now have
[04:46] (286.64s)
a commit message labeled test and we
[04:48] (288.72s)
want to test how this behaves. So we
[04:50] (290.88s)
proceed and now you can see that the
[04:52] (292.56s)
review has started. This is the file we
[04:54] (294.64s)
committed. The review has been completed
[04:56] (296.56s)
and I believe it has generated a few
[04:58] (298.56s)
comments. Yes, it added a comment that
[05:00] (300.48s)
says remove stray test comment. It
[05:02] (302.72s)
recognizes that this is just a test
[05:04] (304.48s)
comment and not something important. I
[05:06] (306.56s)
just wanted to walk you through this fix
[05:08] (308.32s)
so you can understand it clearly. Now
[05:10] (310.08s)
let us go back to the project and I will
[05:12] (312.08s)
show you how the rest of the workflow
[05:13] (313.76s)
plays out. Okay. So I just implemented
[05:16] (316.08s)
several other features from my
[05:17] (317.60s)
implementation plan. First of all, let
[05:19] (319.60s)
me try to open the project to see if it
[05:21] (321.60s)
actually runs properly. You can see that
[05:23] (323.60s)
there are some errors. And now I want to
[05:25] (325.52s)
check whether the tool can actually
[05:27] (327.36s)
detect and address these errors during
[05:29] (329.52s)
its review process. I believe this part
[05:31] (331.60s)
of the work falls under phase 4 of the
[05:33] (333.84s)
implementation plan. We can now see the
[05:36] (336.00s)
recent changes that were made. So let us
[05:37] (337.92s)
proceed with the review. You can observe
[05:39] (339.60s)
that I am now setting everything up,
[05:41] (341.36s)
analyzing all the changes and reviewing
[05:43] (343.52s)
the modified files. The files that were
[05:45] (345.76s)
changed are listed here at the bottom.
[05:47] (347.60s)
Let us take a look at what it finds and
[05:49] (349.68s)
whether its review can help resolve the
[05:51] (351.84s)
existing errors. We are now ready to run
[05:53] (353.92s)
the review. You can now see the list of
[05:56] (356.00s)
files that were reviewed. When we open
[05:57] (357.92s)
any of these, we can see that it has
[05:59] (359.84s)
provided suggestions for each one.
[06:01] (361.76s)
Clicking on a suggestion opens it in
[06:03] (363.68s)
detail and shows us exactly what the
[06:05] (365.68s)
tool recommends. The next step in this
[06:07] (367.76s)
workflow is to hand these suggestions
[06:09] (369.84s)
over to the cursor AI agent. If you're
[06:12] (372.16s)
enjoying the video, I'd really
[06:13] (373.68s)
appreciate it if you could subscribe to
[06:15] (375.52s)
the channel. We're aiming to reach
[06:17] (377.20s)
25,000 subscribers by the end of this
[06:19] (379.60s)
month, and your support genuinely helps.
[06:21] (381.68s)
We share videos like this three times a
[06:23] (383.76s)
week, so there is always something new
[06:25] (385.60s)
and useful for you to explore. Now, the
[06:27] (387.92s)
next step to getting those comments
[06:29] (389.44s)
applied is that after you have opened
[06:31] (391.28s)
them up, you are going to click on the
[06:32] (392.80s)
fix with AI button. What this does is
[06:34] (394.96s)
copy a set of instructions, and if you
[06:36] (396.88s)
look at the bottom, you will see them
[06:38] (398.40s)
labeled as code gen instructions, which
[06:40] (400.64s)
are then copied to your clipboard. After
[06:42] (402.72s)
that, you simply paste those
[06:44] (404.08s)
instructions into the cursor agent. The
[06:46] (406.08s)
tedious part of this process is that you
[06:48] (408.24s)
have to do it one by one for each
[06:50] (410.08s)
individual comment. You need to provide
[06:52] (412.00s)
each comment separately. And as you
[06:53] (413.84s)
already know, these AI models generally
[06:56] (416.08s)
do not perform well when they are asked
[06:57] (417.84s)
to handle multiple tasks at the same
[06:59] (419.92s)
time. One thing I highly recommend is
[07:01] (421.76s)
switching to the Gemini 2.5 Pro model
[07:04] (424.40s)
because in my experience, that is the
[07:06] (426.08s)
only model that can reliably handle
[07:07] (427.92s)
multiple instructions at once. This
[07:09] (429.84s)
allows you to go ahead and give it as
[07:11] (431.60s)
many comments as you like. I have now
[07:13] (433.36s)
given it three comments from the address
[07:15] (435.20s)
form. And at this point, I am just going
[07:17] (437.36s)
to paste the codegen instructions into
[07:19] (439.44s)
cursor and see what it generates and how
[07:21] (441.84s)
it fixes the issues. Okay, so this is
[07:24] (444.32s)
the store that was finally built. There
[07:26] (446.08s)
was an issue with components not
[07:27] (447.76s)
rendering properly on the client side,
[07:29] (449.68s)
but that has been resolved. The review
[07:31] (451.36s)
process also played a key role in
[07:33] (453.20s)
tightening up the site's security,
[07:34] (454.88s)
especially in the area of password
[07:36] (456.64s)
storage, which was being handled
[07:38] (458.08s)
incorrectly earlier. Overall, the site
[07:40] (460.24s)
is now fully functional. All the
[07:41] (461.92s)
animations are working exactly as
[07:43] (463.76s)
expected. One thing I do regret is not
[07:46] (466.08s)
using Shaden components. I had
[07:48] (468.08s)
instructed the agent to manually create
[07:50] (470.08s)
all the components, which in hindsight
[07:52] (472.08s)
was not the best decision. That aside,
[07:54] (474.16s)
everything looks good and is functioning
[07:55] (475.76s)
well. There are still a few features
[07:57] (477.36s)
left to implement. As I mentioned
[07:59] (479.04s)
earlier, I am currently at phase four of
[08:01] (481.36s)
the implementation plan. So, the final
[08:03] (483.36s)
styling and polish will likely be
[08:05] (485.12s)
completed in the upcoming phases. So, at
[08:07] (487.68s)
the start of the video, I mentioned that
[08:09] (489.52s)
I would show you how to apply my
[08:11] (491.28s)
implementation plan approach to your own
[08:13] (493.36s)
projects by breaking them into small and
[08:15] (495.52s)
manageable chunks. This is exactly what
[08:17] (497.52s)
I meant. You begin by briefly describing
[08:19] (499.52s)
your project and defining its
[08:21] (501.16s)
specifications. In my case, I was
[08:23] (503.20s)
building a Nex.js JS front-end
[08:24] (504.80s)
application that would eventually be
[08:26] (506.48s)
integrated with a fast API backend. Your
[08:29] (509.12s)
project might be different, but the core
[08:30] (510.96s)
idea remains the same. You describe what
[08:33] (513.28s)
you are building and which text stack
[08:35] (515.12s)
you are using. Since I was focused on
[08:37] (517.04s)
building just the nextJS front end, I
[08:39] (519.36s)
instructed the agent to list all the
[08:41] (521.28s)
required pages and modules inside a
[08:43] (523.88s)
structure.md file that I had already
[08:46] (526.16s)
prepared. After that, I asked it to
[08:48] (528.32s)
generate a 10-phase implementation plan
[08:50] (530.80s)
based on that structure. To make the
[08:52] (532.56s)
workflow more autonomous and avoid
[08:54] (534.64s)
repeating instructions every time, you
[08:56] (536.72s)
add a rule inside your project's cursor
[08:59] (539.04s)
settings and configure it to always keep
[09:01] (541.20s)
the agent attached. From there, the
[09:03] (543.04s)
agent follows the implementation plan
[09:05] (545.04s)
step by step. If it needs any
[09:06] (546.64s)
clarification, it is expected to ask
[09:08] (548.88s)
before proceeding. Once a phase begins,
[09:10] (550.88s)
it marks that phase as in progress,
[09:13] (553.04s)
completes the implementation, and then
[09:14] (554.96s)
commits the changes to git locally. At
[09:17] (557.20s)
that point, you receive a prompt from
[09:19] (559.04s)
code rabbit indicating that it is time
[09:21] (561.04s)
to start the review process. You run the
[09:23] (563.28s)
review, collect the suggestions, and
[09:25] (565.28s)
paste those suggestions back as
[09:26] (566.96s)
feedback. These suggestions now act as
[09:29] (569.20s)
the user's input. After that, you
[09:31] (571.28s)
instruct cursor to continue, and it
[09:33] (573.20s)
returns to the implementation plan,
[09:35] (575.12s)
marks the current phase as complete, and
[09:37] (577.28s)
proceeds to the next one. This creates a
[09:39] (579.44s)
smooth and structured workflow that
[09:41] (581.04s)
progresses phase by phase with
[09:42] (582.72s)
integrated review cycles at every step.
[09:44] (584.88s)
One improvement that could really
[09:46] (586.24s)
enhance this process in my opinion is
[09:48] (588.24s)
better retrieval of the review comments.
[09:50] (590.24s)
At the moment, there is a comments tab
[09:52] (592.08s)
that displays everything, but if there
[09:54] (594.00s)
were a way to automatically extract and
[09:56] (596.24s)
paste those comments directly into
[09:58] (598.16s)
cursor, the entire process would become
[10:00] (600.48s)
much more efficient. That brings us to
[10:02] (602.48s)
the end of this video. If you'd like to
[10:04] (604.16s)
support the channel and help us keep
[10:05] (605.84s)
making tutorials like this, you can do
[10:07] (607.76s)
so by using the super thanks button
[10:09] (609.60s)
below. As always, thank you for watching
[10:11] (611.68s)
and I'll see you in the next one.