What's up friends? I'm going to keep

this short and sweet. I have identified

seven phases of development with AI. In

other words, as you're working through

coding with your AI coding assistant, in

my case Claude Code usually, then these

are the seven phases you should be

thinking about for shipping great work.

The way you achieve these phases is kind

of up to you. There are many different

implementations of it, but these are the

ones that I have kind of understood to

be kind of common across lots and lots

of different approaches. Whether you're

doing rough loops like I mostly am,

whether you're doing GSD, whether you're

using Spec Kit, you are probably going

to be using these seven phases. If you

dig this stuff and you believe that

engineering fundamentals are really

important in the AI age, then guess

what? So do I. And this is what I cover

and elaborate on in my newsletter. This

is not for vibe coders. We are people

that are serious about AI engineering

and serious about building applications

that are built to last. So if that

sounds like you and you want to improve

your skills, then this is the place. But

without further ado, let's go into the

list. Phase one, we start with the idea.

You have some kind of idea, some reason

that you are invoking this progress,

something that you want the AI to do for

you. This might be that you have an

entire app idea that you want to build.

Or you might just have a narrow thing

that you want to complete within the

code base that you're in, like a bug fix

or a feature. I also count refactors as

part of this, too. So if you have a code

base that you need to refactor, then

this process will work for you, too.

This idea can be as small and as big as

you like. We can expand this idea and

this process can take very very large

ideas and turn them into reality. Or it

can be teeny, very narrow and very

focused. Doesn't matter. Now, just to

give you a glimpse of the future setup

here, the idea is going to be turned

into a set of tickets, which a kind of

AI is going to complete. Now, that set

of tickets might end up being lots and

lots of different kind of like AIs

working at once, or maybe just a big

list of tasks that the AI is going to

complete sequentially. So if this idea

involves any kind of research here, any

kind of like difficult explore phases as

part of building the code, then you may

want to include a research phase now.

For instance, if you're doing like a

Stripe integration or maybe integrating

with an API that's not very common, then

you might want to create an asset that

kind of takes all of the research about

that thing like based on your idea and

kind of caches it and puts it inside the

repo or somewhere that your agent can

access. Essentially, every time your

agent is doing work, it might need to

explore the repo in a fresh context

window. And if that exploration is

difficult, so it's an external API or

it's somewhere that's hard to access,

then you'll want to cache it in a

research.md asset and you'll definitely

want to run a research phase at this

point. The next step after research is

to get to prototyping. Now, in the

prototype stage, we're still not really

sure what we're actually building on

even maybe why we're building it.

Prototyping is really important if you

need to impose your taste on the

outcome. words, maybe you need some UI

that needs to look a certain way or

behave a certain way. You're not quite

sure which one to do. What I tend to do

is just chuck up a bunch of different

ideas on a throwaway route, which is

kind of like the LLM showing me all of

the different ways it can think of to

build out the prototype. I then iterate

on the prototype inside a couple of

sessions and say, "Okay, now that one

looks like the best." I found that doing

this early is absolutely essential

because then you can actually commit the

prototype to your code base and then

make that available to the agent when it

actually goes to implement it. The next

step, we are in step four now is to

create a PRD. Now that we understand a

bit more about the kind of like external

APIs that we're using in the research

phase, now that we understand a bit more

about the prototype and we've actually

seen some code, it's time to start

actually properly describing the

destination. We should now feel

confident in ourselves that we can kind

of like understand the end state, what

we're trying to create at the end. We

won't know all of the implementation

decisions yet. We will just kind of know

the basic stuff that the user is going

to see and the way that it's going to

behave. We don't have to call this a

PRD, by the way. This is a PRD is a

product requirements document, but

really it's just some kind of document

that describes the end state of where

we're going. Now, in the process of

creating this end state, we really need

to hammer out the design. And this means

we need to prompt the agent to

absolutely grill us walking down every

part of our decision tree. I have a

write a PRD skill that is purpose

designed for this, which I will link to

below if you're interested. But once

we've created the PRD, then it's time to

actually start breaking down the PRD

into some kind of implementation plan.

For those of you who are not developers

or you've never used a, I don't know, a

Kanban board or a Jira board or anything

like that, a Kanban board is just a list

of tickets that have blocking

relationships between them. We're

essentially just describing the work

that needs to be done. So, I then have a

separate skill for turning my PRD into

separate issues. We could create a

single sequential plan that turns the uh

PRD into like actual code, but with a

Kanban board you actually get to

parallelize really effectively. And so,

I can just literally go on my Kanban

board, find all of the tickets that

aren't blocking, and spin up an agent

for each one and get it to resolve it.

But of course, what I'm starting to talk

about here is execution. So, in some

kind of loop here, run a coding agent to

execute all of the tickets on the Kanban

board. Most times you won't need to

parallelize this. Most times a

sequential agent just working through

each ticket will be enough. And for me,

this is a Ralph loop, which works

really, really effectively with this

setup. And I'll drop some links below on

writing about Ralph that I've done. Now,

finally, once you've done with

execution, you've got a completed asset

for you to actually look at, then you

get the agent to create a QA plan for

the human to QA the completed work. And

what this usually results in is more

tasks in the Kanban board and going

through the execution loop again. So,

you will tend to loop these last three

steps quite a few times until you

iterate towards a perfect product. And

QA here also involves a human actually

going and reading the code that's been

produced during the execution loop. That

might not always be needed, especially

if you're using a kind of gray box

architecture that I've talked about in

previous videos. But overall, these

seven phases are the things I'm thinking

about whenever I'm working with an AI

agent. We start with the idea, some kind

of app or feature or refactor. If we

know there are external dependencies and

difficult to execute explore phases,

then we cache it in a research phase.

And by the way, this research generally

only lives for the lifetime of this

sprint essentially, or the lifetime of

the idea that we're imposing on the app.

The reason for that is that research can

go out of date, or it can just rot away

essentially, and actually cause our

agent to take a wrong turn where it's

not needed. If I need to impose my

taste, then I will use a prototype here.

So, I'll really just sit with an agent,

human in the loop, to hash out some

ideas. This is not just for design as

well. It can be for a software

architecture, too, or let's say testing

something out with an external service.

This is an essential step because by the

time we get to the PRD, it's a little

bit too abstract. You really need

concrete feedback first. Then I write

the PRD, which is the documentation, the

spec for where we are going. Next, I

make a kind of understanding of the

journey towards the PRD by turning it

into a Kanban board. I generally use

GitHub issues for both the PRD and the

Kanban board, by the way. It's just an

easy thing I found. Although GitHub

doesn't have yet a kind of built-in way

to represent blocking relationships

between tickets. So, you might be just

better off with something like Linear,

which does. Once the Kanban board is all

ready and set up, then I execute it in

some kind of loop. For me, that's a

Ralph loop. You could also, I suppose,

do execution human in the loop style,

where you sit and execute the tickets

individually. But I generally find with

all of this setup, with the research,

with the prototype, with the Kanban

board, with the PRD helping it, you can

totally run this execution loop AFK, and

the results will be really good. And to

make sure that they're really good, we

then enter a QA phase where we get the

agent to produce a QA plan. Then a

human, yes, a human, yep, we're here,

actually walks through and QAs the

completed work and then produces more

tickets for the Kanban board, which then

goes and executed, more QA, you get the

idea. So what do you think about this?

What did I get wrong and what am I

missing here? I imagine these phases

will grow to eight phases and nine

phases as I get more ideas. There's no

explicit mention of code review here,

really. I suppose I could do that as

part of the execution flow. I suppose

maybe it comes under QA, but you know,

it's definitely an essential step to

producing good code. By the way, you can

tell that I care about good code and if

you do too, then you should check out my

newsletter. But whether you sign up or

don't, thanks for watching and I'll see

you very soon.