I don't consider BMad vibe coding.
I think of it as the antithesis of vibe coding because you're
actually putting some thought in working with a plan.
Today's guest is Brian Madison, creator of the BMad Method, a
spec-driven AI development framework that transformed his
team from skeptics to 100% agentic developers, now used by
a community of 30,000 engineers worldwide.
What I really started to notice early on with the AI is that it
can be an amazing facilitator. It's almost like pair
programming. If you can explain, what is BMad
Method? The BMad Method right now has
multiple workflows. You work with a product
manager to produce a PRD. You work with an architect to
produce your architecture or solution design.
Each of these artifacts will eventually produce what are
user stories and epics to break your work down.
Product manager started seeing this and saying, wow, this can
actually help me produce better PRDs than I ever had before.
What kind of impact do you see? Is it like productivity impact,
the number of people becomes lesser?
We're at a point now where a single developer can definitely
finish a user story much faster. A user story that used to take a
week, maybe it takes hours or a day now.
When the work is defined, the output is gonna be quicker.
As we develop better tools, it will get faster and faster.
If the unit of work used to be the user story, I really believe
very soon, the unit of work has become the feature or the epic.
Engineers now kind of like lose their identity because code is
largely written by AI agents now.
A lot of developers, their identity is tied to how good or
how fast they can type the code. It's just another abstraction,
right? It's you're almost becoming
more of a leader of AI. One of our greatest skills is
the ability to take a problem and decompose it into small
things. That is not a natural thing for
most people, which is why we're gonna work with AI so well.
Hey, quick pause. My goal with Tech Lead Journal
is simple. Learn from the best in tech so
we can all grow together. If this resonates with you, hit
subscribe to follow the channel.
It's the biggest way for you to support the show and help us
keep bringing great guests and insights to you.
Thanks for being here, and let's get back to it.
Hello guys. Welcome back to another new
episode of the Tech Lead Journal podcast.
Today, I'm very excited to meet someone who is the creator
of the BMad method, B-M-A-D. So I haven't heard about BMad
method before, but someone in my community actually mentioned
about it, and he found it really interesting and useful to
use it to apply agentic AI and all that for your software
development. So I think, today, I'm really
looking forward for this conversation.
Brian Madison, welcome to the show.
Thank you, Henry. I'm so excited to be here.
And that's so cool that somebody in your community, you know,
let you know about the BMad. So I'm happy to be here and talk
to it about, you know, talk about it with you.
It's very exciting. Yeah.
So maybe before we go into the BMad, so when I did a little bit
of research looking at your background, one interesting
thing that I found is that you actually started in the US
Army first before going into software engineering, software
development. So maybe tell us this unique
background, how did it shape you?
And what actually brought you, you know, the knowledge from US
Army to software engineering? Yeah, sure.
Henry. Yeah, that's a great question.
I started out actually in electronics and engineering,
so I've pretty much been in engineering all my life.
You know, I guess I should go back even before the Army when
I was a child, you know, I grew up with a Texas Instruments
computer and I started, you know, probably programming when
I was, I don't know, I don't even — Like I remember being in
kindergarten and typing away on computers.
But I really had a love for computers and electronics and
went in the army to do that. It really did shape me in ways
I never expected. I know this is gonna sound a
little cliche, but it really did teach me leadership.
I probably grew up as a child with not a lot of
self-confidence maybe, and I really developed a sense of
self-confidence and leadership in the army that I don't know if
I - maybe I always had it - but I really developed that.
In the Army though, you really do turn, you know, get to lead
in interesting situations. And there's some things that I
learned there that have really — even now I was thinking about
this the other day — it really plays in my career right now.
When you're leading, you know, you have to show
self-confidence don't always have that for the benefit of the
people following you — and this really applies even in the
workplace when you're, you know, leading, when you're the
tech lead on a team — you have to show some confidence and
leadership, but you also have to place trust on your team.
You're responsible for the team. You are the owner at the end of
the day. You are responsible for the
actions of your team, but you have to trust in your team and
delegate. And I think, I learned a lot of
that because it's very easy to think you have to do it all, but
you really learn when you're managing a large group of team
in the army or a squad. You have to really rely on the
people on your team. And that's, you know, something
that's hard to do at first. And I really learned that.
Another great thing that happened to me in the Army
though, Henry, is I got very lucky.
I was assigned to a lot of NATO units, which means I was
working with the Dutch and the French and Canadians, and so
many different countries. So I was assigned in these units
with very diverse groups of people that I would've never
been exposed to. I got to travel the world and
get outside of the bubble of America.
A lot of people that grew up in America, they're kind of like
in this bubble. I loved traveling the world and
just meeting people everywhere, and I really have
carried that through all my life.
I really strongly believe in good, diverse teams with
interesting perspectives. And I don't — I mean, maybe I
would've developed that over time —but I really enjoyed just
that opportunity to see so many different perspectives and
meet people from so, you know, so many places.
So that's really all. Probably indirectly, shaped my
career. And then when I got out of the
military, it was an easy transition into, still working
for the Department of Defense. That's what really transitioned
me into working on simulations and computers.
And I realized I really loved just working with computers
and software and programming, and kind of made a career out
of it since then. So it really, you know, it
really shaped where I am now. So it's been a long time, Henry.
It's been, you know, over 20 years now since I've been in
the military. And so it's kind of interesting
thinking back on it and how it has kind of shaped where I've
ended up. Yeah.
Thanks for sharing your background and your story.
So definitely very interesting journey, I would say.
And you mentioned about self-confidence.
From many engineers that I know, some of them actually kind of
like lack self-confidence, especially, you know, in a big
team set up or maybe talking to executives.
Some engineers really did have challenges, especially, you
know, when conveying messages and they're somehow not
confident, especially talking about technical stuff.
Maybe from your point of view, right, from your experience,
because you have turned yourself to more self-confident, how
would you advise people to kind of like be more self-confident?
You know, that can be something that's really hard at first,
especially if you do struggle with self-confidence.
But a few things that I use, and I have shared this with other
people, is if you cannot explain an idea, it doesn't matter how
good it is, if you cannot convey the idea.
So sometimes you have to believe in what you're doing and just
share the idea with confidence. Some people will say fake it
till you make it. I don't know.
That's, I don't know if that's really the right way to say it,
but you just, you gotta develop that, whether you feel it
inside. Everybody suffers from imposter
syndrome. I still do, Henry.
I mean, I'm feeling it right now, right?
But like, should I really be on this podcast?
But no, I, actually, I'm happy to be here and I believe it.
But everybody's gonna have that voice of self-doubt or many
people will. You just gotta remember that
not everybody sees, you know. They're listening to you because
they believe you have something to tell them.
I believe I have something to share with you, Henry.
I believe you have stuff to share with me.
So whether we have that voice in our head, just remember that
is just the voice in your head and not everybody feels that
way because or else they wouldn't even be listening to
you. So feel good about yourself,
share your message. But as engineers, a lot of times
we focus on the code and, you know, the beauty of it and the
technical details. But share it with confidence to
really explain what it is you're doing to your audience so
they can appreciate it. I think just sometimes trying to
get out of your head, it's easier said than done, but this
is something that can be dealt with and built up over time.
And sometimes it takes time, but I think everybody can get
there. If you work at it, it's a
skill that you can develop. Yeah, speaking about imposter
syndrome, definitely, I also feel it. you know, even though
how many years of experience you have worked.
Especially these days, especially all these
technologies seems to advance rapidly.
You know, you won't know everything, right?
So definitely always there's a imposter syndrome, especially
people who work in tech. And yeah, being confident is
something that can be trained. So I think for everyone who
listen, if you're not confident, you can train that
maybe in a smaller scale. I really, really I believed
that too, Henry. Yeah.
And I think that's a, you know, I think that is a good
reminder for people. And I, still tell that to
people, because I'm pretty confident when I'm speaking in
front of people, when I'm presenting to a board or to
leadership and people see that, but they might not realize
that as leaders we still suffer from that weird voice in our
head, right? it doesn't necessarily go away.
But when you're — I know when you're new in a career, you
feel like, wow, do I really belong here, right?
Or wow, I got lucky getting this job.
But just know that everybody has gone through that.
It's a universal feeling that I think most go through.
And I think as leaders, if we share that we even still go
through that sometimes, I think that can actually help build
some self-confidence and make people not feel like, oh, I must
be weird because I'm feeling this.
Because I used to feel like that and I'm like, wow.
Like I remember when I was, you know, new in my career.
I used to have those thoughts and not think that anybody
felt that way. But then you kind of start to
realize it's universal. Yeah.
So let's go into your the BMad thing, right?
So first of all, I would like to clarify what does BMad stand
for? Because I see a couple of
different definition, but I also kind of like see your name.
Brian Madison. Is this like Brian Madison as
BMad? So tell us what does it stand
for actually? It really started out as just
people — first of all, Henry, if you like, you can't call me
BMad. People actually call me BMad
in my day-to-day life. It is just been a nickname for
a long time. And when I was starting BMad and
I think we'll talk a little bit more about why I started
BMad and how it started. It did, it did not start out as
this grand vision where I needed to put a good name on it
or anything. So I stuck with BMad and I made
the acronym match something. When I was starting BMad though,
I really was trying to map processes onto a way of working
that I've always worked, which was Agile.
I've been working, you know, for the last 15+ years out of my
25+ year career using Agile methodologies.
I've been involved in Agile transformations.
And for me it was a very good thought framework, so I came up
with the breakthrough method of Agile AI-driven development.
Over time I realized it's very hard to say.
It's very long, and it actually ends up spelling like
B-M-A-A-D-D. So it doesn't even work that
well. But for what I was doing, it
actually does make sense. So, yes, it is my name.
It is the breakthrough method of Agile AI-driven development.
But as the platform and what we've been building as a
community has evolved, I now just call it Build More
Architect Dreams because — we'll talk a little bit about
what the BMad method is, but it's become more than what it
originally meant. So yes, there's not a clear
answer, Henry. It means multiple things.
But, you know, it's funny, I was watching another podcast or a
video, and I didn't even know about it.
I'm watching it. And it's funny because like
halfway through the host just realized, oh, wait a minute, did
this guy just name it after himself?
And he, so, so yes. So I don't know.
It's funny story, I think, but yes, the BMad method means
multiple things. But it really is about taking a
way of structuring Agile, and, you know, a way to think about
working in an Agile method with AI to do context
engineering at the end of the day.
Right. So definitely it's a fun trivia,
right? So for people who are kind of
like maybe confused, what does it stand for?
I think maybe, we'll, let's just call it whatever that is name
in the GitHub, which is like, Build More Architect Dreams,
right? Or maybe simply your name as the
creator. You know what's funny, Henry, is
a lot of people will like use AI just to create like an
article about BMad. Maybe they wanna just like, you
know, put something up on their social or whatever.
And the funny thing is, it's a little bit better known now by
the models, but the older models, like every time I see
a different article about BMad, it has a different acronym.
Because the AI would just like guess what BMad stands for.
So like if you Google it, you might find like a hundred
different answers just because people keep putting up
different articles and it just whatever it spits out, it's
like. So it's actually pretty fun
'cause sometimes I'll see those and I'm like, dang, I
should have used that one, I actually like that one better.
Right. Speaking of, which, right, so
maybe if you can explain what is BMad method?
Because I assume some people might have heard about it, but
some may not, right? Especially even like for people
who have used, you know, a lot of AI in their software
development, some may not have heard about it.
Yeah, lemme give you a good explanation.
The BMad method as it is right now, if you go to, you can
look at my YouTube channel, there's a masterclass on there.
Or you can go to the — if you just go to GitHub and you
search for the BMad method, you'll find it.
What it is right now is a way to do context and spec
engineering. But what it does, as I
mentioned, is it maps these Agile personas and ways of
working into doing Agile. So when you start out with a
project, if you've done vibe coding before, Henry, and I
think everybody's tried vibe coding at this point, you
eventually hit a wall. Even now the models are very
good. You know, they can almost one
shot very simple applications. But as you keep working with the
agent mode in these tools, eventually you hit a wall and
you still hit a wall where — and this is kind of the vibe
coding thing, right? You just, you tell it to do one
thing and it starts doing it three different ways.
Or it gets stuck in these death spirals where it starts testing
over and over again and then it will just randomly start
throwing stuff away. The BMad method right now has
multiple what will be skills, but they're just workflows right
now, organized in a way to work through.
So you work with a product manager to produce a PRD.
And you know, a lot of people produce PRDs and then they
jump right into the coding. But what I found is just a PRD
on its own always isn't enough. So then you can work with a
design agent, a UX expert to help produce your design.
You work with an architect to produce your architecture or
solution design. And I can go into the benefits
of some of these and why these different artifacts matter.
But each of these artifacts, if you think of it as a funnel,
Henry, they kind of each feed into the next one to
eventually produce what our user stories and epics to break your
work down. And then those get filled with
context, with a different agent and a different process.
So then when you actually develop with the agent mode,
you take your story, it has everything it needs in that one
user story so the agent mode doesn't have to spend a lot of
context reading all of these different documents and trying
to figure out what to do. So the theory is when it
actually finally picks up that user story, it can pretty much
know everything it needs to know to implement the story
without making bad decisions. It's gonna know exactly what
libraries and frameworks you're using and make good decisions.
But the difference I think between the BMad Method and
other frameworks, especially when it first started, there's
a lot of, you know, similar stuff out there now.
But I didn't wanna just come up with something where I just
give the AI my idea and it spits out all these documents and
give them to me. One of the things I really
realized, it's funny but the BMad method has been going about
a year now, almost a year. A lot of people treat the AI
like a ChatGPT or, you know, even the agent mode.
They ask it a question, give it an answer.
I have this function, how would you refactor it?
What libraries should I use to do X, Y, Z?
What I really started to notice early on with the AI is that it
can be an amazing facilitator. I come from a background like
you, Henry. I've been an engineer, like I
said, for 25 years. I know a lot of things and I
have opinions. And I think especially as
engineers, and this is something else we can talk about
if we have time, but don't think of the AI as just a
replacement for your own skills. So the way I've built the BMad
method is when it goes through these workflows, it's having
multi-turn conversations with you and trying to pull the best
information out of you. It's gonna ask you questions and
it will give you suggestions, but it really tries to teach you
as the expert, working with the AI as a partner.
It's almost like pair programming.
So you might not be an expert product person because you're an
engineer, but working through the PRD, it's gonna ask you
things that you might not normally think of.
Like, you know, do you need admin?
What are the user journeys? What are the flows through your
system? It will help you come up with
more requirements. Because the more that you can
kind of specify upfront, the less you'll be having to change
when you're actually building your application.
So that is really why you wanna go through this whole funnel.
But there's other features also of the BMad method.
One of the things that people really seem to love, and this
surprised me, but we have a brainstorming mode at the very
top of the funnel. So if you don't even know
exactly what you wanna do, this will do brainstorming with
you, acting as a facilitator. And people might have done this,
you know, if you go into like ChatGPT or some of these other
ones, there are brainstorming modes in there, but I've
developed something that I feel is really special because
people have told me sometimes that's all they use.
And people have told me they've spent six hours just using the
brainstorming agent, using it for everything across their
lives, which really surprised me.
You know, it's funny when you release a piece of software and
you start learning how other people are using it, it gives
you new ideas. And so that's what happened with
here. So the BMad method has evolved.
I know this is a very long answer of what is the BMad
method. I hope this is making sense,
Henry. But it really is this platform
with all of these different skills and tools, but they're
all meant to work together to kind of eventually produce
software. But yeah, the brainstorming is
special because it has all these techniques in it.
It's working with you. I am horrible at brainstorming.
If you give me a whiteboard like Miro or something and they
have these brainstorming methods like built into it, I stare at
it and it gives me the rules, and I still, I don't know, I
just draw a blank. And I used to always think I'm
not a creative person, and so many people have told me this.
I never realized it was, I was a creative person.
When you treat the AI as a facilitator, and it is not
doing the brainstorming for you, it's perf, it's specifically
set up not to do the brainstorming for you but to
give you prompts and ideas and work through these different
interesting techniques, all of a sudden you're coming up with
stuff and then it helps you kind of distill down what you came up
with. I believe I'm a very creative
person now. And that is what so many
people have told me. So it's just so, it's so cool to
see people that think they are not creative.
Now all of a sudden, you know, coming up with creative ideas
through the help of AI, but it is not like the AI coming up
with the ideas. It really is them.
So that is really, I think, the special sauce of all the BMad
method is it treats you as somebody with ideas and it's
not just doing all of it for you.
So let me pause there cause I know that's a lot.
Yeah. Speaking about creativity, I
think that kind of like just reminds me that to be creative,
it comes back to the questions that you ask, right?
Like if you naturally don't think in questions, sometimes
you can get stuck, right? But if you are always like
curious, asking different questions, different ways,
different perspectives, I think you can be creative.
Yeah. And that's the cool thing about
the brainstorming method also. Like if anybody wants to try out
the BMad method, if you try nothing out, just try out the
BMad method brainstorming. It's different than everything
I've seen out there. It's about 50 different
techniques built into it. Depending on what you're working
on, you'll tell it what you wanna do and it'll suggest some
of the techniques. But there's some crazy ones in
there. There's like alien visitors, you
know, and it kind of guides you through if like there were
aliens seeing this for the first time, what would their
perspective be? There's, just, there's idea
gardening, there's some of the classic ones like the thinking
hats and, you know, the seven ways of, you know, dissecting a
problem. But they're all just very
creative. And again it will, like you
said, you hit it on the nail. It's the questions it asks you,
and you'll come up with some very interesting things.
It's a lot of fun. I love doing it.
I, and I even use it for things outside of software
engineering. It's a lot of fun.
So maybe since I'm not like a very advanced BMad user, in
fact, I have never used it in my project before.
So if I can understand it further, first, it's like you
try to solve this kind of like context engineering problem,
especially when you build applications that evolves over
time, right? Especially complex software, you
kind of want to build some kind of context knowledge base
so that the agent will be able to refer to it and always use
that to produce the next output, right?
And the other thing is that you have these different kind of
like personas built in. Maybe some people is, like you
can associate that as like agent skills these days, like
where you have different skills for different purpose.
And, yeah. And then the third thing that I
can associate BMad is actually with spec-driven development.
Maybe let's start from there first.
Is this a different flavor of spec-driven development or is
it something different? Yeah, Henry, that's a great
question. You know, when I kind of gotta
go back to when I started BMad, there was no name for these
things. Like even when I started it,
there wasn't really a name for vibe coding and then like, vibe
coding became a very popular term.
And I don't consider BMad vibe coding.
I think of it as the antithesis of vibe coding because you're
actually putting some thought and planning upfront and
working with a plan. Context engineering was
something I didn't have a name for.
It's funny. I must be like many engineers,
you know, they say naming is hard.
I'm not good at naming and branding things, I guess.
But we were doing context engineering before that was a
term. And if you think about what is
context engineering, again, it's taking those ideas, getting
it down to something. There wasn't really a name for
it yet, but this thing, I was calling it the user story
because that's what I had for my own vocabulary of working in
Agile. So, you know, so long, with
acceptance criteria in it. So a very good user story is not
just, you know, as an X, I wanna do Y so that Z, but it's
also putting in good BDD or some kind of style of acceptance
criteria. Just in the quote 'real world'
before AI, if you do your user stories that way when your
developers pick them up, they really know what needs to be
done for the story. And you can specify things.
By building the stories in that way with the BDD, I was
noticing these huge improvements in the agent to actually be
able to build these complex software applications 100%
without me having to type the code.
And this is even a year ago when the models were nowhere
near what they are now. So that was context engineering.
And what we are really producing are specs.
So they call it spec engineering now.
And that really is what BMad is producing for you.
And now we're starting to lean into the same language and we're
calling things skills and context engineering and spec
engineering. But really the stories with the
AC in them, you know, organized into these epics, are
specifications. And, you know, just like what
we now call spec engineering, it's basically the same thing.
So it's a spec engineering framework.
But the difference with BMad, again, is that you can start
at the top of this thought funnel and it really helps you
plan and think about what you're gonna need before you produce
all of your specs and have it start working so you're not
hopefully changing this much halfway through or forgetting
major features or, oh, I forgot I need a database or I need
authentication. So it will guide you and help
you through that. Now you asked about the agents.
Henry, when I first made the BMad method, and maybe we can
talk a little bit about why I even made it, but it started
out as just six files. So I knew that I wanted to
create a PRD, and then I knew I wanted to create this like
tech stack list, which I called the architecture, and I knew
if I was working on UI, I wanted some UX information there.
So I just, at the time, you know, all of the prompting
guidance was give it a persona, you know, tell it like you are
a professional product manager and you have all these
attributes. And in the single file, it was
talking about here's the PRD and this is the information that we
need, and do this in a facilitative way.
So, you know, you're getting this information out of the
user. It grew over time to be multiple
files in a separate agent, because I wanted to give people
the ability to customize these things.
But the reason the agent is there is because it started out
as kind of tied to the PRD. It was kind of a thought
process. In the real world, when you're
working in Agile on a lot of teams, the product manager is
producing the PRD. Or the lead engineer, the tech
leader, the architect is producing the solution design.
So it's kind of just how it evolved.
But now with agents in the BMad method, the agents have the
ability to have memory and remember things, and can
evolve over time. So it has become much more
than as it started. There's another thing that I
should also mention about the BMad method is it is part of a
platform now. So there is something called
the BMad Builder. It's going through some rework.
It will be up really soon. But it's basically a skill
builder for workflows. So you can create your own
custom workflows and work them into the BMad method.
Unlike most skill builders though and skills in general
is, in the BMad method, they all register into a help system and
they all have sequencing and information.
So as you install different modules, which are like apps for
the BMad method or plugins, you know, is what Anthropic calls
them. The interesting thing is they
all have information about how they're related to each other
and it dynamically populates the help.
So if you don't even know what to do with the BMad method
'cause it can be overwhelming at first, you can just ask the
help and describe to it what you wanna do.
And it will suggest, oh, you don't really know what your
idea is yet. You might wanna start with the
brainstorming. Oh, you installed the Creative
Intelligence Suite and you need to work on a pitch.
Well, maybe you want to use that module and use its
storytelling for business workflow to help you kind of
think of these ideas. So the BMad method has also
grown to be a lot of different modules.
The community can also contribute modules.
And it evolves to help you with many different things.
So it's more than a skill collection because it all ends
up being tied together. But it can do now a lot more
than just helping you get to the end and do software development.
Yeah, sounds like... I know that was a very long
answer. Yeah, sounds like it has grown
since you started it like a year ago or so, right?
So it has grown into like more this framework, modules,
plugins. And I'm quite curious when you
mentioned just now, right, why ...
Like the story why you actually started BMad method.
Maybe if you can share with me, how did it started in the
first place? Like what kind of problems do
you see? Yeah.
That's a good question. Thanks for asking that, because
I think it helps explain where it is also now.
Henry, a little over a year ago, I work at a company called
Extend. It's a startup in San Francisco.
It's a, you know, smallish company.
And I started out as a staff engineer and now, you know, I
manage teams across a product engineering work.
And we were using Copilot, and if you remember, you know,
Copilot like two years ago, it was basically a very good
autocomplete, right? Like at the time it seemed like
magic. But a little over a year ago,
you know, Cursor's started getting very big.
I assume you're familiar with a lot of these tools, Henry?
Yep. Yeah.
So Cursor came out. I was working in this
organization and we were looking at other tools to
replace Copilot. People loved Copilot.
You know, we'd been using it about a year.
And it was great for autocomplete.
You could like show it a function and it would help you
like rework the function. And it did seem like magic at
the time. When ChatGPT like really started
getting big though, like when that 3.1 came out, we started
seeing engineers using ChatGPT instead of Stack Overflow,
right? And it was getting good at
answering questions. And then Cursor came out.
And so we were talking about it in the organization and a few
of us started playing with Cursor on the side and we were
enamored with the agent mode. It was amazing!
Even for the time, it was nowhere near as powerful as
any of the tools we have now. It seems like generations ago.
It's hard to believe it was only a little over a year ago.
But we rolled it out across the company.
Now as I was managing my teams, I saw that they picked up
Cursor and they liked it because it had like a very good way to
do autocomplete on multiple lines.
But people were still typing code.
But a few of us in the company, mostly working on like smaller
tools or utilities, we're using this agent mode.
And I was seeing this disconnect between the engineers on the
teams over the months, the few months of us rolling out Cursor.
Nobody was really using the agent mode to talk to it and
actually write the code for them.
But I was seeing other people in the company, like a few people
like myself and a few others, we were able to get it to do a
little bit more. But nothing big or grand that it
wasn't working very well in brownfield.
It struggled a lot. It would run out of context
really quick. The disconnect from what I was
seeing on YouTube, Henry, though, was these channels
showing Cursor and these tools and these amazing claims.
You can have no experience, you don't even need to be a
software developer, and overnight you can build your
million dollar SaaS application. And I kept seeing these videos
and they were impressive when you would watch them, but I'm
like that seems like a little bit farfetched.
I don't know about that. But there was this wide
disconnect and I kept seeing those videos.
And then at the other end of the spectrum, I was seeing
engineers in my company not really wanting anything to do
with the agent mode. It just seemed like a fad or
maybe you could use it to ask it a question like ChatGPT.
But there was this chasm. So I became obsessed.
I'm like there has to be more to it.
So as a leader of my team, I wanted to figure out is there
something to this agent mode because Cursor's making these
claims. Sonnet 3.5 is supposed, at the
time, was supposed to be this amazing new thing.
But everybody was using it like autocomplete.
So I started, before there was a term for vibe coding, I was
basically vibe coding at night. I would watch Netflix and just
vibe and it was fun. And Cursor at the time was very
slow. You would hit this thing, they
would call Slow Mode. I don't know if everybody knows
Slow Mode, but after you would use up your tokens.
It would like make you wait for 15 minutes before it would
start processing. So it was great for watching
TV on the couch. Every once in a while you would
look back and give it another command.
But that's when I started seeing the vibe coding curse, right?
I had an idea for a pretty complex application at the time.
And I gave myself the challenge, I'm gonna figure out how to
get this agent to build this complicated application,
multiple stacks, front-end, back-end, database.
And get to do it without me typing any code.
And I would do this over and over again, Henry.
And I started to kind of realize like, oh, it gets this far and
it starts breaking. Or it starts randomly doing a
test, it fails, and it says, well, maybe if I just throw out
the database and put in another one, it'll work better.
And if you're not paying attention, it'll do these
crazy things. So I said, well, if I have this
file that says we are using these libraries and frameworks
and only use those, I started to notice that, oh, now I can
get a little bit farther where it doesn't start doing those
still silly things. And then I started to realize
like, oh, if I actually create a prompt file, I don't have to
keep repeating myself, and it gets a little bit farther.
Oh, what if I take a PRD, and have it lean so it knows all
the requirements upfront, and it gets a little bit farther.
And it's just, it kind of evolved out of this loop that
I was doing. And I got to a point where I
could actually build this pretty complex application.
It was exciting. And again, this is like a year
and a half ago now with old Sonnet 3.5 in Cursor with this
limited context window and it was doing this thing.
And that's another thing is with Cursor, you start to realize,
wow, this thing starts hallucinating really quick.
And this is not like a knock on Cursor right now, but this is
just the state of things at the time.
So you had to start coming up with your own ways of like,
oh, if we have files and we break it down into smaller
segments, it actually does better.
So why don't we call that a user story?
And so thing kind of started forming where basically I'm
taking what I've done for the last 15 years with Agile and
thinking in this Agile fashion. I said it actually works really
well to use that as a thought framework, as a model to kind of
apply it. Here we're doing the same thing.
We're talking about a problem, we're doing a product inception.
We're breaking it down, we're doing a solution design, and
we're coming up with stories. Again, context engineering,
there wasn't a name for it yet. Spec engineering, there wasn't
a name for it yet. So I was so excited.
I'm like, this is amazing. I can take this back to my team.
It is gonna revolutionize everything.
I brought it back and nothing changed.
So that was the surprising thing.
But I put it online and it did start to, you know, catch fire
there with that first one. I just put it up there to be
this thought framework. I never thought it would become
anything it is like today, Henry.
And it started resonating a lot with people online.
Product managers started seeing this and saying, wow, this can
actually help me produce better PRDs than I ever had before.
Because as a professional product manager, it's
reminding me I forget these things and it's actually
helping ask me the questions of. So it's funny because product
managers started reaching out to me saying they were using it.
And then people that have never written code before were
starting to use it. And it's like they're learning
like how Agile works and how industry works and people
started learning from it. But I still wasn't seeing it
catch fire in my own organization which was the whole
point. So I did this technique, Henry.
If I can go into maybe another little story, 'cause I think
this is useful for a lot of tech leaders right now because you
might be seeing this in your own organizations.
And since I've done this, I've actually talked to a lot of
companies and helped transform my own organization and others.
So there is a success story here at the end.
But if you just give engineers this thing and say, hey guys,
I figured it out. If you just do a PRD, and do
this, and do this, it's gonna give you this magic.
It's gonna work. Engineers, I think, have egos.
We all have egos, and it's like, no, I'll figure it out myself.
And they don't really come to the same conclusions.
And so they kind of will still feel like, yeah, the agent mode
is good, but I'm still gonna go back to doing it this other
way. I'm faster.
What I did with every — and by the way, it's not for lack of
trying. Like I would tell people to try
it. They would try the agent mode,
especially in legacy projects where you have big code bases.
It's like, nah, it's still not figuring it out.
It's getting it wrong. It's messing up the code.
I'll just go in and fix it. And you kind of fall back
because you're under the demands of your current sprint.
You know, your team probably wants you to get things done.
And a lot of times you don't feel like you have the space
to really experiment. So you just kind of fall back on
what you're, what you need to do.
We had done AI sprints before in our company where the goal was
let's try to come up with an agent or let's try to come up
with some way to put AI or everybody come up with a
creative use of AI. And those were pretty
successful. And we did some hackathons and
it led to some good ideas within our company, even, you
know, for our products. But I said, what if instead of
an AI hackathon where the goal is to come up with some new AI
feature for the product, I had everybody do what I did for
months in a two week sprint. So with my team, I took my team,
Henry, and I said, we work in two week sprints.
If people don't know what a sprint is, it's like a
two-week block of work where the team commits to so much work
at the beginning. I assume by now everybody knows
by Agile, but just if people don't, right, you commit to a
group of work and by the end of the two weeks, the team
really tries to push and get that two week work done.
I said for this sprint, what we're gonna do is everybody's
only gonna have one story. Each will be assigned a story.
That's not something we normally do in Agile.
We want it to be more organic, but I said, in this case,
everybody will have one story to do.
This is a piece of work that would normally take you two to
three days to do. But the only caveat is everybody
has to use the agent mode. You cannot type any code.
And if you get it done, I want you to do it over again and keep
doing it and refining it. This was the most transformative
sprint, because first of all, it gave everybody the permission
to not have to worry about getting the thing done and
moving on to the next thing. And even in a normal sprint, if
you tell your developers and your teams, don't worry, like
learn how to use these tools, take some time to do it, a lot
of developers will still self internalize that, yeah, well I
can take the time. I really still need to get the
work done. And that takes the priority.
So by taking the pressure off for two weeks, it gave everybody
this permission to fail. The permission to fail, right?
The permission to take a chance and see what happens.
Henry, when I tell you this was the most transformative thing
I've ever seen, like it's not an understatement.
People started coming to the same conclusions.
And basically inventing spec-driven development.
You know, that's why it's funny because all these frameworks
are coming out and it probably seems across the industry that
people are always kind of coming up with the same ideas.
Because if you actually go through this and do this, you
start coming to your own conclusions.
Oh, I don't have to repeat myself to the agent every time.
I can just put it in a file and give it that information, and I
don't have to explain to it, hey, I'm a X, Y, Z, and we're
doing this thing and we have to do this.
You might not have the words for it, but you'll come to all
these same conclusions. Not only did people start
figuring this out, but they started figuring out like, oh,
we can save these prompts and it can help me do the same thing
across all these code bases. And I can create an agent
persona and they, it can help me do these things.
Oh, I can give it a task list. So whether you call it a PRD or
a story breakdown or a list of things to do, it'll do better.
And oh, it failed for this reason, but when I start over,
if it has this rule or this thing, it will now get a
little bit farther. Not only did people figure out
how to get their stories and use agent modes, it was
transformative in ways I did not even expect.
All of a sudden people started saying, why do we need to do
error triage manually every morning and look at the logs?
We can now create a prompt that does that for us and pulls
this information. Or, oh, there's this thing
called MCP. Why don't we put an MCP in
front of this tool? Before that, for months I was
trying to get people to like, let's be creative guys and just
think of these things. Whatever it was about this
exercise, not only did people start thinking about how to work
with agent mode, but they started looking at all these
opportunities to start automating their job away and
it became like wildfire. And this is even before like
there was a skills explosion or before the tools were good as
they are now. So if I could give one piece of
advice to every company, if you wanna transform your engineering
team and get them to start using these tools, give them
that space to do it. After that — this is no
exaggeration — a few engineers went from never using the agent
mode to using it 100% of the time, where they've taken it
as their challenge to do everything with the agent mode.
And this is not simple greenfield hobby projects.
Like a lot of people think this only works with a greenfield
or simple projects. This was people working in these
legacy, you know, services that have existed for 5, 6, 7
years using the agent mode. Now since then, this has spread
across the organization and it's been transformative across
product engineering and architecture and design.
And, yeah, it's just been magic. Like I can't explain how useful
that was. So this all evolved from, you
know, trying to do this myself, coming up with this
thought framework, which was the BMad method, and then using
it as a teaching tool to kind of have people do the same
exercise, come to their own conclusions which funny enough
were basically the same conclusions, right?
Having a plan, giving it small bite-sized things, giving it
context. Again, we didn't have the name
for it at the time but it became context engineering.
So let me pause there, Henry, 'cause that's kind of a long
story. But it's just, it was an amazing
experience and it's transformed things.
Yeah. Thanks for sharing such a
beautiful story. I think I can see when you
look back, right? So it's kind of like the
transformational impact that I think you must be proud of,
right? But like which is also a
reminder for, you know, leaders here, listeners here,
right? So I think organizations that
thrive is organization that learns a lot, right?
And give the space for people, you know, to fail, experiment
without kind of like the pressure of always delivering
all the time, right? So I think that's a actually a
very good story. Speaking about, you know, this,
the thing that you mentioned, you know, you can work with
legacy code base, you can work, you know, or purely 100%
agentic. What kind of impact, maybe if
you can quantify a little bit to tease, you know, the
listeners here to give it a try. Like what kind of impact have
you seen? Is it like productivity impact,
the number of people becomes lesser?
Or what kind of impact do you see?
Maybe not just from your team, but other users as well?
Yeah, well let me tie it to the organization first and then
I'll talk about users of the BMad method.
But in the organization since we did that, you know, that was
probably six, six to eight months ago that we did it.
Maybe six months ago, nine months ago.
A lot has changed since then. The tooling has gotten better.
Skills have exploded. We started to realize that this
is not only great for the engineers, but can we help
accelerate product? And you know, again, the BMad
method I told you about, how like product managers reach out
about how it can help them produce better PRDs.
So, you know, training and realizing these tools, like
now this is common sense, but 6-8 months ago we were
realizing that these tools are actually really good for
everybody. So helping share this
information and teaching everybody to start working this
way. And you know what is now a
pretty common term, but we started calling it like thinking
AI native, it doesn't mean like what is the next AI product we
can build or bolt onto our product but how can we start
using AI in all of our workflows?
As a tech leader or a manager, you can use AI to help you
look at data and create feedback loops to better understand
where your team is operating. So, you know, you can use it for
so much more than coding and engineering.
So we started realizing all of these things and there's been
this huge acceleration. There's been a lot of studies,
you know, and I think the general consensus is you can see
productivity gains from anywhere from, some people say
10-20%, some people say even more.
As software engineers, we bring a lot more to the table and not
everything is pounding out code. When you're, you know, a senior
engineer or a junior engineer or anywhere in there, your job
is not to type code all day. And sometimes we lose sight of
that. So AI will help you speed that
aspect up. But it can also help you speed
up the other aspects of the job. The other 60-70% of the time
as an engineer, you're having discussions, you're thinking,
you're communicating, you're having confidence in explaining
ideas to different people in different ways.
Those things don't go away, and those things are still the very
human aspect of what we bring to the table.
It's funny, I just had this conversation a week or two ago
because we are having such acceleration with AI in our
organization and people are getting better and better using
at it. Now everybody is using agent
mode. Everybody is using skills.
Everybody's producing these amazing skills to do everything.
You know, you can spit up a new dashboard to monitor something
in a day now, what used to, you know, take months of planning
and, you know, what tool are we gonna use.
And some developers on my team have started to ask the
question, well, it's fun and it's exciting, but I'm also
starting to lose my, not lose my identity a little bit, but a lot
of developers, their identity is tied to how good or how fast
they can type the code. But what I really, you know, try
to share with people, and I strongly believe this, and I
think a lot of them are also kind of feeling this is, it's
just another abstraction, right? It's like the switch from
Assembly language to, I'll just say to TypeScript, right?
But this feels like almost that much of a gap.
You're able to step away a little bit.
You're almost becoming more of a leader of AI.
You're looking at it, you're planning, you are thinking
about a bigger picture. And I think it really frees you
up to focus on more interesting challenges.
You know, like how to do the for loop or how, you know, like
what is the best way to structure this code.
It's still important, and as an experienced engineer it's still
important to keep those things in mind.
But this also frees you up to think about it in a different
way and plan. And as the unit of work changes
for developers, 'cause I will say this is something that will
happen and is happening now. If the unit of work used to be
the user story, I really believe very soon the unit of
work is become, is gonna become the feature or the Epic.
Different teams use different phrases, but what I mean by an
epic is a collection of related user stories to build a whole
feature. We're at a point now where a
single developer can definitely finish a user story much faster.
A user story that used to take a week, maybe it takes hours or
a day now. And that is realistically true,
that there is faster velocity. When the work is defined, the
output is gonna be quicker. And as we develop better tools,
it will get faster and faster. We can automate code reviews, we
can, you know, I mean, that's a whole other topic, but what I
wanna say is now the developer can be responsible for a whole
epic and maybe even deliver that epic themselves.
So what I see is this transformation coming where
now the developer can be more responsible, or almost
everybody, you know, almost everybody can be a tech lead at
this point in the sense that we call them epic champions or
feature champions. And that's a good way to develop
all the people on your team, right?
Regardless of their level, give them responsibility for an
epic. But now by giving them
responsibility for an epic, they can actually work closer
with the product manager or whoever's defining the epic.
They should really be more involved in that conversation,
understanding it, being able to explain it, and really
implementing the whole thing almost themselves now.
So we are in a transitional period where this larger body
of work will become the unit of work.
But I think it's exciting because it really moves you up
the funnel. Instead of just being handed a
single task where maybe you're not really fully aware of how it
fits into the whole bigger picture, we are being freed up
as engineers now to actually be able to start focusing on
that. I think that's exciting.
Because remember, our goal as engineers is not to, you know,
create the most — I mean, sometimes optimization
matters, right? But it's not the elegant for
loop that you wrote, right? It's not gonna matter six months
from now. It's the features that you're
building to deliver value for the company that you work for.
And so you actually now have the ability as an engineer to step
back a little bit, orchestrate these things to do the work
with you. Still treating it as a
facilitator. Still, you know, keeping your
own discernment and taste in the picture, and bringing your
experience to the table to guide the AI, but you get to
focus on this other stuff. So framing it that way, I think
people are very excited and starting to see that, yeah, this
is good. It does free me up to kind of
look at these bigger picture things and feel like you're
actually having a bigger impact on the company.
Because now you're delivering whole features at a time that
are delivering value, instead of delivering small pieces that
might take three months to actually release to production
and give value. So it's an exciting time to be
an engineer. I wanna very briefly though, say
also, for the BMad method itself, I have heard from many
people that have never done software engineering, so go
back to what I said was the scammy thing I've seen before.
I really did also develop and keep evolving the BMad method
with the community because people were giving their own
feedback. They really do appreciate that
if you've never built software before, if you've never been an
engineer, we take for granted as engineers, one of our
greatest skills is the ability to take a problem and
decompose it into small things, which is why we're gonna work
with AI so well. That is not something people
take for granted. And if you've been a tech, if
you're a tech lead or if you've been in tech tech even
more than a year or two and you've been out of university
for a while, you start to forget that.
It just becomes just an innate skill you have.
You know, you might even do it in the world.
You're thinking about how to cook and you're thinking it in
these small, granular steps, right?
That is not a natural thing for most people.
So that is really one of the engineering superpowers.
So when people that have never developed something and they
first just try vibe coding, they're not thinking about
decomposing it into these smaller problems.
And that's where I think people really realize the magic of
the BMad method is, oh, I've, when it's working with you and
you're not a software engineer and it's forcing you to think
about breaking it down into these smaller pieces, and
actually thinking about like, oh, I never thought I might
need authentication. Or yeah, I guess I do need a UI
to go in and administer these things.
Or whatever, right? Like we take those for granted
so much, but it's helping so many people just get their ideas
down on paper. Whether they build the actual
final application or it still gets difficult for them at some
point, it's been magic and then it's been helping people
plan out their ideas in their applications in a thoughtful,
methodical way. People have reached out to me
that it's helped them build pitch decks and, you know,
launch applications that they've been able to get VC
funding more, that they were having trouble explaining
before. And just working with AI, it
was never doing them for that. So as engineers, remember that
really is a superpower. The ability to break things down
into these small tasks, and that is how, that really is the
magic. And you know, that it really is
the lesson that everybody learned even from this two
weeks, you know, sprint that I did.
Now that I, think about it, I just thought of this now,
Henry, but it really did kind of remind them that just like
humans, oh yeah, if we break this down into small, granular
things and give it to the AI, it can even work well in the
nastiest old code bases and still figure it out because
we're giving it this bite-sized bit of instruction that it can
figure out and do so. Yeah, so that's how it's helped
out both, you know, in the organization and also, you know,
people from all walks of life kind of think methodically.
Cool! So I really like the reminders
that you mentioned just now, right?
So when engineers now kind of like lose their identity, you
know, because code is largely written by AI agents now.
So I think you reminded something about, you know,
moving up the abstraction layers and still using our problem
decomposition skills to actually solve a problem and can
become much more ambitious now, right?
You're talking about, you know, epic level instead of just user
story or individual tasks. So I think those are great
reminders for engineers to evolve yourself.
So speaking about, you know, evolve, evolution, right?
Because one of the challenges working with AI is actually
yeah, definitely, context engineering.
Because if you have a complex system, you know, with large
user stories, large number of features over the time with
large number of developers, you know, changing the code,
sometimes it can lose track and it can be out of sync from
the spec and the code as well. So tell us, how do you actually
solve this with your BMad method?
With the BMad method itself, let's just talk about a
greenfield project for a second, just to keep it simple.
And then I can talk about, you know, more of a legacy
application. But for a brand new application,
one of the places the BMad method does help is just the
better planning upfront. Again, it will help you think of
things that you might forget if you were just doing vibe
coding or even if you just create a quick, simple spec.
You might forget certain features and then you're
halfway through and it's harder to have the AI put those in
after the fact, if you can think of, you know, some of those
things up front. But, you know, there's a
saying, best laid plans, right? It's still, you're still gonna
forget things no matter how much planning.
You still wanna be Agile with it and you're still gonna have to
change things. The PRD, the architecture, and
the specs that you're gonna do, first of all, just like in
the real world, I always look at those as a snapshot.
In the real world, when you've been doing Agile or anything,
you create a solution design. The solution design is a
point-in-time document that I never that I remember keep
around as actual documentation long-term.
Even, you know, before AI, it's gonna evolve, it's gonna
change. It's meant to kind of convey a
picture of what we're gonna build.
But the best documentation is the code itself.
The code is a piece of documentation.
And that's the same with the AI. But you asked how does the
BMad help with that? We do have a few skills in the
BMad method. One is correct course.
So if you're halfway through your build and let's say you
forgot something major like, oh, this relational database is
not gonna work. I need to use NoSQL.
I forgot a major feature, I did not consider authentication.
That's a major change that you're going to use and I hope
the BMad method will help you actually come to those
conclusions before that. But you might wanna change it,
right? We do have a correct course
thing. The Scrum master will help you
do correct course, and it will actually talk you through what
is the impact of your change. Is it something that can just be
worked in with some new stories and kind of change the
flow? Or is it so drastic that you
need to do a replan? And this actually comes from
Agile ideas also, right? This happens in Agile.
You might be halfway through a project and you have to pull
the cord and do a, you know, a quick meeting and figure out,
are we throwing this all out? Are we gonna pivot?
It's no different with AI. So what it will do is it will
help you go through and update the documents as you need to and
replan the stories. And hopefully, you know, you can
just change the stories that are not done and work in your
changes there. So that works actually for both
greenfield and existing projects.
So that's one way that it helps. But I will say the bigger thing
is, the bigger way the BMad method helps, is it does really
coach you and work through trying to figure out most of
these things upfront. And that is the biggest
difference between vibe coding and some of the leaner spec
engineering kits. I mean, I think they're all
good. But some of them are not gonna
really push you to think a lot of these things upfront.
And sometimes that's fine. So in BMad, there is a quick
flow also because you don't always need a PRD in an
architecture up front. If you're working in an existing
project and you just want to add like a new feature onto an
existing, you already have a REST API and you want to add a
new route to it, you don't need the whole B..., you know, you
don't use the whole BMad method. Instead you use the quick flow
or you just make a quick spec, which basically amounts to just
understanding the current state of the project.
The AI will scan and understand your code base.
It will understand your documentation, and if you
don't have documentation, you want to generate good
documentation and context for the AI.
And it will help you generate just the story or the spec
that you need just for the one feature.
So brownfield in some ways believe it or not, is actually
easier with AI when you start to understand these techniques.
And we don't really have enough time to go into a lot of those
techniques. But again, it's giving the AI
the understanding of your code base, working in small
increments. And then you can start doing
magic things. Like even Claude agents can
start doing these things now. You can, or you can give it...
So, you know, Ralph loops are very popular or these things
that can autonomously, you know, work for you.
If you start using some of these techniques that will
actually work for you. And it's pretty amazing where
the tooling is getting to help you with it.
Wow, cool! So many different tips and
trick, I would say, and also embedded inside the BMad
workflow. It sounds really useful.
So maybe if, for people who are kind of like intrigued and
want to give a try, is there any like, I don't know, quick
start, advice, or tips that you wanna give to the listeners here
so that they can get up to speed with BMad method?
Because sometimes when you use a framework, it can be, you
know, super daunting, you know, there's so many different
things. But how do you do a quick start
for BMad? Well, a couple things I wanna
say is, first of all, if you're an engineer, continue to
be curious and just learn the tools themselves.
I would say before even using BMad, if you haven't used AI
or agent mode yet, first, just start with, you know, Claude
Code or, you know, Kimi or whatever tool you're gonna use.
Pick one and learn it well, and try to do the exercise I did
and start to come to some of the understanding of how the
context window works. Why it starts hallucinating.
Why it makes sense to, you know, start new conversations and
not keep the same one going. Because I have seen a lot of
people will come into BMad, and without developing some of
that foundational understanding of just how the LLMs work in
general, it can still be a little bit of a challenge.
So I wanna say any of these frameworks that you use, it is
still important to learn the tool, keep up with what the
tools are doing, and they're evolving so fast.
So learn to use a tool very well.
But then to get into using the BMad method specifically, you
can go to the GitHub. There's an installer, you
install it. Once you install it, you can do
BMad help, which is just a skills/bmad-help, and ask it
questions and it will give you advice of how to use the BMad
method. There is a website,
docs.bmad-method.org. You can go there and there's a
quickstart on there and it will kind of guide you also
through, first you do this skill, and then you do this
skill, and it's, and there's a
pretty simple workflow there. So that is how I would
recommend using the BMad method. But if somebody just wants to
experience the magic of treating the AI as a
facilitator, if nothing else, again, even if you don't think
you're creative, follow the tutorial, install the BMad
method for the tool of your choice.
I would recommend Claude Code, but whatever you're using.
Just work through — a GLM is very good with it also 'cause
they're both very creative models.
Just do the brainstorming and see how interesting it is.
And another thing I didn't mention about the
brainstorming is at the end of the brainstorming, it's gonna do
two or three different techniques with you.
It's gonna produce this report and a summary of the
brainstorming you did. And it's gonna also tell you
the nuggets and insights and highlights that you actually
came up with doing this brainstorming.
Just try that. You'll get a taste and a feeling
for what it means to treat the AI as a facilitator instead of
just a, you know, better Google. And that will I think unlock the
rest of the BMad method with you.
One of the thing is we do have a Discord.
It's totally free, so I would invite everybody to come there.
We have a community of 20-30,000 in there.
Very popular, but very helpful people.
There's just a lot of people. Also in organizations there's a
lot of tech leaders and people that own companies in there, all
trying to figure out how to apply AI in the workforce and
how to use these tools. It's a very welcoming community.
So just come in there and ask questions.
Also we're very happy to help you, you know, just how to use
the AI agents in general. We're in there exploring, you
know, what to do with these new models and what the new features
are and all these new techniques.
Because this is gonna change. What I'm saying today will not
be the same six months from now. So there's a lot of resources
out there. So I welcome everybody to come
in and try it and say hi. Reach out to me and say hello
also, if you heard about this on Henry's podcast here.
Yeah. So I'll definitely make sure to
put those things in the show notes.
So you mentioned about a couple of models.
So tell us like what models that these BMad tool support?
Does it have to be BYOK, or you know, what kind of, you know,
how do you run the agent with the AI model?
Sure. Very good question.
One thing I recommend to everybody is if you can afford
it — well this is much more affordable regardless, is go
with a subscription. Don't bring your own API key.
I will say some of the BMad method workflows right now, we
are working on improving them and making them leaner, but
they are context heavy. These are gonna use a lot of
tokens because it is working back and forth with you doing
all of this planning. It will read in documentation
and other things. So I highly recommend getting a
good subscription to Claude Code or Codex or, you know,
Kimi, or any of these. The nice thing about the BMad
method is we have built it to be model and tool agnostic.
So when you use the installer for the BMad method, I think
there's 12 or 15 tools that we support in there now.
Very soon we will be full skill compliant.
So this will work with anything that basically supports skills.
One of the goals with the BMad method is to actually get away
from the IDE and also support tools like Claude Cowork or
these platforms that allow non-technical.
Very soon the skills explosion is gonna lead to, you know,
web browsers and web tools will also support skills.
So very soon this is gonna work across platforms.
But find something, get a subscription, 'cause you're
gonna be using a lot of tokens. And that is my advice.
But it works across the models. Some models are more creative
than others. Some models will produce
better code than others. So if you use a tool like Cursor
or something that allows you to use different models, you'll
start to learn over time that the brainstorming is better with
Claude or GLM. Code review, we have code review
things in there that help improve the code.
Those might be better with Codex or, you know, the ChatGPT
model or these other things. But you don't have to worry
about all those details at first.
At first, just pick a tool, pick a model, and start learning
that one really well. And you'll start to learn maybe
where some models work better than the other ones but you can
learn to work with the model that you have also and make it
work for you. So those are just some of the
skills that you have to kind of develop a feel for over time.
But you start to pick it up, it's kind of like riding a bike.
You just start to kind of get a feel for it, and you'll start
working together with it really well.
Yeah. Always happy to whenever the
tool is agnostic, you know, especially all these AI models
that you can just pick and choose, right?
So definitely, it's a advantage, I would say.
We have covered a lot. As we go to the end of our
conversation, is there something else that you wanna
mention or shout out about BMad, maybe something that we
haven't covered today? You know, I think we covered a
lot of it, Henry. Again, I just suggest everybody
go out there and just try it out.
Have fun with it. And if you take nothing else
away from this, I'll say again, just treat the AI like a
facilitator. And it's honestly a magical
experience when you try it the first time, if you haven't
really worked with AI before. So that is kind of like my one
message. Right.
So Brian, as a tradition in my podcast, I always ask this
last question which I call the three technical leadership
wisdom. If you can think of it just like
advice you wanna give to the listeners, maybe if you can
share your version today that would be great.
Yeah. I really love this question.
I've listened to a few of your episodes, Henry, and I have
become a fan, and I like that you asked this for everybody.
I want to take this from the perspective of sharing
information for, with new tech leads.
Or people that are leaders or people that might be thinking
about leaders, because we can all be leaders, especially now
with AI, right? So, you know, the first one that
I've seen leaders really struggle with, especially when
they're a new leader is delegation.
So I just want you to remember that you as a tech lead or an
engineering manager or any kind of leader, your goal is really
to start becoming a force multiplier for your team.
And the best way you can do that is to delegate.
And at first you're gonna feel like, oh, I'm just pawning my
work off to people or this doesn't feel right.
But the more that you can learn to do that, A) the more you
can really focus and shepherding and helping your team, but
also you're going to give people on your team the opportunity to
go, to grow, and be responsible for things.
And you'll be able to take on more and more leadership
because you're starting to learn to trust people and delegate.
And even, you know, get away from knowing all of the details
and relying on other people. It's really, delegation is a
superpower and it's not like cheating, but I see people
struggle with that. So delegation, you know, is
really a force multiplier. The second one, and I already
talked about this so I'll be really brief on this, but giving
your team permission to experiment and fail.
And I already talked about the AI sprint.
But what that really means is sometimes you really gotta
give them the space to experiment and know that it's
okay if they come out with the wrong thing.
Or, you know, pull back the pressures from the sprint for
somebody to let them do a little bit of an experiment to come
to these conclusions. And you will see a flourishing
of new ideas and new ways of thinking if people really feel —
I think the term is psychological complexity or is
that psychological safety, excuse me, right?
But part of psychological safety — and complexity — is the
ability to feel comfortable in failing.
People forget that, and sometimes just think it means,
you know, feeling comfortable talking, but it is also
permission to fail or permission to experiment.
The third one, and this is a new one that I've come up with and
it's really recent, but with this AI and transformation,
remember that a lot of people are scared right now or just
don't know what the future holds.
I don't know if scared is the right word, but some people are
scared, some people are uncertain.
None of us have the answer of what is coming.
As a leader — and I said this at the beginning, I really picked
this up from my army training — sometimes it is putting a good
face on things because not only can your team recognize
confidence, but they can also recognize fear, and that will
have an impact on how they operate.
So sometimes you do have to put a good face on things to
lead people through adversity. And I'm not saying AI and this
transformation is adversity. But helping people learn to grow
through this new transition and recognize their own
self-worth. And people are gonna embrace
these tools and then they're gonna have these moments of,
wait, what is my purpose now? If you can shepherd them through
these times, that will make you a great leader.
But that also really shows that you care about people.
As a leader, you need to care about people.
And part of caring is just helping lead through adversity
or challenging times, or helping people realize what their
self-worth is. And I think we've shared a
little bit of that throughout the podcast of what your
self-worth is, as these AI tools comes, it is stepping back and
applying your experience and your discernment and knowing
that you can work with the AI as a partner, but you're giving it
something that the AI, I don't think has or ever will has,
which is your lived experience and knowledge and discernment.
So helping your team do that is really part of being a leader.
I have one more, Henry, though. I know you said three but I
wanna give one more. And this is a cliche old one
that I've always heard, but it applies now more than ever.
Leaders are readers and I really strongly believe that.
If you're new to tech leadership, it's fun to focus
on, you know, still learning engineering patterns.
There is a lot of fun in learning about leadership and
about management and organization.
Maybe this sounds boring. You had one of my favorite
people on your podcast a few weeks ago, Gene Kim.
I am a jump. I love Gene Kim's books, I've
read all of them. And I love business books and
management books that kind of have a story in 'em.
So I'm a sucker for those types of books.
But learn these techniques and you'll start to realize it's
just like engineering. You're starting to learn ways
of working with people or how to apply these different things.
And you might start to really enjoy the leadership and
management side of things and it will just help you grow.
So read about techniques and focus not only on the
technical, but how to become a better leader.
And you will, you'll become a better leader.
It's a lot of fun. So, sorry I had to squeeze one
more in there. But, you know, leaders are
readers and I believe that. Happy for more wisdom from my
guest to share. So thank you for sharing such
a lovely message. I think all those are really
critical, you know, skills for leaders.
You know, being able to delegate, creating
psychological safety, right? Caring about people going
through, you know, difficult periods, you know, adversity and
things like that. And definitely, inviting
people to read more. So BMad, if people want to
connect with you, asking you more questions maybe about BMad
maybe about other things, is there a place where they can
find you online? Yeah, the best thing, honestly,
it's easy. I mean I have a lot of email
addresses, but check me out on YouTube.
I do have a masterclass on there where you can also watch and
learn about the BMad method and my contact information is on
YouTube. But the easiest is come into
Discord. So if you go to our GitHub for
the BMad method, there is a Discord link.
You can join our community. It's free.
Come in there and say hello, ask questions.
Myself and the community will be happy to help you out and tell
you more about BMad or you know, how to apply engineering and
these changes across your own organization.
Happy to help. Right.
It's been a pleasant conversation.
Thank you so much for sharing all those things.
I really love your story as well, the background, how you
came up with this BMad method. I wish you good luck and great
success with this evolution of the BMad.
Thank you Henry. This was so much fun.
I really enjoyed talking to you and I love your show.
So, thank you so much. This was awesome.