Building with AI
A working session for product team leaders.
What's actually working, and what isn't.
Brian Casel
A conversation, not a talk
Let's compare notes.
Half-formed thoughts welcome
We're figuring this out together!
Five themes
1Shaping & planning
2How features get built
3Review & QA
4The human side
5What abundance unlocks
1
Section 1 of 5
The Shaping & Planning Shift
Where our time goes now.
1
2
3
4
5
We flipped the ratio
Far less time writing code, far more planning
Idea → code, too fast
Teams skip the deep upfront thinking and pay for it later in rework and drift.
Plans go sideways
Nonsensical specs, drift from standards, lack of trust.
80–90% in shaping & planning
Going deep upfront is what earns confidence in the code AI writes.
Shape before you plan
Pitch the idea; let AI grill you on the strategic and architectural calls before scope locks.
Shaping is where the team weighs in
Leaders, PMs, engineers, designers leave their imprint — then it feeds the plan.
Review moves upstream
The deepest review happens on the spec, before a line of code exists.
How much of your time is really planning vs. building?
And is it enough?
What would a “shaping phase” look like on your team?
And who's in the room for it?
When your AI plans go wrong — why?
Planning depth, or the model?
2
Section 2 of 5
How Features Get Built
Fewer cooks. More ownership.
1
2
3
4
5
The handoff chain is dissolving
PM → design → frontend → backend → QA existed because the skills were silo'd.
Nobody's sure how to restructure
Who owns what, how many people per feature, where collaboration actually happens.
Everyone covers more ground
Backend devs ship frontend and vice versa — surface area per person is way up.
One owner per feature
Shift from many cooks to a single person — or a pair — owning it end to end.
Pair across disciplines
Backend + frontend/design, so both sides hit your team's standards.
Pair to mentor
It's also how juniors get real, guided experience now.
Consensus lives upstream
Team alignment happens in shaping — not in PR review.
Single-owner features, or many hands?
Where are you on that — and how's it going?
Where has pairing worked for you?
Backend + frontend, senior + junior, something else?
If consensus moves to shaping…
What changes about how your team meets and decides?
3
Section 3 of 5
Review & QA
The new bottleneck — and where it goes.
1
2
3
4
5
The bottleneck moved to reading
The volume of generated PRs, specs, and docs landing for review is relentless.
Review on every PR is straining
Still the norm — and increasingly the slowest, most draining part of shipping.
Faster, but is it better?
Most teams can measure speed; almost none can measure quality.
Deep spec → trust the code
When the data model and logic were specced extensively, line-by-line review isn't the point.
QA the experience, not the lines
Confidence comes from tests, AI verification loops, and human QA on the real UX.
Build a verification stack
Automated checks → agent-assisted pass → humans only on the judgment calls.
Batch your reviews
Dedicated blocks instead of a constant interrupt stream.
What if you stopped reviewing every line?
What would have to be true for you to trust the code?
Has anyone moved review upstream?
Into the spec, before code — did it hold up?
What's your QA confidence stack?
Tests, AI loops, human QA, gut feel?
4
Section 4 of 5
The Human Side
Juniors, craft, pace, and what's worth building.
1
2
3
4
5
Juniors are struggling
Accepting code they don't fully understand, learning less by osmosis than we did.
Craft identity is shifting
Some grieve the keystroke; engagement and morale can dip.
The pace is relentless
Speed went up — sustainability often went down.
Pairing rebuilds apprenticeship
Juniors learn alongside seniors and agents, with reading code as a first-class skill.
The craft moved up — it didn't die
From the keystroke to system and spec design; the elegant-solution part expanded.
Restraint is the new edge
When everyone can ship fast, knowing what not to build is the advantage.
Pace is a leadership choice
The tools enable 100x; you're not obligated to run at 100x.
What's happening to your juniors?
Thriving, drowning, somewhere in between?
More sustainable, or less?
Be honest.
If speed isn't the advantage — what is?
What should we optimize for instead?
Where has AI created tension on your team?
And how are you handling it?
5
Section 5 of 5
What Abundance Unlocks
When building gets cheap, new moves become possible.
1
2
3
4
5
Building got cheap and fast
The cost of production dropped. Old instincts to “protect” our work no longer apply.
But our habits haven't caught up
We still treat code as precious, because that's what scarcity taught us.
The surplus is going unused
The speed is real; Now what should we spend it on?
Rebuild often
Mis-scoped or too much rework? Just rebuild it. Scrapping and starting over is cheap now.
Prototype to throw away
A 70–80% prototype is useful because the throwaway version smooths the path to the real one.
Duplicate in parallel, then compare
Two people build the same scope separately, then merge conclusions into the final plan.
Let non-engineers touch the code
Support, PMs, designers, CS can prototype and ask questions of the codebase — without interrupting the team's flow.
What's the surplus buying you?
Now that building is faster — what are you actually spending that speed on?
What have you been wanting to ask this room?
The question you came in with, or one that's surfaced today.
What's one thing you wish more people were talking about?
The under-discussed idea, worry, or opportunity on your mind.
Quick round — what are you trying with your team on Monday?
Don't adopt the fastest.
Adopt deliberately.
Brian Casel
·
buildermethods.com
·
@casjam