Ryan Carson joins Claire Vo on How I AI to turn open-ended AI coding into a repeatable feature-building process. In this May 2025 episode, the five-time founder demonstrates three instruction files in Cursor, an AI-assisted code editor. A yacht-club customer database supplies the example: add a report showing members’ boat names and how many emails each member received.

Start with a feature brief · 03:26–06:40

  • Carson separates three jobs: writing a product requirements document, turning it into tasks, and managing implementation. Each job has its own reusable instructions. The prompts are shared in his AI Dev Tasks repository.
  • The first rule asks for a brief that a junior developer can understand and implement. Vo calls out that wording because it pushes the model to explain details that an experienced person might silently assume.
  • He includes the instruction file in Cursor’s context, describes the report, and uses agent mode, which lets the model work with project files. A larger feature gets this preparation; a tiny change can take a lighter path.

Answer the questions that determine scope · 06:49–10:59

  • Cursor asks what problem the report solves, who will use it, and where it should appear. Carson supplies the purpose and identifies administrators as the users. He lets the model choose some remaining details.
  • His rule gives questions separate numbered references such as 2.1 and 2.2. This small formatting constraint makes answers easier to address than a bullet containing several questions.
  • The resulting Markdown document lives in a tasks folder. It includes functional requirements, non-goals, and design considerations, giving later steps a persistent specification to reference.
  • His preferred model at recording time is Gemini 2.5 Pro, though the demo initially has Claude 3.7 Sonnet selected. These are his May 2025 choices, not a current model ranking.

Review the plan before expanding it · 11:02–15:58

  • Carson tags both the task-generation rule and the completed brief. The rule defines a step-by-step process and an output format with Markdown checkboxes.
  • The model first proposes parent tasks. It asks for permission before generating subtasks, creating a review point before implementation begins. Vo notes that the instructions explicitly describe decisions and user interaction points.
  • The completed list also names relevant files. Carson says that listing them helps keep attention on the parts of the codebase that matter, alongside explicitly tagging files in the conversation.
  • He mentions Task Master as a more elaborate open-source alternative. He prefers the smaller, more controllable process for his own work.

Complete one subtask, then stop · 16:32–18:55

  • A third rule governs execution: work on one subtask, mark it complete immediately, and wait for the user’s go-ahead. Carson passes that rule and the task list into Cursor together.
  • The first demonstrated subtask concerns the Prisma database schema for email campaigns. Cursor reads the existing project context and checks off item 1.1 before asking to proceed.
  • The checklist makes progress visible outside the chat. It also gives Carson somewhere to add work himself, without introducing another project-management service.

Separate approval from version history · 18:58–21:40

  • Carson reviews the work after each task because small problems and linting errors still appear. A completed checkbox is a progress marker, not proof that the application is correct.
  • His Git commits happen when a parent task leaves the app in a workable state. Sometimes he waits until the whole task list is complete. He judges the interval by what he would need to undo.
  • He reports using this approach for features of roughly 10,000 lines. That is his experience, not a measured reliability result. Vo also sees value for product managers who only need the requirements-to-task-list handoff.
  • Carson considered sending tasks into Asana through an integration, then kept the Markdown file. His recommendation is to master the simple version before adding machinery.

Give the editor database and browser tools · 21:50–26:44

  • MCP, the standard for connecting agents to tools, lets Carson ask database questions from Cursor. PostgreSQL is his most-used integration: he asks whether a particular value exists in a row without writing the query himself.
  • He also shows Browserbase and mentions Stagehand. In the demo, Cursor controls a remote browser, opens ChatPRD, takes a screenshot, and navigates to pricing.
  • Carson expects browser control to help with front-end testing. The episode demonstrates navigation, not a completed automated testing system. Vo emphasizes the reduced need to switch between task trackers, browser tabs, and database tools.

Choose exactly what enters the prompt · 26:46–31:16

  • Repo Prompt, a Mac tool, lets Carson select files and inspect their token count. He removes generated material before choosing application code, components, the Prisma schema, and scripts.
  • He adds a maintainability question and a stored architect prompt, then copies the package into o3. File contents, paths, and instructions are separated with XML-style labels.
  • Carson uses this for heavier reasoning when he wants more control over context than the editor’s automatic selection provides. His argument is that a large context window still needs relevant material.

Keep the founder claim bounded · 31:23–34:14

  • Carson closes with his music-assisted late-night coding routine and enthusiasm for building a company alone. He explicitly says this does not make him as capable as a dedicated product manager or as deep a thinker as a CTO.
  • When a model stalls, his tactic is to ask it politely to think again. The demonstrated structure comes from the documents, task boundaries, and human review, rather than that wording alone.

Caveat: this is Carson’s workflow and a partial feature demonstration, not evidence that a solo founder can replace every engineering role.