Aakash GuptaThe Claude Code Setup for Non-Technical PMs That Nobody Shows You
CHAPTERS
- 0:00 – 4:30
Non-technical PMs are becoming backlog bureaucrats (and why that’s dangerous)
Andre frames the core problem: many non-technical PMs are trapped in Jira decks and dependency cycles, while AI-native teams expect PMs (and even CEOs) to ship. The chapter sets the urgency—PMs who don’t build risk being left behind as small teams move faster with AI-assisted coding.
- •Non-technical PMs often become “bureaucrats” managing tickets and decks instead of building
- •AI-native orgs show PMs/CEOs directly contributing to GitHub and shipping features
- •Dependency on engineering slows iteration and limits PM impact
- •The role of PM is shifting toward direct contribution and building
- •Transformation requires tools + permission + skill-building
- 4:30 – 5:30
The 4-level Builder PM framework: from prototyping to automated agent teams
Andre lays out a four-step progression that reduces fear and increases capability: start with Lovable, bridge into Claude Code via GitHub, move to production workflows with Vercel and an IDE, then scale with agents and reusable skills. This becomes the roadmap for the rest of the episode.
- •Level 1: Lovable for low-friction prototyping
- •Level 2: Lovable + Claude Code connected through GitHub for more flexibility
- •Level 3: Claude Code + Vercel (often inside Cursor) for real production workflows
- •Level 4: Automation with agents/skills and a shared CLAUDE.md process layer
- •Framework is designed for non-technical comfort and gradual complexity
- 5:30 – 8:02
Level 1 — Start with Lovable: safe, visual, and personal-first projects
Andre explains why Lovable is the best on-ramp for non-technical PMs: it’s less intimidating than an IDE, and it abstracts away infrastructure details like auth and databases. He recommends beginning with a personal, low-risk project to learn by doing without fear of breaking company systems.
- •Lovable is less scary than jumping directly into an IDE or codebase
- •Start with personal projects to reduce risk and build confidence
- •Lovable abstracts the stack: databases, authentication, and setup complexity
- •Use the AI like a senior engineer: ask what you’re missing and learn iteratively
- •Early-stage code quality doesn’t need to be perfect—momentum matters
- 8:02 – 13:46
Level 2 concept — The Lovable ↔ Claude Code bridge via GitHub (Lovable as QA/infra)
Andre introduces an “accidental but powerful” workflow: use Claude Code for more capable coding, keep Lovable as the visual preview, QA, and deployment layer, and sync everything through GitHub. This lets non-technical PMs graduate to code changes while still seeing the product evolve in an approachable UI.
- •Claude Code desktop can feel intimidating compared to Lovable’s visual builder
- •GitHub is the shared source of truth connecting Claude Code and Lovable
- •Lovable can act as a preview/QA layer while Claude Code does the heavy lifting
- •Merges from GitHub show up in Lovable, enabling quick visual validation
- •You can postpone dealing with hosting/deployments until later
- 13:46 – 18:55
Live walkthrough — Create in Lovable, connect GitHub, then open the same repo in Claude Code
In a step-by-step demo, Andre bootstraps a new Lovable app, connects it to GitHub, and then selects that repository inside Claude Code. The key lesson: start on Lovable first (so it generates the project structure), then let Claude Code modify the same codebase through GitHub.
- •Bootstrap the app in Lovable first to generate the initial codebase
- •Connect the Lovable project to your GitHub account to create a repo
- •Ensure Claude Code is connected to GitHub via connectors/authentication
- •Select the newly created repository inside Claude Code to work on it
- •This workflow is ideal for personal repos; company repos require different access patterns
- 18:55 – 25:18
Make changes in Claude Code, see them in Lovable: merge → preview → publish
Andre demonstrates making UI changes (theme colors, then header redesign) in Claude Code, merging to GitHub, and watching Lovable update automatically. He emphasizes Lovable’s two-step model: GitHub updates power the preview, but you must hit Publish to update the public live URL.
- •Claude Code implements changes and creates/merges PRs into the repo
- •Lovable detects repo updates and refreshes the preview experience
- •Use screenshots + prompts to iterate quickly on UI/UX with Claude Code
- •Non-technical users can converse with Claude Code, not just issue commands
- •Lovable preview updates from GitHub; the public link updates only after Publish
- 25:18 – 28:50
Branching demystified: what “main,” “PR,” and “merge” mean for non-technical PMs
Aakash provides a simplified explanation of branches and pull requests so non-technical PMs aren’t blocked by terminology. Andre adds the nuance: this “merge straight to main” approach is fine for personal projects, but company workflows will reintroduce reviews and pipelines.
- •Main branch is the canonical version; branches are isolated work areas
- •Pull requests propose changes; merges bring work back into main
- •This demo skips review because it’s low-risk, personal experimentation
- •In real teams, you’ll adapt to the engineering pipeline and approvals
- •You can ask Claude Code to handle git mechanics without mastering them upfront
- 28:50 – 35:34
Level 3 — Move to production: Vercel previews + multiple branches for speed and safety
Andre explains why he eventually leaves Lovable as infrastructure: to work faster with multiple parallel efforts, you need real branching workflows and reliable preview environments. Vercel becomes the deployment bridge from GitHub to users, producing a preview URL per branch before merging to production.
- •As projects grow, you’ll want multiple sessions/branches running in parallel
- •Vercel provides branch-based preview deployments for QA before release
- •Each deployment line in Vercel corresponds to a branch/change set
- •Workflow: Claude Code → GitHub repo → Vercel preview → merge to main → production
- •This is a more standard, scalable approach than using Lovable as infra
- 35:34 – 37:38
Mental model: Lovable vs Claude Code vs GitHub vs Vercel (who does what)
Aakash asks for clarity, and Andre provides a crisp system map: Claude Code is where you create changes, GitHub is where code lives, and Vercel is the bridge that serves code to users. Lovable is primarily an AI builder/IDE, though it can be used as a convenient preview/hosting layer early on.
- •Claude Code: coding agent/work environment
- •GitHub: source control repository where the codebase lives
- •Vercel: hosting/deployment layer connecting repo changes to user-accessible builds
- •Lovable: AI builder/IDE that can also act as early-stage hosting/preview
- •Non-technical success comes from pragmatic use of abstractions, not deep infra mastery
- 37:38 – 41:45
Why Andre prefers Cursor + Claude Code: IDE comfort, sessions, and visual git context
Andre shows working in Cursor with Claude Code to gain file visibility, manage multiple “sessions” (epic-sized work streams), and feel more comfortable with navigation. Aakash adds practical benefits: Cursor’s generous free plan for debugging and strong GitHub syncing make it a helpful companion even if Claude Code does the real coding.
- •Cursor provides a more comfortable UI (e.g., vertical sessions/tabs) for some users
- •You can run multiple sessions aligned to epics and ship in parallel
- •Cursor’s free agent can help debug setup issues (e.g., Claude Code login)
- •GitHub integration is smooth—projects stay linked as you work
- •Vercel previews validate each branch before merging to main
- 41:45 – 43:16
Level 4 — Avoiding “slop” with agents, skills, and a shared CLAUDE.md memory layer
Andre addresses the fear of AI-generated messy code by introducing a structured “machine that builds the machine.” He uses CLAUDE.md to encode rules/values and a library of agents/skills to enforce better process, freeing humans to focus on problem discovery and decision-making.
- •Risk: vague prompts can generate “slop,” complexity, and poor maintainability
- •CLAUDE.md acts like team values/memory loaded into every new session
- •Agents/skills provide repeatable structure: design, engineering quality, discovery, implementation
- •Goal is to spend more time on problem framing, less on solution micromanagement
- •AI-native teams invest heavily in improving the system, not just feature-by-feature tweaks
- 43:16 – 46:11
CLAUDE.md explained: persistent rules that shape every session and interaction
Andre explains CLAUDE.md as an always-loaded configuration that Claude consults by default, similar to how a team’s operating principles shape decisions. He recommends continuously updating it based on repeated mistakes or annoyances so future work improves automatically.
- •CLAUDE.md is read every time you start a new session
- •It defines default behavior, rules, architecture preferences, and workflow expectations
- •Update it when Claude repeats mistakes or you find yourself repeating instructions
- •Treat it like team culture/values that guide decision-making
- •Complexity is optional—start small and evolve over time
- 46:11 – 51:49
PM orchestrator pattern: agents aren’t proactive—your config calls them on every task
Andre clarifies what agents are and how they’re invoked: CLAUDE.md loads automatically, but agents/skills run only when called. His setup includes a rule to always call a PM-orchestrator agent first, which then routes work to specialists (designer, engineer, implementer, researcher) mirroring a real product squad.
- •Agents and skills live in a folder available to every new session
- •Claude reads CLAUDE.md by default; agents/skills are used only when invoked
- •A key rule: always call the PM orchestrator agent first
- •PM agent delegates to specialized agents (designer, engineer, implementer, discovery, research)
- •Build your agent set based on how your real team works—don’t blindly copy huge bundles
- 51:49 – 1:01:29
How AI-native teams operate: improve the machine, reduce collaboration drag, ship faster
Andre argues that execution-stage collaboration (dependencies, handoffs) is the biggest velocity killer; teams should collaborate more in discovery and in final review/release, while individuals execute independently with strong guardrails. He describes teams spending ~50% of time improving agent/skill infrastructure, compounding speed and quality.
- •Invest in infrastructure/agents to prevent repeated failures and reduce rework
- •If a feature comes out wrong, fix the pipeline (agents/skills), not just the output
- •Collaboration should concentrate in discovery and delivery—not execution dependencies
- •Engineers/designers/PMs all contribute to improving their respective agents/skills
- •Small AI-native teams can match output of much larger teams through compounding automation
- 1:01:29 – 1:10:11
Europe vs US product culture, and the Monday morning move to become a builder PM
Andre contrasts Europe’s product-owner-heavy, delivery-manager culture with more empowered US-style product building, arguing it disempowers squads and slows learning. He closes with a practical Monday plan: ask for collaborator access to a low-risk repo, pick the oldest backlog item, build it with Claude Code on a branch, and show the magic—without merging to prod.
- •European PO culture often emphasizes delivery/project management over empowered building
- •Titles and structure can unintentionally centralize ownership and disempower squads
- •Change can start via small experiments: invite engineering/design into discovery and delivery rituals
- •Monday move: get access to a low-risk repo, pick the oldest backlog item, build on a branch with Claude Code
- •Use early wins to earn permission, confidence, and a new operating model
