How I AIA 3-step AI coding workflow for solo founders | Ryan Carson (5x founder)
CHAPTERS
- 0:00 – 3:25
Why solo founders need a structured AI coding workflow (Ryan’s recent projects)
Claire introduces the episode theme: 2025 may be the year of vibe coding, but scalable execution needs structure. Ryan shares recent AI-enabled projects—from building a game with his kid to shipping pieces of his new startup—to set the stage for a repeatable workflow.
- •“Vibe coding” vs. building the right things with an execution strategy
- •Ryan’s recent AI builds: family game project and day-to-day startup work
- •Goal of the episode: PRDs + task lists + advanced prompting inside Cursor
- •AI tools as leverage for solo founders who wear many hats
- 3:25 – 5:00
Cursor setup: using “Rules” files to standardize PRDs, tasks, and execution
Ryan opens Cursor (a VS Code fork) and explains why he relies on structured rule files instead of ad hoc prompting. He frames the core challenge as managing context and scope so the model can reliably implement larger changes.
- •Cursor as the main environment; agent mode and model choice considerations
- •Rule files as reusable, versionable “prompt primitives” in the repo
- •Keeping AI work within a “manageable amount” the model can execute
- •Using a vibe-coded sample app (yacht club CRM) as the demo project
- 5:00 – 9:53
Demo: Generating a PRD in Cursor (and why “junior developer” framing works)
Ryan demonstrates creating a PRD for a new feature by @including a PRD rule file and giving a clear feature request. Claire highlights a subtle but powerful instruction: make the PRD understandable for a junior developer to reduce ambiguity and over-assumptions.
- •PRD prompt pattern: include the PRD rule + provide the feature request
- •Clarifying questions as the first output to fill gaps before writing the PRD
- •“Suitable for a junior developer” to force clarity, completeness, and simplicity
- •Practical formatting constraints to improve usability (e.g., structured questions)
- 9:53 – 11:00
Model choice, cost, and iteration habits while drafting requirements
They briefly compare preferred models and tradeoffs (Claude, Gemini, o3) and discuss the reality of paying for “max” modes. The focus is on consistency: learn one model’s strengths/weaknesses through repetition and refine prompts accordingly.
- •Ryan often defaults to Gemini 2.5 Pro; demo uses Claude 3.7 Sonnet
- •Claire’s workflow: o3 first, then 3.7 Sonnet when stalled
- •Cost reality for serious usage (hundreds per month) and why it can be worth it
- •Skill-building comes from iterative prompting and editing, not one-shot prompts
- 11:00 – 15:31
Open-source workflow assets + alternative: Task Master (and why Ryan keeps it simpler)
Ryan points viewers to his open-source rule files and mentions Task Master, a more powerful CLI-based approach. He explains he intentionally prefers a lighter-weight, more controlled workflow that stays easy to understand and maintain.
- •Open-source prompt/rule repo shared for reuse and adaptation
- •Task Master as a feature-rich alternative for task generation and management
- •Why Ryan chose “less power, more control” for his personal workflow
- •Keeping the system understandable beats over-automation early on
- 15:31 – 18:07
Recap: the #1 mistake—rushing context (and why slowing down speeds up)
Ryan emphasizes that most failures come from insufficient context and impatience. Creating the PRD and task list may feel slower, but it reduces rework and rabbit holes, making overall delivery faster and more reliable.
- •Main failure mode: rushing context and expecting the model to infer details
- •PRD + task list as the two steps that prevent wasted cycles
- •Treating the model like a capable helper that still needs the right “paperwork”
- •Outcome: fewer reversions, cleaner implementation, less drift
- 18:07 – 18:56
Demo: Turning the PRD into a detailed Markdown task list
Ryan uses a second rule file to convert the PRD into an executable plan: parent tasks, subtasks, and checkboxes in Markdown. The rule enforces an interactive process (draft tasks → confirm → ‘Go’) to ensure alignment before coding.
- •Generate-tasks rule: explicit steps, output format, and interaction points
- •Markdown checklists for visibility and easy progress tracking
- •“Go to proceed” gating to avoid premature deep implementation
- •Prompt craft approach: have an LLM draft, then Ryan edits and adds constraints
- 18:56 – 20:00
Systematic execution in Cursor: one subtask at a time with human-in-the-loop checks
Ryan demonstrates a third rule that governs how the AI should work through the task list: do one subtask, mark it complete, stop, and ask permission to continue. This structure limits scope creep and makes it easier to spot errors early.
- •Task-list management rule: single-subtask execution and forced pauses
- •Auto-checking boxes after completion to keep a live, accurate plan
- •Human review after each step to catch lint errors and small regressions
- •Why this scales to “big features” (lots of code) with fewer surprises
- 20:00 – 21:50
Change management: when to commit to Git and how to decide rollback risk
They discuss practical version control habits when AI is making many changes quickly. Ryan typically commits after a parent task if the app is in a workable state, otherwise waits until the set of tasks is complete, balancing safety with momentum.
- •Commit cadence: after parent tasks vs. after the whole task set
- •Heuristic: “If I had to revert now, how bad would it be?”
- •AI increases change velocity, so rollback strategy becomes more important
- •Treating task boundaries as natural commit boundaries
- 21:50 – 24:50
Why task lists are a PM time-saver (even without full automation)
Claire notes that even stopping after PRD → task list is valuable for PMs and engineers, because breaking work into codebase-aware steps is a common bottleneck. Ryan argues against over-engineering: a simple Markdown file is often the fastest, clearest solution.
- •Task decomposition is a frequent PM/engineering failure point
- •LLM-generated tasks can resemble epics + tickets and reduce coordination load
- •Markdown as a low-friction “source of truth” you can edit anytime
- •Start simple before wiring into tools like Asana/Linear via MCP
- 24:50 – 26:45
Demo: MCPs in Cursor—headless browser testing with Browserbase/Stagehand
Ryan shows how MCP servers let Cursor control external tools via natural language. He demos Browserbase to navigate to a website and take screenshots in a cloud browser, framing it as a step toward automated front-end testing and faster bug reproduction.
- •MCP concept: give the AI safe, tool-based access to external systems
- •Browserbase demo: navigate, click around, and capture screenshots remotely
- •Use case: reduce UI debugging friction vs. manual screenshot-and-explain loops
- •Stagehand mentioned as another automation/testing-oriented MCP option
- 26:45 – 31:23
Which MCPs are most useful day-to-day (Postgres as the workhorse)
Ryan explains that Postgres is his most-used MCP because it eliminates tedious context switching and manual SQL for basic checks. They connect MCPs to a broader theme: reducing engineering toil by consolidating tasks (PM, browser, DB) into one interface.
- •Postgres MCP: ask natural-language questions about real DB state
- •Why it matters: quick verification without writing SQL or opening extra tools
- •Prisma/SQLite MCPs for specific projects; Postgres for daily startup work
- •AI dev tools as “toil reducers” that collapse multi-tab workflows
- 31:23 – 32:10
Demo: Repo Prompt for precise context control (escaping the context ‘black box’)
Ryan introduces Repo Prompt as a way to explicitly select and package repo files into a structured prompt with token counts and XML-like boundaries. He uses it when the stakes are higher and he needs certainty about exactly what the model is seeing.
- •Problem: Cursor context can feel implicit unless you tag everything carefully
- •Repo Prompt workflow: select folders/files, manage token budget, exclude generated code
- •Outputs a structured prompt with file paths and contents for clarity and control
- •Best for “heavy lifting” architectural reviews and deep reasoning tasks
- 32:10 – 34:44
Personal stack: music for flow + lightning round on how AI changes founding
Ryan jokes that EDM is a core part of his development setup, then closes with reflections on how AI rewrites what a solo founder can do. He shares his tactic for getting models back on track—polite, directive nudges to “think harder”—and where to find his work online.
- •Music as a focus tool during late-night building sessions
- •AI enabling solo founders to cover PM/CTO-like work (imperfectly but effectively)
- •Correction tactic: nudge the model politely to re-evaluate and try again
- •Where to follow Ryan: X (ryancarson) and ryancarson.com
