How I AIA 3-step AI coding workflow for solo founders | Ryan Carson (5x founder)
CHAPTERS
- 0:00 – 2:32
Why “slowing down for context” is the fastest way to ship with AI
Ryan opens with his core thesis: most people fail with AI coding by rushing context. He and Claire frame the episode around bringing structure—PRDs, task lists, and disciplined execution—so you’re not just “vibe coding,” you’re building the right thing reliably.
- •Rushing context is the most common AI-coding failure mode
- •Two-step structure (PRD → tasks) speeds execution despite feeling slower
- •AI works best when you constrain scope to what it can realistically do
- •Human-in-the-loop discipline is essential for consistent results
- 2:32 – 3:43
Ryan’s recent AI builds: family game dev and nonstop founder prototyping
Claire asks what Ryan has built recently with AI, and he shares a mix of personal and professional projects. The segment sets the stage: AI is now a constant collaborator—from helping his kids build a game to accelerating his startup work.
- •Using ChatGPT as a “family AI coach”
- •Building a simple side-scroller game with his 14-year-old as creative director
- •AI-enabled “all day, every day” prototyping for his startup
- •AI expands what a solo founder can attempt end-to-end
- 3:43 – 5:22
Workflow overview in Cursor: using Rules files to enforce a plan
Ryan introduces Cursor (a VS Code fork) and explains why he relies on a repeatable workflow. He previews the three key ingredients he’s standardized as reusable Rules: create a PRD, generate a task list, then execute tasks one-by-one.
- •Cursor as the execution environment (agent mode + model choice)
- •The need to manage context intentionally (what you show vs. what you ask)
- •Standardizing prompts as reusable Rules files
- •A “three file” system: PRD rule, task-generation rule, task-execution rule
- 5:22 – 8:59
Demo: Generating a PRD in Cursor (and why “junior dev” framing works)
Ryan runs a PRD-generation rule in Cursor for a sample feature: a report showing boat names and email counts. Claire highlights a key prompt tactic—writing the PRD for a junior developer—which forces clarity and reduces implicit assumptions.
- •Using @include to inject the PRD rule into context
- •Prompting a concrete feature request (email report for yacht club CRM)
- •Calling out “PRD suitable for a junior developer” to enforce explicitness
- •Model talk: Claude Sonnet vs Gemini vs o3; tradeoffs and cost considerations
- 8:59 – 9:54
Open-source prompts + Task Master alternative: picking the right complexity level
Ryan points to his open-sourced rules and contrasts his lightweight approach with more powerful automation like Task Master. The takeaway is pragmatic: use the simplest system that gives you control and repeatability.
- •Rules files are open-sourced for reuse and adaptation
- •Task Master as a more powerful CLI-driven task system
- •Ryan prefers “less power, more control” for day-to-day shipping
- •Choosing tooling based on personal tolerance for complexity
- 9:54 – 10:52
From PRD to tasks: the “recap” and the anti-pattern of rushed context
With the PRD produced, Ryan and Claire reiterate the logic: make intent explicit for the model before coding begins. Ryan emphasizes that slowing down to provide context prevents rabbit holes and rework later.
- •PRD sections (functional requirements, non-goals, design considerations) provide grounding
- •Rushed context leads to misalignment and wasted iterations
- •A small upfront investment yields faster downstream execution
- •Context quality is more important than clever prompting tricks
- 10:52 – 16:31
Demo: Turning the PRD into a detailed Markdown task list
Ryan runs his task-generation rule against the PRD to produce a structured checklist with subtasks. They discuss why explicit formatting (Markdown, checkboxes, step-by-step process) improves usability and keeps AI output actionable.
- •Task rule defines what a “good task list” looks like and how it’s produced
- •The rule asks clarifying questions, then generates tasks in a consistent format
- •Markdown checkboxes make progress tracking frictionless
- •Learning to write rules by iterating, getting specific, and editing AI drafts
- 16:31 – 18:58
Executing systematically: task-by-task “agentic” behavior with user checkpoints
Ryan shows the third rule: task list management. Cursor is instructed to do only one subtask at a time, mark it complete, and stop for confirmation—turning a chaotic agent into a predictable collaborator.
- •“One subtask at a time” prevents runaway changes and compounding errors
- •Immediate checkbox updates create a tight feedback loop
- •Stop-and-wait checkpoints keep the human in control
- •This structure mimics agentic workflows while staying linear and debuggable
- 18:58 – 20:35
Change management: when to commit, when to revert, and why human review matters
Claire asks how Ryan handles Git and change control during AI-assisted coding. Ryan explains his cadence—committing after parent tasks or after a stable milestone—and reiterates the importance of reviewing each step for small breakages and lint errors.
- •Commit strategy: after parent tasks or when the app is “workable”
- •Sometimes defer commits until all tasks are completed (half-day chunks)
- •Always evaluate how painful a revert would be before proceeding
- •Human-in-the-loop review catches subtle issues AI introduces
- 20:35 – 21:49
Why task lists help PMs too: preventing the PRD-to-execution breakdown
Claire zooms out: even without full code generation, PRD → task list is a major leverage point for PMs and engineers. The generated tasks resemble epics and actionable steps tailored to the actual codebase, reducing coordination bottlenecks.
- •Task decomposition is a common failure point in product execution
- •AI-generated tasks can translate PRDs into implementable steps in a specific repo
- •Markdown task lists are intentionally “simple” and easy to edit
- •Avoid over-engineering (e.g., auto-creating Asana tasks) if it adds friction
- 21:49 – 25:22
Demo: MCPs for front-end testing and cross-tool “toil reduction”
Ryan demonstrates MCP integration, especially Browserbase, to control a headless browser from Cursor and capture screenshots. They discuss how this unlocks practical front-end testing and reduces the overhead of switching between tools and tabs.
- •MCPs let Cursor interact with external systems via natural language
- •Browserbase MCP: remote headless browsing + screenshots from within Cursor
- •Potential for automated front-end QA and more precise bug reproduction
- •Centralizing workflows reduces “tab overload” and coordination toil
- 25:22 – 26:50
Which MCPs to use: Postgres as the daily driver (plus Prisma/SQLite)
Ryan explains which MCPs he relies on most and why. Postgres stands out as the most useful in his startup work—allowing quick database verification without hand-writing SQL—while Prisma/SQLite are helpful for smaller projects.
- •Postgres MCP is most valuable for real startup debugging and verification
- •Natural-language DB checks replace manual SQL and context switching
- •Prisma and SQLite MCPs are useful for smaller or local projects
- •MCP choice should match the systems you query most frequently
- 26:50 – 31:27
Demo: Repo Prompt for precise context control beyond Cursor’s “magic”
Ryan introduces Repo Prompt as a way to explicitly select files and generate a large, well-structured prompt payload—complete with token counts and file demarcation. This gives maximum control for heavyweight reasoning tasks in models like o3, avoiding uncertainty about what’s in context.
- •Cursor context management can feel opaque unless you manually tag everything
- •Repo Prompt lets you curate exact files and see token counts before exporting
- •Outputs structured prompts with clear file paths and XML-style tagging
- •Best for “heavy lifting” questions like architecture/maintainability reviews
- 31:27 – 34:44
Ryan’s dev “stack” secret: EDM for deep work + lightning-round founder takeaways
Ryan jokes that Tiësto is part of his development stack, then closes with reflections on how AI changes company-building. He argues AI enables true solo-company execution, and shares his gentle tactic for getting models back on track: asking them to “think harder.”
- •Music as a focus ritual during late-night building sessions
- •AI is a ‘complete rewrite’ of what solo founders can realistically do
- •You may not match specialists, but you can still ship an entire company solo
- •When AI derails: calmly prompt it to reconsider and try again
