Now that our project and repository are set up, it's time to choose the tool which we are going to use to perform a Gentic coding. The tool that I'm going to be using is Cloud Code with Opus 4.8. That being said, you are not required to use the same tool and model as me. If you prefer using OpenCode and their models, feel free to do so. Or if you prefer using Codex and GPT models, you can do that as well.
Of course, it is preferable to use Cloud Code with Opus 4.8 if available for you because that will give you the closest output to what I will be getting throughout this tutorial. If you ever do find yourself in a position that your AI is producing significantly different output from my AI, rest assured that this entire project is open source and every chapter that we are going to do after this one will have a corresponding branch in GitHub. So no matter where you find yourself, you will always have a way to point your AI to how the code is supposed to look like or you can just skip that entirely and just use the branch as a checkpoint so you immediately get that code in your codebase and then continue from that chapter onwards. So don't worry, I'm doing my best to mitigate or should I say improve the deterministic output of this tutorial even though we are going to be using agentic coding. As you can see from these three examples, you can run a lot of these tools inside of command line interfaces, but you are of course welcome to use any graphical user interfaces if you prefer them or desktop tools, equivalents of these apps.
For example, I personally prefer using Cloud Code for VS Code, which is a really cool extension which allows me to open Cloud Code, as I said, the tool which I will be using in a graphical user interface which looks like this. It's easier to read and it will be easier for you to follow along. So if you're using Cloud Code and Visual Studio Code, make sure to install this extension. It's pretty neat and it will help you a lot. So let's perform our first agentic coding task.
There is one problem in our code base. I have a file called agents.md. This is a pretty standard file, which a lot of coding tools use to get some necessary instructions on how to behave in this project. The problem is agents.md isn't always read by Cloud Code. So what people usually do is they copy and paste this and then they rename it to clod.md.
But that can be pretty tedious to do, especially if we plan on adding changes to these files which we actually do. So how about we create a symbolic link which basically references the agents.md inside a file named clod.md. There is technically a way of just doing agents.md, I saw that, but why don't we just do a real symbolic link? So I'm gonna go ahead and do the following. I'm going to open Cloud Code.
I'm going to switch to auto mode so I don't have to allow everything and I'm just going to tell it create a symbolic Claude.md file that references agents.md. So this will be our first prompt. If you've never done a symbolic link before or don't know how to do that, you can just ask AI to do that instead. There we go. So now Claude code is a symbolic link which references agents.md.
So if I click inside of Claude.md, you can see the exact same output inside. To test if the symbolic link actually works, I would recommend going inside of agents.md and do something like test123 and save this file. Then let's go inside of clod.md and if it is correctly set up, you should see that content immediately available here in clod.md as well. And if you remove it from here, I think it should work vice versa. There we go.
So you can see that whatever I type in one file is immediately available in the other file. So with this very simple prompt, we have now created a symbolic link between these two instructions so regardless if you're using OpenCode, Codex, CloudCode or maybe switching between all three at the same time, you will rest assured that all of your prompts will get the exact same project instructions. And these ones are pretty important for example. So what we have in our CloudMD and AgentsMD is the instruction which is now built in in every new Next.js app. This is not Next.js you know.
It's basically instructing the AI to tell it to ignore its training data and instead to use the node modules inside of here. So it's telling the AI, hey, if you are ever wondering about how to do something with Next.js, don't try to use your training data, but instead go inside of here and find Next.js and find the documentation wherever they have added it, right? And then it can read the up-to-date data about this project that we are in. So that's the kind of stuff that we are going to be adding here. Now let's do our first code change which actually alters the project.
So make sure you do npm run dev and make sure the project is running on the localhost 3000. And what I'm going to do now is the following. I'm going to start a new conversation and I'm going to tell it, set up Sonar, which is a component which we've added through Shazzy and UI in layout because Sonar is basically a toast component which first needs to be added to the layout file and alter the existing page.tsx so that when we click on the button we use Toast API. I'm using auto mode so I don't have to approve anything manually so you can just click here and then add that. As you can see it immediately recognized what it has to do.
So I'm just going to let it finish and then we're going to look through the code changes. This shouldn't be a big change so that's why I'm doing it this way because we can just take a look at the git diff and then we are going to see if it did it correctly or not. There we go. So it's finished. So I have a couple of files changed here.
Layout.tsx is the first one. So what was done here is that we have a brand new import toaster from Components UI Sonar and it was rendered right beneath the team provider. So here's what I would actually do first. It's made a mistake and the mistake is that the toaster should be inside of the team provider, right? I think this will still work.
Let's take a look at the page.tsx. So we have toast here, it's changed this to use client, perfect. And this button now has an onclick which basically calls the toast button clicked. So if I click this, there we go, button clicked. And looks like even though it didn't, wasn't added in the theme provider in the layout, it still works.
That's interesting. So it looks like the theme provider doesn't need to encapsulate the toaster. So I'm just gonna go ahead and ask AI whether this is required or not. I see the toaster component wasn't added within the theme provider. Is that necessary?
I can see that regardless of this, the theme switching still works on the toast component. Is it because we are using CSS class name for theme change? So let's get an answer for this, right? Why is this working? This is what you can use AI for.
Whenever you don't understand something, go ahead and ask it a question and then we're going to see the answer. So this is how I intend to use AI in this tutorial. Not as a vibe coding, but as a gentic coding to speed up what we would usually do by hand. So you will see that the curriculum for this project is very similar to all other projects that I have, meaning that we are not just going to randomly prompt finish the whole app for me and do some weird loop and let it do its work autonomously. No, we are staying in control.
You can see that I'm not satisfied with the way it rendered my toast component so I'm asking it is this the correct way to do so. So let's see what it answered. Write on both accounts. The reason it works is because attribute class is what actually changes on the HTML tag. So what is it talking about?
We have this component called theme provider which was built in and you can see that the attribute for next themes provider was set to class, meaning that whenever the theme changes we don't programmatically change it using some API we change the whole CSS attribute I mean we add a CSS attribute to the HTML tag so that's why it worked but I still think that it makes sense to render the toaster inside of here. So yes, it's not necessary, but it is semantic so the useThemeValue if ever used within Sonar gets the real value inside. And this is how it should look at the end, so let me close this. In the layout.tsx the toaster component should be rendered within the theme provider after the children and the page.tsx doesn't need any changes. Let's confirm one more time that this works.
There we go. So nothing has changed because it uses the class attribute to change the theme, but now it is semantically correct and if we ever want to access the API within the Toaster component, it will have the correct theme status. Brilliant! So you just performed your very first agentic coding task. Let's go ahead and commit these changes.
Git add, git commit, git push. Brilliant! Amazing job and see you in the next chapter.