How Senior Engineers Actually Build with AI in 2026 | Build a Full Stack Job Applications Platform

Something changed this year. Every developer I know is quietly asking the same question. Do the skills I spent years building still matter? It's a fair question. AI writes better code every month. The gap between junior and senior is closing. And the more you delegate, the more the output starts to look the same. Generic and inconsistent. It's impressive for 5 minutes of glory on X, but becomes impossible to maintain by the third feature. But that's not the real story. AI doesn't make developers less valuable. It makes the gap between developers with a system and developers without one larger than it's ever been. Anyone can open up Clawude and get code out. That's easy. What almost no one figures out is how to give the agent enough context, structure, and direction to build something that holds together, something you can ship, maintain, and trust. That's the actual skill, and it's completely learnable. This is Job Pilot, a full stack AI agent that finds jobs, scores each role against your profile, and then sends real browsers across the open web to research the company behind every listing. It writes your cover letter and tailor your resume to match. This application would have taken a team of developers at least a month to build. Now, I built it on my own in a couple of days. without writing a single line by hand. And by the end of this video, you'll have built it, too. Same stack, same way I did. If you know basic JavaScript, you can follow along. But the app isn't why you're here. You're here for this. Five open-source agent skills: architect, remember, review, recover, and imprint. They'll give your agent memory, focus, and the ability to ship without drifting. You install them once and then use them on every project after today. They're free, open- source, and completely yours after this video. You can get them from a GitHub repo down below. And I also took the time to write a full guide covering exactly how to use each one of these skills in more detail. I'll put it in the description, too. Now, the stack next.js GS16, INSForge for the back end, browser base and stage hand for real browser automation, GPT40 for intelligence, PostHog for analytics. By the end, you won't just have a working AI agent. You'll have a system for building anything. A system that doesn't get replaced by the next model, but instead gets stronger every time you use it. We are now at a time where one engineer with the right system has no ceiling on what gets shipped. So let's build. Before we touch a single tool, give me 5 minutes to tell you about the part that decides whether your build ships or falls apart halfway through. There's no quote in this section yet. It's the most important one in this entire video because this is the process of how I think before I write a single prompt. Without it, even the best model will drift. It'll start contradicting itself and just break your codebase. If you've felt that, you know what I mean. And if you haven't, first of all, you're crazy. Great job. But you most likely will. The problem is that most developers using AI do the same thing. They open up the editor, describe what they want, the code appears, and they react to whatever comes out. Sometimes it's great, sometimes it's broken. Fix it, move on, and repeat. That's great for demo apps, but that workflow has a ceiling, and most devs hit it fast. The problem is that AI has no idea of what you're building. It knows what you said in the last message, maybe a few messages back, but it doesn't know the decisions you made 3 days ago, what you decided not to build, your conventions, your folder structure, or where your project stands today. So, it guesses and those guesses compound. 3 weeks in, your database is full of contradictions that nobody can fully explain. So, here's how to fix it. The first half of the fix is context. Not just telling the agent what to build, but giving it a complete picture of the system it's building inside of. For job pilot, I wrote nine context files before the agent touched the line. What the product is and who is it for? architecture, folder structure, code standards, UI rules, design tokens, library specific patterns, a build plan, and a living progress tracker that updates as we go. Nine files so that the agent never has to guess. It is some real time upfront, but you only have to write them once. And then these files travel with the project for its entire life. And if you keep watching, I'll show you how we can set them up together when we start the project. Now, the second half of the fix are agent skills. In my previous video, I used spec files. One spec per feature each build session. It worked, but it was pretty heavy as every feature needed a new document. But this time, I improved that workflow. What you're watching today is the latest workflow I'm working with after years of improving it. This time I replaced specs with something better. Five agent skills built from real production builds, real failures I've encountered, and real sessions where the agent drifted and I had to figure out why. Each skill came from a specific problem that I kept hitting until I refined the solution. And each one is just a command you run inside of your AI session. Here's what they do and what they prevent. First one on the list is architect, which you run before any complex feature. Without it, you start typing a prompt, the agent builds, and then halfway through you realize you never decided how O would work for this. Your agent just made a guess, and now you're refactoring with it. When you run architect, it reads your context files, asks focused questions one at a time, surfaces the decisions you haven't made yet, and produces a plan. That's the conversation you should be having before every serious feature. And now it happens automatically. The second skill is called remember. You use it at the end of every session. Without it, every new session starts from zero. You spend 10 minutes reexplaining what was decided yesterday or you don't and the agent contradicts itself by lunch with it. You run remember when you wrap up it compresses what happened, decisions made, patterns established, progress completed into a memory file. Then the next session loads it on open which gives you continuity without reexplaining. Then there's review which you run after a feature is built. Without it, the agent finishes a feature 400 lines. You skim, you commit, and 3 days later you find a bug. With it, you run review. It checks if the implementation matched the plan, if it respects your architecture boundaries, and if it's production ready. It then returns issues by severity, critical, important, minor, and it never autofixes things, so you stay in control. I also came up with recover for when things break. Without it, something's wrong. You're 4 hours into a session. You don't know if it's a targeted bug, a polluted context, or a wrong assumption from earlier. So, the AI starts spiraling, and you spiral, too. With it, you run recover. It diagnoses which failure mode you're in and gives you the right correct response. That's one prompt instead of a very frustrated afternoon. And finally, there's imprint, which I use after building any UIs because without it, three sessions in your buttons all look different. spacing is a tiny bit off and your design system has mistakes that you didn't really notice with it. When you run imprint, it captures the new components patterns into your UI registry. So you run it across the codebase, it finds the inconsistencies and produces a fixed list. That way the design system stays coherent across every sessions. Five skills handles every serious failure mode developers hit when building with AI agents. Drift, inconsistency, broken sessions, UI chaos, and lost memory. One skill for each one of them. It took a lot of trial and error and frustration to come up with them, but here they are, and they're open source, not just locked to this project or this stack or this agent. You can install them once and use them anywhere. So, I'll leave the link in the description. And to make it even easier, I've also put together a guide covering exactly how to use each skill in more detail, when to run them, and how to set up your own context files for any project you build. I'll put it in the description, too. So, here's the full loop. Start every project by writing context files. nine documents that give the agent complete knowledge of what you're building. That's the foundation. And I just realized that I didn't go into too much depth about the nine files in this crash course, but I did write more about them within the guide that I just mentioned. So you can check it out there. But these files are the foundation. Then you build feature by feature. Before any complex feature, run architect. After you implement it, run imprint if it's UI. review if it's complex and at the end of the session remember and when something breaks call recover context makes sure the agent knows your system and the skills make sure that every session is focused every feature is reviewed and that nothing gets lost between conversations. That's the system and it is simple on paper, but what matters is using it on a real project under real pressure. And that's what the rest of this video is for. Here you just heard about some new skills and new concepts that you might end up using. But if you continue watching until the end, I'll show you how you can actually use them to build job pilot. every feature, every session, same workflow and to also be able to use them across all of your future projects. And if you want to go deeper, the Agentic Dev course teaches all of this from the ground up, the fundamentals, the architecture thinking, and the patterns that made me come up with these five skills in the first place. So, within the course, I'll take these skills apart and show you how you can make yours. Those are the patterns that make AI work on serious projects. So, I'll leave the weight list link in the description so you can know when the course is out. So, now that you understand the workflow, let's learn it and practice it in action. Time to build. That's the system and the product you build with it is almost beside the point. If you swap job pilot for anything else, the workflow won't change, but you still need a stack to build on. So here's what we are using for this build and why each piece earns its spot in an app like this. For the entire back end, we'll use ins. Job pilot needs three things on day one. O, a database and file storage. Almost every single app needs this. Google and GitHub login, tables for profiles and jobs, and a bucket to hold resume PDFs. Ins gives you all of this in one platform. And the part that matters for this is the MCP server because your agent connects straight to your backend, reads the live schema, and wires things all on its own instead of guessing against an API it half remembers. And the free tier covers everything that we built today. So, while we're here, let's immediately create an account. Click the Ins link down in the description, sign up, and you'll be redirected to your dashboard so that later on we can immediately start using it. For browser automation, you'll use browserbase along with their AI browser SDK, Stage Hand. A big chunk of Job Pilot runs in a real browser, reading any job URL you paste in and sending an agent across the web to research a company before you apply. You don't want that running on a headless browser on your own machine because it crashes and some companies can detect it as a bot. Browserbase instead gives you a real managed browser in the cloud with session recording and a live view. You can drop straight into the app so users watch the agent work. Stage hand sits on top of that and lets the agent read and pull data from any page in plain language instead of using the brittle CSS selectors. Once again, it's free to start and everything we'll do will fall under that free plan. Click the special link down in the description so you can follow along and see exactly what I'm seeing later on when we set it up. For now, just creating an account is enough. And for analytics, you'll use Post Hog. Once people are searching, researching companies, and tailoring resumes, you want to see what's actually happening, which actions get used, what lands, and where people drop off. Posthog roles analytics, session replays, and feature flags into one tool. And it's super quick to wire up thanks to their Post Hog wizard. It'll power your full analytics and help you use this new workflow that I'm teaching in this video with so much more potential because you'll make educated decisions on what you want to build now that you can actually build super fast, allowing you to build the features that your users actually want. Once again, their free tier is super generous and I'll leave the link down in the description so you can create an account and later on we can just one-click install it with a wizard. So, if you haven't, pause the video and create accounts as we'll be using them within the first couple of lessons. If you've done that, perfect. Now we are ready to build job pilot feature by feature while following this workflow that I taught you in the crash course but that we'll now together explore throughout the full build. So let's go. Okay, I hope you're ready to get started developing our application in this new agentic workflow that I want to teach you. We'll start straight from the beginning by creating a new empty folder on our desktop. And you can go ahead and call it something like job pilot, which is going to be the name of our application. And then simply drag and drop it into your VS code or cursor or any other text editor or IDE that you use nowadays. I mean, even the concept of what a text editor is is changing nowadays. Cursor and Codeex for some time have been using this view where on the left side you have a list of conversations you have with your agents. In the middle you have the actual conversation contents and then on the right you can have either code or a preview of the browser. Recently VS Code came up with that option as well. You just need to search for the agents window or click the button in the top right and it'll open up something that looks like this where no longer you have the files on the left side and then the code in the middle and that's it. where you have a list of sessions on the left side and then the actual conversation in the middle. Love it or hate it, what it means to be a developer or an engineer is changing. And that's exactly the goal of this video to guide you through that transition smoothly and to help you stay on top of it. So now that we have an empty project, go ahead and open up your integrated terminal while that still exists. Jokes aside, I think there's always going to be place for a terminal and create a new Nex.js application. You can do that by running mpx create next app at latest and then just dot to create it within the current directory. It'll ask you whether you want to install the create next app installer. So just go ahead and say why yes. And it'll ask you some questions such as would you like to use the nextgs defaults. In this case, we're going to proceed with that as it's going to turn on TypeScript, ESLint, no React compiler, T1 CSS, no source directory, app router, and the default agents.mmd file. So, let's go with the recommended options. Give it a minute to set everything up. Once that's done, you can, of course, go ahead and run mpm rundev to spin up the project on localhost 3000 and then open it up within your browser. This is new. I commandcllicked it expecting that it's going to open it up in my default browser like it used to do for years, but instead it actually opened up the app as a tab in my VS Code window. This is pretty cool. It's an integrated browser within which local host links automatically open up. Pretty cool. You can use it just as a regular browser or you can also turn on the inspect element so you can select specific elements and then it automatically puts them within your agentic chat session. I love this. So far, you had to use a third party app or a browser extension in order to be able to do that, but now it's integrated directly within your VS Code. This is amazing. So, it knows that this is referring to your app, that is referring to an H1, and it even passes a screenshot to the part that you're trying to fix. So, now you can just say modify this, and it'll immediately do it. Love it. We'll definitely use this later on. You can also add element to chat, add screenshot to chat, or add console logs to chat. Pretty cool stuff. And there's a full browser console and elements tab right here. Love it. Now, let's go ahead and modify some of the default files right here by heading over into the app and then page. We can clean this page up by just running rafc. If that isn't working for you, you can head over to extensions and install React snippets. There's a couple of different packages. Uh there's the simple React snippets that I have right now within which you can simply say sfc to create a stateless functional component, but there's also this ES7 react redux react native snippets that allows you to use the RAFCE keyword. So you can either use that or you can use the sfc from the other one. Either way works for me. Let's call this page home. And then within the home, we can simply return an H1 that says job pilot. And I think I'm zoomed in a bit too much. So I'll zoom out a bit. And you can hopefully still see everything on the screen. Now let's head over into the globals.css where we have the default styling. Right now we want to remove all of that default styling, but just keep the import to tailwind CSS so we can use all of its utilities. Later on, we will fill in this root as well as the theme in line as well as some media where it prefers the color scheme set to dark. So, we can specify the dark mode of our application where we'll be able to modify some root classes and then of course there is the body uh in case we want to do some resets. Later on, I'll provide you with the styling so that we can focus on what matters and that is learning about this agentic workflow. Let's also head over into our public and remove everything from it. The only thing we'll keep is the empty public folder because later on we'll fill it in with additional assets. So now that we have an empty slate of our application like it's completely empty, there's nothing there. We want to set up our agentic skills and context files that we'll use in all of the upcoming lessons of this video, but also in every upcoming project that you work on. To start setting up our agentic workflow, we'll need some context files. And just so you don't have to create one by one by hand, down in the description, I'll leave a video kit link which is going to look something like this. Here you have different useful links such as the link to the open source codebase of this project, the deployment, the assets, and some guides, Discord channels, and so on. And on the right side, you have some snippets that I'll refer to throughout this video. So, I've put all that neatly in one place so that you can refer to it as we go through the build. Let's start off with the assets part. So, click on this. It'll lead you to this Google Drive where you can download the public folder zip as well as the context zip. Once you get them, you can unzip them, remove this public folder, and then simply drag and drop both of these folders right here at the root of your application. And you can say copy folders. public is going to be simple. Here we have our job pilot logo as well as the images we'll be using later on for our agents dashboard and so on. And then the context is where the magic happens. But before I go through each one of these individually and explain them in this video, I'll teach you how to take your agentic development workflow even further by using custom skills. I've been writing code using AI for many years now, but especially throughout the last 6 to 12 months, I doubled down on it. Ever since Claude Opus 46 came out, and since then, I've been improving my workflows, but I didn't feel like rewriting all my rules for every single project. So, skills made a lot of sense. I created a series of skills that combine all of my workflows and learnings and struggles of years of working with agents into a set of skills that you can install into any project. And installing them is super simple. You just have to run MPX skills at latest add JavaScript Mastery Pro skills or you can install them individually. Below you can find some info on each one of these skills. But don't worry as that's exactly the point of this video to teach you how to use these skills. If you want to know how I created these skills in the first place, how I came up with the ideas, and why I thought these specific workflows need to be turned into skills, you'll likely be interested in the agentic development course that I'm working on. That's going to be a collection of all of my learnings over the years of trying to tell AI to write code. Now, it actually can, and I'm ready to compile it into a single course. So, for now, you can only join the wait list, but it's going to be out soon. Now with that in mind, you can head back over into a terminal and you can open up a second window and within it run MPX skills add latest add JavaScript Mastery Pro skills. It'll ask you whether you want to install the skills installer. So you can say Y. Proceed. And then it'll ask you which skills you want to install. In this case, you can select all of them. There's just five. It'll ask you for which agents you want to install those skills. You can select the one you're using. You have a lot of options right here. Um, we can use clot code or we can use something like codeex or gemini. That's going to be completely up to you. Of course, there's also cursor, but you can see for it that's universal and it works right out of the box. So, press enter. Install it either on the project or globally through sim link and proceed with installation. Now, after now, after you install it, if you would be so kind, you can also give this repo a star. So, as more of us use these skills, we'll get more issues and pull requests to improve them even further and make them better. Once installed, you'll see these skills appear directly within your project right within agents. And here they are. In the crash course, you already learned about when and how we'll be using these skills. And very soon, we'll start putting that to practice. Now, before we start using our context files, which are going to work together with our skills, I want you to think about something. Imagine you're a developer and a client comes to you and says, "Build me a website." With no brief, no requirements, no design, just that. What do you do? I mean, you make guesses, right? Assumptions. You build something that made sense to you, but not necessarily what they wanted. That's exactly what happens when you open up a chat window like I do right here and then you tell it something like build me a SAS app. The model, whichever one you're using nowadays, isn't stupid. It just has no idea what you actually want. So, it fills the gaps with its best guesses. And three sessions in, those guesses compound into something that, well, nobody asked for. So, before we write a single prompt, we want to give our agent everything it needs to know. And that's coming in form of these nine files. Each one of which gives the agent a specific layer of knowledge that it would otherwise have to guess. It starts with the big picture, which is the project overview. Here we tell the agent what job pilot or whatever project you're working on. Actually, it's a full stack AI powered job hunting assistant. The user sets up their profile once, uploads their resume, and the agent automatically discovers relevant jobs from LinkedIn, scoring each one against the user's profile using GPD40 or later on we can switch this. So, we tell it what it is and what problem it solves, and we tell it about the problem it solves. Job hunting is one of the most repetitive and timeconuming tasks a developer faces. So, the goal here is to eliminate all of that. Now, why are we telling it that? Well, the more context it has, the better decisions it'll be able to make with the limited context that we give it through the prompts. Then, we also give it every single page and the full user flow, how the user moves from page to page and exactly what happens. We also give it some more information about the specific functionalities of the app, which in this case is finding actual jobs and provide more info. Then a bit below we talk about what's in scope but also at the same time and this is important what's out of scope for this application. The agent reads this file once and knows exactly what we're building and more importantly what we're not. That way there's no scope creep. It's simple for it to understand our success criteria. So once it knows what we're building, it also needs to know how it's built. And for that there's another context file called architecture.mmd. You can also open it up in markdown. It's going to look something like this. And this file is all about the stack as well as the folder structure of the application. The system boundaries and data flow as well as database schemas and a set of rules that our AI agent must never violate. For example, API routes contain no UI logic. Components contain no DB logic. Agent code in agent never imports from components or actions. Server actions never call agents. And you you get the idea. That's the architecture. That was the architecture. But now it needs to know what to build and in what order. And that's what the build plan is for. Within the build plan, we tell it how we want to split this build into phases. For example, we're going to have 25 total features across five phases with every feature being defined, scoped, and sequenced correctly. So that way, the agent never has to decide what comes next because it already knows it. This is the road map that we follow for the entire build. And if you're wondering, but hey, how do I actually come up with all of this? or do I have to prompt my AI agent to create this before we even begin? The answer is yes. That's something that we'll dive much deeper within in the agentic development course. But yeah, through the conversation with AI before you even begin with the build, you come up with these rules and different things that you want to build. It can easily split it into different features one by one for you and then that's the plan that we can follow. Of course, we can choose to deviate from it, but more or less we're going to stick with it. So once we know what to build, then it needs to know how to write the code. And that's what the code standards file is for. Here we tell it a bit about the TypeScript rules. For example, the naming conventions or NexJS 16 conventions, the file and folder naming, the component structure, how we handle specific errors or server actions. Basically, every single convention that you follow that you can think of, write it down once. And this is what keeps the agent consistent across every session instead of simply drifting away into its own style by week two. And it also needs to know how to use the tools. So for that, we have the library docs.md. This file is not just generic documentation. It's on exactly how we use each library in a specific project like job pilot in this case. So before using any library check if an MCP server is configured for that library read that file and only then act. In this case we'll be using ins. So we tell it how we can use it and some rules that it can follow. Same thing for o dbqueries and browser base which we'll be using later on to actually scrape the data. check for the MCP of this library that we want to use and some examples of how we can use it. Of course, I was super detailed right here, but these context files are something that you can build along the way as you're building the application, but of course, the more you prepare at the start, the better. Now, for the UI layer, there's three files, each handling a different part. Let's start with UI tokens. Here we define every single color, spacing value, border radius or typography scale and we pull it directly from the design defined as CSS variables. The agent will use these exact values with no hard-coded hex values or no inconsistency between the pages. So once it knows the primitives, we can head over into the UI rules.mmd. Here we tell it how the UI behaves. uh things like the font, the layout and how cards should look like, the button styles too, the badges and everything. And this is what keeps every page feeling like it belongs to the same product. You know that if you're building with AI, very often the AI will start deviating from the general design. But with this in place, you can essentially consider it your entire design system. write the visual rules here once and then the agent will follow them across every page. And if you already have a Figma design, you can use a Figma MCP or just feed it over into AI and it'll generate this for you. Finally, there's the UI registry. This is a living document, so we're essentially starting it empty. Later on, I'll teach you how to use the import scale, which fills it automatically as we build components. So, as soon as you create some of the components, it'll check if a similar component exists. If yes, it'll match its exact classes. If no, it'll build it following the UI rules and UI tokens and then add it here. This is super powerful if you're building without a design, and it's what keeps your components consistent across the entire codebase. There's also another file called progress tracker, which also begins kind of empty. None of the check boxes have been checked, but it'll be automatically updated after we complete every new feature. So, at the start of any new session, the agent knows exactly where we left off with no reexlaining needed. That's it. These are the nine files that give the agent the full picture of what we're building, how the system works, what to build next, how to write the code, how to use the tools, and how the UI should look and behave. In this case, I was super detailed. When you're building these for your projects, you can start slow and then keep adding things as you go. And you'll most likely keep adding things as you switch it from a project to another project because you'll figure out what works and you'll want to stick with it, but then modify just slightly to suit that new project. In this case, I took the time and I made it very detailed for two reasons. First of all, you can browse these files and try to understand the process that I follow while writing them. Again, within the agentic development course, I'll give you the full uncut version of me actually generating these files with AI. And the second reason is that since we're building this application together, I want both of our agents to give us more or less the same output. The less specific you are, the less similar and less perfect output you're going to get. But with this detailed context files, we should be getting almost the same output so that you can easily follow along until the end of this course. So how do we tie all of this together? Well, it has to do with the agents.mmd file, which right now is completely empty. If you head back over to your video kit, you'll see a final agents.md file right here, which you can copy and simply paste it right here. It's simple. It just ties everything together. Here we're speaking directly to the agent. We tell it to read in this exact order before any implementation. Read all of these nine files. And if you think that making it read these files is going to consume a lot of tokens, trust me, it's going to consume significantly less tokens than it would take it to generate some stuff that you'll end up scrapping and never using and going back and forth and fixing it. This workflow is made for the highest speed of development, but also the lowest token cost. Trust me on that, and you'll see for yourself as you continue following along. There's also some rules that never change, like no hard-coded hex values, update the progress tracker after every feature, load the skill before touching any third party libraries, and it lists all the skills and exactly when to use them. Think of it like this. The context files are the knowledge and the agents. MD file is the instruction manual that tells the agent how to use that knowledge. Without it, the agent might skip a file, read them in the wrong order, or miss a rule. With it, every session starts exactly the same way, consistent, focused, and fully loaded. If you're using Claude, you'll need a claw.md file, which in this case should automatically point to the agents.mmd file. So, this should be good no matter which agent you're using. You'll also notice that under context, there's this designs folder. This is to make sure that every page has a visual reference so that when the agent builds UI, it's not inventing. It's simply trying to match what's already there. That's how you get consistent and polished UI without correcting it every session. And if you're finding all this overwhelming, just follow along with this video, build it with me, and I think you're going to get a pretty good idea of how you can use this workflow for your own projects. Of course, if you want to dive deeper and learn how to create these files from scratch, you can join the weight list for the full Aente course. But while that's not out, I actually already prepared the full AI development starter kit, including these context files, workflows, and the skills that we talked about, all within a single reference book that you can always go back to and look at when you're crafting these for your own projects. So, now that the context is ready and our agents MD file is here, we're officially ready to start developing our application. Now, just before we run our first prompt, I want to tell you about the workflow that we'll be using. So, no matter which agent you go with, the interface is more or less the same. You can open it up by pressing command shiftp and then search for chat. At least that's how it's called in VS Code. Here you'll see that you have the regular chat belonging to VS Code, Microsoft, and Copilot. There's also claude code and Codex. And these right here are just extensions. So if you head over to extensions and search for Codex, you can see it right here. It has almost 10 million downloads. And as soon as you install it, it'll appear right here. Same situation is happening with Claude or any other agent you decide to use. You install them and they appear right here. So this video is completely agnostic when it comes to the tool you're using. The thinking and the specs are what actually matters. the tool is your call. That said, here's what I'd recommend. Claude Code is amazing and you can totally use it on the sonnet model which is cost effective and that's what I've done for the past two videos. In this one, I'll be using Codex. Lately, I was able to achieve a lot with very little token spent and that's what most people are running these days. It's also the most budget option available as they have the go plan for only about eight bucks per month, a plus plan, and they're usually giving away a month for free depending on your region. In my case, I'll go with plus. Either way, I'll make sure you don't burn through a ton of tokens regardless of what you pick. And sure, you can also use a Codex app or cursor or whatever you want or this agent window in VS Code. everything works. The context and the workflow that we're going to go through and use together throughout this video is agnostic to whichever tools you or your team are using. So, go ahead and open up your agent of choice. You can do that by pressing commandshift I, which automatically opens up the chat window, and you can just select the agent you want to use. So, let's start with setting up our design foundation. Everything we defined within UI tokens, we also need to put within our globals.css before the agent touches a single component. We want to do this first and then every page we build after will be consistent from the start. If you skip it, the agent will just start guessing. So, open up CEX or your agent of choice. Moving forward, when I say codex, you can think of that as your own agent. And let's tell it something like this. Read the agents.mmd file and follow the reading order specified. Confirm once you've read all context files and are ready to build. With this prompt, the agent will read everything, confirm it's loaded, and then we build. So let's run it once to see what it has to say. And here you'll also be able to watch it do its things like read the agents MD and then finally moving through the files that we gave it UI token UI rules UI registry and so on. Now, we want to make sure that the agent uses Tailwind CSS V4, not V3. And for these types of situations, there's a package called context 7, which has up-to-date docs for LLMs and AI code editors. For example, the NexJS docs was changed 54 minutes ago, better raw 20 hours ago, and here's Tailwind CSS changed 20 hours ago. You want to click on it and then we want to give this info over to our agent so that it has the latest data available. We can do that right here within our terminal by running mpx ctx7 context 7 skills search tailwind CSS. It'll ask us whether you want to install the context and then you can select some of the skills. There's going to be many, but you can go with Tailwind CSS, Tailwind CSS patterns, Tailwind CSS utility components, I think, is going to be another one that we want to use. Yep, utility classes right here. And finally, the best practices. So, that's going to look something like this. And then press enter. You can install them right here. And now the agent will have both our project tokens and up-to-date Tailwind CSS v4 knowledge which means that we are ready to write the globals.css prompt. In this case we don't have to use the architect skill because there's no logic. It's just straightforward setup. So I'll tell it to read the UI tokens.m MD file and use Tailwind installed skills to check the correct Tailwind v4 setup and then set up the globals.css file. This fairly detailed context and skill setup allows us to write very short and quick prompts. So you'll see now that the setup is done how we can very quickly progress through the application given that the right context has already been put into place. Give it some time to think about it. And you might want to pause this video for a couple of minutes until the agent does this on your end. For me, it took about 3 minutes. It first checked the Tailwind skills, verified the Nex.js docs, and only once it understood which technologies it's working with, it made sure that the CSS matches the token specification cleanly. Then it made sure that the build is running, that the fonts are being set up properly, and that's it. It set up Tailm for globals in app.globals globals using the token pattern from the context UI tokens a full theme and it also aligned the layout with the project font rule by switching it to enter. Great. So now if you want to check out the app.globals.css, it's going to look something like this. We get all of these new styles that now we can use within our application. So, back within the homepage, if you head over here and give it a class name of something like let's head over into our globals to see which fonts can we use, there's going to be the font text color info dark for example. So, you can give it a class name of something like bg info dark and also text dash white as well as text dash 3xl. And then if you head back, you can see that all of these styles got applied. This means that our globals.css had been set up properly, at least for the initial primitive colors that we can use across our application to have consistent styling. So now that the globals file has been set up, immediately in the next lesson, let's build the homepage. Now that our design tokens are in place, we're ready to build the first page. And this is where everything we set up starts to pay off. Since we're going to start a new session, so you can head over into codeex and exit the current session, want to start a new context for every new feature we're building. Start with a new chat. And whenever you do so, I always like to tell it to read the agents.md file and follow the specified reading order and then confirm once it's actually read out. You can think of this as a pre-step that I always like to do before I start working on more complex features. And then while it's doing its thing, we can already start prompting it to build a feature. So I'll tell it to build the complete homepage exactly as shown in and then here we can utilize our design images under context landing page.png. I want to provide it with an image of the design that you can either find online or design it using Figma or some other design tools. So as shown in and this is going to be the landing page.png file and want to say use images from the public folder when needed and run it just at the right time when it finished reading the agents MD file and all the other context files. And notice just how short that prompt is. No stack explanation, no folder structure, no UI rules because the agent already has all of that from the context files. We just tell it what to build and where the visual references. That's it. And this is where the magic happens. Codex immediately started treating this as phase 1 feature 01 homepage. So it's loading the relevant build skills, the current homepage layout files, the Nex.js local docs and available assets. So we can match the design cleanly before touching the code. The app is still very small which is good for matching the design precisely. It got the design loaded. It's going to also take a look at some images. It dissected it and it's loading the front-end design guidance. It's using the architect skill for the homepage structure and the imprint after implementation so we can keep this first feature deliberate and consistent with the project rules. And all of this is happening from a single short prompt that we gave it. We're building a fully designed marketing homepage that matches the landing page design with a topnap bar, hero, and everything else. The language that it's locking in exactly as shown. Use images from public complete homepage decisions that it's making. It made a decision to split the code into components to stay within the existing project token system and to make sure that it works on desktop but also mobile. It made some assumptions which is good and then it created a stepbystep list of how it can start doing it. Finally, after all of that, it's moving into implementation and it'll keep the component shapes close to the architecture docs. Now it's editing creating one component after another. The homepage structure is done and then it'll even lint it to check for any TypeScript or app router issues before it does the required registry or progress updates in the visual cleanup. There we go. Lint is clean. It's going to do another compile level check to catch any server errors or next images issues by running mpm run build. Looks like the production build failed, which is amazing that we ran it. So, we're able to notice this issue. And that's because Next Font couldn't reach Google Fonts from the sandbox. So, it's going to rerun that build with network approval so we can verify the homepage compiles end to end. The build is passing. It's doing the final repo required bookkeeping next, such as marking the phase one feature homepage 01 complete in the tracker and imprinting that homepage patterns into the UI registry so future pages stay visually consistent. It's updating the two live docs right now, both the feature completion and the exact homepage class patterns we established. This is great. And I think even at this point, while we haven't yet checked out the output, you can see why that initial grunt work that we needed to do to set everything up is paying off significantly. While it's finishing, you can review the modified files starting from the globals where it added some new component specific styles to the layout where it updated the title and the description, which is amazing. We didn't even ask it to do that, but it did it. Here is the homepage and check just how clean that is. There's a navbar, there's a hero, there's a how it works, there's the features, success stories, call to action session exactly as I would have coded it. So to people who say that the AI generated code isn't clean and readable and scalable, simply share them this part of the video. So after the homepage, there are the individual components like the call to action section which is also super clean. the features section where it even extracted the data before the actual output. The hero section, how it works, success stories, footer, logo, all of these are just some representational components. And on top of changing these, it also updated the progress tracker.md. So we can go ahead and preview it. It simply marked the homepage as complete as well as the UI registry where now it added some new files like the landing footer so that if it needs to be reused later on, it knows exactly how a footer should look like within our application or maybe a call to action banner or maybe a testimonial section. All of these are likely to appear on other pages. And now, believe it or not, our agent documented these features for us. And thanks to the context system we have put in place, it'll simply refer to this UI registry whenever it needs to do something similar in the future. So, I guess this is the moment of truth. We have to run our application and see how does this homepage look like. I'll open it up right here in the preview. Zoom it to a proper size. And check this out. Besides these buttons, which are fully dark, which we're going to fix, and I'm super happy that there's something this obviously wrong, we're going to fix it. Don't worry. Take a look at the rest of the application. I mean, you can hover over these buttons and they move. The hero section and the font size and colors are done incredibly well. The subheading as well. It used this image from the assets and displayed it nicely. There's a second section right here. Manage your job search with ease. Another section apply with more confidence where it used another image. A full page success stories using Tom Wilson and its image from the public folder as well as a little ending part and then the footer. It did about a 99% match on the first try with no back and forth, no corrections, and no reexplaining the design system. The context files did the work up front, so we don't have to do it here. But I definitely want to fix the buttons. And thanks to our design system, we only have to fix it once. This is actually a situation where I'm going to use this new VS code add element to chat feature where I'm going to select a button and add a corrective prompt saying that all the buttons on the screen right now appear fully black background and dark text which is not visible on the dark background. Make them match the actual design and updated within the registry and the globals. So, all the buttons on the screen look great. And you can see that now we're passing it all the info and the screenshot. In the screenshot, I can actually see the text right here, which is too dark. But, as I said, the contrast just isn't good. So, we have to fix it. It's going to trace where button colors and tokens are defined. Collect all the project rules. Confirm the token intent for the button. And all of this is happening super quickly right now. It's basically doing it in real time as I'm speaking. It identified the button class usage. It found a conflicting token definitions in the repo. So, it's going to inspect it further by allowing it access to the browser. It'll now take a look at the application and see why it hasn't been done properly. It pinpointed the root cause. The text accent foreground utility is not taking effect on those dark CTAs, so they inherit dark text. It'll simply fix the globals.css, CSS, which is now super simple, modify it across all the buttons and update the UI registry so that mistake doesn't happen again. But after some time, it found that the approach wasn't being emitted into compiled CSS properly. So it tried switching back to a more reliable approach, but then at the end of the day just brought it back to dark buttons. And it told me that Copilot has been working for a while and that it can continue to iterate, but maybe we need to refine the prompt. And then I figured that in this case it did it using Copilot because when we added this inspect element, it only works with VS Code's native chat application. But instead, we can copy this prompt and paste it as a corrective prompt directly into the codeex agent or whichever agent you used because this one already has all the info from our context and it should be able to fix it without necessarily pointing to it. It knows what the buttons are. So, this was actually a good experiment. Let's see how much more powerful this agent is considering that it has the context from before when we gave it the task to actually create this landing page. Oh, wait. It actually did it super quickly. It found that the homepage was styling CTA's ad hoc and it replaced that with the landing button primary and landing button secondary classes in globals. Updated it and now it looks great on the navbar as well as on the hero section and everywhere else where the buttons are being used. I think that's right here in the footer. So you can see that one corrective prompt, even without pointing to it with our finger, was able to immediately make a huge difference to our landing page. And that's it. The homepage is now done. The only thing that you need to do if you want to stay consistent with my workflow is to save the session before we move on. So open up your chat and simply run forward slash remember. What this does is it'll save only the most important parts of the session so that the agent can refer to them later on. For example, about the buttons not being correct. And how can you know exactly what got saved? Well, it's simple. You can just head over into the memory.md file which it now created. If we preview it in markdown, you can see right here that the current state is that the homepage is fully implemented and matches the design and it knows that the next session should start with the second feature of the phase one which is the authentication. Perfect. So in the next lesson, let's implement the O. Now, just before we start adding authentication to our project, let me introduce you to the tool that's going to be powering the entire back end of this project, including the O. It's called Ins. And if you haven't heard of it, pay attention because it changes how you build backends with AI. Ins gives your agent a complete backend in one platform that includes authentication, database, storage, edge functions, model gateways, real-time functionalities, and the vector search and embeddings. And all of it working directly with your coding agents, which makes it the perfect fit for this video and the workflow that I want to teach you. It's not retrofitted for AI workflows, but rather built for them from the ground up. What that means in practice is instead of your agent guessing how to wire up authentication for example or writing database queries against an API that it half knows ins ships with an MCP server. Your agent then connects directly to your backend reads live schemas manages tables and configures authentication based on all of these tools and knowledge that it has. That's the difference between a copilot and an agent that actually builds things for you from the ground up. And for our job pilot project, InsForge is going to handle everything behind the scenes, including the O, the entire database, resume storage, and all of it. It's a single platform, one connection, and no configuration that we have to manage ourselves. To start hooking it up, open up your agents, start a new chat, and run the remember command. This is the first time we're using it. Specifically, we want to say restore what it remembered before. This is only going to pull up the most important history so that it can use that data to do better work in the future. Now, before we go ahead and set up ins, go ahead and copy your entire agents.m MD file as it is and save it somewhere safe. That's because when ins writes its own instructions into agents and sometimes it may overwrite your custom content and we need that content back after the setup. So, make sure to copy everything that is in here. Then head back over to InsForge. I'll leave the link down in the description that you can click on to follow along and see exactly what I'm seeing and start building today. You can log in through either GitHub or Google. And when you're in, you can create your project. You can start with JSM call it something like job pilot or maybe your own name and choose the region that is closest to you. Once you create it, it's going to load the interface and you can either install it through the CLI or you can install it in agent mode. You can proceed with the CLI or select any of the agents here. I'll go ahead and click install on the codeex part since that's what we're using. It'll give you the option of the CLI. So, you can simply copy and paste this or an MCP, which is what I want to teach you how to implement. Simply copy the installation prompt. Open up a new Codex chat and simply paste what you copied. I'm using InsForge as my backend platform. Please run this command to install the Ins MCP server. And I believe for this the medium reasoning model is going to be fine. And I'll be using GPT 5.5. This should do the trick. It'll now install the Ins MCP server with the exact command we provided. Now it said that the install command failed in sandbox because network access to mpm is blocked. So we can either run it manually or we can approve the permissions. So I'll say approve and it'll try it once again with these added permissions. Either way is totally fine. The next step is to restart the coding agent to check whether it has been installed properly. So to verify the connection we can simply start a new session and tell it something like I'm using ins as my backend platform call ins MCP's fetch docs to learn about ins and now we can see whether it'll actually call the ins mcp and confirm the connection. You can see that right here fetch docs. There we go. And it has the full info. Now open up the agents.mmd file. You can see that ins added its own contents into the agents.mmd file. Thankfully, I told you to copy your previous agents.mmd. So, we can still bring it back. So, right on top of the insk documentation, you can bring back what was previously within your agents.mmd. These instructions are important because they tell the agent how to use the backend. Your custom instructions tell it how to build this specific project, but both need to be here. Neither replaces one another. So now with ins set up we are ready to implement authentication. Go ahead and open up your agent by heading over to codex and within a new chat we can tell it something like check the progress tracker and also the build plan right because there we listed everything we want to do. then use the INSF forge MCP to fetch the latest ins documentation before we start implementing O. So again, you'll see me ask it to pull all the data together before it starts implementing things so that we know it's going to do it in the proper way. It'll read the progress tracker to figure out where we are right now in the process of developing the project. Then it'll check out the build plan to know what it needs to build next and finally fetch the ins docs via the MCP. So notice what's happening here. The agent is checking where we are in the build, what the O requires, and then pulling live ins documentation through an MCP, not some outdated data. So now it's going to confirm the build plan. The next feature is O covering UI, Google GitHub, OOTH, callback handling, and so on. It has the latest ins docs and the only thing you have to do now is to say something like start or go ahead given all the context we have that's enough to spin it up and give it the permission to start developing the feature O2 in this case O since this one touches routing middleware client server boundaries and the login UI it's going to use the architect skill to form the blueprint it knows that it has to be a custom ins flow and it pulled the latest nextGS6 16 docs where it noticed that middleware was replaced with proxy. Since most of the codebase online has been written with older versions of Nex.js, if we didn't have these very detailed instructions on pulling the latest docs and using them, it is highly likely that the agent would have used the older version of the middleware and placed it at the wrong spot, therefore breaking the app. But since we have all of this setup done, it did it properly. So, let's give it some time and see the implementation. Feel free to pause the video um as this actually took 8 minutes for me on medium reasoning. But yeah, after 8 minutes or so, it implemented the full O feature includes the insk O setup, the OOTH start routes with Google and GitHub, server routes for OOTH callback exchange, refresh and logout routes, Nex.js 16 route protection via proxy. So definitely make sure that you have a proxy right here in the root of the application and not a middleware file because this changed in next.js version 16 and our agent caught it. Added login UI which we'll check out soon. Minimal protected placeholders and it updated the progress tracker and UI registry. We also have to add thev file to our application because currently doesn't exist. And in there we have to add the next public ins URL and ins add an add-on key. So, let's do that right away. We don't want the agent to handle our environment variables. We're going to do it ourselves by creating a new.env.local. Heading back over to our ins dashboard under install at the bottom there's going to be API keys. It's always great to fetch them in case we need to use them later on. So, I'll look at the project URL. That's going to be ins project URL. And after that we'll have the next public ins URL as well as the next public inson key. So prep both of them and then simply paste the keys you can get directly from the dashboard. We can revisit this later on in case we need to update them. But yeah, let's go ahead and check it out. If you head over to your localhost 3000, either open it locally or you can open it up in your browser. Click get started and it'll redirect you to this beautifully designed authentication page. And now one thing that I want to point out here is that we never actually gave it a design for the o page itself. Keep that in mind. We did give it a design for the landing page and that included some primitives, some assets that it can use and the general idea of where we want to take the design of this application. But off page we didn't give it a design for. And take a look at just how polished and on brand this looks like. But now the big question is can we actually log in? I'll go ahead and proceed with Google. And it says we could not start that signin method. Please try again. And I'm actually super glad this happened because I get a chance to show you another one of the skills that I created and that'll become a huge part of your workflow. It's called recover. So go ahead and open up the chat that you were within and in the same window use the recover skill. So when something goes wrong during build, it's going to diagnose the problem and fix it properly and not just lose its way around it. So in most cases, it's going to be just enough for you to pass the error message that you're seeing. But you can also add some additional context like authentication is not working properly. Press enter and just watch how it'll recover itself. figure out exactly what the issue is, diagnose the problem, and then make only one targeted change once the root cause is clear. Looks like failure mode one, a specific thing is broken. And it was able to find it within a second. Root cause next public ins for URL is set to an IK key value, not the ins backend URL. So, we have to make the next public ins for URL this one right here. So simply head over into ourv and make sure that the next public infford URL is set to an actual URL and not a key that I had right here. This was on me, but again I'm glad to show you just how powerful the recover skill is. So once you fix the envitize and you'll be redirected back to your profile. Currently there is nothing there but just the fact that we are logged in is perfect. You can go ahead and log out if you want to. That's working as well. Now, if you go to the profile, it's going to bring you back to the O. And once again, you can just log in. And that's it. We're in. So, now that we know that the feature has been implemented properly, we can make use of another skill called review. So, after building a feature, we want to verify that it matches what was planned, respecting the system architecture and design standards, and is ready to proceed. The skill is super quick, less than a minute. It gives us back the findings. The critical one that oath wasn't able to start without the proper env. That's on me. Uh that the O route handlers do not follow the required error handling. Okay. Do not wrap the route logic in try catch as project standards require every route handler to catch log errors and return human safe responses. The ooth buttons use a link to sideffecting API routes. In production link behavior can include pre-fetching, navigation optimizations, side effects and so on. So that's something that we can fix. So it found the issues. The plan pieces are mostly present. Login UI, Google GitHub oath routes and so on. Some issues that we've seen. So now before we move on to implementing the next feature and you can see it already knows what it is because of our context files, we can tell it to fix it. It quickly noticed that we fixed the env issue oursel and then it also fixed the following review issues and updated the UI registry for the button and the pattern. So that's great. We'll need to restart the Nex.js server to pick up the corrected env. But yeah, now that everything is done, I also want to run the imprint skill. So after building any UI components, we want to extract the visual patterns that matter for consistency and save them to the UI registry. In this case, it looks like it already updated the UI registry, but just in case it missed some stuff while doing the review, I'll run this skill manually. And in about 10 seconds, it imprinted the login card. So, the final thing we need to do is run the remember skill to save what matters at the end of the session because this was a good one. And you can also run save. And finally, it saved it all in the memory. So that in the next session, we can simply run remember restore to pick it up from here. Let's keep building. Now that we have the landing page, the auth page, I think this is the right point to start tracking what's happening within your application. Because that's the question that most developers never ask until it's too late. How do you know that your app is actually working the way you think it is? Not does it compile, but are users actually finding the jobs within the platform? Are they generating the cover letters or creating their accounts and profiles? Without that data, you're just guessing. And guessing on a product you just shipped is how you end up optimizing the wrong things. That's why I want to introduce Post Hog in this stack. It's open- source, built for engineers, not marketers. And it includes event tracking, funnels, session replays, feature flags, all within one platform. As we continue developing Job Pilot, you'll see exactly what it does, but basically it tracks every meaningful user action and it powers the three analytics charts that we'll show on the dashboard. Every job search, every cover letter generated, and every resume that we created for our users, and Posthog will capture it. So, let's set it up. Click the Post Hog link down in the description and create your free account if you don't have one already. You can choose your region and sign in with any platform that you prefer. If you're creating it for the first time, you need to create a new organization. You can call it something like JSM_. And then enter either your name or the name of your organization. And then also select your role. Most likely it's going to be an engineering. And if you have a second also you can say JavaScript mastery right here in where did you hear about us? So let's create the organization. and it's going to ask you what do you want to do with Post Hog. In this case, we want to understand how our users behave. That's the closest match to what we're building. We can turn on the product analytics, the session replay, the web analytics, and later on we'll be able to add all of this additional stuff as well. So, let's go. I'll say it out loud. Post Hog has the best iname setup wizard. You just used one single command and no matter which framework you use, it'll install and set up Post Hog and also add the initial event tracking specifically tailored to the application that you're building. So back within the application, you can open up a new terminal and run MPX-Y add post hog wizard at latest and you can also add the region. I'll expand this so we can see what's happening. It'll likely ask you whether you want to install the post hog wizard installer. And as it says, let's do 2 hours of work in 8 minutes. Directory recognized. Framework is here. And we want to do the post hog integration. So continue. It's going to ask us to authenticate within our browser. That was quick. And now on the left side, it'll keep telling us some stuff about the agent and how it works, like some helpful tips in a game while it's loading the next level. Here, it's not loading the next level, but rather analyzing our project and setting up its own tasks. First, it needs to plan which event it's going to track. Then, it needs to install Post Hog, initialize the Post Hog client, capture the events, identify users, and finally create the Post Hog dashboard. This is going to take a couple of minutes. So, go grab some coffee and pause the video and I'll be right back. And after the setup is done, it'll detect all of the agents we have. And it's asking us whether we want to install the Post Hog MCP server and plugin as well. I'll proceed with doing that and I'll do it for Visual Studio Code and Cloud Code. And we'll give it access to everything. Now, what this does is it allows you to just ask your agent plain text questions about some of the funnels or features within your application and then it can access all of the data from your Post Hog dashboard and make more intelligent decisions on implementing some things within the codebase. For example, you can ask it what are the top five errors in my project this week. is going to return it and then you can continue speaking with your agent to fix them or show me a full stack trace for the most recent crash and then propose a fix. You can go deeper across many different use cases, but yeah, definitely go ahead and install it. So now that Post Hog has been initialized, I'll head back over to our agent. We'll start a new codec session. We can tell it to use Post Hog to track some events within our current application. Even though we don't have a lot happening right now, it should be able to use the MCP and our current codebase and figure out a couple of things it can track already just so we can verify everything is working. The agent nicely understands that the current UI is still in the O foundation phase. So most of the approved business events don't have live workflows yet. It's going to add it just for initialization, user identify and reset, and a typed server tracking helper for the approved event names for the profile job flows later on. That's all that I need for now. And there we go. It added a couple of events that allow us to identify our users on logout or when they visit the dashboard and so on. So, let's quickly test it out by heading back over here. I'll sign out. I'll continue with GitHub one more time to log in. visit the homepage, the profile, the find jobs, and the dashboard. And back within the onboarding, you should be able to see installation complete. If for you, for some reason, it still says that it's waiting for some events to happen, what you can do is click need to set up manually, choose Nex.js, and then right here under the second step, you can manually copy the env.local. then restart the application, log out and log in one more time and switch a couple of pages. And at that time, it should say that it auto captured something new. Either way, you can click skip or next to continue setting up our configuration. I'll leave all of these three options turned on, such as auto capturing front-end interactions so that we automatically track clicks, submits, and more. I mean, a couple of years ago, I wouldn't know what to do with that data. But now that we have the AI, it can make sense of it. So, you're immediately getting so much more valuable info. Heat maps are useful if you can capture generally where people are clicking, moving their mouse, and scrolling to. And then also web vitals, super useful info to have. While we're here, you can also enable session replays because sometimes it might not be clear what's happening just from the clicks. If a user stops scrolling and just stares at one portion of the screen, you want to get in their shoes and see what they're seeing. That's what the session replays are for. So, I'll enable them, too. And finally, you can choose between one of the two free plans, either pay as you go, starting completely for free, giving you up to 1 million events, 5,000 session recordings, and 1 million feature flag experiments, or for now, you can just start completely for free. That'll bring you directly into your Post Hog dashboard. There's a quick start that you can start off with, but also under browse, you can head over into activity and check out exactly what is happening within your application. You can see that we're trying to identify some users. Those users are clicking the form and moving across our application. This is just the start. We've started collecting the data. But later on, as we implement some actual features of our app, we'll start making sense of the data. And the biggest help for that is going to be Post Hog AI. So stay with me. Let's implement a couple features together and then we'll come back to Posthog to show you how to truly understand what your users are actually using your app for and how you can improve it based off of the data that we're now tracking. Great work. Once that is done, you can get back to one of your agent chats and tell it that I've initialized PostHog using the Post Hog wizard. So review it by using the review skill and remember save what we did. That way we'll update our context and we'll be able to move directly to the next feature. And this is also a cool little tip that shows you that you can use multiple skills in the same prompt. This took less than a minute. It provided us with a review. Everything passed and it saved it to memory. So in the next lesson, let's focus on maybe the most important part of the app, and that is the database schema. The database schema is the foundation everything else sits on top of. If you get this wrong, you'll be tracing bugs all the way to bad column decisions you made at this point. So this is exactly the moment to use our architect skill before touching anything. So go ahead and open up your agent. And in this case, I actually want to switch over to cloud code to show you that these context files and the workflow that I'm teaching you is completely agent agnostic. I'll use something like sonnet on a high effort within it. You also want to make sure that you have access to the skills. So if you run something like remember, it needs to be there. If it's not, you can open up the terminal in a new window and run MPX skills add latest add JavaScript mastery pro skills. Add all five skills and make sure to add them for cloud code. Once that is done, you can run remember like this and say restore to restore the previous session. It'll automatically figure out what we want to do. Reading the memory file and project context to restore the session state. Perfect. Post hog got implemented wired up. And now we have to do the database schema. Now we can use the architect skill to tell it to architect the feature number four. It'll read all the relevant context files before it talks to us and produce a full implementation plan for the database schema, tables, columns, types, relationships, absolutely everything. And it'll give us that plan so that we can actually review it and tell it whether it's a go or a nogo. And pretty quickly, actually in 30 seconds, the agent came back to me and it looks like it wants to have a conversation. First, it's making sure that we're speaking the same language. Rowle security policy. I understand this as posgress RLS rule attached to the table that automatically filters every query to only the current user's rows using o ID. Users can never read or write another user's data even if they craft a direct API call. Is that right? Yeah, that is right. Authenticated access only. Yep, that is pretty clear. And then schema creation. Yep, this is exactly what we want to do against the ins posgress database not generating migration files. I think the reason why it's asking me all of these decisions is because I had not the plan mode, but I think I had the thinking turned on. It might not even be necessary. So for now, I'll simply tell it to proceed with suggested decisions and then it'll get the implementation plan and start working on it. There we go. This is a pretty hefty plan, 12 steps. Confirm and I'll start building. And I'm super glad it asked me to confirm because we installed the Ins MCP for Codeex. But to make it truly agnostic, you also have to install it for the other agent you're using. So back within InsForge, you can click install. Go ahead and choose cloud code which is the first version and you can do it either through CLI or MCP. Either way works. Let's do CLI this time. I'll just tell it I confirm. But before do the following and then paste what we have. So that way it'll get all the information about ins and it'll know how to set up our Ins database properly. The ins cli is now installed and linked and now it'll load the ins skills before proceeding. That's exactly what I meant when I said that Ins was built agentic from the ground up. So agents can work with it so naturally and build entire backend systems with o databases and more. There we go. Clean slate, no tables, no migrations. Let's proceed with the full implementation. I'm assuming this one will take a bit longer. So pause the video and I'll be right back. And after doing some thinking and implementing and then thinking and reading and writing it finalized the feature updated the progress tracker in the UI registry. So phase one with features from 0 to 4 for being the database schema are now completed. It updated the progress tracker and it applied the migrations. The backend through ins is now built. Four tables applied via CLI migrations. There is tables for profiles, agent runs, jobs, and agent logs. All of which are going to start making sense very soon as soon as we start adding the features. Only the authenticated users can perform operations and the rest of the stuff has been completed. Now, if you head back over to InsForge, specifically under database, you'll see four different tables, which means that all of them have been successfully created. The agent didn't write a migration file or configure a connection string. It created all four tables directly through the INSForge MCP. And that's what agent native infrastructure looks like in practice. Agent logs is going to be the agents paper trail. Like every step that it takes during a run will get written right here with info, success, warnings, errors. So if something goes wrong during a job search, this is where you find out exactly what happened and why. But again, that's going to start making more sense soon. agent runs. Every LinkedIn search the agent performs gets logged right here. Job title, searched, location, how many jobs were found, when it started and completed. This is how the dashboard knows what searches happened. Finally, the jobs, every job discovered or imported, match score, cover letter, specifically made for each user. That's the entire job hunting history in one table. And then there are the profiles. Every user's career data will live right here. Name, skills, experience, resume, LinkedIn contact ID. This is what the agent reads when it scores a job against you. And if you open up storage here, you'll see just empty résumés. Every ré operation in this app will read and write to this bucket. And since we can already see the four database tables and the storage bucket, that tells us that everything has been implemented properly. So you can run forward sl remember to use the remember skill and say save. It'll figure out that we wanted to use the remember skill and update the memory. So if you check it out, you'll see that the phase one foundation is 100% complete, features one to four, live ins backend has all four tables, 20 RLS policies, two triggers, and one private storage bucket types exists. No app level code touches the DB yet. That's going to start soon in phase two. And it says that these open questions from previous sessions haven't been resolved. I didn't consider them that important, but it's good that it's keeping track. So from the next lesson onward, we'll start focusing on the profile page UI. And considering that the phase one is now done, I think it's due time to actually push this code over to GitHub. So head over to github.com/new and create a new repo which you can call job pilot or whichever name you prefer. Then just create it. And you can push over to it by opening the terminal. And we can do this manually. And even though you don't have to do this manually, you can just copy and paste all that into your agent. Old habits die hard. So I'll say get init add dot get commit-m implement everything up to phase one get branch dash m main get remote add origin and finally get push u origin main. Perfect. Now, if you go back and reload, you'll be able to see your code appear right here. And I always like to clean it up a bit. So, you can hide the releases, deployments, and packages. Give it some topics such as agentic workflows because that's what we're working on right here. Later on, we'll be able to add the deployed version or deployed link of our application. And for now, we can give a quick description of the app. I believe our agent or the wrote that for us right here in the root of the application AI powered job search assistance for matching roles, tailored resumes and faster applications. You never know who's looking at your profile and it's always good to tidy it up a bit and to stay consistent. So now that the latest changes have been pushed, we are ready to start focusing on phase two of the application. Great job coming this far. And let's dive right into the phase two. If you head over into the build plan, you'll see that our database schema is done and we are ready to begin phase two, which is the profile page. Starting with the UI, you always want to separate the concerns. Do the UI first and then the logic second. So in this case, we'll first build a complete profile page with UI with mock data without save logic. Within the UI, the profile will need the attention banner at the top, completion percentage ring, missing field tags highlighted, and so on, connected account section, resume section, profile information form with clearly labeled sections, and then save profile button at the bottom. So, let's simply open up a new window. I'll head over to clot code, and I'll tell it to remember, but specifically restore what we remembered before. It'll read the memory file and restore our session. There we go. Now it knows exactly what we focused on. So the next thing we have to do is simply tell it to build a profile UI. And just so it stops asking these open questions, I'll say you can close the open questions. And then we can tell it to build the complete profile exactly as shown in the profile.png. That's going to be…

Transcript truncated. Watch the full video for the complete content.