Okay, awesome.
Today we are talking about how to build an AI-friendly PRD.
So first off, what is a PRD?
It's a project requirement document.
These have been around forever.
It's nothing really new.
But what's really interesting now is that with the power of AI, we can create these
obviously a lot faster and be a lot more accurate.
And it's one of the cool things that we can do as a team because we have essentially taken
flip the structure a little bit now, as far as like previously, we used to spend 80% of
a project just writing code and actually putting things, building the thing.
And maybe there's 10, 15, 20% of the project is like meeting with clients and shaping and
getting clear and then just going and doing majority of the work.
So what we found using the framing, shaping process that we've been diving into with Ryan
is that you can actually get a lot more work done in that kind of uphill piece of the framing
and the shaping was really about half the project, at least on that.
And then you can use AI kind of on the downhill of the project.
Okay.
I think I've shared this before, but this idea of we've talked about framing a little
bit, there's some shaping, which we'll get into more of that.
There's a lot of resources from Ryan on that.
And what we essentially are working to do is to have this continual process of going
into framing, shaping, building, and then the shipping.
And I think about it like this, like the project really is, we start with the framing
of kind of what is this thing even going to be and shaping.
And this is, it's not necessarily the bulk of the hours or the work.
It's just the, all the unknowns it's in shape up, they call it the kind of the uphill piece
of the project.
It's just, you don't really know where that top of the hill starts to peak.
And then it's all after that, it gets really easy.
And this can be helpful to, to continue to frame and shape and prototype.
To me, this is doing quick little spike projects of, Oh, we need to actually go in and make
a little thing or test this AI OCR piece we were doing yesterday.
And just iterating like test, it's all happening as uphill things.
We just don't know what we don't know.
So you just pick on a thread and you keep pulling on that thread and okay, where does
this going to go?
How do we figure this out?
And then once you get clarity, we'll do some more training on kind of more of the shaping
piece.
I think there's some mystery still there, but framing we talked about in a previous
video.
And once you get this clarity, that's where we want to create this kind of where this
flag is.
This is where we're going to create this.
We're called the PRD that's going to then go ahead and help build it.
And we can, at this point, we're starting to take the project, put it into a task grid.
We're taking the project, we're putting it into the AI friendly PRD, and then we're just
going and executing on that project.
And the way that I like to think about this, I'll start here at the top, get back to my
notes so we don't get too off track, but it essentially creates this like single source
of truth for us.
Once we've got everything and it's clear, then we just put it in to this document.
We can go execute on this, this document, what it's going to look like as an actual
file in cursor, it's a dot MD markdown file that you'll have all this very specific sections
in there.
You'll have different tasks set up.
And then we have this way for the AI to track what's worked on and what's not worked on.
And I mentioned this a little bit, but why we're working on this is because it helps
us create very precise executed things for the AI.
So AI is your junior dev that's going to run around and go do exactly what you say.
But when we give it very vague things, it just starts taking a shotgun approach, just
like randomly changing files.
And that's where you're like, oh, AI is, this is the sort of epitome of a vibe code movement,
right?
We're not vibe coders here.
And we, the anti-vibe coding trend, I haven't come up with a name for it yet, but we'll
come up with something.
And the idea is that you are going to get extremely precise.
You get extremely clear with the client, what the requirements are and what the limitations
are for this project.
And then when you've done that, and we have a very clear plan of attack, and there's not
a lot of unknowns there.
We've ruled out anything that's, oh, I don't, this is fuzzy.
I don't know how this little component is actually going to work.
We've really ruled that out.
We've already figured out some solutions and decisions.
Put this PRD together and you can go have AI build the first kind of version 0.1 of
this new feature.
So that's kind of how we're thinking about it.
And it continues to kind of align everybody, of course, with the client, the project manager,
you as the developer, and then of course, our best part of the team is the AI.
So they're really part of the team that is working.
And it just helps us get something out quicker that we can see and play with and experience,
because that first version that we built may not have accounted for something.
And so we can easily go back and then iterate on that.
So getting that first thing out the door is really helpful.
And then clients can see it.
Everybody can react to it once it's real.
It's hard to react to something when it's in a breadboard form or just in a prototype.
And then the way I think about this is like I've said this before, like the humans are
us.
We are going to own client communication.
We're the experts at.
finding the root cause and digging in.
Like it's this very, almost like you're going to the founder
therapy, I think is what Luchin called it.
You're just essentially interviewing them, getting questions.
What's, why is this a problem?
Why do you feel this way?
What friction is it causing?
Why now is we're trying to get deep into like their problem and
experience what they're trying to experience so we can be as helpful as possible.
And then with that, we are taking that and then we're going to use AI
on what it's good at, it's just the coding.
But where we're not doing is getting this kind of vibe coders.
Cause vibe coders generally is people just like sitting down and
just noodling around, like, I think I'm going to add a live streaming
to my website and just put in a prompt.
And off it goes and just let it YOLO settings on cursor where
just everything just is done for you.
You may make very few decisions and then outcomes like a cool app.
And then there's this whole thing about it.
So this is not what we're doing there.
We're getting very specific.
Cause we're working in very high level business operation type tools
where these things need to be precise.
We can't just make a change and then just accidentally makes other
changes in the app and breaks things.
We want to be really precise.
That's where the quality is going to come in.
And that's where if we have someone who is an expert, they're going to oversee it
and they're going to essentially be the senior dev.
So I said, if you're a dev, any dev leveraging AI, you're now senior dev,
right, you're now managing these junior devs and you're going to check on their work.
You're not going to just let code go through the get shipped and you're
going to be really picky about it because you're trying to train them up and you
care about the quality of what's going out, but it allows us to go a lot faster
obviously, and get the grunt work out of the way, but we're not spending days
doing something where you spend a few hours building something and then
spend more of that time helping the client understand how to use it,
optimizing it, tweaking it and getting it ready to ship.
So we're essentially again, helping create really crisp specific tasks.
This is not nothing vague about this, keeping it concrete, reviewing all the
commits, seeing what it is adding, and just if it gets stuck, obviously keeping it moving.
We have, I've taken our shape of AI.
There's now the way to create an AI PRD.
So what I was going to do for you guys is do a little example here.
First off, what it does is it essentially you give it a bunch of inputs.
You can give it a task grid, you could give it the framing doc, you could give
it a number of different pieces, but you want to give it as much context as possible.
And then the GBT will return a little framing doc at the top to help give the AI
some context and then different sections and tasks.
And so the important thing here is if you use the shape of GBT, it's a, it's,
it's version one of your PRD.
It's not the thing you're going to go and then I'll execute on.
So I'm going to actually do this for you guys for a project that
Eluchin and I shaped up.
So this migrating web app from Flutter to JS.
I'm probably not going to keep what we do in this demo, but it'll help prove the
point because what's nice about this is already chopped the project into some
sections here, and then from here, we're going to move it into cursor.
So what I'm going to do just really quick is grab this.
I'm just going to screenshot it and I'm just going to paste it in here.
And so we want to say something like write a AI, use that phrase.
It's going to know what to do with that.
And I'm also going to grab from FigJam here.
This is not very precise because we didn't, at the end of it, a very long work session.
We came up with very clear concrete tasks.
We actually didn't go back and do the problem statement, but I think I grabbed
this one to give some like general context.
So my windows are, let me just make this bigger because it's
screenshots not going to be.
So I'm just going to screenshot FigJam like that and jump in here.
I'm just going to get both of those things as context.
I'm using the, so what you can pick shape up AI, and then you can pick what model.
I've seen some really good examples with O3.
It does take a minute, a bit longer, but, or O3 pro.
So these are, let's go ahead and try that out and see how it goes here.
In the meantime, I will go ahead and get cursor up.
I'm going to kind of show you guys how we would put this in.
And there's the important thing here is that we are again, getting a draft.
This is not what we're going to go through and execute on at the end.
We need to, cause what does shape up AI not have right now?
It doesn't have the context of the entire code base.
So after we're done with this, I'm going to put it into cursor.
I'm going to take that shape deficit.
Okay.
Now update this now that you have like context of the code base.
And I want to see really specific things.
Like I want to see that, Oh, it's going to change this directory.
It's going to add these files because this is where you see AI go pretty wonky.
Sometimes like it just all of a sudden decides to start creating like additional
directories and a new routes file that doesn't need to be there.
There's already a routes file.
Just need to add a new route inside.
Like it gets very redundant fast because it's a little bit dumb.
So let's see.
It's pulled all these into tasks.
Let's see what it did.
And again, this is not, so I'm going to leave the bottom part off and it
is going to generate a, an MD file.
So you can actually download.
This, um, as an MD file right here, and you can't see mine.
I can, I'm gonna go to the repo and I'm going to go, you guys can't see this,
but in tribe, I have a directory called instructions and I'm just going to call
it web to JS, CMS dot MD, and I'm going to flip over now to cursor and, and
then I'm going to make this much, much bigger cause you guys aren't going to.
There we go.
Cool.
So in cursor, we now have this like web to CMS here.
I'm going to make this, let's get some room here.
Cool.
Same doc and everything here.
So I'm going to go in now and say, this is for tribes.
So it's easy.
We can say update this doc and you can leave it in agent mode because
we do want it to edit this.
There is an ask mode here where you can ask it questions about the code base,
but we do actually want it to edit files.
So I'm going to say update this document now that you have context with, and you
can say the code base like that.
And we have this tribe overview MD file.
It's got a bunch of information, make no code changes, only update PRD.
Everything's on max here and we'll just fire that off.
So what's cool about cursor now is you actually can queue up other
messages while you're working.
So you can go ahead and say, is there anything else we can do to optimize?
These are general things.
And you can go ahead and queue that up.
And it just sits in the task window down here.
I don't know if you guys have played with this and you can fire that when it's
ready, you can have messages queued up or I can delete them if needed.
So I'm going to go through, let me just, there we go.
Clean that up and shrink this down a bit.
This is the tiniest cursor window I've ever used.
Cause I normally on a much bigger screen, but, and then what we're also doing here
is we're wanting to track like the difference of what is it identifying?
Because one thing that it's, we have in here, which I already knows a problem
is we're saying a bunch of stuff about this.
We have to build a things, notifications.
So it doesn't know a lot of things.
This is probably where it's going to, this demo is going to break down
really fast because half the stuff has to be in tribe social mobile app.
And some of it's going to be in the tribe social JavaScript repo.
So there's two different repos going on.
And I want to see, actually be curious to see how much it actually catches
that, because I think we said, this is just simple, like migrating the site.
So it can't do that.
Obviously that's nothing it can do for that.
And now it's ready to come back with its first batch of edits.
Let's see.
So we would read through this.
So this is, I'm not, I don't want to rush this in a demo, but I want to just
give you guys the workflow really quick.
So what I'm going to do is if I was really doing this, I would literally
say at the top here, okay.
And read it word for word from top to bottom, be like, Oh, that's wrong.
Or that's a mistake.
Or it's, and then I could accept those changes and walk, work my way through it.
The goal is not to be like, this is everything in this document is
what it's going to go execute on.
So your job, you're like, should be really focused on how do I make this
absolutely as precise as possible and give it the most context possible.
If I keep going down, let me just see.
And I think, no, it's got this as a three week project.
Okay.
That's fine.
I don't really mind.
I like to think of like when it says a week, I like to think of it as an hour.
So we're like the, what is it?
An interstellar, right?
Where the days take hours, or that's if you guys are familiar with that,
maybe that's what it feels like.
So if you can get through a, an hour here, it'd probably be like at least a
day or at least for a week of what it thinks.
So I'm gonna keep going through it's, is it working on it still?
Cause it's very jumpy.
So we can go through each of these and I can read like what's its approach.
This is, there's a lot of pieces here.
And one thing is it's already a little bit.
So I would just say number each section.
So it's easier to find.
And so we'll continue to iterate on this and build this document.
So this should take time.
Like this, I don't want to rush this, but I wanted to show you the workflow as far
as plugging it into cursor and then having it totally go through and
update everything to make it better.
And the other thing I will do is I try to keep it around two to 300 lines.
This doesn't need to be a thousand lines.
I think if you get into something where it's much, much larger, it just makes it
very complicated to go and find things.
Let me take this preview off here.
And we've got, let's see here.
So we've got this, I'm just coming through.
Okay, cool.
At this point you would finish it and then get this where you're happy with it.
Get it approved.
I would create this on a new branch.
And again, this whole thing with AI stuff, of course, is to be very, to hold it loosely.
So I'm going to build this whole product like PRD.
I'm going to fire it away on a brand new branch and just let it go and do all
the things at once and test it.
And then I may take the whole thing, just reset the branch and start it totally.
If I'm like, oh, that PRD didn't work, throw the whole thing out, edit it, clean,
reset the database, quickly get it back to zero and then just build it again.
Cause it's not like we have to, oh, we have to save all this work that it's done now.
If you, oh, it ended up creating this whole other thing and I didn't need that.
And it's over if it's too much, like just reset the branch or start a new
branch if you don't want to lose what you've worked on and just iterate it again.
So.
This is where, once you finish this, I would start a brand new session.
And every time you start one of these sections, so each section will
have, let's say three to five tasks.
Each section at least should be on its own, own tasks.
So your prompts would be something like, let's build this.
And it should know, based on the instructions here, that it's
going to just do one section, each of the tasks, update those.
And it's going to stop at that point.
And when you're done with that, you can save it.
You can check the code just for that one section.
Hopefully it's broken into little sections here.
So this one was like, do a code split.
So we have to create this and this, we have to do this.
It's a pretty easy, because this is using our framework.
Each thing starts with a verb.
It's very clear that it's going to deploy this to all nodes and confirm
that everything makes functional.
So if we want that, we don't have to do that.
I may have pulled this out.
We don't need to deploy all this, you know, right out the gate, but we could,
this is a shippable piece if they want it to, and then we'd start this
kind of split thing building out.
And also what's helpful is if I'm doing this as me right now, but Lucian and I
were working on this together in great detail, so if we had, if we continue
this together, we would have a lot of opinions on these different tasks.
And we can say, okay, yeah, let's strike, strike that, change
it, move things around, whatever.
And so you're building it, the plan for it and getting really specific.
All this stuff that we're doing is getting, is clarity and
just being extremely specific.
That's what we're doing.
We can't have things that are vague because you're going to tell
it to go execute on all these tasks.
So just make sure that it's a, it is a task you need.
And if not delete it, like just, if you don't think it's, if it's over the
top, sure, do we need to optimize the Firebase queries to achieve less
than a hundred milliseconds late?
Maybe, I don't know.
And that seems like a little bit over the top, right out the gate.
And anyway, we'll go through this finishes and you would basically
go through section by section.
I would keep it all separated if you can in, in that, in the branch.
And then let's jump back to this.
And here we go.
Oops.
Cool.
And you could iterate here, but to me, this is gets like a nice
first draft of the template going.
So that's how we would go through that.
And then I, we did to the demo and then I just said, yeah, go through it slowly.
Best, best practices, new cursor session per section.
And you'll continue that PRD and it should be like a live
PRD that updates the status.
So you just should be like, okay, now do section two.
Okay.
Now do section three and you're committing each thing so you can
roll back because inevitably it may get one might be fine.
Two might be fine.
It gets into three and then it just, you know, crashes or maybe the
app hits a bunch of bugs or something.
You want to make sure that I like to make sure that the app still is working.
So I'll have it running locally and I'll see what it's doing.
Does the thing even load?
Are we hitting compiling errors?
What what's going on so that we're not like committing, okay.
Section three's in here, but it totally broke everything.
Cause then if you do that and then now four starts to get built, you get further
and further away from like a working version, so that's how we'll just
make sure that it passes tests and keep, keep committing there to that branch.
And then it said that dedicate branch.
So that's pretty much it.
I wanted to cover it.
It's pretty, I went through it very quickly.
The best thing is going to be for you guys to go through it in
detail yourselves and just test it.
You will build a little, a level of trust with the AI on this
and it will get better and better.
I do want to show one little bonus thing, which is, which I've been
experimenting with, which is cloud code.
I don't know if you guys are using this at all, but cloud code, you can run it
in any editor and you install it here.
So you can get you guys a cloud code pro account if you want, but you just
start kick off a session like this.
And we can say, yes, we trust that file.
Now here's where we can, it basically runs in the terminal.
So if you're, you love doing things in the terminal, this will be for you.
And I can just link to this and say at, what did we call this?
Web two here are my requirements.
And then just see now what this will do, what I like about it.
I just want to give you guys a super quick high-level demo.
Ah, perfect.
It's already overloading the API.
Fantastic.
So may have to be on a pro account.
I noticed the cloud was actually down this morning.
Potentially that's what it is, but I did this the other day for another project.
And it does this, it essentially creates like a little to-do list for yourself.
And it starts to actually manage the project for you.
And then you do, you actually choose each task that you want to do.
So it's going to do this one.
It's going to be like, Hey, I'm, I want to change these three lines.
And you look at the three lines and you're like, yeah, that's good.
Make that change.
And it works, works, works.
And it's cool.
I want to make these five changes, or I want to add this new file
and you can step it through one.
It's a little bit of a more of a simple process.
So this will, this is actually going to run ahead and start doing this.
I may not, this may not be the way to do this, but CloudCode is an interesting
workflow and you'd think it would be the same as for Sonnet Max here.
It's actually quite a different workflow entirely.
And this actually is independent of what's happening in the terminal.
So I found for.
new feature, I integrated a new framing functionality to the Novo dashboard.
So you could eventually be able to have a conversation with Claude and
then Claude will actually create the framed grid with the different
bullet points and stuff underneath that we could send to a client
and then export that to Notion.
So I was able to do that in about an hour using this process.
And I built a little PRD for it and had it executed and it actually
worked right out the gate.
I was very impressed.
It does run out of like tokens and usage.
You'll see, depending on your account.
So just experiment with it.
If it, try these different workflows and see what works for you.
So that's everything I want to touch on for the PRD and we'll
just jump into some discussion.