Aakash GuptaGoogle PM Runs 7 Claude Code Agents to Build Apps (0 Employees)
CHAPTERS
- 0:00 – 1:13
From PM OS to “startup OS”: agents doing PRDs, designs, tickets, and shipping
Aakash sets the stakes: AI agents can now execute large chunks of the end-to-end startup workflow, from product docs to code shipping. He tees up the key questions—what breaks with too much context and how to avoid AI-generated spaghetti code.
- •AI agents now cover PRDs, design, ticketing, and shipping
- •Promise of live demo: zero to TestFlight
- •Concern: too much context and reliability of agent workflows
- •Motivation: PM skill gap will widen quickly
- 1:13 – 2:46
Housekeeping + positioning: Claude Code as designer, developer, and systems analyst
The host shares subscription/bundle promos, then frames the episode as a ‘startup operating system’ rather than a personal PM workflow. The premise: Claude Code can stand in for multiple company functions, not just assist a single PM.
- •Subscribe + AI tools bundle mention
- •Shift from ‘PM OS’ to ‘startup OS’ framing
- •Claude Code positioned as multi-role teammate (design/dev/analysis)
- •Expectation-setting for a full build walkthrough
- 2:46 – 4:57
Inside Gabor’s 21-agent “company”: roles, responsibilities, and why specialization matters
Gabor explains his multi-agent setup that mirrors a real software org. He highlights the system analyst as central, with supporting agents for brand, CTO-level decisions, privacy, testing, performance, UX flows, and maintainability.
- •21-agent roster: CTO, designers, performance, product council, test architect, UX flow architect, etc.
- •Agents emulate a real-world team structure
- •System analyst is the “key player” for docs + tickets
- •Maintainability and security built into the org chart
- 4:57 – 6:00
System analyst agent deep dive: clarifying questions, dependencies, and doc-driven development
They open the system analyst definition and discuss how it transforms ambiguous ideas into structured requirements and dependencies. The chapter emphasizes how upstream analysis drives downstream ticket quality and build reliability.
- •System analyst breaks down requirements and technical specs
- •Asks clarifying questions to resolve ambiguity
- •Documents dependencies explicitly
- •Primary output: Confluence documentation + Jira tickets
- 6:00 – 8:00
Live build kickoff in the Claude consumer app: voice-first ideation for a hockey rules AI app
Gabor begins in the Claude desktop/mobile app to make the workflow accessible and voice-driven. He outlines the app idea: an AI chat assistant for IIHF hockey rules, inspired by his experience as a referee.
- •Start in consumer Claude app for accessibility and voice mode
- •App concept: Rule Ask—chat assistant for IIHF rules
- •Personal domain expertise as product advantage (referee experience)
- •Goal: demonstrate zero-to-shipping workflow
- 8:00 – 11:45
Prompting for role quality: defining “good vs bad” system analysts to improve agent behavior
Before building, Gabor asks Claude to describe what makes a strong system analyst and how the role functions in software teams. This becomes meta-scaffolding: using AI to help craft better AI instructions.
- •Role definition prompt to shape agent expectations
- •Good vs bad analyst behaviors contrasted (elicitation, modeling, stakeholder mgmt)
- •Using LLMs to bootstrap better agent specs
- •Sets tone: clarity before execution
- 11:45 – 16:06
Documentation + MCP connectors: Confluence/Jira as the memory that prevents “vibe code” chaos
Gabor explains why he anchors everything in Confluence and Jira, connected via Atlassian MCP. He argues documentation makes decisions replicable and apps maintainable, contrasting it with one-shot prompting that yields fragile results.
- •Confluence for docs; Jira for dev tickets; both connected via MCP
- •Documentation makes work replicable and maintainable
- •Analogy: building a house needs an architect/team, not one vague instruction
- •Sets up “scaffolding” as a core anti-spaghetti strategy
- 16:06 – 21:17
Scaffolding tactics: question-first workflow, one-at-a-time prompts, and a “spaghetti agent”
Gabor shows the exact prompt pattern that forces clarifying questions before writing. He also introduces a maintainability-focused agent to catch circular references, naming, and commenting—guardrails non-engineers may miss.
- •Instruct Claude: ask clarifying questions before writing anything
- •Ask questions one at a time to avoid overwhelm
- •Restrict tool access to specific Jira/Confluence spaces
- •Maintainability agent to detect spaghetti code risks
- 21:17 – 26:00
Claude Code setup hiccups: project agents, permissions, and safe operation boundaries
They switch to Claude Code to create project-specific agents and workflows, hit a setup snag, then recover by creating a new directory. Gabor stresses reading permissions carefully and limiting agent actions to the project folder.
- •Project vs global agents; separate setup required in Claude Code
- •Troubleshooting: agents not appearing → new directory workaround
- •Security practice: scrutinize permissions (avoid password stores)
- •Claude usage tracking and authentication steps
- 26:00 – 43:11
Dictating the full product spec: stack, RAG sources, token/cost limits, privacy, and key management
Gabor dictates a detailed PRD-like spec: Flutter + Firebase, IIHF rulebook + situation book embeddings, web fallback, strict API key handling, and per-device usage limits. He argues dictation dramatically increases spec depth and quality.
- •Tech stack: Flutter front end, Firebase back end, iOS 16+
- •RAG plan: rulebook primary, situation book secondary, web fallback
- •Cost control: token/context balancing + 20k-word daily limit
- •Security: API keys only in Firebase Secret Manager; no server-side user storage
- 43:11 – 47:02
From answers to artifacts: Confluence documentation generation (and why PMs should build)
After clarifying Q&A, Gabor triggers Confluence page creation—product overview through technical architecture and AI agent spec. He explains how shipping a real app plus documentation becomes credible proof for portfolios and interviews.
- •System analyst produces structured Confluence pages automatically
- •Review criterion: accuracy vs what was dictated
- •AI agent spec and architecture doc become shareable artifacts
- •Portfolio angle: demonstrable proof beats vague ‘AI familiarity’
- 47:02 – 1:00:16
Visual direction in minutes: Figma Make style guide from inspiration screenshots
Gabor uses SpottedInProd and personal imagery to seed a Figma Make prompt that produces a full style guide (colors, typography, components). He clarifies the ‘inspiration, don’t copy’ instruction to avoid tool refusal and IP issues.
- •Design inspiration sourcing (SpottedInProd + personal photo)
- •Figma Make prompt: typography, colors, CTA states, error states, components
- •Explicit ‘don’t copy’ constraint to keep workflow compliant
- •Tool comparison: Figma Make vs Lovable/Bolt; preference for idea→prompt→code→product
- 1:00:16 – 1:12:27
Idea-to-design pipeline: Claude Code builds Figma screens and a clickable prototype automatically
With Figma MCP and Chrome DevTools MCP, multiple agents generate screen layouts in Figma and then wire prototype arrows for navigation. The workflow demonstrates agentic execution across tools, producing a high-fidelity, minimal-screen UI quickly.
- •Save style guide to Claude project memory for consistent decisions
- •Install/use MCPs: Figma + Chrome DevTools + Confluence/Jira
- •Agents generate multiple screens directly in Figma
- •UX flow architect automates prototype linking (arrows)
- 1:12:27 – 1:44:14
Ticket factory: Jira epics, Figma-linked front-end stories, backend setup, sprints, and context limits
The system analyst and other agents create Jira epics and tickets, ensuring each front-end ticket links to exact Figma frames or screenshots. Gabor explains why ticketing improves quality by reducing context overload and enforcing dependencies via sprint tagging.
- •Parallelization: design/prototype + backend initialization tickets
- •Front-end tickets require Figma links/screenshots to avoid generic ‘AI-looking’ UI
- •Sprint tagging workaround due to MCP sprint-creation limitations
- •Lesson: too much context causes compression → missed style palette details
- 1:44:14 – 1:56:28
Build, simulate, and ship: debugging retrieval quality, running iOS Simulator, and uploading to TestFlight
After sprint execution, they reach a working build, fix a retrieval accuracy issue, and demo the app in the iOS Simulator with an ‘observer mode’ showing RAG steps and token usage. Finally, they upload to TestFlight and outline the remaining steps for App Store submission.
- •Coding becomes fast once specs + tickets + scaffolding exist
- •Observer mode: rulebook hits, situation book hits, web fallback, tokens/latency
- •Simulator demo: answers + direct PDF rule references
- •TestFlight upload process + warning: first App Store reviews can take >1 week
- 1:56:28 – 2:03:14
Career segment: from Deliveroo during COVID to Google PM, and what actually helped
Gabor shares his COVID-era unemployment story, financial constraints in London, and working Deliveroo shifts. He then details how structured FAANG interview practice, coaching, and consistent mock loops led to breaking into Google.
- •COVID layoff + self-employed status blocked government support
- •Deliveroo as a survival job in London lockdown
- •Paid coaching with performance-based deal; ~200 hours prep
- •Peer practice group via igotanoffer-quality-bar community
- 2:03:14 – 2:15:18
AI PM certificates vs real proof: portfolios, building stories, and how to start with agents
They debate certificates and conclude skills and demonstrable building matter more than PDFs. Gabor recommends hands-on courses only for learning (not credentialing), and urges PMs to build apps to avoid falling behind as products become agentic.
- •Certificates are secondary; knowledge + hands-on building is the signal
- •Portfolio shift: real shipped artifacts + debugging stories (e.g., scoring thresholds)
- •Tool take: Claude Code strongest today; Cowork/Dispatch improving but fragile
- •Getting started: use any LLM, ask questions, then build; seek structure to accelerate
