YT prompt 001

<Úloha>
Si skúsený obsahový analytik a redaktor špecializujúci sa na tvorbu komplexných, no zrozumiteľných zhrnutí pre širokú škálu videí - od technologických a vedeckých až po recenzie produktov a populárno-náučné. Tvoja analýza sa vždy snaží zachytiť podstatu témy, kriticky ju zhodnotiť a zasadiť do širšieho kontextu. Vďaka excelentnému ovládaniu spisovnej slovenčiny a schopnosti prispôsobiť jazyk a hĺbku výkladu cieľovému publiku sú tvoje súhrny známe svojou zrozumiteľnosťou a prehľadnou štruktúrou.

# Hlavná inštrukcia
Pozorne analyzuj prepis videa a vytvor jeho štruktúrované zhrnutie v slovenčine, pričom prispôsob štýl a rozsah analýzy typu obsahu a cieľovému publiku.

## Štruktúra analýzy
Členiť analýzu do hlavných sekcií a označiť nadpismi:

### 1. Základné informácie a kontext
- Uveď dostupné základné údaje o videu: názov, autora, dátum publikovania, dĺžku, kategóriu/žáner.
- V 2-3 vetách načrtni kontext a hlavnú tému videa.
- Identifikuj cieľové publikum a očakávanú úroveň predznalostí.

### 2. Kľúčové myšlienky a posolstvá
- Vypichni 3-5 najdôležitejších myšlienok, tvrdení alebo záverov z videa.
- Ku každej stručne vysvetli, prečo je významná a ako zapadá do celkovej témy.
- Ak treba, podopri krátkymi citáciami alebo parafázami z prepisu (prelož do slovenčiny, anglické termíny ponechaj ak sú zaužívané).

### 3. Detailnejší rozbor obsahu
Pre každú hlavnú myšlienku:
- Rozober nejdôležítejšie súvislosti, dôsledky a implikácie.
- Zasaď do kontextu ostatných častí videa aj širšej témy.
- Ilustruj relevantnými detailami a príkladmi z videa.
- Ak video obsahuje kľúčové vizuály (grafy, schémy, ukážky), v krátkosti ich opíš a vysvetli ich význam.

Miera detailov nech zodpovedá typu obsahu - pri technických/vedeckých videách zachádzaj viac do hĺbky, kým pri populárno-náučných sa sústreď na jasnosť a názornosť.

### 4. Zhrnutie hlavných poznatkov
- V 2-4 odsekoch zrekapituluj najdôležitejšie myšlienky a posolstvá.
- Zvýrazni praktické aplikácie a dopady prezentovaných informácií.
- Poukáž na prieniky a súvislosti s inými témami či trendami.

### 5. Kritické zhodnotenie a odporúčania
- Neprikrášľuj, ale ak spozuruješ faktické chyby, nezrovnalosti alebo slabšie miesta argumentácie, taktne na ne upozorni.
- Ak video vyvoláva ďalšie otázky alebo otvára priestor na diskusiu, načrtni možné smery.
- Prípadne navrhni, ako by sa dalo video obsahovo alebo spracovaním ešte vylepšiť.

## Formálne náležitosti
- Štruktúruj text do prehľadných odsekov a sekcií s výstižnými podnadpismi.
- Používaj spisovnú slovenčinu s citom pre terminológiu, ale zrozumiteľnosť nech má prednosť pred odbornosťou.
- Rozsah prispôsob informačnej hustote a komplexnosti obsahu - populárno-náučné videá zhŕňaj stručnejšie, odborné témy môžeš rozobrať detailnejšie.
- Ak vhodne dopĺňa tok textu, použi číslované a odrážkové zoznamy.
- Na záver skontroluj:
  1. Pokrýva analýza všetky kľúčové prvky obsahu?
  2. Sleduje text jasnú logiku a plynule na seba nadväzuje?
  3. Je jazyk zrozumiteľný pre cieľové publikum?
  4. Sú hlavné tvrdenia a závery riadne podložené obsahom videa?
  5. Pôsobí formátovanie konzistentne a zvyšuje prehľadnosť?

# Prepis videa
<ContentTitle> [Vibe Coding Tutorial and Best Practices (Cursor / Windsurf)] </ContentTitle>

<Transcript> [I've been vibe coding like crazy lately, which basically just means using an AI agent to do
my coding for me. Very little actual writing of code. In fact, basically none. And I'm going
to tell you all of the things that I learned along the way to get the most out of it. Let's
get right into it. All right. So quickly, what I'm talking about with vibe coding or really
agentic coding, whatever you want to call it, is you're using this agent based coding in cursor
or windsurf. And you can see it right here. So there's agent, ask and edit. This is not
your starting to code something. You hit tab and it finishes that piece of code for you.
This is, I am literally trying to get AI to write the entire application end to end. And so it's a
little bit more difficult to do. And there are definitely some limitations. Now, first, what is
my setup? Either cursor or windsurf. And I have almost exclusively been using Claude 3.7 models,
mostly focused on the thinking version. So I'm using Claude 3.7 Sonnet thinking right here.
Now in cursor and windsurf, you can set up really any model that you want. To do that,
you go up to cursor settings. And here it comes with a predefined list of models that you can
choose from, all provided by cursor directly or windsurf. And then you can also add models down
here. The way that you add custom models is essentially, and it's not super clean, is by
overtaking this OpenAI API key here. So you turn it on, you add your key and you can override the
base URL. You can only do that once, which means you can only really have one non-OpenAI API service,
but that's okay. So here I use Grok and I put my Grok key here. Grok is formatted using the OpenAI
API standard. So it just works. Now, whatever model you choose, if you're using it with the agent
feature, you want to make sure that it really supports agentic behavior and function calling
and tool calling really well. Most models don't. Claude 3.7 thinking does. So what I would recommend
doing first is getting a very specific spec written. That just means a very detailed explanation of
what you want built. And so I'm actually using Grok 3 for that. Write a spec for an application
that will be a Twitter clone, be as specific as possible. We're going to be using Python for the
backend. So I'll just hit enter and I work with AI separately to help me write that spec. And here
you can see it writes out all of the not only technical specification, but also how it operates,
how it works, et cetera. And here you can even see it's writing out the database schema. So this is
really complete. Here are the API endpoints. And so once it's done, you basically take all of that
and you paste it into cursor. I'll show you what that looks like. So we have a brand new cursor
window. You're going to come up to the top right and click this toggle AI pane. Here it's going to
open up the chat window. If you have a recent version of cursor, the agent will be the default.
I have Claude 3.7 sonnet thinking as my model. And here's the important part. We're going to paste
our spec in. But before doing that, one of the thing I learned, and this is especially important
as the code base gets larger, is to use rules. Cursor rules are windsurf rules. Both of the IDEs
support rules. And the rules are basically a way to tell AI to tell the agent how you want to code,
what technologies you should use, what workflows you want to use. And this was a huge discovery
for me because frequently I would try to build something and it would build it using some
technology that wasn't already in my stack and it would break other things. If there was a bug and
I was trying to fix the bug, it would try to use a different technology. A good example is I wanted
to use a SQL database for everything. But every time I ran into an issue with SQL database, the
agent would try to fix it by switching to JSON storage in a file. And it was just super annoying
because I would think it was working and then nothing would be appearing in the database and
so on and so forth. All right, so switching back to this is my actual project. I am going to show
you where the rules are. So in cursor settings, you go down to rules. And you can have user
specific rules, which are rules for any project, but I like adding it to project rules. You add a
new rule and it essentially creates this dot cursor folder and within that a rules folder.
All of these dot MDC files are the rules and you can reference them kind of like a system message
for the AI to work with. Thanks to the sponsor of this segment, Mammoth. Access the best generative
AI for just $10 per month. This includes the best LLMs like Claude, DeepSeek, GPT-4.0, Lama models,
Mistral, Gemini, Grok, and reasoning models like DeepSeek R1 and 03mini. And for that same price,
it also includes the best image generation models, Mid Journey, Flux Pro, Recraft, Dolly,
Stable Diffusion, all in one place. And you can create custom Mammoths to help you on your projects.
These are kind of like agents and you give them all your custom context and they will know
what you need them to do. You can install it on any device, Apple, Android, Windows,
Linux. You can do one click reprompting and so much more. So definitely check out Mammoth.
They've been a great partner to this channel. Tell them I sent you links down below. Now back
to the video. So let me show you my coding preferences. This is how it's formatted,
all natural language. Description, you can auto attach different files, but I didn't use that.
Coding pattern preferences. Now let me go through each of these and tell you why I added them because
hopefully it's going to save you a lot of time by just understanding why these things are necessary,
which kind of reflects some of the tendencies that these AI coding agents have that don't really
work all that well. So always prefer simple solutions that speaks for itself. Avoid duplication
of code whenever possible, which means checking for other areas of the code base
that might already have similar code and functionality. What I found is that when
adding new functionality or trying to fix old functionality, it would often duplicate code
thinking that that code did not already exist. So now I'm explicitly saying make sure you check
everywhere, make sure this code doesn't already exist. And if it does fix that rather than adding
new working code. Another thing that I struggled with is the AI agents didn't have a good sense
of the split between dev, test and prod environments. And this was a huge, huge learning for me.
I would make some change, write some tests for it. The tests would affect the dev environment.
The production environment would be trying to use local stuff and it was just a mess. So
now I say, okay, everything you do, you are going to take into account. We want separate dev,
test and prod environments. Here's another issue. You are careful to only make changes
that are requested or you are confident are well understood and related to the change being
requested. Another issue that I ran into is I would ask for a change and one little piece of
code, one little piece of functionality and like three other things would just break for no reason.
And it was just trying to touch other pieces of code. So I'm really emphasizing to make sure only
focus on the thing that I'm asking you to focus on. Again, next re-emphasizing, just focus on
what I'm asking you to focus on. Don't introduce new things. So when fixing an issue or bug,
do not introduce a new pattern or technology without first exhausting all options for the
existing implementation. And if you finally do this, make sure to remove the old implementation
afterwards so we don't have duplicate logic. Again, this is something I would find.
Something would be done one way. It would not work perfectly. I would say fix that. And rather than
fixing it, it would just rewrite it in a different way, completely thinking it was new code. So
hopefully that fixes it. So keep the code base very clean and organized. I would oftentimes
find disorganization in the code. Avoid writing scripts and files if possible, especially if the
script is likely only to be run once. What I found again is that when the agent was testing
something, so let's say one of the API endpoints was broken or one of the pages was broken,
it would write a script to test it, which is fine. But then it would just leave the script in my
code base and I would have a bunch of different one-off scripts that would likely never be used
again. So I want them either to just write the script and execute it in line or when it's done
with the script, just delete the file. All right. Next, this is an obvious one. Avoid having files
over 200 to 300 lines of code. Refactor at that point. Now that's not usually a good hard and fast
rule to have, but for AI, I think it's appropriate. I would frequently find files that were just
absolutely massive. And then I would ask it to refactor it. And by the time I noticed it,
the refactoring would break all the tests and it would just take a long time. So just get ahead of
it. As soon as it looks like you're about to get over that line size, go ahead and refactor the code.
I also found that it would mock data like crazy stub and mock data, which basically just means
have kind of backup fake data, but that doesn't really work in dev or production environments.
So let's say I asked it to go scrape an article and for whatever reason the scraping failed,
it would catch the error and fall back to using mock data and think everything worked,
but it didn't work. That is not what I wanted the behavior to be. What I really wanted is it to
actually scrape the data properly. And so it would always use mock data. It was really frustrating.
So I explicitly said, do not use mock data for dev or prod only in test environments. And I kind
of doubled down and said it again, never add stubbing or fake data patterns to code that affects
the dev and prod environments. Next, I actually found it overriding my .env file. So I had to
frequently get new API keys. So I just said, don't do that. Now, another rule is my stack.
And I could probably even get more detailed with this, but this is just what is your technical
stack? Because again, I would find it using, for example, if the SQL didn't work, it would just
switch to using a JSON store in a file, which was not what I wanted. So I said Python for the back
end, HTML JS for the front end, SQL database, never JSON file storage, separate databases for
dev tests and prod. Again, just reemphasizing that elastic search for search using a hosted version
because I would talk about elastic search and it would think, okay, you want to do that locally.
Sometimes it would do it with a hosted version, but I only wanted it to be hosted and Python tests.
And I'm going to get to testing in a moment. Next, I had my coding workflow preferences,
a little bit of duplicative information here, but hopefully just kind of giving it more guidance. So
focus on areas of code relevant to the task. Do not touch code that is unrelated to the task.
Obviously, you could see I ran into a lot of issues with this. Write thorough tests for all
major functionality. I was doing this manually. I would just have it write some code for me and
then say, okay, now write tests for it. And sometimes I would forget. So now it should just
write tests for all major functionality. Avoid making major changes to patterns and architecture
of how a feature works after it has shown to work well, unless explicitly instructed, it should say
instructed. And so again, I would say, hey, fix this issue. And to fix it, it would basically throw
away the original pattern and rewrite it from scratch using some other pattern or some other
tech. And I didn't want that. I wanted it to just fix what I had already there. And always think
about what other methods and areas of code might be affected by code changes. So those are the
rules. You can add more and just give it as much instruction as you see fit, because this is going
to be really helpful as you go. So now we have that full spec back in grok. So what I would do
is obviously go through it, work with grok on it or whatever other AI you want to use, make sure it
is exactly what you want, make the appropriate changes, copy it all, paste it into here, and
you're good to go. So I'm not going to iterate on this. I'm just going to take it on one shot. I'm
going to highlight it all. I'm going to paste it right into the window and say, build this based
on this spec and let's see. So it's going to go. I'm not going to watch it. Let's just assume it's
going to go. I'll show you what it looks like in a moment, but let me just show you some more best
practices. Okay, so back to my existing code. One thing that you're going to notice and you should
get used to is this panel right here. This is all the context you're giving it. This is important
because at a certain point it becomes too much context and it starts not performing as well. So
you kind of have to be very aware of how much context you're giving it, how long the conversation
is before starting a new chat. And you can see right here in dark gray, start a new chat for
better results. Now this is something you're going to have to just figure out by playing with it. If
you start a new chat, you lose context. You can move some of the context over to a new chat window,
but that's annoying. You want to give it as much context as possible, but if you give it too much
context, it starts performing poorly. So make sure you're playing around with that. All right,
so I'm going to start a new chat. I'm going to click it one more time. So immediately,
the first thing it does is insert workflow preferences, but I want all of my rules in
there every time. So I'll click my stack and coding preferences. And so now it has the context of these
three rules. I don't actually know if it does it automatically, but it seems like I do have to
manually insert these three files, which you know, fine. My next suggestion is stay very narrow with
your requests from the agent, meaning fix little things, add little features, and test as much as
you can. Have it write tests. Now testing is an entire thing of its own. What I have found works
best is end-to-end testing. So testing where it's actually clicking through and attempting to do
what you as a user would be doing rather than unit tests, for example. And keep in mind,
every single time you write something, you're going to run the tests. And if the tests pass,
great. And if the tests don't pass, have it fix the tests. But the fixing of the test is interesting.
You have to keep a close eye on it because sometimes it'll fix tests in a way that affects
production the way you think it should work, where actually just addressing a failure of the test is
really the right way to go. So you kind of got to just keep an eye on it. You don't necessarily have
to code it yourself or manually adjust anything, but make sure the tests pass and then use the
integration tests to confirm or just simply go to the app yourself and test that functionality
yourself. And so if you look right here, we have tons of different tests, tests for everything.
Another recommendation, kind of jumping all over the place, but use a popular stack. Okay,
if you're using some nascent technology, AI is probably not going to do as well because it
doesn't have as much exposure to whatever that coding language is or that stack is,
and thus it's just not going to perform as well. So I would choose really common stacks. For me,
I like Python, HTML and JavaScript on the front end. Keep it very simple. SQL for the database,
Elasticsearch if I'm doing search, but choose very popular technology stacks,
and you'll just have a lot more documentation for AI to go research.
All right, let me show you an example chat, what it actually looks like. So this is an older feature
that I built. So enforce a maximum tag length of 20 characters. Make sure we don't already have
code for this, write tests for this after implementation. Obviously, I'm like reinforcing
over and over again how I want it to code. It can't hurt. Then you send and it starts. So first,
it thinks. Okay, and you can actually read the thought process, which is really nice. Then you
have tool calling. So where you see listed directory, listed directory, read files, search files,
it has a bunch of tools available to it. You can also use MCP servers. If you want to give it
external tools, that's a whole separate issue. I actually didn't use that at all in any of my code
yet, but I need to play around with that some more. So I'll get to that eventually, but that's for
another video. So you can see here, all this stuff happens. You can actually just click through and
really dig in and get a feel for how the agent operates with your code base. So here I'm going
to scroll down. So it grepped right there, read the file, read the file. And then it says based on
my analysis of the code base here is what I found. It tells me what it's going to do. And then it
starts. Now there are three settings for executing things. You can do completely manually, which means
every time it's actually going to make a change or execute something that might affect your files,
it'll ask you and you have to manually approve things every time. For me, I do YOLO mode and
it is literally called YOLO mode. That's the opposite. It just auto executes everything.
And it's risky for sure, because it'll push to GitHub. It'll deploy to production. So if you
actually have a production level code base and people are using it, I would not recommend that,
but for vibe coding something from scratch, go ahead. And then they also have kind of the in
between. I think it's called auto. And that just means it's going to make the determination of
which ones it does automatically and which commands it will ask you to approve. So it makes some
changes. You can see it's running these tests. All the tests pass. Out of all my tests, one test
failed. So we need to fix the failing tests. So it looks at why it failed and it starts changing
the code. And you can see here more mock repository stuff. I couldn't stand that. That really
frustrated me like crazy, which is why I mentioned like five different times, don't use any mock or
stub data at all in dev or production. So continued on all the tests pass. Great. Give me a summary at
the very end of all the things that changed. And then I just continued. But remember the more you
continue, the more the context window just becomes bloated and you want to just start a new chat as
frequently as it makes sense. I know that's not a very prescriptive rule, but you're going to have
to figure out what is best for you. So I really became pretty darn dependent on the agents to do
things for me. I would even say, okay, commit this code, write a good description and deploy it to
Heroku and it would do that. And it really didn't have any problems. The thing is all of this stuff
is pretty slow. Now I feel a little bit spoiled at this point because I'm saying this stuff is
slow, but it's writing more code than I could in a much shorter period of time. But every command
that I would send off, it would take between two and sometimes up to 15 minutes to finish the
iteration cycle. It would test things, try things, run the tests. The test failed, it would fix it.
It would verify things are working. And so it's a little bit slow in that sense. One potential
solution to that is to have different cursor windows open and just let it operate on different
branches and have kind of two branches going at the same time. And you can do that multiple times.
And so, yeah, you can have a lot of different branches that you're working on at the same time
and then merge them all together at the end. I occasionally switch back and forth between
Cloud 3.7 thinking and Cloud 3.7 regular non-thinking. Thinking tends to work best.
It's just a little bit slower. And then occasionally I would just say refactor the code.
I would give it some instructions like find the longest files and refactor that, but make sure
to do low risk refactoring. And I would explicitly tell it that. And so it would just make the code
a little bit cleaner, a little bit more organized without refactoring patterns for the most part,
which I didn't really care to do because that would just break too many things. Now I did reach
a point at which it was really difficult to make any changes. I would make a change and it would
just take so many iterations to get it right, so many iterations to fix a bug. And I think if I had
known all of this stuff beforehand, I would have been able to get a lot further. And I gotta say,
it does become pretty addicting. I'm sitting doing something else. I will come write a command,
build this feature and walk away and just let it work and come back 10 minutes later to see either
it worked or it didn't. I would iterate, walk away, come back. And so it's something you can
almost do asynchronously. Something where you're doing something else and you can just give it
command after command. Now one thing that I do wish I had was this available on my phone. Now
Replit has something like this, but I don't love its coding agent. It's just a little bit more
difficult to use. So I really wish that there was a fully hosted version that I can use on my phone
anywhere because coding, legitimate coding becomes much more feasible when you're using an agent like
this and just typing something out on your phone is super easy to do and you can watch it and you
can iterate on it. And it doesn't require a full screen, a keyboard and a mouse. So it's kind of
opening up an entire world of possibilities with mobile coding. So a couple of last suggestions,
commit often, commit often. I cannot suggest that enough. Make sure that every single change you
make you are committing because you can always roll back if it gets to a state that is just
unfixable. And another version of that is you can actually see the chat history. So you can roll back
to previous chats. So if I just click this one, so I added dark mode, I scroll to the very top and
I can just say restore checkpoint and it will roll the code back for me. So you not only have get to
do that, but you also have this built-in versioning through cursor or through windsurf itself.
So those are all of the best practices that I've learned over about 100 or 150 hours worth of
vibe coding, different applications, a game, and it's been a lot of fun. And I can't wait till these
tools get better. This is the worst that they will ever be. And so all of these problems you're
experiencing now or I'm experiencing now, they're only going to get easier to deal with in the future.
So enjoy, vibe code away. You really need to know very little about coding to build something
incredible. And I encourage you to build. If you enjoyed this video, please consider giving
a like and subscribe and I'll see you in the next one. ] </Transcript>

</Úloha>