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

It's 2026 and most of the senior

engineers I know aren't really writing

code anymore. They design the systems

and let AI handle the implementation.

And the gap between developers who can

do that and developers who can't is

dividing the industry right now. This

app is what that looks like when you do

it well. Real-time multiplayer SaaS, AI

agents running in the background, full

production code, and I didn't write a

single line of it. An agent built the

whole thing. And by the end of this

video, you'll have built it, too. The

same app, the same stack, the same way I

did. And here's what makes this

different from other AI build tutorials.

I built this app using the exact

methodology the app itself is designed

to teach. Specs first, architecture

defined, every feature planned before we

start building. I've been doing this

architecture work by hand before every

serious project for years. And at some

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

am I doing all of this manually when I

could build the tool that does it with

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

real-time collaborative workspace where

you describe a system in plain English

and then AI agent maps it onto a shared

canvas live. Your team edits the design

together and when it's ready, the app

generates a complete technical

specification you can build from.

Now, if you've tried building anything

serious like this with AI, you already

know the wall.

The first few hours feel incredible and

then a week later, the agent has

forgotten every decision you've made,

one new feature breaks three others, and

the code base you were excited about

just starts fighting you.

That's not an AI problem. It's an

architecture problem. And it's the same

wall all of you are hitting in your

careers where the senior dev advice

online sounds great as long as you're

already senior. The developers who win

in this market aren't avoiding AI, and

they're not handing everything over to

it, either.

They're learning to think like senior

engineers, and then using AI to build at

the speed of one. And that's what this

video teaches. By the end, you'll know

how to design a system before writing

any code, how to use the six-file

context system I write before every

project, and how a senior engineer

actually thinks when working with AI.

Oh, and that six-file context system I

just mentioned, I've packaged it into a

free guide you can grab and use on any

of your upcoming projects, not just this

one. The link is down in the

description. Next, the stack is Next.js,

React 19, Liveblocks for real-time

collaboration with agents, Trigger.dev

for background work with AI agents,

Clerk for auth and user management,

Prisma and Postgres for data, Vercel

Blob for storage, all production grade

and deployed by the end of the video.

So, one person with the right system can

now build what used to take a team. And

by the end of the next few hours, that

person is you.

So,

let's build it.

Before we open up a single tool, I want

to spend the next 10 minutes on the part

of the video that I think is most

important, and that decides whether what

you're building ships or falls apart in

the third week. There's going to be no

syntax and no code in this section.

Rather, what I'm teaching you is the way

that I think before I write a single

prompt, and the way I plan a build

before I touch the agent, and the system

that I use to keep AI from drifting

halfway through a project.

So that by the end, you'll know the

conversations to have before you build

the six-file context system that turns

an AI agent from a guesser into a

developer who already knows your

codebase,

and how to break any project into units

the agent can ship cleanly one at a

time. So, if you've been frustrated by

AI breaking your code,

then this is the video that fixes it.

The intro touched on something I want to

sit with for a minute.

You heard me say senior engineers a lot.

And if you're early in your career, that

framing probably hit a nerve. So, let me

be direct about what I mean.

The job market for developers right now

is harder than it was 2 years ago.

Some entry-level work has been

automated. Clients who used to hire

freelancers for straightforward projects

are now doing it themselves. And a lot

of people who learn to prompt without

learning how to think are now flooding

the market. So, if you're worried about

that, you're not wrong to be worried.

But the developers getting squeezed

aren't the ones who learned deeply.

They're the ones who learned just enough

to execute without understanding the

system behind it. That was always a

fragile place to be.

And AI just made that fragility visible

faster.

So, the way through is to learn the kind

of thinking that AI cannot replace. The

architectural thinking, the

systems-level judgment, and then use AI

to build at the speed of someone twice

your experience. The clearer your

understanding of what you're building,

the better the AI output. Which means

that learning properly isn't a waste of

time in the AI era. It's the best

investment that makes everything else

possible.

So, when I say things like think like a

senior engineer in this video, I don't

mean you need 10 years of experience to

apply this.

These are learnable habits and you can

start building them today on this

project. And here's something most

developers outside of Big Tech don't

really know. At Google, Amazon, and

Netflix, before any serious project

starts, engineers spend weeks writing

documents and sometimes months.

Design docs, one-pagers, RFCs, the

format changes by company, but the

principle is the same.

Figure out what you're building before

you build it.

And senior engineers at these companies

sometimes go months without writing

production code. They're designing

systems, making architectural decisions,

reviewing what other engineers ship. So,

software engineering has never really

been about typing the most lines per

day.

It's always been about thinking clearly

about what should exist before you build

it.

And AI didn't invent that discipline. It

just made it the most important skill in

the room. And that's the whole

foundation for the spec-driven agentic

development course that I've been

developing for a long time now. So, if

you want to stay up-to-date on how

that's going and receive an occasional

email where I share my thoughts at the

current state of the industry, I'll

leave the link down below so you can

subscribe for the newsletter. But, let

me immediately make it concrete in this

video.

Here are two different prompts that two

different developers might write to

build the same feature.

The first one says, "Build me a SaaS app

with authentication and a real-time

canvas."

And the second one says,

"I'm adding a LiveBlocks room provider

to the workspace route.

Auth is already handled by Clerk

middleware. The canvas uses React Flow.

Room tokens should be issued only after

verifying project membership. Wire the

provider into the existing workspace

layout without touching the sidebar or

navbar. Both developers want roughly the

same thing.

But the second prompt reveals a

developer who knows their auth layer,

understands their component boundaries,

and knows what should and shouldn't be

touched. They've thought about the

system, so they're communicating

decisions and not wishes.

So, the AI isn't smarter when it reads

the second prompt. The developer is.

And that is the difference between vibe

coding and what I'm going to teach you,

which is spec-driven development, which

is also the premise behind that

spec-driven agentic development course

that I'm actively developing. Vibe

coding focuses on the outcome.

You describe what you want, let the

agent run, and react to whatever comes

out.

For a weekend prototype, that's fine.

But for anything you're going to

maintain, it just collapses.

New features break the old ones, the

code base starts contradicting itself,

and you spend more time untangling AI

mistakes than actually building.

Spec-driven keeps the thinking with you

and gives the agent a system to execute

against.

You stay the architect and the agent

becomes the implementation engine. So,

how do you actually build that system?

Because that's the part that nobody

really teaches. It starts before you

open up any AI coding tool, with a

conversation. When I get an idea for

something I want to build, I open up a

planning AI, ChatGPT, Claude, or Gemini,

whichever's on hand, and I talk through

it. What does this thing actually do?

Who uses it? What are the core flows?

Where are the complex patterns, and what

could go wrong?

I push back on the answers and let AI

pressure test my thinking until the

system becomes clear in my head. This

conversation is the work. It's what

senior engineers do before they build,

except they usually do it in their head

or on a whiteboard. But, doing it with

AI externalizes it and makes it faster.

When the system is clear, you write it

down. And that's where the six-file

context system comes from.

Not from sitting at a blank page trying

to write documentation, but from taking

the output of the architectural

conversation and organizing it into

documents that travel with the project

for its entire life. For Ghost AI, I

organized everything into one folder

called context.

Six files, and what matters is that

before your AI agent writes anything, it

already knows what you're building, how

it fits together, what the rules are,

and where things stand right now. That's

what you're going to learn about in this

video. But, very quickly, here's what

each one of them does at a glance.

The project overview covers what the

product is, who is it for, the core

flows, and what's deliberately out of

scope.

The architecture file defines the tech

stack, the boundaries between layers,

and the invariants the codebase must

never break. The code standards keeps

the agent consistent across every unit

of the build with shared TypeScript and

Next.js conventions. The AI workflow

rules keep the agent disciplined,

defining how to scope work and what to

do when something needs a decision.

The UI context holds design tokens and

component conventions, so the UI stays

coherent across every page the agent

ships.

And the progress tracker, which is the

one most developers skip and most need,

holds the current phase, what's in

progress, what's complete, and the

architectural decisions made along the

way. It's the only file that actually

updates constantly throughout the build.

And it's how the agent picks up exactly

where you left off in a single prompt.

These six files are what make the

difference an AI agent that drifts and

one that executes. And you don't have to

build them from scratch for every

project. I've put together a free blank

template of all six files with

step-by-step instructions on how I

generate them using AI for whichever

project I'm working on. And it's not

specific to Ghost AI. It works for any

application. Click the link down in the

description to get it so you can apply

this methodology to your own project

starting today.

We'll open up each one of these and I'll

walk you through what's actually inside

in the next lesson when we set up the

project architecture for real. But yeah,

once these six files exist, the build

runs in units. We're going to break down

the project into specific scoped pieces

before we start. Not vague phases like

build a dashboard, but concrete units

small enough to build in a single focus

session with clear conditions for what

done looks like. That means that

together for Ghost AI, we'll map out the

entire build. Each lesson will have its

own spec file. The spec defines the

goal, the design decisions, the

implementation details, dependencies,

and a checklist of what has to be true

before the unit is complete.

You write the spec in the same way you

write the context file through a

conversation with the planning AI.

Then you give the spec to your coding

agent in one prompt. Make sure to read

that spec. Mark that unit as in progress

in the progress tracker. Implement it

exactly as specified without going

beyond scope. The agent will read your

spec, read your context file, and build

against a defined system instead of

guessing.

You review it against the checklist and

if it passes, you close the unit, push

the code, and move to the next spec. If

something's off, you write a focused

corrective prompt, exactly what's wrong,

exactly what you expect, fix that

specific thing, and move on.

That's the entire workflow, the same one

I used to build Ghost AI, and the same

one you're about to use to build it with

me. Oh, and last thing before we begin.

These files take time to write. The

conversation, the architectural

decisions, the unit planning, all of it

is real upfront work. And a lot of

developers skip it because they want to

feel productive immediately. I mean,

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

the agent, type a prompt, and start

watching code appear.

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

by skipping this is the time you lose in

week three debugging AI output that's

drifted away from anything coherent. So,

do this work once, and you'll do it

faster every project after. And finally,

it's time to build.

Okay, enough talk, and let's build.

Open up your desktop and create a new

folder. Call it something like Ghost AI,

and then simply drag and drop it into

your favorite code editor. For this

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

the file explorer on the left side, we

have the code in the middle, and then we

have the chat window which you can open

up by pressing command shift P, and then

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

just command shift I to open it as well.

No matter which agent you're using, is

it Copilot, Claude, Codex, or whatever,

the interface is more or less the same.

This is how it looks like on Codex, and

this is just general chat.

So, this video is completely agentic

tool agnostic. The thinking and the

specs are what matters. The tool is

completely your call. I'll personally be

using Claude code as that's what most

people are using and what's we're using

internally within JSM. If you want the

budget option, you can go with Codex.

There's the Go plan, which is super

cheap, the plus plan, which is also

cheap, and I think they're also offering

a month for free. And if you're already

paying for something like Cursor, Win

serve, or any other AI agent, just use

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

lot of tokens, no matter what you're

using, and that you learn a ton. Okay,

so let's get started.

We'll start with a fresh Next.js

project. I'll do this manually with no

prompts and agents.

It's just a single command and it takes

a couple of seconds and that'll give us

a clean and predictable foundation to

build everything else in top of. So,

simply open up your integrated terminal

and run MPX create next app at latest

dot, which is going to create it in the

current repository. It'll ask you

whether you want to install the Next.js

installer, so you can just say Y, yes,

and proceed.

And I also want you to know that you

don't necessarily have to follow along

by using Next.js.

Of course, the majority of the context

for AI agents we'll be working with is

going to be featured around Next.js, but

if you want to build this in TanStack,

Angular, Vue, or anything else, the

concepts will still be as valuable.

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

to ask you whether you would like to use

the defaults, so just press enter,

which is going to install React,

TypeScript, ESLint, Tailwind CSS, and

the app router. Let's give it a moment

until it finishes. Once the installation

finishes, we need to clear out the

default boilerplate.

That's going to be within app and then

page. Next.js ships with a lot of

placeholder content that, honestly, we

don't really need. Now, you could go

ahead and clean it up manually by

opening up your globals.css

and cleaning everything besides the

Tailwind CSS directives, deleting some

SVGs and other stuff within the public

folder, and replacing the page.tsx with

a minimal component.

Or we can use this as our first

interaction with the coding agent.

So, go ahead and open up your agent of

choice. I'll just press command shift I

to open up my chat sessions. And what I

love about VS Code is that it's not

shying away from the agnostic approach

to agents.

You can use their agents right here,

such as Copilot CLI,

or if you head over to extensions and

then install an extension like Claude

Code,

which has like 12 million downloads, or

something like CodeX, which has 8

million downloads,

and I installed both, you can actually

just navigate over to them by selecting

additional views,

and then choosing the extension you

want. Of course, alternatively, you can

also just run all of these agents within

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

For the longest time, I've been using

Claude CLI, but the Claude VS Code

extension recently got so much better,

and honestly, it's working the same way

as the CLI does, but with a bit of a

nicer UI and a graphical interface that

allows us to use it in an easier way.

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

I'll expand it so we have more space to

work with, and you can notice that

there's a little microphone button right

here. So, you can either tap it or hold

the command D key to speak into it. With

CodeX and other agents, you can either

type it manually,

or what you can do is use a tool like

Whisper Flow, not sponsored by the way,

which is what I use to write prompts

when I speak with agents. Speaking is

just much faster. If you install it, you

can just press the command key

and start speaking into it. Like, clean

up this Next.js boilerplate. Strip

globals.css down to just the Tailwind

directives. Delete all SVGs in the

public folder, but keep the favicon.

Remove page.module.css.

Replace page.tsx with a minimal

component that just renders a centered

div saying Ghost AI.

And I can stop it right here, and you

can immediately see the output. Cool

stuff, right? Go ahead and write

something like this, and let's see how

well Agent handles it.

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

permissions every single time whenever

we're doing something, for now I will

say edit manually. Oh, and of course, we

have to talk about the actual models

we'll be using. In this case, we're

using the default model, which is Opus 4

7 with a million token context, which is

amazing, but you're going to hit the

limits very soon. Instead, you'll be

able to follow along this entire build

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

inexpensive, and it sometimes get lost

unless you have the context files, which

I'll teach you how to build so you guide

it in a bit of a better way, and make it

work much more like Opus does. So,

that's what I'm going to select. If

you're working with Codex, you can also

go ahead and choose any model you'd

like, like 5 4, 5 3, or anything else.

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

to think for a couple of seconds, read

all the necessary files, and apply all

four changes.

Globals, just the import. Page, minimal

centered Ghost AI component. Deleted

five SVGs, but kept the favicon. And

this file that I tried to trick it with

doesn't really exist, so there's nothing

to delete.

You can see all the changes in the diff

right here, and you can also see which

files have been modified on the left

side.

There we go, just simple Ghost AI, and

just the import for Tailwind. Which

means that these classes right here

should work to center the div. Before we

run it, let's actually head over to

package.json.

Make sure that the project name is set

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

npm run dev.

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

you open it up, you should be able to

see something that looks like this.

This means that our project is

initialized, it's cleaned up, and now we

are ready to move to the part that

actually determines just how well

everything goes. Setting up our context

files and planning the build before the

agent writes a single feature. So, let's

do that next.

Not that long ago, I talked about how

senior engineers spend weeks designing

systems before anyone writes a line of

code.

They write design docs, they define

boundaries, and they make decisions

early on so that everything else becomes

predictable.

So, let me show you how we are going to

approach that.

We're going to create a new folder right

here in the root of our application,

which we're going to call context.

Everything inside of it is what your

coding agent will read before it does

anything. This is how it knows your

project, and this is how it stays

consistent across every session, commit,

or unit of the build.

So, you can switch multiple agents and

share the context file with another

developer so he can continue working

with his agent from there. That's the

catch. We're going to have a couple of

different files within the context

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

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

with the final zipped context folder so

we can easily review everything

together. So, delete the context folder

you just created. In the video kit link

down in the description, get the zipped

version of the folder, unzip it, and

then just drag and drop it in.

And here, you'll see six, well, seven

different files with this agents.md.

Might seem scary at first, but don't

worry as I walk you through every single

one of these files and show you how you

can create them for yourself in the

future. Let's start with the project

overview. And let me walk you through

why it's structured the way it is

because understanding this is more

valuable than just copying the file.

Currently, we're looking at the markdown

version of the file, but in VS Code, I

believe this is done by default, you can

also open the preview to the side by

pressing command K and then V or just

pressing this icon at the top and then

you can close the actual MD and just see

the formatted version. I think it's a

bit easier to read this way. I typically

open up these project overview documents

with a one paragraph summary and then a

numbered list of goals. This gives the

agent the big picture immediately. So,

when a requirement gets ambiguous 3

weeks into the build and it will, this

is where you resolve it. The agent uses

this constantly to understand intent

when a spec isn't specific enough.

Notice the goals are concrete and

measurable, not build a good canvas.

Instead, let authenticated users create

and manage architecture projects or let

AI generate an initial architecture from

a natural language prompt. The agent

knows exactly what success looks like.

And yeah, this is useful for us while we

are going through the process of

building the app. Just so you know what

we are building. Just so everybody in

the team, in this case me teaching you

and you following along and you building

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

stay eye is a real-time collaborative

system design workspace. Users describe

a system in plain English and then AI

agent maps that system onto a shared

canvas. Collaborators refine the

architecture and the app generates a

technical specification document from

the resulting graph.

Okay, great. We have the overview, we

have the goals, and then we have the

core user flow. So, let me zoom this in

and let's go through this together

because this sequence matters. The agent

can sometimes lose track of how features

connect to each other.

By defining a full flow from sign in to

the spec generation, we make the logical

sequence explicit. So, the agent won't

try to build the spec generation feature

on the login page because it knows the

user has to create a project and the

design architecture first. In the

features, we get specific about

technologies. And I want to take a

second on this because the tools I chose

for Ghost AI weren't random. I took a

lot of time to choose what actually

makes sense. Starting with

authentication. For user sign in, route

protection, project creation, ownership,

and collaborator access, we're using

Clerk. Could you have gone and created

the full auth from scratch? I mean,

sure, but it would take you a couple of

days up to a couple of weeks to do it

properly, even with AI.

And when you do it, it's never going to

be as secure as something like Clerk.

And nowadays, the speed of shipping

matters more than anything. If you have

a specific product you want to push, you

want to get it in front of potential

users as soon as possible. And that's

why for many of these agentic builds,

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

Clerk into it. Especially considering

just how well Clerk works with your

agents. You can either just copy the

prompt or use Clerk skills with

whichever agent you're using.

That way, it'll immediately become a

professional developer at using Clerk

and it'll be able to implement it within

any project. And there's also the MCP,

which is a server that allows AI agents

like Claude,

or others

to access Clerk as the case snippets and

implementation patterns, and basically

implement everything for you. Oh, and

not to mention that Clerk CLI is also

being worked on. You'll just be able to

ask your agent to use the Clerk CLI to

add auth to your app, allowing you to

not even have to leave your terminal or

copy and paste any API keys. Clerk right

now really is the leader in agentic

development. And with a completely free

pricing of up to 50,000 monthly

recurring users, it's a no-brainer for

me to build all of my applications with

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

link down in the description. You can

click it, and then sign up so that we

can very soon more easily get started

with building. Okay, on top of auth, the

most important part of our application

is the collaborative canvas.

And in this case, I wanted to make it

real-time. So, for any kind of canvas,

it makes sense to use React Flow. And if

you want to make any part of your

application live with cursors, so you

can see what other people are doing,

presence indicators, and node or edge

editing, I mean, it just makes sense to

use Liveblocks. Liveblocks is the leader

for anything multiplayer, but not only

apps, agents as well. Let me show you

what I mean.

I mean, this is the app without

Liveblocks, and then if you add it, you

immediately get live avatars. You can

get the AI chat to generate something,

and you can also leave comments and

track what people are doing within your

app, which is super useful for the

collaborative canvas we're building.

But, what's even cooler is interacting

directly with AI assistants to do

something within our application. I

mean, if you try to build all of this

from scratch, it would definitely take

some time. But, with their AI assistants

feature, you can just watch an AI do it

for you. Oh, and this whole React Flow

thing you're seeing, that got released

recently, which means that in this

video, we're building the latest stuff

out there. Oh, and like Clerk and the

many other amazing dev tools that are

adapting to agentic development,

Liveblocks also offers the agent skills,

which you just have to install, and your

agent will immediately know what it has

to do to make the Liveblocks integration

work. I'll teach you about all of that

as we continue with the build. After the

canvas, we have the starter system

design, which I decided to have because

it's very difficult for people to start

with a blank canvas. So, I want to have

some kind of a curated library of

pre-built system design templates, where

users can import a starter template into

the canvas at any point during editing.

But also, if the template doesn't do

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

allow our users to generate a system

design from a prompt with AI. Then, that

output will be structured as canvas

nodes, and then we'll write it onto the

canvas. And finally, we'll take a look

at everything that is on the canvas, and

we'll convert it into a technical

specification in a markdown format. And

then users will be able to view and

download the generated specs. Oh, and an

additional thing that I want to teach

you is while we're generating stuff with

AI, that'll obviously take time. As the

user will likely provide a long idea of

how they want to architect their app,

and then the AI output is going to take

potentially a minute or two. And running

a more than 60-second AI generation call

inside a Next.js API route will just

time out in production. So, that's why

I'll also teach you how to use

Trigger.dev. It'll allow us to run

background tasks that can run as long as

they need to, with the retry logic and

status tracking built-in. The way in

which we'll combine Liveblocks and

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

have to be very clear in letting our AI

agent understand that it doesn't have to

invent a custom web socket

implementation when Liveblocks is

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

AI generation inside a request handler

when trigger dev is defined as the layer

for that work. Naming the tools we're

going to use for the project in advance

is crucial. Oh, and trigger allows you

to do so much more. Recently, they've

been diving deeper into allowing you to

build and deploy AI agents, which is

something we can explore in an

additional video. But in this one, we'll

also focus on many of its features,

specifically running background tasks

and reporting back to the front end. So

while a long task is happening, we can

keep the user updated on what's

happening behind the scenes and allow

the user to continue doing whatever

they're doing on the application because

we're no longer blocking the front end

side while handling a specific task. So

I'll leave a special link pointing to

trigger as well as live blocks down in

the description so you can create your

accounts and then we'll be able to

immediately dive into the development.

Then we have the scope part which

contains the in scope and out of scope

features. And it's maybe the most

important section for keeping your build

focused. The out of scope section is

doing serious work right here.

Billing and subscription systems,

enterprise permissions, version

specification history and so on. This is

telling the agent, don't even think

about them. But we can add them later on

after we build the base of our

application. This is great because it

keeps every session focused on what we

are actually building.

And finally, there's success criteria.

Here, we define what actually matters.

These are the benchmarks that your agent

and you can verify against after each

major feature lands. Not, does it look

right? But, can a signed in user create

and open up a project? Can multiple

users collaborate? Can the graph be

converted into a persisted markdown

specification?

Very simple, yet concrete.

So that's our project overview. Written

in a way that makes sense to agents, but

also other team members working on the

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

AI workflow rules. This file is

different from others in a way that it's

not about what we're building. It's

about how the agent behaves when

building it. And the most important rule

right here is to work on one feature

unit or subsystem at a time. We don't

want to combine unrelated system

boundaries in a single implementation

step. And that single rule prevents most

failures that the agents cause.

Basically, all of these rules right here

tell the agent, "Stay in your lane.

Focus on one part of what you're doing,

and then move on to the next one." After

that, we have the code standards. So,

you can open up that, and let's quickly

take a look. This file is what keeps the

code base consistent from our first all

the way to the last chapter. Without it,

the agent would drift away. Like,

specific patterns that it uses for API

routes when implementing feature five

might look different from feature 16. Or

maybe it's going to change some things

regarding the TypeScript types, or how

it uses Next.js, how it styles things.

But here, we add that consistency. Like,

we tell it, "Make sure to have strict

mode enabled, and avoid using any." Or

we're telling it to add use client only

when the component needs browser

interactivity. Or for styling, we're

telling it, "No raw Tailwind color

classes. Reference the tokens through

the Tailwind utility names." I think you

get the point. We want to stay

consistent. Then, we have the UI

context, which, as you can guess, dives

a bit deeper into theming. Like, when I

was initially coming up with a design

for this application, I wanted to have

something that is simple, yet functional

and modern. And I spoke with AI a bit to

generate this theme. Dark mode, no light

mode, Uh, all colors are already

defined, and we're telling the AI to use

these colors.

And again, if you're wondering how

exactly I created all six of these

documents by speaking with different AI

agents, that's something that I'll cover

in much more detail within the

spec-driven agentic development course.

So, you can join the waitlist in the

description. But, I think you get the

idea that I didn't just sit down and

handpick every color in the file. I

described the aesthetic that I wanted to

AI, dark, technical, precise, something

that feels like an engineering tool, and

then I went back and forth on the

palette, um, the token names, and this

is what it came up with. Also, some

font, border radiuses, and so on. That's

exactly how you should approach your own

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

you need to know the feel you're going

for, and then AI can help you get there.

Oh, and while the project overview gave

some information about the project, the

architecture context will give you the

blueprint on how to build it. Here, I

specified the tech stack,

like every technology that we want to

use, alongside the role that it has

within the application. For auth, we're

using Clerk for user identity and route

protection. For databases, it's going to

be Prisma and Postgres. For canvas, it's

going to be Liveblocks and React Flow

for real-time collaborative canvas.

For background tasks, it's going to be

Trigger.dev, and for storage, we're

going to use Vercel Blobs. We also

defined some system boundaries, like

where we're going to put the request

handlers. Trigger is what we're going to

use for the long-running background

jobs, and some other folders that we're

going to use.

Then, we defined the storage model,

where and how we're going to save

something. And specifically here, I

decided to use a hybrid storage model,

which is another senior-level decision.

We aren't going to be stuffing massive

JSON blobs or three-page markdown files

into our database. Instead, we're going

to use Postgres only for metadata and

Vercel blob for the actual files. And

this keeps our database lean. And this

is important. We also need to tell it

how different tools are working

together.

Since we're using Clerk with Liveblocks,

we need to set a strict rule that

project memberships must be verified

before a Liveblocks token is ever

issued. This ensures that our Ghost AI

isn't just collaborative, but secure.

And finally, invariants are the rules

that the system must never violate. For

example, request handlers do not run

long-lived AI works. That belongs in

background tasks through trigger.dev.

Metadata and large artifacts are stored

in separate layers. Auth and ownership

are enforced at every mutation boundary.

Client components only used when needed.

And the canvas schema must remain

consistent. Of course, we'll dive much

deeper into this when we actually dive

into building the application. But I

wanted you to have a good idea of what

it is that we're building. And finally,

there's the progress tracker. This is

the only file in the context folder that

will look completely different by the

end of this video.

Right now, it is completely empty.

Intentionally, because it reflects the

actual state of the project. And right

now, nothing has been built yet. So, as

we complete each lesson, we're going to

update this file. The current phase,

what's in progress, what's complete, and

what's coming next. And remember what I

said in the beginning about agents

having no memory between sessions.

This file is the solution to that

problem.

At the start of every new session,

whether that's tomorrow, next week, or 6

months from now, one prompt is all it

takes to restore full context. Our agent

will read the progress tracker,

understand exactly where the project

stands, and pick up exactly where you

left off. So, you don't have to

re-explain yourself. Even though it's

going to be a small file, it does more

work than any other file in the project.

Oh, and finally, there's the agents.md

file. Within it, we're going to wire

everything together. When you installed

Next.js,

that file was already created for you

automatically at the root. This is the

entry point file, and every major coding

agent has one. They just name it

differently.

Claude calls it claude.md, Cursor, Win

Surf, and others use different names,

but the idea is always the same. It's

the first thing that the agent reads at

the start of every session.

So, Next.js has already added the first

section for you, and it tells the agent

that this is a recent version, and its

training data might be outdated, so read

the install documentation before writing

any code. Good default, and we can leave

it, but now we can add our own part

below it.

So, copy your agents.md, delete it from

the context, and instead move it right

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

do we have within it. We're basically

instructing the agent to read all six

context files in order before

implementing anything, and then to

update the progress tracker after each

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

going to waste context and tokens?"

Well, I mean, sure, it has to read

through the files, but that's not even

1/10 of how many tokens you're going to

save because there's going to be less

back and forth, and less mistakes and

bug fixing and correcting while you're

implementing the features in the first

place. So, that's the system. And now

that you understand it, let's start

building with it.

Now that the context files are ready,

before we build a single feature,

there's one more thing we need to set

up, and skipping this one is the most

common mistake I see in AI-assisted

projects.

And that is the globals.css

file.

This one right here. We've defined all

of our color tokens within our UI

context right here. But, if we don't

translate those tokens into actual CSS

custom properties within the globals.css

file, well, it'll just write the inline

colors. So, instead of maybe saying

something like text faint, it'll just

write #505060.

And the moment you want to change it,

you have to change it across all places.

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

is also the first real demonstration of

the spec-driven workflow in action. So,

let's do it properly. Create a new

folder inside side of the context folder

and call it feature specs, like this.

And then inside of it, create the first

spec file.

01

design system.

md. And then within it, we want to tell

it something like read the agents file

before starting.

Then, we need to tell it what we're

doing here, like adding the design

system and the UI components.

Then, we're telling it to install and

configure shadcn-ui.

And then we want it to add the following

components.

I figured we're going to use these

across the rest of the application.

Whenever we wanted to modify these files

after the installation, so we can

specify that.

We can also ask it to install

lucid-react for icons

and create a lib-utils.ts

with a reusable class names helper for

merging tailwind class names. Although,

I think it would do this by default,

it's good to mention it.

Finally, we want to ensure that all of

the components match the existing dark

theme within globals.css.

And then, we want to apply some checks

when it is done.

For example, we want to make sure that

all components import without errors,

that the cn works properly, and that no

default light styling appears. This is

what we call a feature specification or

a feature spec.

Every unit we build from here on has

one.

The spec tells the agent exactly what to

do, exactly what not to touch, and how

to verify when it's done. No guessing.

So, let's open up our agent by pressing

command shift I. As I said, you can use

anyone. I'll use Claude code.

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

open up that file, which will

automatically put it within its context.

And then, you can tell it something like

read

add 01 design system update

the progress tracker MD file to mark

this as in progress.

And then, implement exactly as

specified. This is the same template

we'll use often, but the only thing

that's going to change is going to be

the spec of the feature we're

developing. So, let's go ahead and run

it, and notice what will happen before

the agent writes a single line of code.

It'll read the specification, and then

update the progress tracker. You can see

how it's going through all the files we

prepared for it, and only once it has

enough context, it'll write and save the

plan, and then execute it. And only when

it has a full plan, it will update the

progress tracker.md, and then start

doing it. So, we can already take a look

at the progress tracker,

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

it is doing. And you can see that the

current phase is feature 01 system

design, the current goal to install and

configure shadcn with dark theme, and

that is currently in progress with the

feature 02 to be done. And it's also

adding the architectural decisions

needed for every step, as well as the

session notes. It's going to ask us

whether we want to run this command to

install shadcn, so I'll say yes, go

ahead. And after it installs everything,

it'll verify it with TypeScript. It

looks like it completed with zero

errors, and finally, it needs to update

the progress tracker to complete it.

So, we can already open it up right here

under progress tracker, and it should

move it from current phase over to

completed.

So, now at any point in our application,

if we come back 2 months later, it'll

know that it's using shadcn, Tailwind V4

with the following components, only

using dark theme,

and all the additional helpers,

as well as the architectural decisions.

So, once it finishes, the agent will

have configured shadcn, installed the

components, and verified that it all

works. So, what do you say that we test

it out?

Back on localhost 3000, the first good

sign should be that we're now officially

in dark mode. And if you head over to

the home page, that's going to be within

app page, we can try to use a shadcn

button component coming from components

UI button, and we can try to make it say

something like click me. You can see

it's coming from there,

and it follows our UI theme. That's it.

Our first feature, being the theming and

shadcn setup, is done. And that's the

spectrum workflow I was telling you

about. We define the specifications, we

run the prompt, we verify the output,

and then we move on. But just before we

move on to our second feature, I want to

add just one little extra step to this

whole workflow that's going to make our

codebase even more scalable,

predictable, and less error-prone. And

that is whenever we implement a specific

feature, let's also review it with Code

Rabbit. There's been a report that says

that AI code creates 1.7 times more

problems, which means that even though

we're faster, we're producing more

issues per PR. Also, the code becomes

less readable, naturally, and the error

handling isn't being done properly.

Security also suffers. So, let's add

that one additional line of defense.

Let's review every single feature that

we add to our project in the same way

that biggest teams, such as the

developers over at Nvidia, are doing it.

I'll leave the link down in the

description, so you can create your free

account and follow along.

You can log in with GitHub, and once

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

already gave it access to many of my

repos. But first, we got to push our

project over to GitHub. So, head over to

github.com/new

and create a new repo. You can call it

Ghost AI.

And just create it. Next, you can copy

these commands one by one, or you can

just copy all of them together,

open up your agent, and paste it. Then,

press enter. It's going to ask us

whether we're going to allow it to stage

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

ahead." And it'll also allow all future

commits, as that's going to help us

speed up the workflow, as well as adding

a remote, and finally push. You can see

that the changes have been pushed

successfully. So, if you come back and

reload,

you'll be able to see the current list

of changes over on the repo. It's always

good to make your project descriptive,

so you can remove the releases,

deployments, and packages, and add a

short description,

such as Ghost AI

is an interactive systems

architecture

builder.

We can route to the deployed website.

For now, I'll just route it to

jsmastery.com, and here we can put the

different topics, such as Next.js,

React, My Blocks, Clerk, Trigger.dev,

and even Code Rabbit, which we'll be

using for reviewing your code. And I

like how AI always adds nice commit

messages and not random gibberish that

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

Code Rabbit, you can head over to add

repositories,

sign in, and give it access to all your

repos. And then, when you're back, you

can just find your project right here.

Which means that it's automatically

being tracked. So, as soon as we start

adding the real features to the app,

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

new feature as we're developing within a

large organization and then get it

reviewed and only when Code Rabbit gives

it a green light,

merge it over to main.

Now that our colors are in and the

initial Shards and components are in as

well, we are ready to start building the

actual application. And the first thing

that we need is the editor, including

the top navbar and the left sidebar

because they're the foundation of every

feature we're going to build from here

on. We're not yet touching off and we're

not building this project creation. We

just need to establish the layout so

when these features come, they have

somewhere to go. So, inside of feature

specs folder, create a new file called

02 editor.md.

And within it, we're going to follow a

similar structure we followed before. We

want to start with explaining what we

need,

such as the base chrome components that

frame every editor screen, the top

navbar and the left sidebar shell. These

will be reused and extended in every

chapter that follows. Then, we need to

focus on what are we actually creating?

That's going to be the editor navbar.

So, we wanted to create a new component

within the editor editor navbar file

and then we want to specify some

requirements that follow. We want this

navbar to be of a fixed height at the

top. We want it to have both left,

center, and right sections, which you

can see right here. On the left, we open

up the sidebar. In the middle, we have

the name and on the right side, we have

additional actions. That's exactly what

we explained right here.

And of course, it's going to be of a

dark background with a subtle bottom

border. Next, we want to explain what we

want to do with the project sidebar. So,

right below, we can say create a project

sidebar component.

It should float above the editor canvas.

Opening it should not push the page

content. So, you can see it remains

where it is.

And slides in from the left. It has the

header that says projects and title and

a close button right here. It can use

the Shazian tabs component. And both

tabs show empty placeholder state, full

width new project button at the bottom

with the plus icon. So, something like

this. Oh, and finally, when we click

create new project, we need this kind of

a dialogue. A new pop-up that shows.

So, for that, we can say something along

the lines of

dialogue pattern. Use the existing color

tokens from globals for dialogue

styling. It supports title, description,

and footer action, but don't build any

dialogues yet.

We just want to create the component for

it. Finally, to check whether it is

done, we can check whether new

components compile without TypeScript

errors, no lint errors, and diagram

pattern is ready for future use. So,

hopefully, you were typing this out with

me, or maybe you paused the screen and

typed it with your own words. But, this

course isn't at all about typing. It is

about understanding what we're doing

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

like typing, nor you should, in the

video kit link down in the description,

I'll provide you with all the prompts

that we're going to use throughout the

rest of this course. So, if at any point

I'm going too fast when explaining them,

and you just want to have it on your end

and listen along, you can totally do

that. But, yeah, let me quickly walk you

through the structure because this is

the template that every spec file in

this project will follow. We start with

a goal. One or two sentences, what does

this unit produce when it is done? Then,

we go over some specific design

decisions. Is it visual or structural or

something specific to the component like

layout behavior, responsiveness, and

this is where we can refer to that UI

context file so that the agent isn't

guessing the colors.

Then we go over into implementation, and

in this case, I decided to separate it

into sections. So, we have the editor

navbar, the project sidebar, and the

dialog pattern, and finally the

verification checklist. So, let's open

up our agent. Whenever you're building a

new feature, always open up a new chat

and don't use one of the older chats.

That's because we don't want some stale

context lingering around. Only remain

within the same chat when what you're

about to do next is related to what

you've done before, such as when you

want to fix specific issues. You can see

that it already has access to the editor

file.

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

the tasks on the progress

tracker and then

implement it

exactly as specified."

And press enter. And in about a minute,

it's all done.

It developed the editor navbar, the

sidebar, and also the dialog pattern.

TypeScript and ESLint both pass clean.

Progress tracker also got updated. So,

let's check the progress tracker first.

It'll be right here within the progress

tracker.

So, if you check feature two completed,

editor navbar and project sidebar both

implemented. You can see them right here

under editor, editor navbar, and project

sidebar.

We just created them so far, but they're

not yet being used within the layout.

And even though this wasn't part of the

checks,

I want to actually be able to see them.

I want to tell it to use the navbar and

the sidebar right now within the

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

the same context window and tell it to

use these two components within a

layout. And within a minute it put it to

use. It even created a placeholder page

so we can navigate over to the editor

and check it out. So, head over to

localhost:3000/editor,

and you can see a canvas coming soon,

but there is a top bar and a left

sidebar, which opens up the projects.

So, you can see that what we requested

indeed got implemented. Since we're not

yet at the point where we need that

because we don't even yet have the

editor, I actually want to show you how

you can undo the changes, at least right

here in Claude code. The only thing you

have to do is press this back arrow on

the message that you used to create

these components, and then say rewind

code to here. Which is going to bring us

back and only give us what the

specification wanted, and that is the

components that we can then use and that

compile, but we're not using them quite

yet. Perfect. So, now that we have the

navbar and a togglable sidebar, let's

quickly check them out. The editor

navbar is pretty straightforward, and

the sidebar accepts some props such as

is open and on close, and uses the

Shadsy and tabs to modify what's being

shown. But, when you're writing code

yourself, you have a natural

understanding of every decision you

made. Heck, you wrote it.

You know why a function is structured in

a specific way or why you used specific

props.

But, AI-generated code doesn't come with

that context.

The agent made decisions that that were

reasonable most of the time, but you

didn't make them. And that means that

reviewing AI output isn't optional. It's

the step that keeps you in control of

your own codebase. So, that's the

perfect use case to test out the Code

Rabbit edition that we added in the last

lesson. I'll open up the chat and tell

it to push all the current changes to a

new branch called development.

Typically, in real production databases,

you often have multiple branches such as

dev, staging, and only then main.

So, for now, we want to push this over

to the development branch, get it

reviewed, and only if it's good, merge

it over to main. So, by giving it this

quick message, it'll run a couple of Git

commands,

figure out that we're currently on main,

that we need to switch over and push to

that new branch. And that's a little pro

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

these commands through the terminal, but

I find it super easy to just stay in

flow and tell the agent to push the code

for me, which you can see it just did.

So, if you head back over to your repo,

you'll see that the development branch

had recent pushes 3 seconds ago.

So, let's go ahead and compare them and

open up the pull request. We have 333

new lines of code across five different

files. So, Code Rabbit immediately

hooked itself onto the PR, and we'll see

whether it'll be able to pull out some

bugs out of the hat.

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

right back. And we got back the

walk-through, where it says exactly what

we introduced in this project, such as

two new React components for an editor

UI Chrome, an editor navbar, and a

project sidebar. These are super simple,

as this was a simple review. Later on,

these are going to get much more

detailed, but yeah, let's check whether

we have some potential issues even on a

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

major issue that says, "Hide the

off-screen sidebar from focus order and

assistive tech when closed." So,

specifically, this is an accessibility

fix, which is definitely a good

implementation.

Since we haven't yet utilized this

component in our app, I'll leave this so

we can add it later. There's also a

minor issue, where the spec lists only

the is open for the sidebar, but the

implementation also requires on close.

So, actually, it's suggesting to change

the specification. This is interesting,

because sometimes you're going to miss

some stuff from the spec, and it's okay

if AI tries to fix it or add some stuff,

but it's equally as important for Code

Rabbit to flag it. Because the whole

reason why we're writing specs in the

first place is so we can have predictive

output. So basically, you can just copy

this part right here, go back to your

code base where we're saying accepts

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

But we're going to say accepts both is

open and on close props. Little change,

I know, but now our code base is

consistent with the spec. And that's it

for this simple PR. As we continue

developing more components, the reviews

are going to get significantly more

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

ahead and merge it, which means that we

are ready to continue developing the

next component.

For this type of application, we don't

really need a traditional homepage.

Most tools like this drop you straight

into the editor.

You sign in from a simple sign in page

and you manage everything from the

canvas. And that's exactly what we'll do

within our app.

But we need auth, sign in, sign up, and

other similar pages where you explain

how your application works

and then allow users to sign back in. So

to get that set up, click the Clerk link

down in the description and sign in. You

can sign in with Google or GitHub. And

once you're in, you can head over to

applications and create a new app on the

dashboard. You can give it a name such

as Ghost AI and choose the sign in

options

such as email, Google, and since this is

a development website, we can also do

GitHub. Then click create application.

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

can do is just install @clerk/nextjs

by copying this command and paste it

straight into the terminal.

And while that is being installed, you

can also set up your Clerk API keys by

copying them from here

and creating a new file called

.env.local

and then paste them right here.

Now, before we hand anything over to the

agent, there are two things you need to

know about Clerk and Next.js 16

specifically, because if you skip this,

the agent will get it wrong. And it says

it right here. If you're using Next.js

15 or lower, name your file

middleware.ts instead of proxy.ts.

The code itself remains the same, only

the file name changes. But, because most

agents were trained on Next.js 14 and 15

code bases, it'll almost certainly

create a middleware.ts file by default.

So, we'll have to specify proxy.ts

explicitly in our spec so it doesn't

have to guess. Oh, and another important

thing is that just by adding middleware,

it doesn't automatically protect all

routes. As you can see right here, by

default, it leaves all the routes

public. And this catches a lot of

developers. You have to explicitly

define which routes are protected and

which are public, which means that we

have to configure everything

intentionally. And this is exactly why

reading the updated documentation before

building with AI matters. The agent

knows Clerk, not necessarily the version

of Clerk you just installed or the

version of Next.js you're running on.

The spec bridges that gap. Oh, but we

can also use agent skills.

As I told you at the start, most major

frameworks and libraries now publish

official skill packages specifically for

this problem. It gives your agent

up-to-date knowledge, current APIs, and

patterns, and the best practices of the

library you're using. So, if you search

on Google or within the docs, Clerk

agent skills, you'll be redirected to

this page. Then, simply copy the

installation command,

head back over to your code base and

paste it in your terminal. npx skills

add clerk skills. Press enter.

You might need to install the skills

package by saying Y and then enter. And

then, by pressing the arrow up and down

keys and the space key, you can select

specific packages, such as core clerk.

You can either select some additional

clerk features or some additional clerk

frameworks. Like in this case, I'm going

to go with clerk next js patterns. And

press enter.

Then, you can select additional agents

that you want to add it to. By default,

it's going to work on codex, cursor, and

anti-gravity. But, if you want to add

Claude code, you have to select it here

and press enter.

And we can install it in project scope

via symlink. That's the recommended way.

So, just proceed with installation.

Perfect. Our skill is installed and

we'll be able to invoke it later on once

we focus on implementing the auth

functionality.

So, now we are ready to write the spec.

Open up your context feature specs and

create a new file called 03 auth.md.

And once again, the full feature specs

files are linked in the description in

case you want to just copy them and then

follow along. Or, you can slowly type it

out with me.

Let's start by telling it that clerk is

already installed and connected. So, we

just need to wire it into the next js

app, provider, auth pages, redirects,

route protections, and the user menu.

When it comes to the design, we just

want to use the clerk's dark theme from

the @clerk/ui themes as the base, and

then we want to override the clerk

appearance variables using the app's

existing CSS variables.

With no hardcoded colors. For the sign

up and sign in pages, this is what we

want to develop. On large screens, we

just want to have a simple two-panel

layout. On the left side, a logo, a

tagline, and text-only features. On the

right side, a centered Clerk form, and

on small screens, forms only.

We don't want to have any kind of

gradients, as that's going to seem

AI-ish. No oversized hero sections,

cards, or scroll-heavy layouts. Keep the

layout minimal and professional.

And then we can dive into a bit more

details on the full implementation.

So, we can say

wrap the root layout with a Clerk

provider using the Clerk's dark theme.

Create sign-in and sign-up pages using

Clerk components. And as I told you

before, we have to be specific in

telling it that it should use the

proxy.ts file name at the project root

instead of the middleware.ts.

And then, we have to define public

routes using the existing sign-in and

sign-up environment variables. Protect

everything else by default. Which means

that we have to update our home page so

that when authenticated users visit it,

we redirect them to the editor. Or when

unauthenticated users visit it, we

redirect them to the sign-in page.

We also want to implement Clerk's

built-in user button to the editor

navbar right section for profile

settings and log out. We want to keep

Clerk's default user menu and profile

flows intact and not rebuild heavily

custom- ized Clerk internals, and want

to use existing Clerk environment

variables without renaming or inventing

new ones. Finally, we can specify

additional dependencies, such as Clerk

UI, if we need to install it. And then,

when it's done, we want to check that

proxy file is there, that all routes are

protected except public auth routes,

auth pages use CSS variables with no

hardcoded colors, Clerk provider wraps

the layout and the build passes. This is

our complete authentication

implementation. Now, you know the drill.

Go ahead and open up your agent,

give it access to this file, and tell it

to read this file and update the

progress tracker.md file accordingly.

Then, implement the auth feature exactly

as specified in the auth.md file. Okay?

You can see that the built-in microphone

feature right here still isn't perfect.

Let me try to do the same thing with

Whisper flow specified in auth.md file.

There we go. That's a bit better, and

specifically it's 03.auth.md.

Perfect. Let's go ahead and run it.

First, it's asking me to run some bash

commands to check whether Clerk has been

properly installed, and we'll say,

"Yeah, go ahead, you can run it." It

took him about 2 minutes or so to go

through all the context we shared, and

only then it'll start to implement

everything in parallel.

And this is much better than if it

started right away and then just ended

up with a bunch of mistakes. So, the

list of updates that it put right here

is to update the .env.local with Clerk

sign-in and sign-up URL vars, create a

proxy with Clerk middleware route

protection, update the app layout with a

Clerk provider and dark theme, create

sign-in and sign-up pages with a

two-panel layout,

update the app page to redirect based on

the auth state, add the user button to

editor navbar,

and create editor page, and then update

the progress tracker, and run npm run

build to verify. It's going to ask me

whether it has the ability to create

some directories, and I'll tell it,

"Yeah, go ahead."

And in the future we can give it some

more permissions so it can do things a

bit more freely. And after it came up

with the initial plan, it actually built

out everything pretty quickly. Maybe

even in less time than it used to think

how to approach it in the first place,

which shows you just how important the

initial context and a proper task are.

And there we go. The build passes, and

here's the summary of everything that

was implemented. I think all of these

things right here shouldn't come as a

surprise because we initially specified

them in the spec. Then it updated the

to-do's, and now it just did it. And

yeah, it's pretty interesting that it

even notes right here that it would have

gotten confused about this middleware

proxy thing if we didn't specify it

properly. But thankfully, it did it in

the right way thanks to the research

that we've done at the start.

So, what do you say that we take it for

a spin? The application is running on

localhost 3000, but whenever I make some

bigger changes, I like to rerun it. But

initially, if you head over to

localhost, you might get redirected to

this clerk handshake part, which is

going to lead to a broken page. But

after you reload, it should properly

redirect you back to the homepage. And

after that, it should just work.

This is something that we can polish and

fix up later on.

But yeah, this is looking interesting.

Definitely not quite as nice as the

original application that I've showed

you that's deployed.

So, what are some of the things that we

can do to make it look more similar to

that one? Well, step one is to search

some kind of design websites online like

Dribbble or award-winning websites, and

then just take a screenshot and try to

get it to match to that closer. Or in

this case, you can head over to the

deployed version of this application,

take a screenshot of this whole UI that

you can see right here,

and then we can feed it over into our

chat. So, go ahead and open up the chat.

Keep in mind that we can still stay

within the authentication window that we

worked on

because now we're fixing some parts

about that specific implementation. So,

what you can do is just click this plus

right here and upload from computer or

just drag and drop the screenshot. Then,

select it and then we can further point

out to some things that could be

improved, not just the layout. It seems

like it didn't properly read the fonts,

that the right side of the screen is

taking a larger portion, so maybe we can

split them 50/50, same as it is right

here, and make the font size a bit

larger. So, it's not just the layout. We

needed to review the screenshot and

update the UI of our current application

to look more like the one on the

screenshot. Means 50/50 left and right

side layout with some kind of a color on

the left side to differentiate it from a

dark background,

as well as we need to fix the fonts so

that it uses the ones outlined in our UI

guidelines. I think for now this is

going to be enough for it to get closer

to the design we want to get. So, press

enter and let's see how it handles it.

And there we go, the build passes, it

updated the globals from circular font

reference to the one that should be

correct right now. The body was pointing

at itself, so this font was never

actually applied to anything. Same fix

for the heading and it also implemented

some other fixes. Let's check it out.

The design now looks much closer to the

finished product. The fonts are being

properly applied and that makes a big

difference. So does the increase in font

size and this shift between the two

different background colors. Of course,

later on we can come up with a unique

logo that we can put right here, but for

now this is looking great.

And believe it or not, we have a fully

functional authentication system built

in right here. So, what do you say that

we go ahead and test it out? You can

head over to sign up to see whether that

works and it does. Later on, if you want

to, you can modify the contents on the

left side depending on whether you're in

sign-in or sign-up page. And then let's

use something like GitHub to sign in.

I'll authorize it and the redirect

redirects us to a page that currently

breaks. So, I'll try to head back over

to localhost:3000 one more time. And now

when we get back, it actually redirects

to the editor properly. You can see that

we have the sidebar, we have a space for

the canvas that's about to come in the

future. And then on top right, we see

all the information about our currently

logged-in account, which is beautiful. I

mean, we get complete user management

within a single prompt that we've done.

Let's also try to sign out for now, and

we do get one issue when we click that

button saying there's an unexpected

response received from the server. So,

if we head back over here and open up

the terminal, we can see an unhandled

rejection. Unexpected response was

received from the server. And then in

the terminal, we see something like

this, which doesn't really tell us much.

Now, what we could do is just copy this,

open up the chat window one more time by

heading over here, and then just pasting

this error and telling it to fix it.

But, I'm actually glad that this error

happened because I can teach you a bit

better and more precise way to handle

these issues and so that when you try to

fix them, you don't cause new ones.

So, instead of pasting this right into

the chat, we're actually going to open

up a new file right here within context

and call it current issues.md.

You can even do it within feature specs.

Either way works. Then, you can paste

any kind of errors that you have and

explain what's happening. So, I'll

explain that when I click the logout

button,

the following error appears. And now I

can paste this error message. And we can

also specify that sometimes when we log

in, we get redirected to this weird long

URL, which doesn't show anything on the

page.

And then we can just paste this URL

right here. Again, the errors on your

end might be a bit different from what

I'm seeing right here. Whatever they

are, I don't want to teach you how to

copy and paste. I want to teach you how

to solve the problems for yourself.

Explore the current issues file and

deeply analyze the problem.

Only when you have the analysis, give it

back to me with the idea of how you're

planning to solve it, and then wait for

me to give it the green light to execute

it. So yeah, writing something like this

makes sense because that way it doesn't

go into the spiral of trying to fix its

own bugs while breaking 10 other things.

You provided the error, it's going to

come back with the analysis. You're the

one deciding whether that analysis makes

sense and whether it can actually

execute it. So, let's run it and see

what it comes back with. And after some

thinking, it's back with the analysis.

And this is so much better and so much

more detailed than if we just told it to

fix it immediately. Now, it actually

tried it out and has a deep idea of

what's happening. The server log is the

key clue. Proxy took 373 milliseconds

out of a half a second total request.

Almost all time is spent in the proxy.

So, that already points it in the right

direction.

As a human person, I would never figure

this out on my own. At least not from

such a vague error message. But yeah,

here it figures out that this button

needs an after sign out URL. So, it's

just going to add it.

And a similar thing is happening with

the handshake URL. It basically needs to

configure that after sign up URL, and

that way it's going to route it

properly. So, it provided a two fix

plan. So, this looks plausible to me,

looks good. So, let's just tell it to

execute the plan and fix the issues.

There we go. So, the fix now seems very

apparent. We just needed this after sign

out URL. And if you want to learn more

tips and tricks just like this one about

actually analyzing and fixing the errors

and how I approach building these

production level applications,

definitely check out the spec driven

agentic development course. It's not out

yet as it's going to be super detailed

and it's going to follow the best

practices from the strongest developer

teams out there. But yeah, it'll be out

soon, but I'm still super glad that

while I'm developing that, you can still

learn how I develop these applications

with the agentic ways with this new

video that you're watching right now.

And you can let me know down in the

comments how you like this new type of

video. I get that it's completely

different from manual coding, but I

still think there's so much to learn and

we can have a predictable development

workflow even with AI doing the writing

for us. So, let's see whether this

actually fixes it. And the build passes.

The after sign out URL prop was removed

from the user button as it belongs in

clerk options and is set via environment

variables. So, we'll soon be able to

verify whether that actually fixes it.

But before, I want to open up my

terminal,

stop it from running and then rerun it

again on localhost 3000 because we

changed the ENVs, so we want to make

sure that they're read by the browser.

So now, heading back over to localhost

3000, maybe you're signed in already,

which is fine. You can simply sign out

now and that brings us to another error,

which is the same one we've had before.

And another thing you can do is head

over to inspect element, switch over to

the application tab, and then clear all

the cookies. So, find the cookies for

localhost 3000, clear them, and then

reload the page.

You'll be redirected back to the home

page and now we can retry with a clean

slate.

So, I'll sign in using GitHub the same

way I did before. That works. I

automatically get redirected over to the

editor, which is great. And now, I'll

sign out, and that worked. So, now head

back over within your terminal,

run git add dot, git commit {dash} m,

implement auth, and then git push. This

is going to push all the changes to

origin development, allowing us to open

up a pull request over to the main

branch. Then, you can open up a PR, and

let's wait for CodeRabbit to review it.

This time, we had many changes, but not

many of them are directly related to

what we did in the code. We just added

these agent skills so that everybody

else's agents working on this code base

also, well, become smart in the

technologies that we're using for the

project. And then, yeah, of course, we

implemented a couple of different files

that CodeRabbit will verify. But,

primarily, what we've done is right here

within app, sign in and sign up pages,

we have added some features that would

display on the left side. And then, the

sign-in page, where on the right side,

we just render the sign-in component

coming from Clerk.

Similar thing happens over to the

sign-up page. So, right here, we're just

rendering the sign-up UI.

Then,

over in the layout, we are wrapping

everything with a Clerk provider,

setting the theme to dark, and setting

some custom variables. That's it.

Everything else remains the same. And

then, within the editor page, we are

simply showing the nav bar and the

sidebar, as well as the rest of the

content.

In the nav bar, we display the Clerk

user button, allowing us to see more

info about the user, and allowing us to

log us out. Pretty straightforward so

far. As our components and features get

more detailed, we're going to do deeper

dives into the code base, but so far so

good. Let's wait for the review. And

quickly we're back with a full

walk-through. This pull request

integrates Clerk auth into a Next.js

application and establishes

comprehensive agent skills for Clerk

integration across multiple frameworks.

It also adds auth middleware, sign-in

and sign-up pages, Clerk provider setup,

and introduces five new skill

definitions for supporting scripts,

documentation, and so on. So, obviously

a lot of the checks right here from

CodeRabbit are going to be about the

skills that we set up, but we can skip

those for now and focus on the ones

about the actual files we implemented.

In this case, it looks like there's one

critical issue, and that is within the

context current issues.md.

Well, you never want to publish current

issues to GitHub anyways, because you

want people to see your code and not

your mistakes. Um what we're doing here

is even worse. We're exposing the

handshake or the JWT token from the

track docs. So, this is a real security

issue. So, what we need to do is delete

this file. Obviously, this won't delete

it from the Git history, but that's fine

for us because this JWT is no longer in

use.

So, right here over to getignore, I'm

going to add our {forward-slash} context

{forward-slash}, and that's going to be

the current issues

.md file.

And I'll also remove everything that is

within it.

Not that it matters right now, because

we're adding it to getignore anyway. So,

let's go ahead and push those changes by

saying get add {dot} get commit update

{dot} getignore.

And get push. Immediately the changes

will be recognized, which means that we

can merge this over to the main branch.

And while we're here, we can also head

over into context on the main branch and

remove the current issues file right

here from GitHub by simply deleting the

file.

And committing the changes.

We can also do the same thing on the

development branch by heading over to

context

and heading over to current issues, and

just removing the file

so that it's no longer here, and it's

not going to be pushed to GitHub any

longer because we added it to get

ignore.

Perfect. With that in mind, we've

successfully implemented the full UI and

functionality for the authentication

within our application.

Now that our authentication is done, and

we can actually sign into our

application, let's make the sidebar

actually do something. As right now, it

is just static. Before we hook up any

real data, we need the UI in place.

The create, rename, and delete

dialogues, plus the editor home state.

So, we're keeping this prompt focused on

UI only with no API calls yet. Head over

into context, feature specs, and add a

new file called 04 project dialogues.

Within it, we can specify that the goal

is to build the editor home screen and

add the project dialogues and sidebar

actions with no API calls yet. So, what

does this specifically mean?

Well, it means that on the home page, we

want to reuse the existing editor layout

without modifying the navbar or sidebar

behavior, but in the center of the page,

we want to add a heading, create a

project, or open up an existing one, and

a description. Start a new architecture

workspace or choose a project from the

sidebar, and a new project button with a

plus icon. Keeping the layout minimal

without wrapping this content in cards.

And then clicking new project should

open up the create project dialogue.

Let me actually show you what I mean by

all of this by heading over to the

finished version of the application, and

quickly signing in. Notice how right

here in the middle we have some text to

greeting us, even though the canvas is

empty, allowing us to create a new

project, which then opens up this

dialogue. That's exactly what we want to

achieve.

So, we'll have a dialogue for creating a

new project, as well as for editing one,

and deleting it. So, let's specify these

three dialogues below.

We're going to have one for creating a

project that takes in the project name

input, the live slug preview based on

the name, and preview updates as the

user types. Then, the one for the rename

with pre-filled project name input, and

the one for delete. Finally, on the

sidebar, we want to add the following

project item actions, rename and delete,

show actions only for the projects that

we own, and hide actions for the shared

or projects belonging to collaborators,

and on mobile, tapping outside the

sidebar closes it, and want to add some

kind of a backdrop scrim. Finally, let's

specify the implementation right here by

telling it to create a dedicated hook to

manage the dialogue state, the form

state, and the loading state, that way

we can reuse the functionality.

And then we want to wire the editor home

new project to create dialogue, the

sidebar create button to create dialogue

as well, sidebar rename to rename

dialogue, and sidebar delete to delete

dialogue. For now, we only want to use

mock project data with no API calls.

And to check when it is done, we need to

check that sidebar actions are wired,

that slug preview works, that no

TypeScript errors exist, and there's

also no linting errors.

So, let's open up Claude Code or your AI

agent of choice,

and then we can tell it to read this

file, update the progress-tracker.md

to mark this as in progress and then

implement it exactly as specified. And

let's run it.

And in about a minute or so, feature

four is done.

Here's what's built. New file hooks use

project dialogues, which centralizes the

dialogue type, form, including the name

and the slug, the loading state and mock

data, which exposes these different

functions to deal with the dialogues.

Then there's the dialogue component, as

well as within the project sidebar, we

also call the dialogues when needed.

So, let's quickly check this hooks file

that it implemented. You can see that it

is strictly typed right here with the

project interface, the dialogue type, to

slug, which takes in the name and turns

it into a human readable ID,

and it even created some mock three

projects that we can verify.

It came up with a lot of different use

states, keeping track of all the

projects, the dialogue type, the

selected project, the name, slug, and

loading.

And all of these are going to be used

within the dialogues themselves. Then it

returns the data, so we can actually use

them. Let's check where the dialogue is

being used. Most often, it is right here

within project dialogues,

where we have the actual code for how

the dialogue looks like. If the dialogue

is of a type create, then we show this

one. If it's of a type rename, we show

this one. And if it's delete, we show

the one below. Before we test it out,

let's check out the progress tracker

that says that the current phase is the

feature four dialogues.

It has the goal to do it. And it has

actually completed the project dialogues

with all of these different components.

So, now if you come back to the editor,

this is going to look much better. It's

no longer just a blank screen, but

rather in the middle, it says create a

project or open up an existing one,

start a new architectural workspace, or

choose is project from the sidebar. And

if you click create project, it actually

opens up a new project dialogue where

you can type something like my project.

It automatically creates a slug at the

bottom as well. And if you click create,

you saw that creating loading.

And of course, the data is currently

static, but you can see how it's going

to look once it actually picks the data

from the database.

So, we have Ghost AI Core, which you can

select

to edit its name

as well as to delete it. This means that

the UI for all of the dialogue

functionalities has now been implemented

alongside this centerpiece of the

application, which means that now that

the majority of the UI is done, in the

next lesson, we can start focusing on

implementing real data with a real

database to make our app come to life.

But before we dive into the database,

let's make sure that our current code is

good. And I want to show you another

Code Rabbit feature allowing you to

review your code directly within your VS

Code, which means that you don't even

have to create a PR and you can be that

much faster. You can install the Code

Rabbit extension, authenticate to your

account.

It'll notice the changes that you have

right now, so you can just click review

all changes. And the review will start

directly within your editor.

So, let's give it a minute. We'll check

the changes and if they're good, push

them. If not, we're going to fix them.

And within a minute, the review is in

and Code Rabbit left the comments

directly on our code base. So, you can

expand all the files and click on them

to see exactly what's happening.

For example, right here, specific

confirmation message and project name

display, the delete project dialogue

lacks key detail. What text should be

shown to the user? Should the dialogue

show which project is being deleted? And

should we show the cancel button as

well? These are some important

questions. And it's good because in this

case Code Rabbit is telling us that we

can be even more precise with our

feature specifications. But, let's see

if it has any comments within our code

base. It says right here that the

project item that is this one right here

appears clickable, but it lacks

interaction handling. It has a cursor

pointer, that is this one right here in

the sidebar, but when I click on it, it

doesn't do anything. That's fine for now

because later on we're going to make it

open the actual canvas of that project.

Since that is not implemented yet,

that's totally fine. Then, another

inconsistency, feature four is being

marked as both in the current phase as

well as finished right here at the

bottom. So, we need to modify the

progress tracker to say that the feature

five is to be done. And then, and then

modify the current goal to be determined

for feature five. Next up, feature five.

This is good. And finally, in the use

project dialog hooks, we have a couple

of comments as well.

First, we have missing validation for

empty slug edge case.

If the user enters a name containing

only special characters, it passes the

truthy check, but returns an empty

string, resulting in a project with an

empty slug. So, if I head back right

here and try to create something, take a

look. It's true.

I can actually create a new project, but

nothing gets added to the slug because

these are not valid slug characters. So,

we definitely have to fix this.

Thankfully, what we need to do is add

slug validation.

So, I'll just press accept right here

and it'll update the code for me. That's

another perk of using Code Rabbit within

VS Code. And I think there is one other

comment right here in this dialog, which

is the same issue right here.

Same as before, the rename operation has

the edge case where the slug could end

up empty. So, we definitely want to fix

the validation there as well.

Now, we can push the changes by saying

get add dot, get commit {dash} m

implement dialogues

and then get pull to pull the latest

changes and then run get push {dash}

{dash} force to push the latest changes.

Because remember, we deleted that file

directly on GitHub, but still we want to

push the local changes as well. So now

if you want to, you can manually open up

a PR by heading over to new pull request

from the development branch

over to the main branch

and we can immediately merge it because

we've already reviewed all the changes

with Code Rabbit with their VS Code

extension. So back within the

application, you can run get pull

and you can also check out to main and

run get pull there as well

to be up to date. But make sure to

switch back to the development branch

because that is where we're actively

developing new features.

Now that our project management UI is

wired up, we need the actual database

behind it. And for that, we're going to

use Prisma with Postgres.

If you prefer a different database, the

process is the same. Just swap the

provider in the schema.

Prisma supports Postgres, MySQL, SQLite,

and more. So let's start with a manual

installation right here within the

terminal. Stop the app from running and

then run npm install Prisma tsx {at}

types {forward-slash} pg {dash} {dash}

save {dash} dev. These are the dev

dependencies so that we have a nice

development workflow. After that is

done, you can install all the necessary

packages needed for us to set up our

database such as {at} Prisma

{forward-slash} client, Prisma adapter

pg, {dot} env, and pg itself. And press

enter. After that is done, initialize

Prisma with the correct output path for

the Next.js router.

You can do that by running npx Prisma

init dash dash output, data slash app

generated Prisma. This creates a new

Prisma folder with the schema.prisma

file and an ENV file at the root. So,

head over to the Prisma dashboard. I'll

leave the link down in the description

and create a new account. You can sign

in with GitHub or Google. And once

you're in, you can create a new project.

I'll call it Ghost AI and they'll give

you a one command setup, but in this

case we can proceed with the connection

string.

So, you can just copy it and then head

over into your .env and override the

current database URL with the new one

that you just got from the dashboard. As

a matter of fact, we can take this

database URL and put it within the

.env.local as that's what we're using

for our environment variables. Then,

open up your prisma.config.ts

and update the path to the schema. It's

just going to be prisma forward slash.

We want to remove this schema.prisma

because we'll make a separate Prisma

model.

So, just use prisma forward slash. Now,

before we run our spec, let's also

install Prisma Agent Skill. We did the

same thing with Clerk, so the same idea

applies. Just for a different library.

Open up your terminal and run MPX skills

add Prisma skills.

It'll ask you which ones you

specifically want to install and in this

case you can select all of them. CLI,

client API, database setup, Postgres,

Postgres setup, and upgrade V7 and press

enter.

You can install them for cloud code

within this project with simlink.

And we can proceed with the

installation. And now we are ready to

generate our schemas. So, let's create a

new file right here within our context

feature specs

05-prisma.md.

And one sentence update is that Prisma

is already installed, but we needed to

add the project data models, Prisma

client singleton, and the first

migration. So, then we have to start

specifying the models that we want to

install.

That we want to set up.

First, we're going to have the project

model.

So, we'll ask it to add project that has

to have an owner ID mapped to the Clerk

user, a name, an optional description, a

status enum, either draft or archived, a

canvas JSON path for future canvas blob

storage, timestamps, and indexes on

owner ID and creation date. So, we can

actually search through them. The second

model we want to have is going to be the

project collaborator, which is a project

relation with cascading delete. It

includes collaborator email, timestamp,

and some constraints on the project and

email, and indexes, so we can actually

map over it. Do not add any extra fields

unless required by Prisma. Finally, to

be able to use these models, we have to

set up Prisma client.

So, create a lib prisma.ts file as a

cached singleton,

branch by database URL. If it starts

with Prisma plus Postgres, then use

accelerate, else direct to add Prisma

adapter PG. In our case, it's going to

start with Postgres forward slash, which

means that it is actually hosted

somewhere. Finally, we want to ask it to

run the migrations and to generate that

Prisma client, and want to verify

whether it has installed all the

dependencies,

such as Prisma, Prisma client, Prisma

adapter PG, and PG itself, and some

checks are whether schema has both

models with correct relations and

indexes, the lib Prisma file exports one

cached Prisma instance,

the migration runs successfully, and the

NPM run build passes. So, let's open up

Claude Code, give it this file, and tell

it to read this file, update the

progress tracker, and implement it

exactly as specified. I think you get

the idea with these prompts.

The actual spec file is doing the heavy

lifting.

So, let's see how it approaches it.

It'll first read the Prisma spec,

the progress tracker, the architecture

context, and only then will it start

implementing it.

It'll first verify we have all the

necessary packages, and it might even

consult the Prisma skill. So, the agent

does a better way implementing the best

practices. So, let's give it some time,

and I'll be right back. Now, it's in the

process of creating the Prisma models

for the project and the project

collaborator.

Then, creating the Prisma singleton, so

we can actually have the client and run

it. It's asking us whether we can

actually run Prisma migrate. So, I'll

allow it to run it.

And then, it'll verify everything is

done, and we'll be able to check it all

out.

You can see that we have many files

changed, but once again, the majority of

these are coming from the agents that we

installed or the agent skills. The

actual generated files that we care

about are going to be within just a

couple of files, such as this Prisma

model right here,

and this Prisma client. That's it. But

okay, let's let it do its thing, and the

feature five is done. Here's what's

created, just two files that we need to

take a look at.

The first one is the project model, and

the second one is the Prisma client. So,

let's go ahead and check them out. I'll

first open up the model that is going to

be within models, project.prisma, and it

looks like I'm missing the Prisma syntax

highlighting. So, I'll head over into

extensions and install Prisma, which

would add the syntax highlighting,

formatting, auto completion, and more.

There we go. This now looks better. But

yeah, essentially we have created a new

model for the project with the ID, owner

ID, name, description, status, the

canvas, which is going to be attached to

a project very soon, and a potential

list of collaborators. And we also made

it indexable so we can search for these

projects.

Same thing happens with the project

collaborator. That's going to be a clerk

ID connected to it. And it's going to

have access to one or more projects.

Then, if we take a look at the actual

Prisma client, that's going to be within

lib Prisma,

we're just using the Prisma PG adapter

to create a new Prisma client and

connect it to it.

Then, we export this global Prisma

instance that we can use to make any

kind of database calls. We can't really

test a lot of stuff right here because

we've just built a database.

But in the next lesson, we can build a

couple of API routes that'll bring us

one step closer to actually making use

of this data.

So, for time being, let's just run git

add dot, git commit {dash} m, implement

Prisma,

and then git push.

Now that our schema is ready, we're

ready to build the API routes that sit

on top of it.

This is back end only.

We're not yet wiring the UI. That'll

come next. But right now, we need to

focus on one single thing.

A clean, secure set of routes for

creating, listing, renaming, and

deleting projects.

So, create a new spec right here under

context feature specs 06

project APIs.md.

And within it, we want to tell it that

the database schema is ready. So, we

need to build the back end project API

routes. The routes are as follows: the

REST endpoints for get API project,

which is going to list the current

user's projects, the post for API

projects, which creates a project, we

have the patch for renaming, and delete

for, obviously, deleting.

We can also give it a couple of rules,

such as use the authenticated clerk user

ID as an owner ID.

And when creating, default missing

project to untitled project and use the

schema's existing ID strategy without

adding sequential IDs. We also want to

tighten up the security a bit by telling

it that the unauthenticated requests

return 401, and only the project owner

can rename or delete. Non-owners

mutations return 403. Which means that

we're making our app secure not only on

the client side, but the server-side API

calls are also going to return invalid

responses if somebody tries to break

them. And again, we're not yet wiring

any UI.

And finally, to verify, we need to check

whether the routes exist, whether the

owner's checks are enforced, whether 401

and 403 responses are handled correctly,

and that the npm run dev build passes.