How Senior Engineers Actually Build With AI in 2026 | Build a Full Stack Systems Architecture App

0:00It's 2026 and most of the senior

0:02engineers I know aren't really writing

0:05code anymore. They design the systems

0:07and let AI handle the implementation.

0:09And the gap between developers who can

0:11do that and developers who can't is

0:14dividing the industry right now. This

0:16app is what that looks like when you do

0:18it well. Real-time multiplayer SaaS, AI

0:21agents running in the background, full

0:23production code, and I didn't write a

0:26single line of it. An agent built the

0:28whole thing. And by the end of this

0:30video, you'll have built it, too. The

0:32same app, the same stack, the same way I

0:36did. And here's what makes this

0:37different from other AI build tutorials.

0:40I built this app using the exact

0:42methodology the app itself is designed

0:45to teach. Specs first, architecture

0:48defined, every feature planned before we

0:51start building. I've been doing this

0:52architecture work by hand before every

0:55serious project for years. And at some

0:58point, it hit me. I'm a developer. Why

1:01am I doing all of this manually when I

1:03could build the tool that does it with

1:05me? So, I did. This is Ghost AI, a

1:09real-time collaborative workspace where

1:11you describe a system in plain English

1:14and then AI agent maps it onto a shared

1:17canvas live. Your team edits the design

1:20together and when it's ready, the app

1:23generates a complete technical

1:24specification you can build from.

1:27Now, if you've tried building anything

1:29serious like this with AI, you already

1:31know the wall.

1:33The first few hours feel incredible and

1:35then a week later, the agent has

1:37forgotten every decision you've made,

1:39one new feature breaks three others, and

1:42the code base you were excited about

1:44just starts fighting you.

1:45That's not an AI problem. It's an

1:48architecture problem. And it's the same

1:50wall all of you are hitting in your

1:52careers where the senior dev advice

1:54online sounds great as long as you're

1:57already senior. The developers who win

2:00in this market aren't avoiding AI, and

2:03they're not handing everything over to

2:05it, either.

2:06They're learning to think like senior

2:08engineers, and then using AI to build at

2:11the speed of one. And that's what this

2:13video teaches. By the end, you'll know

2:16how to design a system before writing

2:19any code, how to use the six-file

2:21context system I write before every

2:24project, and how a senior engineer

2:27actually thinks when working with AI.

2:29Oh, and that six-file context system I

2:31just mentioned, I've packaged it into a

2:34free guide you can grab and use on any

2:36of your upcoming projects, not just this

2:38one. The link is down in the

2:39description. Next, the stack is Next.js,

2:43React 19, Liveblocks for real-time

2:46collaboration with agents, Trigger.dev

2:49for background work with AI agents,

2:51Clerk for auth and user management,

2:54Prisma and Postgres for data, Vercel

2:57Blob for storage, all production grade

3:00and deployed by the end of the video.

3:03So, one person with the right system can

3:06now build what used to take a team. And

3:09by the end of the next few hours, that

3:11person is you.

3:12So,

3:13let's build it.

3:17Before we open up a single tool, I want

3:19to spend the next 10 minutes on the part

3:22of the video that I think is most

3:24important, and that decides whether what

3:27you're building ships or falls apart in

3:30the third week. There's going to be no

3:32syntax and no code in this section.

3:35Rather, what I'm teaching you is the way

3:37that I think before I write a single

3:40prompt, and the way I plan a build

3:43before I touch the agent, and the system

3:46that I use to keep AI from drifting

3:48halfway through a project.

3:50So that by the end, you'll know the

3:52conversations to have before you build

3:55the six-file context system that turns

3:57an AI agent from a guesser into a

4:00developer who already knows your

4:02codebase,

4:03and how to break any project into units

4:06the agent can ship cleanly one at a

4:08time. So, if you've been frustrated by

4:11AI breaking your code,

4:13then this is the video that fixes it.

4:14The intro touched on something I want to

4:17sit with for a minute.

4:19You heard me say senior engineers a lot.

4:22And if you're early in your career, that

4:24framing probably hit a nerve. So, let me

4:27be direct about what I mean.

4:29The job market for developers right now

4:32is harder than it was 2 years ago.

4:35Some entry-level work has been

4:37automated. Clients who used to hire

4:39freelancers for straightforward projects

4:42are now doing it themselves. And a lot

4:44of people who learn to prompt without

4:47learning how to think are now flooding

4:49the market. So, if you're worried about

4:51that, you're not wrong to be worried.

4:54But the developers getting squeezed

4:56aren't the ones who learned deeply.

4:59They're the ones who learned just enough

5:01to execute without understanding the

5:03system behind it. That was always a

5:06fragile place to be.

5:08And AI just made that fragility visible

5:11faster.

5:12So, the way through is to learn the kind

5:15of thinking that AI cannot replace. The

5:18architectural thinking, the

5:20systems-level judgment, and then use AI

5:23to build at the speed of someone twice

5:25your experience. The clearer your

5:28understanding of what you're building,

5:30the better the AI output. Which means

5:32that learning properly isn't a waste of

5:35time in the AI era. It's the best

5:37investment that makes everything else

5:39possible.

5:41So, when I say things like think like a

5:44senior engineer in this video, I don't

5:46mean you need 10 years of experience to

5:48apply this.

5:50These are learnable habits and you can

5:52start building them today on this

5:54project. And here's something most

5:56developers outside of Big Tech don't

5:58really know. At Google, Amazon, and

6:01Netflix, before any serious project

6:04starts, engineers spend weeks writing

6:07documents and sometimes months.

6:10Design docs, one-pagers, RFCs, the

6:14format changes by company, but the

6:16principle is the same.

6:18Figure out what you're building before

6:21you build it.

6:22And senior engineers at these companies

6:24sometimes go months without writing

6:26production code. They're designing

6:28systems, making architectural decisions,

6:31reviewing what other engineers ship. So,

6:34software engineering has never really

6:36been about typing the most lines per

6:38day.

6:39It's always been about thinking clearly

6:41about what should exist before you build

6:44it.

6:45And AI didn't invent that discipline. It

6:48just made it the most important skill in

6:49the room. And that's the whole

6:51foundation for the spec-driven agentic

6:54development course that I've been

6:55developing for a long time now. So, if

6:58you want to stay up-to-date on how

7:00that's going and receive an occasional

7:01email where I share my thoughts at the

7:03current state of the industry, I'll

7:05leave the link down below so you can

7:06subscribe for the newsletter. But, let

7:08me immediately make it concrete in this

7:10video.

7:11Here are two different prompts that two

7:14different developers might write to

7:16build the same feature.

7:18The first one says, "Build me a SaaS app

7:21with authentication and a real-time

7:23canvas."

7:24And the second one says,

7:25"I'm adding a LiveBlocks room provider

7:28to the workspace route.

7:29Auth is already handled by Clerk

7:31middleware. The canvas uses React Flow.

7:35Room tokens should be issued only after

7:38verifying project membership. Wire the

7:41provider into the existing workspace

7:43layout without touching the sidebar or

7:45navbar. Both developers want roughly the

7:49same thing.

7:50But the second prompt reveals a

7:52developer who knows their auth layer,

7:54understands their component boundaries,

7:57and knows what should and shouldn't be

7:58touched. They've thought about the

8:00system, so they're communicating

8:02decisions and not wishes.

8:04So, the AI isn't smarter when it reads

8:07the second prompt. The developer is.

8:10And that is the difference between vibe

8:12coding and what I'm going to teach you,

8:14which is spec-driven development, which

8:17is also the premise behind that

8:19spec-driven agentic development course

8:21that I'm actively developing. Vibe

8:23coding focuses on the outcome.

8:26You describe what you want, let the

8:28agent run, and react to whatever comes

8:31out.

8:32For a weekend prototype, that's fine.

8:35But for anything you're going to

8:36maintain, it just collapses.

8:39New features break the old ones, the

8:42code base starts contradicting itself,

8:44and you spend more time untangling AI

8:46mistakes than actually building.

8:49Spec-driven keeps the thinking with you

8:52and gives the agent a system to execute

8:55against.

8:56You stay the architect and the agent

8:59becomes the implementation engine. So,

9:01how do you actually build that system?

9:03Because that's the part that nobody

9:05really teaches. It starts before you

9:07open up any AI coding tool, with a

9:10conversation. When I get an idea for

9:12something I want to build, I open up a

9:15planning AI, ChatGPT, Claude, or Gemini,

9:18whichever's on hand, and I talk through

9:20it. What does this thing actually do?

9:22Who uses it? What are the core flows?

9:25Where are the complex patterns, and what

9:26could go wrong?

9:28I push back on the answers and let AI

9:31pressure test my thinking until the

9:33system becomes clear in my head. This

9:36conversation is the work. It's what

9:38senior engineers do before they build,

9:41except they usually do it in their head

9:43or on a whiteboard. But, doing it with

9:45AI externalizes it and makes it faster.

9:49When the system is clear, you write it

9:51down. And that's where the six-file

9:53context system comes from.

9:54Not from sitting at a blank page trying

9:56to write documentation, but from taking

9:59the output of the architectural

10:01conversation and organizing it into

10:03documents that travel with the project

10:06for its entire life. For Ghost AI, I

10:09organized everything into one folder

10:11called context.

10:13Six files, and what matters is that

10:15before your AI agent writes anything, it

10:18already knows what you're building, how

10:20it fits together, what the rules are,

10:22and where things stand right now. That's

10:24what you're going to learn about in this

10:26video. But, very quickly, here's what

10:28each one of them does at a glance.

10:31The project overview covers what the

10:34product is, who is it for, the core

10:36flows, and what's deliberately out of

10:39scope.

10:40The architecture file defines the tech

10:42stack, the boundaries between layers,

10:45and the invariants the codebase must

10:47never break. The code standards keeps

10:50the agent consistent across every unit

10:52of the build with shared TypeScript and

10:55Next.js conventions. The AI workflow

10:58rules keep the agent disciplined,

11:00defining how to scope work and what to

11:02do when something needs a decision.

11:05The UI context holds design tokens and

11:08component conventions, so the UI stays

11:11coherent across every page the agent

11:13ships.

11:14And the progress tracker, which is the

11:16one most developers skip and most need,

11:19holds the current phase, what's in

11:21progress, what's complete, and the

11:23architectural decisions made along the

11:25way. It's the only file that actually

11:27updates constantly throughout the build.

11:30And it's how the agent picks up exactly

11:32where you left off in a single prompt.

11:34These six files are what make the

11:37difference an AI agent that drifts and

11:40one that executes. And you don't have to

11:42build them from scratch for every

11:44project. I've put together a free blank

11:47template of all six files with

11:49step-by-step instructions on how I

11:51generate them using AI for whichever

11:54project I'm working on. And it's not

11:56specific to Ghost AI. It works for any

11:58application. Click the link down in the

12:00description to get it so you can apply

12:02this methodology to your own project

12:04starting today.

12:06We'll open up each one of these and I'll

12:08walk you through what's actually inside

12:10in the next lesson when we set up the

12:12project architecture for real. But yeah,

12:14once these six files exist, the build

12:17runs in units. We're going to break down

12:19the project into specific scoped pieces

12:22before we start. Not vague phases like

12:25build a dashboard, but concrete units

12:28small enough to build in a single focus

12:31session with clear conditions for what

12:33done looks like. That means that

12:35together for Ghost AI, we'll map out the

12:38entire build. Each lesson will have its

12:41own spec file. The spec defines the

12:44goal, the design decisions, the

12:46implementation details, dependencies,

12:48and a checklist of what has to be true

12:51before the unit is complete.

12:53You write the spec in the same way you

12:55write the context file through a

12:57conversation with the planning AI.

12:59Then you give the spec to your coding

13:01agent in one prompt. Make sure to read

13:04that spec. Mark that unit as in progress

13:07in the progress tracker. Implement it

13:09exactly as specified without going

13:12beyond scope. The agent will read your

13:14spec, read your context file, and build

13:17against a defined system instead of

13:20guessing.

13:21You review it against the checklist and

13:24if it passes, you close the unit, push

13:26the code, and move to the next spec. If

13:29something's off, you write a focused

13:32corrective prompt, exactly what's wrong,

13:35exactly what you expect, fix that

13:36specific thing, and move on.

13:39That's the entire workflow, the same one

13:41I used to build Ghost AI, and the same

13:44one you're about to use to build it with

13:47me. Oh, and last thing before we begin.

13:49These files take time to write. The

13:52conversation, the architectural

13:54decisions, the unit planning, all of it

13:57is real upfront work. And a lot of

13:59developers skip it because they want to

14:01feel productive immediately. I mean,

14:04I've done that as well. So, you open up

14:06the agent, type a prompt, and start

14:09watching code appear.

14:10But, that's the trap. The time you save

14:14by skipping this is the time you lose in

14:17week three debugging AI output that's

14:20drifted away from anything coherent. So,

14:23do this work once, and you'll do it

14:25faster every project after. And finally,

14:28it's time to build.

14:32Okay, enough talk, and let's build.

14:36Open up your desktop and create a new

14:38folder. Call it something like Ghost AI,

14:42and then simply drag and drop it into

14:44your favorite code editor. For this

14:46video, I'll be using VS Code as we have

14:49the file explorer on the left side, we

14:51have the code in the middle, and then we

14:53have the chat window which you can open

14:55up by pressing command shift P, and then

14:58just search for chat. Or, I think it's

15:00just command shift I to open it as well.

15:03No matter which agent you're using, is

15:05it Copilot, Claude, Codex, or whatever,

15:07the interface is more or less the same.

15:10This is how it looks like on Codex, and

15:12this is just general chat.

15:15So, this video is completely agentic

15:17tool agnostic. The thinking and the

15:20specs are what matters. The tool is

15:23completely your call. I'll personally be

15:25using Claude code as that's what most

15:27people are using and what's we're using

15:29internally within JSM. If you want the

15:31budget option, you can go with Codex.

15:34There's the Go plan, which is super

15:35cheap, the plus plan, which is also

15:37cheap, and I think they're also offering

15:39a month for free. And if you're already

15:41paying for something like Cursor, Win

15:43serve, or any other AI agent, just use

15:46that. I'll make sure you don't spend a

15:48lot of tokens, no matter what you're

15:49using, and that you learn a ton. Okay,

15:52so let's get started.

15:54We'll start with a fresh Next.js

15:56project. I'll do this manually with no

15:58prompts and agents.

16:00It's just a single command and it takes

16:02a couple of seconds and that'll give us

16:04a clean and predictable foundation to

16:06build everything else in top of. So,

16:08simply open up your integrated terminal

16:11and run MPX create next app at latest

16:15dot, which is going to create it in the

16:16current repository. It'll ask you

16:18whether you want to install the Next.js

16:20installer, so you can just say Y, yes,

16:22and proceed.

16:23And I also want you to know that you

16:25don't necessarily have to follow along

16:27by using Next.js.

16:29Of course, the majority of the context

16:31for AI agents we'll be working with is

16:33going to be featured around Next.js, but

16:36if you want to build this in TanStack,

16:38Angular, Vue, or anything else, the

16:40concepts will still be as valuable.

16:43So, let's just say Y for now. It's going

16:45to ask you whether you would like to use

16:46the defaults, so just press enter,

16:49which is going to install React,

16:51TypeScript, ESLint, Tailwind CSS, and

16:54the app router. Let's give it a moment

16:56until it finishes. Once the installation

16:58finishes, we need to clear out the

17:00default boilerplate.

17:01That's going to be within app and then

17:04page. Next.js ships with a lot of

17:06placeholder content that, honestly, we

17:08don't really need. Now, you could go

17:11ahead and clean it up manually by

17:13opening up your globals.css

17:15and cleaning everything besides the

17:17Tailwind CSS directives, deleting some

17:20SVGs and other stuff within the public

17:22folder, and replacing the page.tsx with

17:25a minimal component.

17:27Or we can use this as our first

17:29interaction with the coding agent.

17:33So, go ahead and open up your agent of

17:35choice. I'll just press command shift I

17:38to open up my chat sessions. And what I

17:40love about VS Code is that it's not

17:43shying away from the agnostic approach

17:45to agents.

17:46You can use their agents right here,

17:48such as Copilot CLI,

17:51or if you head over to extensions and

17:54then install an extension like Claude

17:56Code,

17:58which has like 12 million downloads, or

18:01something like CodeX, which has 8

18:03million downloads,

18:05and I installed both, you can actually

18:07just navigate over to them by selecting

18:10additional views,

18:11and then choosing the extension you

18:13want. Of course, alternatively, you can

18:15also just run all of these agents within

18:17the CLI by typing Claude, and you're in.

18:21For the longest time, I've been using

18:23Claude CLI, but the Claude VS Code

18:26extension recently got so much better,

18:28and honestly, it's working the same way

18:30as the CLI does, but with a bit of a

18:32nicer UI and a graphical interface that

18:35allows us to use it in an easier way.

18:37So, that's what I'll be proceeding with.

18:39I'll expand it so we have more space to

18:41work with, and you can notice that

18:43there's a little microphone button right

18:44here. So, you can either tap it or hold

18:47the command D key to speak into it. With

18:50CodeX and other agents, you can either

18:52type it manually,

18:53or what you can do is use a tool like

18:57Whisper Flow, not sponsored by the way,

18:59which is what I use to write prompts

19:02when I speak with agents. Speaking is

19:04just much faster. If you install it, you

19:06can just press the command key

19:09and start speaking into it. Like, clean

19:12up this Next.js boilerplate. Strip

19:15globals.css down to just the Tailwind

19:17directives. Delete all SVGs in the

19:20public folder, but keep the favicon.

19:23Remove page.module.css.

19:26Replace page.tsx with a minimal

19:28component that just renders a centered

19:31div saying Ghost AI.

19:34And I can stop it right here, and you

19:36can immediately see the output. Cool

19:38stuff, right? Go ahead and write

19:40something like this, and let's see how

19:42well Agent handles it.

19:43Also, just so we don't have to give it

19:46permissions every single time whenever

19:47we're doing something, for now I will

19:49say edit manually. Oh, and of course, we

19:52have to talk about the actual models

19:54we'll be using. In this case, we're

19:56using the default model, which is Opus 4

19:587 with a million token context, which is

20:00amazing, but you're going to hit the

20:02limits very soon. Instead, you'll be

20:04able to follow along this entire build

20:06with using Sonnet 4 6. It's fast, it's

20:10inexpensive, and it sometimes get lost

20:13unless you have the context files, which

20:16I'll teach you how to build so you guide

20:17it in a bit of a better way, and make it

20:20work much more like Opus does. So,

20:23that's what I'm going to select. If

20:24you're working with Codex, you can also

20:26go ahead and choose any model you'd

20:27like, like 5 4, 5 3, or anything else.

20:31Okay, let's give it a shot. It's going

20:33to think for a couple of seconds, read

20:35all the necessary files, and apply all

20:38four changes.

20:39Globals, just the import. Page, minimal

20:42centered Ghost AI component. Deleted

20:44five SVGs, but kept the favicon. And

20:47this file that I tried to trick it with

20:48doesn't really exist, so there's nothing

20:50to delete.

20:51You can see all the changes in the diff

20:53right here, and you can also see which

20:55files have been modified on the left

20:56side.

20:58There we go, just simple Ghost AI, and

21:01just the import for Tailwind. Which

21:03means that these classes right here

21:04should work to center the div. Before we

21:06run it, let's actually head over to

21:08package.json.

21:10Make sure that the project name is set

21:12to Ghost AI, and let's run it by running

21:15npm run dev.

21:18It'll run it on localhost:3000. So, if

21:21you open it up, you should be able to

21:23see something that looks like this.

21:25This means that our project is

21:26initialized, it's cleaned up, and now we

21:29are ready to move to the part that

21:31actually determines just how well

21:33everything goes. Setting up our context

21:36files and planning the build before the

21:38agent writes a single feature. So, let's

21:42do that next.

21:45Not that long ago, I talked about how

21:47senior engineers spend weeks designing

21:50systems before anyone writes a line of

21:53code.

21:54They write design docs, they define

21:56boundaries, and they make decisions

21:59early on so that everything else becomes

22:01predictable.

22:02So, let me show you how we are going to

22:04approach that.

22:06We're going to create a new folder right

22:08here in the root of our application,

22:10which we're going to call context.

22:12Everything inside of it is what your

22:15coding agent will read before it does

22:17anything. This is how it knows your

22:19project, and this is how it stays

22:21consistent across every session, commit,

22:24or unit of the build.

22:26So, you can switch multiple agents and

22:28share the context file with another

22:30developer so he can continue working

22:32with his agent from there. That's the

22:34catch. We're going to have a couple of

22:36different files within the context

22:37folder. Now, I don't want you to do a

22:40lot of copy-pasting, so I'll provide you

22:42with the final zipped context folder so

22:44we can easily review everything

22:46together. So, delete the context folder

22:48you just created. In the video kit link

22:51down in the description, get the zipped

22:53version of the folder, unzip it, and

22:55then just drag and drop it in.

22:57And here, you'll see six, well, seven

23:00different files with this agents.md.

23:02Might seem scary at first, but don't

23:05worry as I walk you through every single

23:07one of these files and show you how you

23:09can create them for yourself in the

23:10future. Let's start with the project

23:13overview. And let me walk you through

23:16why it's structured the way it is

23:18because understanding this is more

23:20valuable than just copying the file.

23:23Currently, we're looking at the markdown

23:25version of the file, but in VS Code, I

23:28believe this is done by default, you can

23:30also open the preview to the side by

23:32pressing command K and then V or just

23:34pressing this icon at the top and then

23:36you can close the actual MD and just see

23:38the formatted version. I think it's a

23:40bit easier to read this way. I typically

23:42open up these project overview documents

23:45with a one paragraph summary and then a

23:48numbered list of goals. This gives the

23:51agent the big picture immediately. So,

23:54when a requirement gets ambiguous 3

23:56weeks into the build and it will, this

23:59is where you resolve it. The agent uses

24:02this constantly to understand intent

24:05when a spec isn't specific enough.

24:08Notice the goals are concrete and

24:10measurable, not build a good canvas.

24:13Instead, let authenticated users create

24:16and manage architecture projects or let

24:19AI generate an initial architecture from

24:21a natural language prompt. The agent

24:24knows exactly what success looks like.

24:27And yeah, this is useful for us while we

24:29are going through the process of

24:30building the app. Just so you know what

24:32we are building. Just so everybody in

24:34the team, in this case me teaching you

24:36and you following along and you building

24:38it with me, are all on the same page. Go

24:42stay eye is a real-time collaborative

24:44system design workspace. Users describe

24:47a system in plain English and then AI

24:49agent maps that system onto a shared

24:51canvas. Collaborators refine the

24:54architecture and the app generates a

24:56technical specification document from

24:58the resulting graph.

25:00Okay, great. We have the overview, we

25:03have the goals, and then we have the

25:05core user flow. So, let me zoom this in

25:08and let's go through this together

25:10because this sequence matters. The agent

25:13can sometimes lose track of how features

25:16connect to each other.

25:17By defining a full flow from sign in to

25:21the spec generation, we make the logical

25:23sequence explicit. So, the agent won't

25:26try to build the spec generation feature

25:28on the login page because it knows the

25:30user has to create a project and the

25:32design architecture first. In the

25:34features, we get specific about

25:37technologies. And I want to take a

25:39second on this because the tools I chose

25:41for Ghost AI weren't random. I took a

25:44lot of time to choose what actually

25:46makes sense. Starting with

25:47authentication. For user sign in, route

25:50protection, project creation, ownership,

25:53and collaborator access, we're using

25:55Clerk. Could you have gone and created

25:57the full auth from scratch? I mean,

25:59sure, but it would take you a couple of

26:01days up to a couple of weeks to do it

26:03properly, even with AI.

26:06And when you do it, it's never going to

26:07be as secure as something like Clerk.

26:10And nowadays, the speed of shipping

26:12matters more than anything. If you have

26:15a specific product you want to push, you

26:17want to get it in front of potential

26:18users as soon as possible. And that's

26:20why for many of these agentic builds,

26:22it's just a no-brainer to plug and play

26:25Clerk into it. Especially considering

26:27just how well Clerk works with your

26:30agents. You can either just copy the

26:32prompt or use Clerk skills with

26:36whichever agent you're using.

26:38That way, it'll immediately become a

26:40professional developer at using Clerk

26:42and it'll be able to implement it within

26:45any project. And there's also the MCP,

26:48which is a server that allows AI agents

26:51like Claude,

26:52or others

26:54to access Clerk as the case snippets and

26:56implementation patterns, and basically

26:58implement everything for you. Oh, and

27:00not to mention that Clerk CLI is also

27:03being worked on. You'll just be able to

27:06ask your agent to use the Clerk CLI to

27:08add auth to your app, allowing you to

27:10not even have to leave your terminal or

27:12copy and paste any API keys. Clerk right

27:14now really is the leader in agentic

27:17development. And with a completely free

27:19pricing of up to 50,000 monthly

27:23recurring users, it's a no-brainer for

27:25me to build all of my applications with

27:27it. So, while we're here, I'll leave the

27:30link down in the description. You can

27:31click it, and then sign up so that we

27:33can very soon more easily get started

27:35with building. Okay, on top of auth, the

27:38most important part of our application

27:40is the collaborative canvas.

27:42And in this case, I wanted to make it

27:45real-time. So, for any kind of canvas,

27:47it makes sense to use React Flow. And if

27:50you want to make any part of your

27:51application live with cursors, so you

27:54can see what other people are doing,

27:55presence indicators, and node or edge

27:58editing, I mean, it just makes sense to

28:00use Liveblocks. Liveblocks is the leader

28:03for anything multiplayer, but not only

28:05apps, agents as well. Let me show you

28:08what I mean.

28:09I mean, this is the app without

28:11Liveblocks, and then if you add it, you

28:13immediately get live avatars. You can

28:16get the AI chat to generate something,

28:19and you can also leave comments and

28:21track what people are doing within your

28:22app, which is super useful for the

28:24collaborative canvas we're building.

28:26But, what's even cooler is interacting

28:29directly with AI assistants to do

28:32something within our application. I

28:33mean, if you try to build all of this

28:35from scratch, it would definitely take

28:37some time. But, with their AI assistants

28:39feature, you can just watch an AI do it

28:42for you. Oh, and this whole React Flow

28:44thing you're seeing, that got released

28:46recently, which means that in this

28:48video, we're building the latest stuff

28:49out there. Oh, and like Clerk and the

28:52many other amazing dev tools that are

28:54adapting to agentic development,

28:56Liveblocks also offers the agent skills,

28:59which you just have to install, and your

29:01agent will immediately know what it has

29:02to do to make the Liveblocks integration

29:05work. I'll teach you about all of that

29:07as we continue with the build. After the

29:09canvas, we have the starter system

29:11design, which I decided to have because

29:13it's very difficult for people to start

29:16with a blank canvas. So, I want to have

29:18some kind of a curated library of

29:20pre-built system design templates, where

29:23users can import a starter template into

29:25the canvas at any point during editing.

29:27But also, if the template doesn't do

29:29what you want it to do, we're going to

29:31allow our users to generate a system

29:33design from a prompt with AI. Then, that

29:37output will be structured as canvas

29:39nodes, and then we'll write it onto the

29:41canvas. And finally, we'll take a look

29:43at everything that is on the canvas, and

29:45we'll convert it into a technical

29:47specification in a markdown format. And

29:49then users will be able to view and

29:51download the generated specs. Oh, and an

29:54additional thing that I want to teach

29:55you is while we're generating stuff with

29:58AI, that'll obviously take time. As the

30:00user will likely provide a long idea of

30:03how they want to architect their app,

30:05and then the AI output is going to take

30:07potentially a minute or two. And running

30:10a more than 60-second AI generation call

30:13inside a Next.js API route will just

30:16time out in production. So, that's why

30:18I'll also teach you how to use

30:19Trigger.dev. It'll allow us to run

30:21background tasks that can run as long as

30:24they need to, with the retry logic and

30:26status tracking built-in. The way in

30:28which we'll combine Liveblocks and

30:30Trigger.dev is pretty amazing. So, we'll

30:33have to be very clear in letting our AI

30:35agent understand that it doesn't have to

30:37invent a custom web socket

30:39implementation when Liveblocks is

30:41already in stack, Or it won't try to run

30:44AI generation inside a request handler

30:47when trigger dev is defined as the layer

30:49for that work. Naming the tools we're

30:51going to use for the project in advance

30:53is crucial. Oh, and trigger allows you

30:55to do so much more. Recently, they've

30:57been diving deeper into allowing you to

30:59build and deploy AI agents, which is

31:01something we can explore in an

31:02additional video. But in this one, we'll

31:05also focus on many of its features,

31:07specifically running background tasks

31:09and reporting back to the front end. So

31:11while a long task is happening, we can

31:13keep the user updated on what's

31:15happening behind the scenes and allow

31:17the user to continue doing whatever

31:19they're doing on the application because

31:20we're no longer blocking the front end

31:22side while handling a specific task. So

31:24I'll leave a special link pointing to

31:26trigger as well as live blocks down in

31:29the description so you can create your

31:31accounts and then we'll be able to

31:32immediately dive into the development.

31:34Then we have the scope part which

31:36contains the in scope and out of scope

31:38features. And it's maybe the most

31:41important section for keeping your build

31:43focused. The out of scope section is

31:45doing serious work right here.

31:48Billing and subscription systems,

31:50enterprise permissions, version

31:51specification history and so on. This is

31:54telling the agent, don't even think

31:56about them. But we can add them later on

31:59after we build the base of our

32:00application. This is great because it

32:02keeps every session focused on what we

32:04are actually building.

32:06And finally, there's success criteria.

32:09Here, we define what actually matters.

32:12These are the benchmarks that your agent

32:14and you can verify against after each

32:17major feature lands. Not, does it look

32:19right? But, can a signed in user create

32:22and open up a project? Can multiple

32:24users collaborate? Can the graph be

32:26converted into a persisted markdown

32:28specification?

32:30Very simple, yet concrete.

32:33So that's our project overview. Written

32:35in a way that makes sense to agents, but

32:38also other team members working on the

32:40project. Next, let's take a look at the

32:42AI workflow rules. This file is

32:45different from others in a way that it's

32:48not about what we're building. It's

32:50about how the agent behaves when

32:52building it. And the most important rule

32:54right here is to work on one feature

32:57unit or subsystem at a time. We don't

33:00want to combine unrelated system

33:01boundaries in a single implementation

33:03step. And that single rule prevents most

33:06failures that the agents cause.

33:08Basically, all of these rules right here

33:10tell the agent, "Stay in your lane.

33:13Focus on one part of what you're doing,

33:15and then move on to the next one." After

33:17that, we have the code standards. So,

33:20you can open up that, and let's quickly

33:23take a look. This file is what keeps the

33:25code base consistent from our first all

33:28the way to the last chapter. Without it,

33:31the agent would drift away. Like,

33:33specific patterns that it uses for API

33:35routes when implementing feature five

33:37might look different from feature 16. Or

33:40maybe it's going to change some things

33:41regarding the TypeScript types, or how

33:43it uses Next.js, how it styles things.

33:46But here, we add that consistency. Like,

33:49we tell it, "Make sure to have strict

33:52mode enabled, and avoid using any." Or

33:54we're telling it to add use client only

33:57when the component needs browser

33:59interactivity. Or for styling, we're

34:01telling it, "No raw Tailwind color

34:03classes. Reference the tokens through

34:06the Tailwind utility names." I think you

34:08get the point. We want to stay

34:09consistent. Then, we have the UI

34:12context, which, as you can guess, dives

34:14a bit deeper into theming. Like, when I

34:17was initially coming up with a design

34:18for this application, I wanted to have

34:20something that is simple, yet functional

34:23and modern. And I spoke with AI a bit to

34:26generate this theme. Dark mode, no light

34:29mode, Uh, all colors are already

34:31defined, and we're telling the AI to use

34:34these colors.

34:35And again, if you're wondering how

34:37exactly I created all six of these

34:40documents by speaking with different AI

34:42agents, that's something that I'll cover

34:45in much more detail within the

34:47spec-driven agentic development course.

34:49So, you can join the waitlist in the

34:51description. But, I think you get the

34:52idea that I didn't just sit down and

34:54handpick every color in the file. I

34:56described the aesthetic that I wanted to

34:58AI, dark, technical, precise, something

35:01that feels like an engineering tool, and

35:04then I went back and forth on the

35:06palette, um, the token names, and this

35:08is what it came up with. Also, some

35:10font, border radiuses, and so on. That's

35:13exactly how you should approach your own

35:15UI. You don't need to be a designer, but

35:18you need to know the feel you're going

35:20for, and then AI can help you get there.

35:22Oh, and while the project overview gave

35:25some information about the project, the

35:28architecture context will give you the

35:30blueprint on how to build it. Here, I

35:32specified the tech stack,

35:35like every technology that we want to

35:36use, alongside the role that it has

35:38within the application. For auth, we're

35:40using Clerk for user identity and route

35:42protection. For databases, it's going to

35:44be Prisma and Postgres. For canvas, it's

35:47going to be Liveblocks and React Flow

35:50for real-time collaborative canvas.

35:52For background tasks, it's going to be

35:54Trigger.dev, and for storage, we're

35:55going to use Vercel Blobs. We also

35:57defined some system boundaries, like

35:59where we're going to put the request

36:01handlers. Trigger is what we're going to

36:03use for the long-running background

36:05jobs, and some other folders that we're

36:07going to use.

36:08Then, we defined the storage model,

36:10where and how we're going to save

36:12something. And specifically here, I

36:14decided to use a hybrid storage model,

36:16which is another senior-level decision.

36:18We aren't going to be stuffing massive

36:21JSON blobs or three-page markdown files

36:23into our database. Instead, we're going

36:25to use Postgres only for metadata and

36:28Vercel blob for the actual files. And

36:31this keeps our database lean. And this

36:33is important. We also need to tell it

36:35how different tools are working

36:37together.

36:38Since we're using Clerk with Liveblocks,

36:40we need to set a strict rule that

36:42project memberships must be verified

36:45before a Liveblocks token is ever

36:47issued. This ensures that our Ghost AI

36:50isn't just collaborative, but secure.

36:52And finally, invariants are the rules

36:55that the system must never violate. For

36:57example, request handlers do not run

37:00long-lived AI works. That belongs in

37:02background tasks through trigger.dev.

37:05Metadata and large artifacts are stored

37:07in separate layers. Auth and ownership

37:10are enforced at every mutation boundary.

37:12Client components only used when needed.

37:15And the canvas schema must remain

37:17consistent. Of course, we'll dive much

37:19deeper into this when we actually dive

37:21into building the application. But I

37:23wanted you to have a good idea of what

37:24it is that we're building. And finally,

37:26there's the progress tracker. This is

37:29the only file in the context folder that

37:31will look completely different by the

37:33end of this video.

37:35Right now, it is completely empty.

37:37Intentionally, because it reflects the

37:40actual state of the project. And right

37:42now, nothing has been built yet. So, as

37:45we complete each lesson, we're going to

37:47update this file. The current phase,

37:49what's in progress, what's complete, and

37:51what's coming next. And remember what I

37:53said in the beginning about agents

37:55having no memory between sessions.

37:57This file is the solution to that

37:59problem.

38:00At the start of every new session,

38:02whether that's tomorrow, next week, or 6

38:04months from now, one prompt is all it

38:06takes to restore full context. Our agent

38:10will read the progress tracker,

38:11understand exactly where the project

38:13stands, and pick up exactly where you

38:15left off. So, you don't have to

38:17re-explain yourself. Even though it's

38:19going to be a small file, it does more

38:21work than any other file in the project.

38:23Oh, and finally, there's the agents.md

38:26file. Within it, we're going to wire

38:29everything together. When you installed

38:30Next.js,

38:32that file was already created for you

38:34automatically at the root. This is the

38:36entry point file, and every major coding

38:38agent has one. They just name it

38:40differently.

38:41Claude calls it claude.md, Cursor, Win

38:44Surf, and others use different names,

38:46but the idea is always the same. It's

38:48the first thing that the agent reads at

38:50the start of every session.

38:52So, Next.js has already added the first

38:54section for you, and it tells the agent

38:56that this is a recent version, and its

38:58training data might be outdated, so read

39:00the install documentation before writing

39:02any code. Good default, and we can leave

39:04it, but now we can add our own part

39:06below it.

39:08So, copy your agents.md, delete it from

39:10the context, and instead move it right

39:13here. It's not long, so let's see what

39:16do we have within it. We're basically

39:17instructing the agent to read all six

39:20context files in order before

39:22implementing anything, and then to

39:25update the progress tracker after each

39:27change. And you might think, "Isn't this

39:29going to waste context and tokens?"

39:32Well, I mean, sure, it has to read

39:33through the files, but that's not even

39:351/10 of how many tokens you're going to

39:37save because there's going to be less

39:39back and forth, and less mistakes and

39:41bug fixing and correcting while you're

39:44implementing the features in the first

39:45place. So, that's the system. And now

39:48that you understand it, let's start

39:50building with it.

39:53Now that the context files are ready,

39:55before we build a single feature,

39:57there's one more thing we need to set

39:59up, and skipping this one is the most

40:01common mistake I see in AI-assisted

40:04projects.

40:05And that is the globals.css

40:08file.

40:09This one right here. We've defined all

40:11of our color tokens within our UI

40:13context right here. But, if we don't

40:16translate those tokens into actual CSS

40:18custom properties within the globals.css

40:21file, well, it'll just write the inline

40:23colors. So, instead of maybe saying

40:25something like text faint, it'll just

40:28write #505060.

40:31And the moment you want to change it,

40:32you have to change it across all places.

40:35So, let's set it up correctly. And this

40:36is also the first real demonstration of

40:39the spec-driven workflow in action. So,

40:42let's do it properly. Create a new

40:44folder inside side of the context folder

40:47and call it feature specs, like this.

40:51And then inside of it, create the first

40:53spec file.

40:5501

40:56design system.

40:59md. And then within it, we want to tell

41:01it something like read the agents file

41:04before starting.

41:06Then, we need to tell it what we're

41:07doing here, like adding the design

41:09system and the UI components.

41:12Then, we're telling it to install and

41:15configure shadcn-ui.

41:17And then we want it to add the following

41:20components.

41:21I figured we're going to use these

41:23across the rest of the application.

41:24Whenever we wanted to modify these files

41:27after the installation, so we can

41:29specify that.

41:30We can also ask it to install

41:32lucid-react for icons

41:35and create a lib-utils.ts

41:38with a reusable class names helper for

41:40merging tailwind class names. Although,

41:42I think it would do this by default,

41:44it's good to mention it.

41:46Finally, we want to ensure that all of

41:49the components match the existing dark

41:51theme within globals.css.

41:54And then, we want to apply some checks

41:56when it is done.

41:58For example, we want to make sure that

42:00all components import without errors,

42:02that the cn works properly, and that no

42:05default light styling appears. This is

42:08what we call a feature specification or

42:10a feature spec.

42:12Every unit we build from here on has

42:14one.

42:15The spec tells the agent exactly what to

42:18do, exactly what not to touch, and how

42:21to verify when it's done. No guessing.

42:24So, let's open up our agent by pressing

42:26command shift I. As I said, you can use

42:29anyone. I'll use Claude code.

42:31I'll start a new chat, and you can even

42:34open up that file, which will

42:35automatically put it within its context.

42:37And then, you can tell it something like

42:39read

42:41add 01 design system update

42:45the progress tracker MD file to mark

42:49this as in progress.

42:51And then, implement exactly as

42:55specified. This is the same template

42:57we'll use often, but the only thing

42:58that's going to change is going to be

43:00the spec of the feature we're

43:01developing. So, let's go ahead and run

43:04it, and notice what will happen before

43:06the agent writes a single line of code.

43:08It'll read the specification, and then

43:11update the progress tracker. You can see

43:14how it's going through all the files we

43:16prepared for it, and only once it has

43:18enough context, it'll write and save the

43:20plan, and then execute it. And only when

43:23it has a full plan, it will update the

43:25progress tracker.md, and then start

43:27doing it. So, we can already take a look

43:30at the progress tracker,

43:32and I'll open it up so we can see what

43:34it is doing. And you can see that the

43:35current phase is feature 01 system

43:38design, the current goal to install and

43:40configure shadcn with dark theme, and

43:43that is currently in progress with the

43:45feature 02 to be done. And it's also

43:48adding the architectural decisions

43:50needed for every step, as well as the

43:52session notes. It's going to ask us

43:54whether we want to run this command to

43:55install shadcn, so I'll say yes, go

43:58ahead. And after it installs everything,

44:00it'll verify it with TypeScript. It

44:03looks like it completed with zero

44:04errors, and finally, it needs to update

44:06the progress tracker to complete it.

44:09So, we can already open it up right here

44:12under progress tracker, and it should

44:14move it from current phase over to

44:16completed.

44:18So, now at any point in our application,

44:20if we come back 2 months later, it'll

44:23know that it's using shadcn, Tailwind V4

44:26with the following components, only

44:27using dark theme,

44:29and all the additional helpers,

44:31as well as the architectural decisions.

44:33So, once it finishes, the agent will

44:35have configured shadcn, installed the

44:38components, and verified that it all

44:39works. So, what do you say that we test

44:41it out?

44:42Back on localhost 3000, the first good

44:45sign should be that we're now officially

44:47in dark mode. And if you head over to

44:49the home page, that's going to be within

44:51app page, we can try to use a shadcn

44:54button component coming from components

44:57UI button, and we can try to make it say

44:59something like click me. You can see

45:01it's coming from there,

45:03and it follows our UI theme. That's it.

45:06Our first feature, being the theming and

45:09shadcn setup, is done. And that's the

45:11spectrum workflow I was telling you

45:13about. We define the specifications, we

45:16run the prompt, we verify the output,

45:19and then we move on. But just before we

45:21move on to our second feature, I want to

45:24add just one little extra step to this

45:26whole workflow that's going to make our

45:28codebase even more scalable,

45:30predictable, and less error-prone. And

45:33that is whenever we implement a specific

45:35feature, let's also review it with Code

45:37Rabbit. There's been a report that says

45:40that AI code creates 1.7 times more

45:42problems, which means that even though

45:44we're faster, we're producing more

45:46issues per PR. Also, the code becomes

45:50less readable, naturally, and the error

45:52handling isn't being done properly.

45:54Security also suffers. So, let's add

45:57that one additional line of defense.

45:59Let's review every single feature that

46:01we add to our project in the same way

46:03that biggest teams, such as the

46:04developers over at Nvidia, are doing it.

46:07I'll leave the link down in the

46:08description, so you can create your free

46:10account and follow along.

46:12You can log in with GitHub, and once

46:14you're in, you'll be able to see that I

46:15already gave it access to many of my

46:17repos. But first, we got to push our

46:19project over to GitHub. So, head over to

46:22github.com/new

46:24and create a new repo. You can call it

46:26Ghost AI.

46:30And just create it. Next, you can copy

46:32these commands one by one, or you can

46:35just copy all of them together,

46:37open up your agent, and paste it. Then,

46:39press enter. It's going to ask us

46:41whether we're going to allow it to stage

46:43all the changes. So, I'll say, "Yeah, go

46:45ahead." And it'll also allow all future

46:47commits, as that's going to help us

46:49speed up the workflow, as well as adding

46:51a remote, and finally push. You can see

46:54that the changes have been pushed

46:55successfully. So, if you come back and

46:57reload,

46:59you'll be able to see the current list

47:00of changes over on the repo. It's always

47:03good to make your project descriptive,

47:05so you can remove the releases,

47:07deployments, and packages, and add a

47:09short description,

47:10such as Ghost AI

47:13is an interactive systems

47:16architecture

47:19builder.

47:20We can route to the deployed website.

47:21For now, I'll just route it to

47:23jsmastery.com, and here we can put the

47:25different topics, such as Next.js,

47:28React, My Blocks, Clerk, Trigger.dev,

47:33and even Code Rabbit, which we'll be

47:34using for reviewing your code. And I

47:37like how AI always adds nice commit

47:39messages and not random gibberish that

47:41I'm used to. But yeah, now back within

47:44Code Rabbit, you can head over to add

47:46repositories,

47:47sign in, and give it access to all your

47:49repos. And then, when you're back, you

47:52can just find your project right here.

47:58Which means that it's automatically

47:59being tracked. So, as soon as we start

48:01adding the real features to the app,

48:03we'll be able to open up a PR for every

48:05new feature as we're developing within a

48:07large organization and then get it

48:09reviewed and only when Code Rabbit gives

48:11it a green light,

48:12merge it over to main.

48:16Now that our colors are in and the

48:18initial Shards and components are in as

48:20well, we are ready to start building the

48:22actual application. And the first thing

48:24that we need is the editor, including

48:27the top navbar and the left sidebar

48:29because they're the foundation of every

48:30feature we're going to build from here

48:32on. We're not yet touching off and we're

48:35not building this project creation. We

48:37just need to establish the layout so

48:39when these features come, they have

48:41somewhere to go. So, inside of feature

48:43specs folder, create a new file called

48:4602 editor.md.

48:49And within it, we're going to follow a

48:50similar structure we followed before. We

48:53want to start with explaining what we

48:55need,

48:56such as the base chrome components that

48:58frame every editor screen, the top

49:00navbar and the left sidebar shell. These

49:04will be reused and extended in every

49:06chapter that follows. Then, we need to

49:08focus on what are we actually creating?

49:11That's going to be the editor navbar.

49:14So, we wanted to create a new component

49:16within the editor editor navbar file

49:19and then we want to specify some

49:20requirements that follow. We want this

49:23navbar to be of a fixed height at the

49:25top. We want it to have both left,

49:28center, and right sections, which you

49:30can see right here. On the left, we open

49:32up the sidebar. In the middle, we have

49:34the name and on the right side, we have

49:36additional actions. That's exactly what

49:38we explained right here.

49:41And of course, it's going to be of a

49:42dark background with a subtle bottom

49:44border. Next, we want to explain what we

49:47want to do with the project sidebar. So,

49:49right below, we can say create a project

49:52sidebar component.

49:54It should float above the editor canvas.

49:57Opening it should not push the page

49:59content. So, you can see it remains

50:01where it is.

50:03And slides in from the left. It has the

50:05header that says projects and title and

50:08a close button right here. It can use

50:10the Shazian tabs component. And both

50:13tabs show empty placeholder state, full

50:16width new project button at the bottom

50:18with the plus icon. So, something like

50:20this. Oh, and finally, when we click

50:23create new project, we need this kind of

50:25a dialogue. A new pop-up that shows.

50:29So, for that, we can say something along

50:31the lines of

50:33dialogue pattern. Use the existing color

50:36tokens from globals for dialogue

50:37styling. It supports title, description,

50:40and footer action, but don't build any

50:42dialogues yet.

50:44We just want to create the component for

50:46it. Finally, to check whether it is

50:48done, we can check whether new

50:50components compile without TypeScript

50:52errors, no lint errors, and diagram

50:54pattern is ready for future use. So,

50:57hopefully, you were typing this out with

50:59me, or maybe you paused the screen and

51:01typed it with your own words. But, this

51:03course isn't at all about typing. It is

51:06about understanding what we're doing

51:08right here. So, if you don't really feel

51:10like typing, nor you should, in the

51:12video kit link down in the description,

51:14I'll provide you with all the prompts

51:17that we're going to use throughout the

51:18rest of this course. So, if at any point

51:20I'm going too fast when explaining them,

51:23and you just want to have it on your end

51:25and listen along, you can totally do

51:27that. But, yeah, let me quickly walk you

51:29through the structure because this is

51:31the template that every spec file in

51:33this project will follow. We start with

51:35a goal. One or two sentences, what does

51:38this unit produce when it is done? Then,

51:41we go over some specific design

51:42decisions. Is it visual or structural or

51:46something specific to the component like

51:48layout behavior, responsiveness, and

51:51this is where we can refer to that UI

51:53context file so that the agent isn't

51:55guessing the colors.

51:56Then we go over into implementation, and

51:59in this case, I decided to separate it

52:01into sections. So, we have the editor

52:03navbar, the project sidebar, and the

52:06dialog pattern, and finally the

52:08verification checklist. So, let's open

52:10up our agent. Whenever you're building a

52:12new feature, always open up a new chat

52:15and don't use one of the older chats.

52:17That's because we don't want some stale

52:19context lingering around. Only remain

52:21within the same chat when what you're

52:23about to do next is related to what

52:25you've done before, such as when you

52:27want to fix specific issues. You can see

52:29that it already has access to the editor

52:31file.

52:33So, I'll say, "Read this file and update

52:37the tasks on the progress

52:40tracker and then

52:43implement it

52:45exactly as specified."

52:48And press enter. And in about a minute,

52:51it's all done.

52:52It developed the editor navbar, the

52:54sidebar, and also the dialog pattern.

52:58TypeScript and ESLint both pass clean.

53:00Progress tracker also got updated. So,

53:03let's check the progress tracker first.

53:05It'll be right here within the progress

53:07tracker.

53:08So, if you check feature two completed,

53:12editor navbar and project sidebar both

53:15implemented. You can see them right here

53:17under editor, editor navbar, and project

53:20sidebar.

53:21We just created them so far, but they're

53:23not yet being used within the layout.

53:25And even though this wasn't part of the

53:27checks,

53:28I want to actually be able to see them.

53:30I want to tell it to use the navbar and

53:33the sidebar right now within the

53:34project. So, I'll open up the chat in

53:37the same context window and tell it to

53:39use these two components within a

53:41layout. And within a minute it put it to

53:44use. It even created a placeholder page

53:46so we can navigate over to the editor

53:49and check it out. So, head over to

53:50localhost:3000/editor,

53:53and you can see a canvas coming soon,

53:55but there is a top bar and a left

53:58sidebar, which opens up the projects.

54:01So, you can see that what we requested

54:03indeed got implemented. Since we're not

54:05yet at the point where we need that

54:06because we don't even yet have the

54:08editor, I actually want to show you how

54:10you can undo the changes, at least right

54:12here in Claude code. The only thing you

54:14have to do is press this back arrow on

54:16the message that you used to create

54:18these components, and then say rewind

54:20code to here. Which is going to bring us

54:22back and only give us what the

54:24specification wanted, and that is the

54:27components that we can then use and that

54:29compile, but we're not using them quite

54:32yet. Perfect. So, now that we have the

54:33navbar and a togglable sidebar, let's

54:36quickly check them out. The editor

54:38navbar is pretty straightforward, and

54:40the sidebar accepts some props such as

54:42is open and on close, and uses the

54:44Shadsy and tabs to modify what's being

54:47shown. But, when you're writing code

54:48yourself, you have a natural

54:50understanding of every decision you

54:52made. Heck, you wrote it.

54:54You know why a function is structured in

54:57a specific way or why you used specific

54:59props.

55:01But, AI-generated code doesn't come with

55:04that context.

55:05The agent made decisions that that were

55:08reasonable most of the time, but you

55:11didn't make them. And that means that

55:13reviewing AI output isn't optional. It's

55:16the step that keeps you in control of

55:17your own codebase. So, that's the

55:19perfect use case to test out the Code

55:21Rabbit edition that we added in the last

55:23lesson. I'll open up the chat and tell

55:25it to push all the current changes to a

55:29new branch called development.

55:31Typically, in real production databases,

55:33you often have multiple branches such as

55:36dev, staging, and only then main.

55:40So, for now, we want to push this over

55:41to the development branch, get it

55:43reviewed, and only if it's good, merge

55:45it over to main. So, by giving it this

55:47quick message, it'll run a couple of Git

55:50commands,

55:51figure out that we're currently on main,

55:53that we need to switch over and push to

55:55that new branch. And that's a little pro

55:57tip. Uh-huh, I mean, sure you could run

56:00these commands through the terminal, but

56:02I find it super easy to just stay in

56:04flow and tell the agent to push the code

56:07for me, which you can see it just did.

56:09So, if you head back over to your repo,

56:11you'll see that the development branch

56:13had recent pushes 3 seconds ago.

56:15So, let's go ahead and compare them and

56:17open up the pull request. We have 333

56:20new lines of code across five different

56:23files. So, Code Rabbit immediately

56:25hooked itself onto the PR, and we'll see

56:28whether it'll be able to pull out some

56:29bugs out of the hat.

56:31Let's give it a minute, and then I'll be

56:33right back. And we got back the

56:35walk-through, where it says exactly what

56:38we introduced in this project, such as

56:40two new React components for an editor

56:42UI Chrome, an editor navbar, and a

56:45project sidebar. These are super simple,

56:47as this was a simple review. Later on,

56:50these are going to get much more

56:51detailed, but yeah, let's check whether

56:54we have some potential issues even on a

56:56simple PR, such as this one. There's one

56:58major issue that says, "Hide the

57:01off-screen sidebar from focus order and

57:03assistive tech when closed." So,

57:05specifically, this is an accessibility

57:07fix, which is definitely a good

57:09implementation.

57:10Since we haven't yet utilized this

57:12component in our app, I'll leave this so

57:13we can add it later. There's also a

57:15minor issue, where the spec lists only

57:18the is open for the sidebar, but the

57:21implementation also requires on close.

57:23So, actually, it's suggesting to change

57:25the specification. This is interesting,

57:27because sometimes you're going to miss

57:29some stuff from the spec, and it's okay

57:31if AI tries to fix it or add some stuff,

57:35but it's equally as important for Code

57:37Rabbit to flag it. Because the whole

57:39reason why we're writing specs in the

57:41first place is so we can have predictive

57:43output. So basically, you can just copy

57:45this part right here, go back to your

57:47code base where we're saying accepts

57:50and then it's going to be is open prop.

57:52But we're going to say accepts both is

57:55open and on close props. Little change,

57:59I know, but now our code base is

58:01consistent with the spec. And that's it

58:03for this simple PR. As we continue

58:05developing more components, the reviews

58:07are going to get significantly more

58:09detailed. So for now, I'm going to go

58:11ahead and merge it, which means that we

58:13are ready to continue developing the

58:15next component.

58:18For this type of application, we don't

58:21really need a traditional homepage.

58:23Most tools like this drop you straight

58:26into the editor.

58:27You sign in from a simple sign in page

58:30and you manage everything from the

58:32canvas. And that's exactly what we'll do

58:34within our app.

58:36But we need auth, sign in, sign up, and

58:39other similar pages where you explain

58:41how your application works

58:43and then allow users to sign back in. So

58:46to get that set up, click the Clerk link

58:48down in the description and sign in. You

58:50can sign in with Google or GitHub. And

58:53once you're in, you can head over to

58:54applications and create a new app on the

58:57dashboard. You can give it a name such

58:59as Ghost AI and choose the sign in

59:02options

59:03such as email, Google, and since this is

59:06a development website, we can also do

59:08GitHub. Then click create application.

59:11We're building on Next.js, so what you

59:13can do is just install @clerk/nextjs

59:17by copying this command and paste it

59:20straight into the terminal.

59:22And while that is being installed, you

59:24can also set up your Clerk API keys by

59:27copying them from here

59:29and creating a new file called

59:31.env.local

59:34and then paste them right here.

59:35Now, before we hand anything over to the

59:38agent, there are two things you need to

59:40know about Clerk and Next.js 16

59:42specifically, because if you skip this,

59:45the agent will get it wrong. And it says

59:47it right here. If you're using Next.js

59:4915 or lower, name your file

59:52middleware.ts instead of proxy.ts.

59:56The code itself remains the same, only

59:58the file name changes. But, because most

1:00:00agents were trained on Next.js 14 and 15

1:00:03code bases, it'll almost certainly

1:00:06create a middleware.ts file by default.

1:00:09So, we'll have to specify proxy.ts

1:00:11explicitly in our spec so it doesn't

1:00:13have to guess. Oh, and another important

1:00:15thing is that just by adding middleware,

1:00:18it doesn't automatically protect all

1:00:20routes. As you can see right here, by

1:00:22default, it leaves all the routes

1:00:24public. And this catches a lot of

1:00:26developers. You have to explicitly

1:00:28define which routes are protected and

1:00:31which are public, which means that we

1:00:32have to configure everything

1:00:34intentionally. And this is exactly why

1:00:36reading the updated documentation before

1:00:38building with AI matters. The agent

1:00:41knows Clerk, not necessarily the version

1:00:43of Clerk you just installed or the

1:00:45version of Next.js you're running on.

1:00:46The spec bridges that gap. Oh, but we

1:00:49can also use agent skills.

1:00:52As I told you at the start, most major

1:00:54frameworks and libraries now publish

1:00:56official skill packages specifically for

1:00:58this problem. It gives your agent

1:01:00up-to-date knowledge, current APIs, and

1:01:03patterns, and the best practices of the

1:01:05library you're using. So, if you search

1:01:07on Google or within the docs, Clerk

1:01:09agent skills, you'll be redirected to

1:01:11this page. Then, simply copy the

1:01:14installation command,

1:01:15head back over to your code base and

1:01:17paste it in your terminal. npx skills

1:01:20add clerk skills. Press enter.

1:01:24You might need to install the skills

1:01:25package by saying Y and then enter. And

1:01:28then, by pressing the arrow up and down

1:01:30keys and the space key, you can select

1:01:33specific packages, such as core clerk.

1:01:36You can either select some additional

1:01:38clerk features or some additional clerk

1:01:40frameworks. Like in this case, I'm going

1:01:42to go with clerk next js patterns. And

1:01:46press enter.

1:01:48Then, you can select additional agents

1:01:50that you want to add it to. By default,

1:01:52it's going to work on codex, cursor, and

1:01:54anti-gravity. But, if you want to add

1:01:56Claude code, you have to select it here

1:01:58and press enter.

1:02:00And we can install it in project scope

1:02:02via symlink. That's the recommended way.

1:02:05So, just proceed with installation.

1:02:07Perfect. Our skill is installed and

1:02:09we'll be able to invoke it later on once

1:02:12we focus on implementing the auth

1:02:13functionality.

1:02:15So, now we are ready to write the spec.

1:02:19Open up your context feature specs and

1:02:21create a new file called 03 auth.md.

1:02:25And once again, the full feature specs

1:02:28files are linked in the description in

1:02:30case you want to just copy them and then

1:02:31follow along. Or, you can slowly type it

1:02:34out with me.

1:02:35Let's start by telling it that clerk is

1:02:38already installed and connected. So, we

1:02:40just need to wire it into the next js

1:02:42app, provider, auth pages, redirects,

1:02:46route protections, and the user menu.

1:02:49When it comes to the design, we just

1:02:52want to use the clerk's dark theme from

1:02:54the @clerk/ui themes as the base, and

1:02:57then we want to override the clerk

1:03:00appearance variables using the app's

1:03:02existing CSS variables.

1:03:05With no hardcoded colors. For the sign

1:03:08up and sign in pages, this is what we

1:03:11want to develop. On large screens, we

1:03:14just want to have a simple two-panel

1:03:16layout. On the left side, a logo, a

1:03:19tagline, and text-only features. On the

1:03:22right side, a centered Clerk form, and

1:03:25on small screens, forms only.

1:03:27We don't want to have any kind of

1:03:29gradients, as that's going to seem

1:03:30AI-ish. No oversized hero sections,

1:03:33cards, or scroll-heavy layouts. Keep the

1:03:36layout minimal and professional.

1:03:38And then we can dive into a bit more

1:03:40details on the full implementation.

1:03:43So, we can say

1:03:46wrap the root layout with a Clerk

1:03:48provider using the Clerk's dark theme.

1:03:52Create sign-in and sign-up pages using

1:03:54Clerk components. And as I told you

1:03:56before, we have to be specific in

1:03:58telling it that it should use the

1:04:00proxy.ts file name at the project root

1:04:03instead of the middleware.ts.

1:04:06And then, we have to define public

1:04:07routes using the existing sign-in and

1:04:10sign-up environment variables. Protect

1:04:12everything else by default. Which means

1:04:15that we have to update our home page so

1:04:18that when authenticated users visit it,

1:04:21we redirect them to the editor. Or when

1:04:24unauthenticated users visit it, we

1:04:26redirect them to the sign-in page.

1:04:29We also want to implement Clerk's

1:04:32built-in user button to the editor

1:04:35navbar right section for profile

1:04:37settings and log out. We want to keep

1:04:39Clerk's default user menu and profile

1:04:41flows intact and not rebuild heavily

1:04:44custom- ized Clerk internals, and want

1:04:46to use existing Clerk environment

1:04:48variables without renaming or inventing

1:04:51new ones. Finally, we can specify

1:04:54additional dependencies, such as Clerk

1:04:56UI, if we need to install it. And then,

1:04:59when it's done, we want to check that

1:05:00proxy file is there, that all routes are

1:05:03protected except public auth routes,

1:05:06auth pages use CSS variables with no

1:05:09hardcoded colors, Clerk provider wraps

1:05:12the layout and the build passes. This is

1:05:15our complete authentication

1:05:17implementation. Now, you know the drill.

1:05:20Go ahead and open up your agent,

1:05:22give it access to this file, and tell it

1:05:25to read this file and update the

1:05:28progress tracker.md file accordingly.

1:05:31Then, implement the auth feature exactly

1:05:34as specified in the auth.md file. Okay?

1:05:38You can see that the built-in microphone

1:05:40feature right here still isn't perfect.

1:05:42Let me try to do the same thing with

1:05:43Whisper flow specified in auth.md file.

1:05:50There we go. That's a bit better, and

1:05:52specifically it's 03.auth.md.

1:05:55Perfect. Let's go ahead and run it.

1:05:58First, it's asking me to run some bash

1:06:00commands to check whether Clerk has been

1:06:02properly installed, and we'll say,

1:06:04"Yeah, go ahead, you can run it." It

1:06:06took him about 2 minutes or so to go

1:06:09through all the context we shared, and

1:06:11only then it'll start to implement

1:06:13everything in parallel.

1:06:15And this is much better than if it

1:06:17started right away and then just ended

1:06:20up with a bunch of mistakes. So, the

1:06:21list of updates that it put right here

1:06:23is to update the .env.local with Clerk

1:06:26sign-in and sign-up URL vars, create a

1:06:29proxy with Clerk middleware route

1:06:31protection, update the app layout with a

1:06:33Clerk provider and dark theme, create

1:06:36sign-in and sign-up pages with a

1:06:38two-panel layout,

1:06:39update the app page to redirect based on

1:06:42the auth state, add the user button to

1:06:44editor navbar,

1:06:46and create editor page, and then update

1:06:48the progress tracker, and run npm run

1:06:50build to verify. It's going to ask me

1:06:53whether it has the ability to create

1:06:55some directories, and I'll tell it,

1:06:57"Yeah, go ahead."

1:06:58And in the future we can give it some

1:07:00more permissions so it can do things a

1:07:02bit more freely. And after it came up

1:07:04with the initial plan, it actually built

1:07:07out everything pretty quickly. Maybe

1:07:09even in less time than it used to think

1:07:12how to approach it in the first place,

1:07:13which shows you just how important the

1:07:16initial context and a proper task are.

1:07:19And there we go. The build passes, and

1:07:21here's the summary of everything that

1:07:23was implemented. I think all of these

1:07:25things right here shouldn't come as a

1:07:27surprise because we initially specified

1:07:30them in the spec. Then it updated the

1:07:33to-do's, and now it just did it. And

1:07:36yeah, it's pretty interesting that it

1:07:37even notes right here that it would have

1:07:39gotten confused about this middleware

1:07:41proxy thing if we didn't specify it

1:07:43properly. But thankfully, it did it in

1:07:46the right way thanks to the research

1:07:47that we've done at the start.

1:07:49So, what do you say that we take it for

1:07:51a spin? The application is running on

1:07:53localhost 3000, but whenever I make some

1:07:55bigger changes, I like to rerun it. But

1:07:58initially, if you head over to

1:07:59localhost, you might get redirected to

1:08:02this clerk handshake part, which is

1:08:04going to lead to a broken page. But

1:08:06after you reload, it should properly

1:08:09redirect you back to the homepage. And

1:08:11after that, it should just work.

1:08:14This is something that we can polish and

1:08:16fix up later on.

1:08:18But yeah, this is looking interesting.

1:08:20Definitely not quite as nice as the

1:08:23original application that I've showed

1:08:25you that's deployed.

1:08:26So, what are some of the things that we

1:08:28can do to make it look more similar to

1:08:31that one? Well, step one is to search

1:08:34some kind of design websites online like

1:08:36Dribbble or award-winning websites, and

1:08:39then just take a screenshot and try to

1:08:41get it to match to that closer. Or in

1:08:43this case, you can head over to the

1:08:45deployed version of this application,

1:08:48take a screenshot of this whole UI that

1:08:51you can see right here,

1:08:52and then we can feed it over into our

1:08:55chat. So, go ahead and open up the chat.

1:08:57Keep in mind that we can still stay

1:08:59within the authentication window that we

1:09:01worked on

1:09:02because now we're fixing some parts

1:09:04about that specific implementation. So,

1:09:06what you can do is just click this plus

1:09:08right here and upload from computer or

1:09:10just drag and drop the screenshot. Then,

1:09:13select it and then we can further point

1:09:15out to some things that could be

1:09:17improved, not just the layout. It seems

1:09:19like it didn't properly read the fonts,

1:09:22that the right side of the screen is

1:09:24taking a larger portion, so maybe we can

1:09:26split them 50/50, same as it is right

1:09:28here, and make the font size a bit

1:09:31larger. So, it's not just the layout. We

1:09:33needed to review the screenshot and

1:09:35update the UI of our current application

1:09:38to look more like the one on the

1:09:39screenshot. Means 50/50 left and right

1:09:43side layout with some kind of a color on

1:09:45the left side to differentiate it from a

1:09:47dark background,

1:09:49as well as we need to fix the fonts so

1:09:51that it uses the ones outlined in our UI

1:09:55guidelines. I think for now this is

1:09:56going to be enough for it to get closer

1:09:59to the design we want to get. So, press

1:10:01enter and let's see how it handles it.

1:10:03And there we go, the build passes, it

1:10:06updated the globals from circular font

1:10:08reference to the one that should be

1:10:10correct right now. The body was pointing

1:10:12at itself, so this font was never

1:10:15actually applied to anything. Same fix

1:10:17for the heading and it also implemented

1:10:19some other fixes. Let's check it out.

1:10:21The design now looks much closer to the

1:10:23finished product. The fonts are being

1:10:26properly applied and that makes a big

1:10:28difference. So does the increase in font

1:10:30size and this shift between the two

1:10:33different background colors. Of course,

1:10:35later on we can come up with a unique

1:10:37logo that we can put right here, but for

1:10:39now this is looking great.

1:10:41And believe it or not, we have a fully

1:10:44functional authentication system built

1:10:46in right here. So, what do you say that

1:10:48we go ahead and test it out? You can

1:10:50head over to sign up to see whether that

1:10:52works and it does. Later on, if you want

1:10:55to, you can modify the contents on the

1:10:57left side depending on whether you're in

1:10:59sign-in or sign-up page. And then let's

1:11:01use something like GitHub to sign in.

1:11:04I'll authorize it and the redirect

1:11:06redirects us to a page that currently

1:11:09breaks. So, I'll try to head back over

1:11:12to localhost:3000 one more time. And now

1:11:15when we get back, it actually redirects

1:11:17to the editor properly. You can see that

1:11:20we have the sidebar, we have a space for

1:11:23the canvas that's about to come in the

1:11:25future. And then on top right, we see

1:11:27all the information about our currently

1:11:29logged-in account, which is beautiful. I

1:11:31mean, we get complete user management

1:11:34within a single prompt that we've done.

1:11:36Let's also try to sign out for now, and

1:11:38we do get one issue when we click that

1:11:40button saying there's an unexpected

1:11:43response received from the server. So,

1:11:45if we head back over here and open up

1:11:47the terminal, we can see an unhandled

1:11:49rejection. Unexpected response was

1:11:51received from the server. And then in

1:11:53the terminal, we see something like

1:11:55this, which doesn't really tell us much.

1:11:58Now, what we could do is just copy this,

1:12:00open up the chat window one more time by

1:12:03heading over here, and then just pasting

1:12:06this error and telling it to fix it.

1:12:08But, I'm actually glad that this error

1:12:10happened because I can teach you a bit

1:12:12better and more precise way to handle

1:12:14these issues and so that when you try to

1:12:16fix them, you don't cause new ones.

1:12:19So, instead of pasting this right into

1:12:21the chat, we're actually going to open

1:12:22up a new file right here within context

1:12:26and call it current issues.md.

1:12:31You can even do it within feature specs.

1:12:33Either way works. Then, you can paste

1:12:35any kind of errors that you have and

1:12:37explain what's happening. So, I'll

1:12:39explain that when I click the logout

1:12:43button,

1:12:46the following error appears. And now I

1:12:49can paste this error message. And we can

1:12:51also specify that sometimes when we log

1:12:54in, we get redirected to this weird long

1:12:57URL, which doesn't show anything on the

1:12:59page.

1:13:00And then we can just paste this URL

1:13:03right here. Again, the errors on your

1:13:05end might be a bit different from what

1:13:08I'm seeing right here. Whatever they

1:13:10are, I don't want to teach you how to

1:13:12copy and paste. I want to teach you how

1:13:14to solve the problems for yourself.

1:13:16Explore the current issues file and

1:13:19deeply analyze the problem.

1:13:22Only when you have the analysis, give it

1:13:24back to me with the idea of how you're

1:13:26planning to solve it, and then wait for

1:13:28me to give it the green light to execute

1:13:31it. So yeah, writing something like this

1:13:33makes sense because that way it doesn't

1:13:35go into the spiral of trying to fix its

1:13:37own bugs while breaking 10 other things.

1:13:39You provided the error, it's going to

1:13:41come back with the analysis. You're the

1:13:43one deciding whether that analysis makes

1:13:45sense and whether it can actually

1:13:47execute it. So, let's run it and see

1:13:50what it comes back with. And after some

1:13:52thinking, it's back with the analysis.

1:13:55And this is so much better and so much

1:13:58more detailed than if we just told it to

1:14:00fix it immediately. Now, it actually

1:14:03tried it out and has a deep idea of

1:14:05what's happening. The server log is the

1:14:07key clue. Proxy took 373 milliseconds

1:14:11out of a half a second total request.

1:14:13Almost all time is spent in the proxy.

1:14:16So, that already points it in the right

1:14:18direction.

1:14:19As a human person, I would never figure

1:14:22this out on my own. At least not from

1:14:24such a vague error message. But yeah,

1:14:27here it figures out that this button

1:14:29needs an after sign out URL. So, it's

1:14:32just going to add it.

1:14:33And a similar thing is happening with

1:14:35the handshake URL. It basically needs to

1:14:38configure that after sign up URL, and

1:14:41that way it's going to route it

1:14:42properly. So, it provided a two fix

1:14:44plan. So, this looks plausible to me,

1:14:47looks good. So, let's just tell it to

1:14:50execute the plan and fix the issues.

1:14:52There we go. So, the fix now seems very

1:14:55apparent. We just needed this after sign

1:14:57out URL. And if you want to learn more

1:14:59tips and tricks just like this one about

1:15:02actually analyzing and fixing the errors

1:15:04and how I approach building these

1:15:06production level applications,

1:15:08definitely check out the spec driven

1:15:10agentic development course. It's not out

1:15:12yet as it's going to be super detailed

1:15:14and it's going to follow the best

1:15:15practices from the strongest developer

1:15:17teams out there. But yeah, it'll be out

1:15:19soon, but I'm still super glad that

1:15:21while I'm developing that, you can still

1:15:24learn how I develop these applications

1:15:26with the agentic ways with this new

1:15:28video that you're watching right now.

1:15:30And you can let me know down in the

1:15:32comments how you like this new type of

1:15:34video. I get that it's completely

1:15:36different from manual coding, but I

1:15:38still think there's so much to learn and

1:15:41we can have a predictable development

1:15:44workflow even with AI doing the writing

1:15:47for us. So, let's see whether this

1:15:49actually fixes it. And the build passes.

1:15:51The after sign out URL prop was removed

1:15:54from the user button as it belongs in

1:15:56clerk options and is set via environment

1:15:58variables. So, we'll soon be able to

1:16:00verify whether that actually fixes it.

1:16:03But before, I want to open up my

1:16:05terminal,

1:16:06stop it from running and then rerun it

1:16:08again on localhost 3000 because we

1:16:10changed the ENVs, so we want to make

1:16:12sure that they're read by the browser.

1:16:14So now, heading back over to localhost

1:16:163000, maybe you're signed in already,

1:16:18which is fine. You can simply sign out

1:16:20now and that brings us to another error,

1:16:23which is the same one we've had before.

1:16:25And another thing you can do is head

1:16:27over to inspect element, switch over to

1:16:29the application tab, and then clear all

1:16:32the cookies. So, find the cookies for

1:16:34localhost 3000, clear them, and then

1:16:36reload the page.

1:16:38You'll be redirected back to the home

1:16:40page and now we can retry with a clean

1:16:42slate.

1:16:43So, I'll sign in using GitHub the same

1:16:46way I did before. That works. I

1:16:48automatically get redirected over to the

1:16:50editor, which is great. And now, I'll

1:16:52sign out, and that worked. So, now head

1:16:55back over within your terminal,

1:16:57run git add dot, git commit {dash} m,

1:17:01implement auth, and then git push. This

1:17:04is going to push all the changes to

1:17:06origin development, allowing us to open

1:17:08up a pull request over to the main

1:17:10branch. Then, you can open up a PR, and

1:17:14let's wait for CodeRabbit to review it.

1:17:16This time, we had many changes, but not

1:17:19many of them are directly related to

1:17:21what we did in the code. We just added

1:17:23these agent skills so that everybody

1:17:25else's agents working on this code base

1:17:28also, well, become smart in the

1:17:30technologies that we're using for the

1:17:32project. And then, yeah, of course, we

1:17:34implemented a couple of different files

1:17:36that CodeRabbit will verify. But,

1:17:38primarily, what we've done is right here

1:17:41within app, sign in and sign up pages,

1:17:45we have added some features that would

1:17:46display on the left side. And then, the

1:17:48sign-in page, where on the right side,

1:17:51we just render the sign-in component

1:17:54coming from Clerk.

1:17:56Similar thing happens over to the

1:17:58sign-up page. So, right here, we're just

1:18:01rendering the sign-up UI.

1:18:03Then,

1:18:04over in the layout, we are wrapping

1:18:07everything with a Clerk provider,

1:18:09setting the theme to dark, and setting

1:18:11some custom variables. That's it.

1:18:14Everything else remains the same. And

1:18:15then, within the editor page, we are

1:18:18simply showing the nav bar and the

1:18:20sidebar, as well as the rest of the

1:18:22content.

1:18:23In the nav bar, we display the Clerk

1:18:26user button, allowing us to see more

1:18:27info about the user, and allowing us to

1:18:30log us out. Pretty straightforward so

1:18:32far. As our components and features get

1:18:34more detailed, we're going to do deeper

1:18:36dives into the code base, but so far so

1:18:39good. Let's wait for the review. And

1:18:41quickly we're back with a full

1:18:43walk-through. This pull request

1:18:45integrates Clerk auth into a Next.js

1:18:47application and establishes

1:18:49comprehensive agent skills for Clerk

1:18:52integration across multiple frameworks.

1:18:54It also adds auth middleware, sign-in

1:18:57and sign-up pages, Clerk provider setup,

1:18:59and introduces five new skill

1:19:01definitions for supporting scripts,

1:19:03documentation, and so on. So, obviously

1:19:06a lot of the checks right here from

1:19:08CodeRabbit are going to be about the

1:19:09skills that we set up, but we can skip

1:19:12those for now and focus on the ones

1:19:14about the actual files we implemented.

1:19:17In this case, it looks like there's one

1:19:19critical issue, and that is within the

1:19:21context current issues.md.

1:19:24Well, you never want to publish current

1:19:26issues to GitHub anyways, because you

1:19:28want people to see your code and not

1:19:30your mistakes. Um what we're doing here

1:19:33is even worse. We're exposing the

1:19:36handshake or the JWT token from the

1:19:38track docs. So, this is a real security

1:19:42issue. So, what we need to do is delete

1:19:44this file. Obviously, this won't delete

1:19:46it from the Git history, but that's fine

1:19:49for us because this JWT is no longer in

1:19:51use.

1:19:53So, right here over to getignore, I'm

1:19:54going to add our {forward-slash} context

1:19:58{forward-slash}, and that's going to be

1:20:00the current issues

1:20:03.md file.

1:20:05And I'll also remove everything that is

1:20:07within it.

1:20:09Not that it matters right now, because

1:20:10we're adding it to getignore anyway. So,

1:20:13let's go ahead and push those changes by

1:20:14saying get add {dot} get commit update

1:20:18{dot} getignore.

1:20:20And get push. Immediately the changes

1:20:23will be recognized, which means that we

1:20:24can merge this over to the main branch.

1:20:27And while we're here, we can also head

1:20:29over into context on the main branch and

1:20:32remove the current issues file right

1:20:34here from GitHub by simply deleting the

1:20:36file.

1:20:38And committing the changes.

1:20:40We can also do the same thing on the

1:20:41development branch by heading over to

1:20:43context

1:20:45and heading over to current issues, and

1:20:48just removing the file

1:20:50so that it's no longer here, and it's

1:20:51not going to be pushed to GitHub any

1:20:53longer because we added it to get

1:20:55ignore.

1:20:56Perfect. With that in mind, we've

1:20:58successfully implemented the full UI and

1:21:01functionality for the authentication

1:21:03within our application.

1:21:07Now that our authentication is done, and

1:21:09we can actually sign into our

1:21:11application, let's make the sidebar

1:21:14actually do something. As right now, it

1:21:16is just static. Before we hook up any

1:21:19real data, we need the UI in place.

1:21:22The create, rename, and delete

1:21:25dialogues, plus the editor home state.

1:21:27So, we're keeping this prompt focused on

1:21:29UI only with no API calls yet. Head over

1:21:33into context, feature specs, and add a

1:21:36new file called 04 project dialogues.

1:21:40Within it, we can specify that the goal

1:21:43is to build the editor home screen and

1:21:45add the project dialogues and sidebar

1:21:47actions with no API calls yet. So, what

1:21:51does this specifically mean?

1:21:52Well, it means that on the home page, we

1:21:54want to reuse the existing editor layout

1:21:58without modifying the navbar or sidebar

1:22:00behavior, but in the center of the page,

1:22:02we want to add a heading, create a

1:22:04project, or open up an existing one, and

1:22:07a description. Start a new architecture

1:22:09workspace or choose a project from the

1:22:11sidebar, and a new project button with a

1:22:14plus icon. Keeping the layout minimal

1:22:16without wrapping this content in cards.

1:22:19And then clicking new project should

1:22:21open up the create project dialogue.

1:22:23Let me actually show you what I mean by

1:22:26all of this by heading over to the

1:22:27finished version of the application, and

1:22:30quickly signing in. Notice how right

1:22:32here in the middle we have some text to

1:22:34greeting us, even though the canvas is

1:22:36empty, allowing us to create a new

1:22:38project, which then opens up this

1:22:39dialogue. That's exactly what we want to

1:22:42achieve.

1:22:43So, we'll have a dialogue for creating a

1:22:45new project, as well as for editing one,

1:22:48and deleting it. So, let's specify these

1:22:51three dialogues below.

1:22:53We're going to have one for creating a

1:22:54project that takes in the project name

1:22:57input, the live slug preview based on

1:23:00the name, and preview updates as the

1:23:02user types. Then, the one for the rename

1:23:05with pre-filled project name input, and

1:23:08the one for delete. Finally, on the

1:23:10sidebar, we want to add the following

1:23:13project item actions, rename and delete,

1:23:16show actions only for the projects that

1:23:18we own, and hide actions for the shared

1:23:21or projects belonging to collaborators,

1:23:23and on mobile, tapping outside the

1:23:25sidebar closes it, and want to add some

1:23:27kind of a backdrop scrim. Finally, let's

1:23:29specify the implementation right here by

1:23:32telling it to create a dedicated hook to

1:23:35manage the dialogue state, the form

1:23:37state, and the loading state, that way

1:23:39we can reuse the functionality.

1:23:41And then we want to wire the editor home

1:23:44new project to create dialogue, the

1:23:47sidebar create button to create dialogue

1:23:49as well, sidebar rename to rename

1:23:52dialogue, and sidebar delete to delete

1:23:54dialogue. For now, we only want to use

1:23:56mock project data with no API calls.

1:24:00And to check when it is done, we need to

1:24:03check that sidebar actions are wired,

1:24:05that slug preview works, that no

1:24:07TypeScript errors exist, and there's

1:24:09also no linting errors.

1:24:11So, let's open up Claude Code or your AI

1:24:14agent of choice,

1:24:16and then we can tell it to read this

1:24:19file, update the progress-tracker.md

1:24:22to mark this as in progress and then

1:24:24implement it exactly as specified. And

1:24:28let's run it.

1:24:29And in about a minute or so, feature

1:24:31four is done.

1:24:33Here's what's built. New file hooks use

1:24:36project dialogues, which centralizes the

1:24:38dialogue type, form, including the name

1:24:41and the slug, the loading state and mock

1:24:44data, which exposes these different

1:24:46functions to deal with the dialogues.

1:24:48Then there's the dialogue component, as

1:24:50well as within the project sidebar, we

1:24:53also call the dialogues when needed.

1:24:56So, let's quickly check this hooks file

1:24:58that it implemented. You can see that it

1:25:00is strictly typed right here with the

1:25:02project interface, the dialogue type, to

1:25:05slug, which takes in the name and turns

1:25:07it into a human readable ID,

1:25:09and it even created some mock three

1:25:11projects that we can verify.

1:25:13It came up with a lot of different use

1:25:15states, keeping track of all the

1:25:17projects, the dialogue type, the

1:25:20selected project, the name, slug, and

1:25:22loading.

1:25:23And all of these are going to be used

1:25:25within the dialogues themselves. Then it

1:25:27returns the data, so we can actually use

1:25:29them. Let's check where the dialogue is

1:25:31being used. Most often, it is right here

1:25:33within project dialogues,

1:25:35where we have the actual code for how

1:25:37the dialogue looks like. If the dialogue

1:25:40is of a type create, then we show this

1:25:42one. If it's of a type rename, we show

1:25:44this one. And if it's delete, we show

1:25:47the one below. Before we test it out,

1:25:49let's check out the progress tracker

1:25:51that says that the current phase is the

1:25:53feature four dialogues.

1:25:55It has the goal to do it. And it has

1:25:58actually completed the project dialogues

1:26:00with all of these different components.

1:26:02So, now if you come back to the editor,

1:26:04this is going to look much better. It's

1:26:06no longer just a blank screen, but

1:26:08rather in the middle, it says create a

1:26:10project or open up an existing one,

1:26:12start a new architectural workspace, or

1:26:14choose is project from the sidebar. And

1:26:16if you click create project, it actually

1:26:19opens up a new project dialogue where

1:26:22you can type something like my project.

1:26:26It automatically creates a slug at the

1:26:28bottom as well. And if you click create,

1:26:30you saw that creating loading.

1:26:33And of course, the data is currently

1:26:35static, but you can see how it's going

1:26:37to look once it actually picks the data

1:26:39from the database.

1:26:41So, we have Ghost AI Core, which you can

1:26:44select

1:26:45to edit its name

1:26:47as well as to delete it. This means that

1:26:50the UI for all of the dialogue

1:26:52functionalities has now been implemented

1:26:54alongside this centerpiece of the

1:26:56application, which means that now that

1:26:58the majority of the UI is done, in the

1:27:00next lesson, we can start focusing on

1:27:03implementing real data with a real

1:27:05database to make our app come to life.

1:27:08But before we dive into the database,

1:27:10let's make sure that our current code is

1:27:12good. And I want to show you another

1:27:14Code Rabbit feature allowing you to

1:27:16review your code directly within your VS

1:27:18Code, which means that you don't even

1:27:20have to create a PR and you can be that

1:27:22much faster. You can install the Code

1:27:24Rabbit extension, authenticate to your

1:27:26account.

1:27:28It'll notice the changes that you have

1:27:29right now, so you can just click review

1:27:32all changes. And the review will start

1:27:34directly within your editor.

1:27:37So, let's give it a minute. We'll check

1:27:39the changes and if they're good, push

1:27:41them. If not, we're going to fix them.

1:27:43And within a minute, the review is in

1:27:45and Code Rabbit left the comments

1:27:47directly on our code base. So, you can

1:27:49expand all the files and click on them

1:27:52to see exactly what's happening.

1:27:55For example, right here, specific

1:27:57confirmation message and project name

1:27:58display, the delete project dialogue

1:28:01lacks key detail. What text should be

1:28:03shown to the user? Should the dialogue

1:28:05show which project is being deleted? And

1:28:08should we show the cancel button as

1:28:09well? These are some important

1:28:11questions. And it's good because in this

1:28:13case Code Rabbit is telling us that we

1:28:15can be even more precise with our

1:28:17feature specifications. But, let's see

1:28:19if it has any comments within our code

1:28:21base. It says right here that the

1:28:22project item that is this one right here

1:28:25appears clickable, but it lacks

1:28:27interaction handling. It has a cursor

1:28:29pointer, that is this one right here in

1:28:31the sidebar, but when I click on it, it

1:28:34doesn't do anything. That's fine for now

1:28:36because later on we're going to make it

1:28:37open the actual canvas of that project.

1:28:40Since that is not implemented yet,

1:28:42that's totally fine. Then, another

1:28:44inconsistency, feature four is being

1:28:46marked as both in the current phase as

1:28:49well as finished right here at the

1:28:50bottom. So, we need to modify the

1:28:52progress tracker to say that the feature

1:28:54five is to be done. And then, and then

1:28:57modify the current goal to be determined

1:29:00for feature five. Next up, feature five.

1:29:03This is good. And finally, in the use

1:29:05project dialog hooks, we have a couple

1:29:08of comments as well.

1:29:09First, we have missing validation for

1:29:12empty slug edge case.

1:29:14If the user enters a name containing

1:29:16only special characters, it passes the

1:29:18truthy check, but returns an empty

1:29:20string, resulting in a project with an

1:29:22empty slug. So, if I head back right

1:29:25here and try to create something, take a

1:29:27look. It's true.

1:29:29I can actually create a new project, but

1:29:31nothing gets added to the slug because

1:29:33these are not valid slug characters. So,

1:29:36we definitely have to fix this.

1:29:37Thankfully, what we need to do is add

1:29:40slug validation.

1:29:42So, I'll just press accept right here

1:29:45and it'll update the code for me. That's

1:29:47another perk of using Code Rabbit within

1:29:49VS Code. And I think there is one other

1:29:51comment right here in this dialog, which

1:29:54is the same issue right here.

1:29:56Same as before, the rename operation has

1:29:58the edge case where the slug could end

1:30:00up empty. So, we definitely want to fix

1:30:02the validation there as well.

1:30:05Now, we can push the changes by saying

1:30:07get add dot, get commit {dash} m

1:30:11implement dialogues

1:30:14and then get pull to pull the latest

1:30:16changes and then run get push {dash}

1:30:19{dash} force to push the latest changes.

1:30:22Because remember, we deleted that file

1:30:24directly on GitHub, but still we want to

1:30:25push the local changes as well. So now

1:30:28if you want to, you can manually open up

1:30:30a PR by heading over to new pull request

1:30:33from the development branch

1:30:34over to the main branch

1:30:37and we can immediately merge it because

1:30:39we've already reviewed all the changes

1:30:41with Code Rabbit with their VS Code

1:30:43extension. So back within the

1:30:45application, you can run get pull

1:30:48and you can also check out to main and

1:30:50run get pull there as well

1:30:53to be up to date. But make sure to

1:30:55switch back to the development branch

1:30:56because that is where we're actively

1:30:58developing new features.

1:31:02Now that our project management UI is

1:31:04wired up, we need the actual database

1:31:06behind it. And for that, we're going to

1:31:08use Prisma with Postgres.

1:31:11If you prefer a different database, the

1:31:13process is the same. Just swap the

1:31:15provider in the schema.

1:31:17Prisma supports Postgres, MySQL, SQLite,

1:31:20and more. So let's start with a manual

1:31:23installation right here within the

1:31:24terminal. Stop the app from running and

1:31:27then run npm install Prisma tsx {at}

1:31:31types {forward-slash} pg {dash} {dash}

1:31:33save {dash} dev. These are the dev

1:31:35dependencies so that we have a nice

1:31:37development workflow. After that is

1:31:39done, you can install all the necessary

1:31:41packages needed for us to set up our

1:31:43database such as {at} Prisma

1:31:45{forward-slash} client, Prisma adapter

1:31:48pg, {dot} env, and pg itself. And press

1:31:52enter. After that is done, initialize

1:31:54Prisma with the correct output path for

1:31:57the Next.js router.

1:31:59You can do that by running npx Prisma

1:32:01init dash dash output, data slash app

1:32:04generated Prisma. This creates a new

1:32:07Prisma folder with the schema.prisma

1:32:10file and an ENV file at the root. So,

1:32:13head over to the Prisma dashboard. I'll

1:32:15leave the link down in the description

1:32:17and create a new account. You can sign

1:32:19in with GitHub or Google. And once

1:32:22you're in, you can create a new project.

1:32:25I'll call it Ghost AI and they'll give

1:32:28you a one command setup, but in this

1:32:30case we can proceed with the connection

1:32:32string.

1:32:33So, you can just copy it and then head

1:32:35over into your .env and override the

1:32:38current database URL with the new one

1:32:40that you just got from the dashboard. As

1:32:42a matter of fact, we can take this

1:32:43database URL and put it within the

1:32:45.env.local as that's what we're using

1:32:47for our environment variables. Then,

1:32:49open up your prisma.config.ts

1:32:53and update the path to the schema. It's

1:32:55just going to be prisma forward slash.

1:32:57We want to remove this schema.prisma

1:33:00because we'll make a separate Prisma

1:33:02model.

1:33:03So, just use prisma forward slash. Now,

1:33:06before we run our spec, let's also

1:33:08install Prisma Agent Skill. We did the

1:33:11same thing with Clerk, so the same idea

1:33:13applies. Just for a different library.

1:33:16Open up your terminal and run MPX skills

1:33:19add Prisma skills.

1:33:22It'll ask you which ones you

1:33:24specifically want to install and in this

1:33:26case you can select all of them. CLI,

1:33:28client API, database setup, Postgres,

1:33:31Postgres setup, and upgrade V7 and press

1:33:33enter.

1:33:35You can install them for cloud code

1:33:37within this project with simlink.

1:33:40And we can proceed with the

1:33:41installation. And now we are ready to

1:33:43generate our schemas. So, let's create a

1:33:46new file right here within our context

1:33:49feature specs

1:33:5105-prisma.md.

1:33:54And one sentence update is that Prisma

1:33:56is already installed, but we needed to

1:33:59add the project data models, Prisma

1:34:01client singleton, and the first

1:34:03migration. So, then we have to start

1:34:05specifying the models that we want to

1:34:07install.

1:34:09That we want to set up.

1:34:11First, we're going to have the project

1:34:13model.

1:34:14So, we'll ask it to add project that has

1:34:19to have an owner ID mapped to the Clerk

1:34:21user, a name, an optional description, a

1:34:25status enum, either draft or archived, a

1:34:28canvas JSON path for future canvas blob

1:34:31storage, timestamps, and indexes on

1:34:34owner ID and creation date. So, we can

1:34:36actually search through them. The second

1:34:38model we want to have is going to be the

1:34:40project collaborator, which is a project

1:34:43relation with cascading delete. It

1:34:46includes collaborator email, timestamp,

1:34:49and some constraints on the project and

1:34:51email, and indexes, so we can actually

1:34:54map over it. Do not add any extra fields

1:34:56unless required by Prisma. Finally, to

1:34:59be able to use these models, we have to

1:35:01set up Prisma client.

1:35:03So, create a lib prisma.ts file as a

1:35:07cached singleton,

1:35:08branch by database URL. If it starts

1:35:11with Prisma plus Postgres, then use

1:35:13accelerate, else direct to add Prisma

1:35:16adapter PG. In our case, it's going to

1:35:19start with Postgres forward slash, which

1:35:22means that it is actually hosted

1:35:24somewhere. Finally, we want to ask it to

1:35:27run the migrations and to generate that

1:35:29Prisma client, and want to verify

1:35:31whether it has installed all the

1:35:32dependencies,

1:35:34such as Prisma, Prisma client, Prisma

1:35:36adapter PG, and PG itself, and some

1:35:39checks are whether schema has both

1:35:41models with correct relations and

1:35:43indexes, the lib Prisma file exports one

1:35:46cached Prisma instance,

1:35:48the migration runs successfully, and the

1:35:50NPM run build passes. So, let's open up

1:35:54Claude Code, give it this file, and tell

1:35:56it to read this file, update the

1:35:59progress tracker, and implement it

1:36:01exactly as specified. I think you get

1:36:04the idea with these prompts.

1:36:06The actual spec file is doing the heavy

1:36:08lifting.

1:36:09So, let's see how it approaches it.

1:36:11It'll first read the Prisma spec,

1:36:14the progress tracker, the architecture

1:36:16context, and only then will it start

1:36:18implementing it.

1:36:20It'll first verify we have all the

1:36:22necessary packages, and it might even

1:36:24consult the Prisma skill. So, the agent

1:36:27does a better way implementing the best

1:36:29practices. So, let's give it some time,

1:36:31and I'll be right back. Now, it's in the

1:36:33process of creating the Prisma models

1:36:36for the project and the project

1:36:37collaborator.

1:36:39Then, creating the Prisma singleton, so

1:36:41we can actually have the client and run

1:36:43it. It's asking us whether we can

1:36:45actually run Prisma migrate. So, I'll

1:36:47allow it to run it.

1:36:50And then, it'll verify everything is

1:36:51done, and we'll be able to check it all

1:36:53out.

1:36:54You can see that we have many files

1:36:56changed, but once again, the majority of

1:36:58these are coming from the agents that we

1:37:00installed or the agent skills. The

1:37:02actual generated files that we care

1:37:04about are going to be within just a

1:37:06couple of files, such as this Prisma

1:37:08model right here,

1:37:10and this Prisma client. That's it. But

1:37:13okay, let's let it do its thing, and the

1:37:15feature five is done. Here's what's

1:37:18created, just two files that we need to

1:37:20take a look at.

1:37:21The first one is the project model, and

1:37:24the second one is the Prisma client. So,

1:37:27let's go ahead and check them out. I'll

1:37:28first open up the model that is going to

1:37:31be within models, project.prisma, and it

1:37:34looks like I'm missing the Prisma syntax

1:37:37highlighting. So, I'll head over into

1:37:39extensions and install Prisma, which

1:37:42would add the syntax highlighting,

1:37:43formatting, auto completion, and more.

1:37:46There we go. This now looks better. But

1:37:48yeah, essentially we have created a new

1:37:50model for the project with the ID, owner

1:37:53ID, name, description, status, the

1:37:56canvas, which is going to be attached to

1:37:57a project very soon, and a potential

1:38:00list of collaborators. And we also made

1:38:02it indexable so we can search for these

1:38:04projects.

1:38:05Same thing happens with the project

1:38:07collaborator. That's going to be a clerk

1:38:09ID connected to it. And it's going to

1:38:12have access to one or more projects.

1:38:15Then, if we take a look at the actual

1:38:17Prisma client, that's going to be within

1:38:20lib Prisma,

1:38:22we're just using the Prisma PG adapter

1:38:24to create a new Prisma client and

1:38:27connect it to it.

1:38:29Then, we export this global Prisma

1:38:31instance that we can use to make any

1:38:33kind of database calls. We can't really

1:38:36test a lot of stuff right here because

1:38:38we've just built a database.

1:38:39But in the next lesson, we can build a

1:38:41couple of API routes that'll bring us

1:38:43one step closer to actually making use

1:38:45of this data.

1:38:47So, for time being, let's just run git

1:38:49add dot, git commit {dash} m, implement

1:38:54Prisma,

1:38:55and then git push.

1:38:59Now that our schema is ready, we're

1:39:02ready to build the API routes that sit

1:39:05on top of it.

1:39:06This is back end only.

1:39:08We're not yet wiring the UI. That'll

1:39:11come next. But right now, we need to

1:39:13focus on one single thing.

1:39:15A clean, secure set of routes for

1:39:18creating, listing, renaming, and

1:39:21deleting projects.

1:39:23So, create a new spec right here under

1:39:26context feature specs 06

1:39:30project APIs.md.

1:39:33And within it, we want to tell it that

1:39:35the database schema is ready. So, we

1:39:38need to build the back end project API

1:39:41routes. The routes are as follows: the

1:39:44REST endpoints for get API project,

1:39:46which is going to list the current

1:39:48user's projects, the post for API

1:39:51projects, which creates a project, we

1:39:54have the patch for renaming, and delete

1:39:57for, obviously, deleting.

1:39:59We can also give it a couple of rules,

1:40:02such as use the authenticated clerk user

1:40:05ID as an owner ID.

1:40:07And when creating, default missing

1:40:10project to untitled project and use the

1:40:12schema's existing ID strategy without

1:40:15adding sequential IDs. We also want to

1:40:18tighten up the security a bit by telling

1:40:20it that the unauthenticated requests

1:40:22return 401, and only the project owner

1:40:26can rename or delete. Non-owners

1:40:28mutations return 403. Which means that

1:40:31we're making our app secure not only on

1:40:33the client side, but the server-side API

1:40:36calls are also going to return invalid

1:40:38responses if somebody tries to break

1:40:41them. And again, we're not yet wiring

1:40:43any UI.

1:40:44And finally, to verify, we need to check

1:40:46whether the routes exist, whether the

1:40:49owner's checks are enforced, whether 401

1:40:52and 403 responses are handled correctly,

1:40:54and that the npm run dev build passes.

1:40:57You know the drill. Open up Claude code,

1:40:59tell it to read the file, and execute.

1:41:03Read this file, update the progress

1:41:05tracker, and implement it exactly as

1:41:07specified. Let's see how it does.

1:41:10The process of actually creating four

1:41:13REST API routes would take us some time,

1:41:16and you most likely already know how to

1:41:17do that. But our agent is just going to

1:41:19do it much more quickly for us. And then

1:41:22when you take a look at it, you can