Today, you and I are gonna build a real feature using Cloud Code instead of all these proof of concepts and fake demos that you see all around YouTube.
I'm gonna add a new feature to my AI engineering tutor app, and this feature is gonna be about the conversation history. Because if you type a question right now, like, what is AI engineering?
It's saved in a database for thirty days for abuse purposes,
but, otherwise, it's automatically deleted.
But some people like to actually have a chat history like you have in ChatGPT here on the left. But right now, I have not implemented this feature properly, so let's go ahead and see how we can implement it together with Cloud Code.
So this is the repository, and we've got the front end and back end application of their repository running already.
I'm gonna go and open up a new terminal here because then we're going to start our Cloud Code session, and I can do that by just typing Claude. There we go. Now this is actually a completely new Claude session. I don't have a Cloud Markdown file or any special instructions.
What I suggest you to do always with the iCoding is to not just jump into the ask of creating this conversation history feature, but first, the AI agent actually get a better sense of how your repository works. So what I'm going to do is I'm going to ask it to create a CLODE
in the file
to describe
the structure
of the front end and back end of this
project,
specifically
detailing how
conversations
are are not stored
at the moment.
The end goal
is going to be that we will
implement a new feature
to show and save conversations
permanently.
But for now,
you learning
the repository
is the most
important
focus.
And by doing this, you're really treating cloud as, for example, a junior engineer,
because a junior engineer, when they join a new team, really just needs to learn how the repository works first before they can add and build new features. So at this moment, you see that it's going to go ahead and search through all of my different files. And this project actually has a couple of folders, so I'll kind of collapse them right now.
You've got a back end folder,
a cron service folder, a embedding service folder, and a front end folder. There's some other folders here and there, but those are the actual services that this application relies on. But for this feature, we only have to edit the back end and the front end because these other folders are basically for ingesting my YouTube videos so that the AI system that this application uses
is actually using all of my content to answer questions properly.
What you can see now is that cloud is really investigating all of these different
files in order to find all the references to how conversations are actually saved at the moment. And you can see that it's starting to create that cloud dot markdown file with the detailed project structure documentation.
Oh, so it actually happened to be done right there. You And can see that it described the architecture with our FastAPI back end, the key components,
authentication,
API endpoints. This is important because you can indeed see that we already have an endpoint to retrieve
a conversation document. So we have sort of a partial implementation already, and it knows how the front end is built with React plus Vite,
which is very good. And then it's got a nice overview of all of these different services that go along with it as well as the data structure for the conversation history. It's very impressive that it was able to capture all of this in just one minute of time, so that's very good. And you can indeed see what the conversation flow looks like in this application again.
So that is very cool. Now in a terminal, it asks me, do you want to make this edit to Cloudmarkdown?
Yes. And I think we'll just gonna say yes and don't ask again so we can make those changes and not have to ask every single time.
Alright. So it's updating its seduce, and it should tell me that it's ready for new inputs. Yep. There we go. So what I wanted to do now is create a requirements pack for this new conversation history feature, and I'm going to kinda describe what I described to you to Claude so that it's aware of how it's currently being implemented
and how we want the final implementation to look like.
Create a
product requirements
markdown
for the new
conversation
history
feature.
Right now, convos are saved
for
thirty days for abuse detection,
but not visible in the user's
UI.
By toggling
the existing
but disabled
history button,
users should be able to
save their
Convos
permanently
and retrieve
them like in other
AI UIs.
Note that we need
to be GDPR compliant,
so it's good if there is a privacy.
I suppose
we can probably call this a privacy
consent form
that the user needs to agree with.
For now, work out the
requirements.
Doc, and don't
code yet.
So here too, I'm not asking you to code yet. So even though this tool is called Cloud Code, I'm not asking you to code yet. I first wanted to create a proper requirements
document
so that from there, it can actually keep track of what it has and has not implemented.
And even if we quit the session and come back tomorrow, we can actually just continue from where we left off. So that's why you want to have those product requirement documents.
So I'm gonna go ahead and make some tea, and then I'll be right back with you when it's done. So, actually, Claude is still thinking about this, but I really wanted to share some progress already with you because some of what I'm seeing here is super impressive and shows you why so many people love Cloud Code. So first of all, if we have a look at what it's already doing, it's researched the entire conversation history UI components which already exist together with how the conversations are being stored. But what I really like is that regarding this GDPR compliance requirement, it actually does a web search to figure out if there are some existing examples for this. Now things like GDPR and being compliant with other things like ISO
are really aspects that you need to verify as a human. You can't rely on AI tools to do everything for you, but by doing a web search here, it's going to at least get 90% of the way there, and I think that is already really great and saves me a lot of headache. So I will have to verify it, but it's a really great start. Oh, and look at that. We actually have a very nice product requirements document.
And in this product requirements document, there are a lot of aspects of the solution like the success metrics,
which I like to see apart from just the functional requirements,
like how we can see here that one of the goals is to have 30% of active users enable the conversation history feature within thirty days. But right now, we're really just concerned with making this work from a functional perspective, so let's have a look at the problem statement.
The current state is that conversations are deleted after thirty days. That's correct. Users lose conversation context when starting a new session. That's correct. You don't have any conversation management in UI. All of that is completely correct, and it got that from reading all of the code and a little bit of my initial input, of course. And, of course, here you can see the user pain points, like how there's context loss, there's no reference system, they cannot go back to previous conversations, etcetera.
What I really like about this is that everything is segmented very well. We have core functionalities like the conversation history toggle, the privacy consent flow, etcetera. I mean, this is exactly what you want to see in a PRD. And to be quite honest, this is a better product requirements document
than I see in a lot of professional use cases at the moment. So, sure, AI is not perfect,
but I'm just telling you that this is better than an average product requirements document. Is it perfect? No. But this is really extensive, and it goes on for a very long time. And it doesn't just talk about the functionality,
It talks about the success metrics. It talks about the potential data structures that it needs to implement, and it even has a little consent model design here. I mean, that is very cool. Right? So let's go ahead and actually just implement an MVP of this feature because the consent model is something that I'm gonna work on for sure. It's just that right now, I want to take things step by step, and I just want the ability for users to select their previous conversations simply by ID. It doesn't need to have a fancy name in the left side of the application,
and then, of course, the saved conversation should persist for more than thirty days. So let's go ahead and ask Claude to implement that. I want us to first implement
an MVP of this PRD,
So that's minimum viable product. Right? It's smallest unit of successful
work that you can create to implement a feature like this. And then we're going to say the idea being that the user can
select their conversations
via a list of conversation
IDs on the left.
This, of course, implies
that Convos
should be persisted
in the database
over thirty days.
Right now, the toggle can just be enabled without the consent form.
We will implement this
later.
And the great part is that you can even ask Claude to then update the PRD and make sure that it ticks off the boxes of the features that it has or has not implemented.
And, of course, you can also move this PRD to
your project management tool of choice, like GitHub or money.com,
whatever you're using. You can definitely export these PRDs to a system like that as well. Alright. So it has a couple of to dos that it's gonna do. It's gonna remove the time to live from conversations container to enable permanent storage, and this is a setting on the Cosmos DB, which is a NoSQL database,
uh, where the container will automatically remove data that has not been touched for thirty days. So that is exactly why we need to remove it because if you have a conversation stored right now, you wanna make sure that it's stored indefinitely unless a user deletes it. Right? And then, of course, we need a new API endpoint to list all the conversations.
We need to enable the conversation history toggle in the sidebar.
We need to create the conversation list UI components, add a conversation selection and switching functionality,
and then, of course, we need to test end to end conversation persistence and retrieval.
So all of those singular steps sound great to me, and you can see that it's actually starting to create some code changes. Now this is a terminal based coding app, so you can check out the diffs like so. But what I like to do is just check out what's going on in Visual Studio Code. So I can actually go to my branches here and see that in customers DB p y,
it's changing a couple of things. It removes that default TTL,
and then if we scroll down here, you can see that, for example, it's creating a new endpoints or rather function to be able to retrieve all of the conversations for a given user. So let's let it cook, and I'll be right back with you once it's done.
Alright. So what you see now is that it actually has ticked off most of its to dos, but we do need to test the end to end conversation persistence and retrieval.
So it seems like it wants to actually run NPM run build just to see if there are any TypeScript errors, so I'm actually gonna say yes to that. That's totally fine. I don't expect there to be a lot of errors, but you never know.
And you can actually see here that there is an error when it's trying to build the full project,
so that's totally fine. It's gonna go back into the code and try and fix that up, and then I'm expecting that it's going to just run everything again
once it's done with fixing this. Now it's gonna build again. Yep. There we go. It's gonna build again, and hopefully we get no errors now. Nope. We do still get an error. Response data is possibly undefined,
and this is exactly what the actual AI coding process looks like sometimes. It's not gonna get it right in one go, but this is running completely in the background. It's not actually interrupting
my regular development flow, so I could be doing something else entirely in the background and working basically in parallel to Cloud Code. So, you know, this is totally fine. Sometimes it just needs a couple of iterations to fix stuff, and now you can indeed see, boom, it's actually able to build the entire project.
We don't wanna build the project in development,
but
is good to know that there are no build errors. So now what it's gonna do is it's gonna test the back end. I think that's a good idea, but you know what? We are here anyway, so let's go and just test it ourselves. I'm gonna go ahead and say no.
And now let's just go ahead and reload our front end and check out what actually happened in practice. So if we check out the other terminals, we have the front end application here and the back end here. So, technically, you know, this all hot reloads and changes, but just to make sure that nothing strange has happened, I'm just gonna reload
both the front end and the back end just to make sure. Right? And then what we're gonna do is we're gonna go back to my browser and then check if the feature was actually implemented properly. So I'm gonna go to my browser, and then I'm gonna go back to the front end application, and it's gonna give itself a full refresh. And now you can see that this conversation history button has a toggle. At this point, if I ask a question now, it should be saved in that conversation. So I'm gonna go ahead and paste the same question here. And then once it's done with answering this, I do expect that it's gonna show on the left here in the sidebar. So let's let it ramble on about AI engineering, and then there we go. So what I'm going to do now is I'm going to give this page a full refresh,
and then what we're gonna see is we are
and then, unfortunately, we see that it doesn't work. So what we need to do is we actually need to go back into Cloud and report that the feature doesn't work, but we need to explain why it doesn't work. So what do we do in a situation like this where the implemented feature doesn't work? You do not want to go back to Claude and just type, uh-oh, the feature doesn't work. Why don't you just do a little bit of investigation work yourself so you can give the AI model the right context so it can actually fix the feature? What do I mean by that? Well, in this case, we can actually have a look at our network tab in our browser to get a better idea of if the conversation is being stored at all. What I mean by that is that I can ask the question, what is AI engineering again?
And you can see that it creates this request for the message response,
and that is indeed being streamed in at the moment. Now I'm just curious to see what happens once the message is done generating.
So the message finishes,
and there's no extra request. So at the very least, we know now that as far as the initial implementation goes, the front end is not responsible for saving the conversation.
I suppose then in the message back end API,
the conversation should have been stored to the database, but that is not happening. So now that we know that context, we can actually formulate the problem in much more detail to cloud, which will improve the chance that it can actually fix the feature. So I'm gonna go back to Visual Studio Code, and then I'm going to type the following. I tested this manually.
It seems the toggle works quite well,
and the convo is not saved if the
toggle is off. However,
if the toggle is on,
the conversation
is also not saved.
I see the front end
does not make a new call to the back end after a message is done,
which makes sense.
But then I assume
the message
back end does not properly
save the conversation
or
something else is amiss. So I don't know exactly what's going wrong. I'm not going to investigate that completely because if I did that, I might as well code the feature myself.
But I do take the effort to investigate a little bit and to test a little bit further than just seeing that the UI doesn't work. Because if you can give your AI models just a little push towards the right direction, they will figure things out much faster and much more accurately,
just like how a junior engineer would operate. So that's why you should always give these AI models the right context. But the proof is in the pudding, so let's go ahead and let it search for anything that it wants and reimplement the solution and see if then it all works.
Looking at our cloud session, it seems to do a couple of things differently now. For example, in the request for the message, it actually seems that we now need to pass a safe conversation flag, which is probably gonna be just a false or true.
And whether it's false or true depends on what the front end toggle looks like. So if you've enabled the conversation history, safe conversation will, of course, be true. If you've not enabled the conversation history toggle, then the safe conversation value is going to be false. So that makes all the sense because based on that flag, the back end will know whether or not the conversation actually needs to be stored for a longer period of time. So that makes sense to me. Alright. What we're gonna do now is just test this implementation again. So I'm gonna fully refresh the page,
and then once again, we're going to ask the question, what is AI engineering? Now if we check out that message request again and I check the headers
or actually rather the payload, you can see here that in the payload, save conversation is set to true. So that's actually a good sign. Now let's let it just generate the entire response, and then we're going to, of course, refresh the page once again. So I'm gonna refresh the page,
and it still doesn't work. So now I'm actually going to go into the database and see if the conversation itself was stored because that will give us a good sign,
and we can pass it on to the AI model so that it understands that the data itself might have been stored, but it's not being retrieved properly.
So in the database, I'm gonna go ahead and refresh my conversations,
and you should indeed be able to see all of these conversations that I recently created. So it does seem like the conversations are being saved, but they're not being retrieved properly. And I'm actually going to take this and copy the entire object
because it will give Cloud a good example of how the conversation has been stored. So I'm going to let it know that the conversations
seem to save in the DB correctly,
but they are not fetched
properly.
Here is an example
of a stored
conversation,
and then it's gonna paste all of that text in.
There we go. So this is another great recommendation.
If you are working on a feature where there's some database interactivity,
you can just go into the database and check whether or not things have been saved correctly. And if they have been saved, you can just let Cloud know. Technically, you could let Cloud connect to your development database directly, but it is very convenient sometimes to help it along yourself and just check out the data and make sure that things are or are not saved.
Alright. It seems to be done. Here's hoping it did well. So we're gonna go ahead and check out the website again, and oh, it looks like it actually auto refreshed this. So this is great. You can actually see these conversations in here. That's a really good sign, but we have to test a little bit further than that. Right? Let's go ahead and disable the conversation history,
and now what I'm going to do is type the following. I do not want you to save this.
It's not like the AI model is actually going to listen to this specific request, but by typing something else, we can actually recognize whether or not this conversation will be saved. So let's see if when we refresh the page, this conversation will show up or not. So I'm gonna go ahead and refresh the page, and then let's go ahead and enable conversation history,
and it's not in there. Now let's go ahead and do one more test.
Please save this chat.
And then we should see this show up on the left side here once the message has been done. Alright?
So there we go. Yep. There we go. Please save this chat. But funnily enough, there is a little bit of a UI improvement that we need to make that I just realized. So as you can see here, there's only four items that can be shown at once and have to scroll. That's actually not very obvious that there even is a scroll bar, so that's something I'm gonna pick up in the second iteration, but at least the interactivity here does work. Now, of course, the AI response here is that it doesn't have the ability to save the chat conversation.
Functionality would need to be handled by the platform you're using to access me, but that's exactly what we're doing here. So, of course, the AI model is not completely aware of all of the features that are on my page right now, but that's another thing that I could change. I could improve the system prompt and just tell it that there is an explicit toggle that the user can enable or disable. So clearly, there's still a lot of work to do, and this implementation is also missing the dialogue form, but it's starting to really come together. Now I have one more surprise for you because you got so far into the video, and that is me sharing a secret with you because not that many people actually care about investing in their AI coding skills or getting ahead in their careers. But you clearly do because you watched this video all the way until the end. And I just wanted to share with you that AI can be such a powerful tool to actually accelerate your career. I grew to senior much faster thanks to AI coding, and you can be part of that too. If you check out the link in the description below, you can join my AI native engineering community, where you can learn way more AI coding techniques as well as how to build full,
real production AI systems like the one that I demoed in the video today. I really hope to see you there because you've got the right potential.
Bye bye.