CHAPTERS
- 0:00 – 1:09
Designers becoming builders: why “shared language is code”
Ryo lays out a core thesis for Cursor: the designer–engineer divide is collapsing as AI makes building accessible to everyone. He argues designers should start by building rough versions, then refine them—because taste and polish are still hard for AI. The payoff is faster iteration and a more magical, collaborative product process.
- •Ryo’s KPI: turn designers into coders; engineers also design
- •AI enables starting from imperfect output and iterating quickly
- •Code becomes the common language across roles
- •Designers’ advantage: making “bad/ugly” outputs truly good
- •Breaking tool boundaries unlocks cross-functional collaboration
- 1:09 – 5:01
Learning by building (websites at 11) vs. “studying” CS
Ryo describes learning software by shipping real projects from a young age, long before he knew formal role boundaries. He contrasts that with outdated academic CS instruction, emphasizing that doing the work teaches the concepts organically. AI agents compress this learning loop dramatically.
- •Early self-driven website building blurred design/engineering/product
- •CS education helped structure, but felt outdated and less practical
- •Core learning method: build first, learn terms later
- •AI agents reduce the intimidation and dependency chain of learning
- •Fast feedback cycles make experimentation the new default
- 5:01 – 6:19
Practical path for designers: from vibe tools to full-power coding in Cursor
Ryo recommends designers start with constrained “vibe coding” tools that fit existing workflows, then graduate to Cursor when limits appear. He frames Cursor as an unopinionated toolset where the interaction style feels similar—but capabilities are effectively unlimited. The goal is to remove the fear of editors, Git, and setup details until they’re needed.
- •Start with Figma Make / v0 to build confidence in a constrained environment
- •Move to Cursor when you hit constraints and need full control
- •Cursor feels similar, but can build anything (web, iOS, beyond)
- •Agents fill knowledge gaps (research, implementation, best practices)
- •Design intuition about systems exists even without deep tool fluency
- 6:19 – 8:39
Inside Cursor’s design team: tiny team, everyone codes, engineers help design
Ryo explains the realities of designing a developer tool inside a fast-growing company. Cursor’s design team is very small, and every team member codes. Because most employees are power users, product ideas come from everywhere—creating a constant need to unify and simplify.
- •Ryo joined as first product/design hire; company grew rapidly (20→250)
- •Design team is ~4 people; brand and product split
- •Everyone at the company uses Cursor; feedback is intense and frequent
- •Engineers have diverse workflows (keyboard-first vs. click-first)
- •Design challenge: keep the core simple while enabling depth via layers
- 8:39 – 11:22
Simplifying the product: unifying Chat, Composer, and Agents into one experience
Ryo recounts Cursor’s earlier UI as a collection of overlapping features layered onto VS Code. The agent experience existed but was hidden behind confusing toggles, which caused user churn—even for him. The big fix was conceptual consolidation: make “Agent” the primary interface with clear modes, then default users into it.
- •Earlier Cursor: Tab + Chat + Composer felt redundant and disjointed
- •Agents were hard to discover (confusing “normal vs agent” toggle)
- •Strategy: merge similar tools into one: Agent as the core concept
- •Introduce modes as settings (ask mode, plan mode, etc.)
- •Flipping the default to Agents drove major adoption changes
- 11:22 – 13:25
Rebuilding Cursor around agents: flipping from file-centric IDE to agent-centric workflow
As the world shifted toward agents writing most code, Cursor’s UI hierarchy needed to change. Ryo describes Cursor 2.0’s agent-first layout: start from a prompt, run multiple agents in parallel, and review changes via a dedicated review flow. This also makes Cursor approachable to non-traditional coders who don’t think in file trees.
- •Trend shift: from “AI assists your coding” to “agent writes most code”
- •Cursor 2.0 flips hierarchy: agent first, code optional until review
- •Multi-agent management: statuses, switching, long-running tasks
- •Review button surfaces all changes without requiring file navigation
- •Lower activation energy vs blank editor + empty file tree
- 13:25 – 17:39
Designing systems, not features: primitives that prevent “button sprawl”
Ryo contrasts traditional feature-by-feature human-centered design with a systems-first approach. He argues that shipping many bespoke solutions fragments the product into confusing navigation and endless controls. Instead, teams should define a small set of primitives that can be recombined to solve evolving needs (Notion as an example).
- •Feature-first design often accumulates buttons, concepts, and nav layers
- •Systems-first design decomposes problems into stable primitives
- •Primitives should stay simple but flexible; complexity emerges from composition
- •Notion example: blocks, pages, databases, teams as enduring concepts
- •Progress comes from recombining and refining primitives, not constant additions
- 17:39 – 23:04
A design critique in practice: Cursor’s old vs. new marketing site
They review the early Cursor homepage and diagnose why it fails: distracting visuals, unclear value, and irrelevant code screenshots. Then they compare the current site, which has refined typography, less alienating aesthetics, and interactive in-browser demos. The goal is faster “aha” moments without requiring a download or setup.
- •Old site issues: gradients/visual noise, disorientation, unclear messaging
- •Code screenshots lack context for most potential users/industries
- •New brand foundation: refined logo, typeface, adaptable light/dark behavior
- •Human-made artwork preserves “human connection” (not AI-generated)
- •Interactive demos in-browser shorten time-to-value and teach the product
- 23:04 – 24:57
Prototyping with “Baby Cursor”: build a playground instead of wrestling prod code
Ryo introduces “Baby Cursor,” a lightweight environment he built quickly to prototype interactions without production constraints. It recreates key hotkeys and behaviors and can even integrate real models, enabling realistic states and outputs. This makes it far more effective than static Figma mocks for agent-driven interfaces.
- •Design prototypes don’t need full production complexity to be useful
- •Baby Cursor built in hours; includes core interactions and hotkeys
- •Real model integration enables authentic live states and outputs
- •Rapid exploration: keyboard navigation, previews, embedded browser ideas
- •Figma mockups struggle with dynamic AI states and parallelism
- 24:57 – 32:59
From prototype to product: multi-agent workflows, plan mode, and fast iteration loops
Ryo demonstrates how agent-centric building works end-to-end: ask for a capability, let the agent inspect the codebase, produce a PRD-like plan, then execute with a single “Build.” The workflow embraces partial success—ship the UI, notice it’s not wired, then iterate. The emphasis is on accelerating creation while keeping review and control available.
- •Multi-agent experiments: run tasks in parallel and compare outputs
- •Plan mode: agent asks clarifying questions and produces a PRD-like plan
- •Build step executes the plan; iteration fixes wiring/bugs quickly
- •Designers can operate in English-first mode, reviewing code when needed
- •Future onboarding: replace repo/project/SSH choices with a “just start” flow
- 32:59 – 38:00
Design as sculpting, not painting: start with a clump, refine with taste and craft
Ryo reframes modern design work: instead of painting static frames, designers will sculpt working software generated by agents. The first output may be 60–70% right, and the designer’s job is to refine structure, interactions, and polish. Craft and coherence—making things truly “pretty” and fitting—remain the human edge.
- •Old process: wireframes → layered visual painting on non-real artifacts
- •New process: generate a functional prototype, then sculpt and mold it
- •Iteration pattern: partial output → diagnose gaps → instruct → refine
- •Human role: taste, detail work, coherence across the whole product
- •Live interactions/motion become easier to explore in real software
- 38:00 – 40:36
The future of interfaces: decomposed primitives + adaptive reconfiguration (not randomness)
Looking forward, Ryo expects interfaces to persist but be decomposed into reusable parts that AI can recompose per user and context. He argues raw text isn’t always the best UI; people still need tables, to-do lists, previews, and interactive states. “Adaptive UI” should mean consistent personalization, not a different interface every time.
- •Interfaces won’t disappear; they’ll be decomposed and recomposed
- •AI should present the best representation (tables, lists, previews) when useful
- •Unify work that used to be split across apps; reduce manual stitching
- •Personalization: same underlying system, different defaults per persona
- •Avoid unpredictable generative UI; optimize for familiarity and expectations
- 40:36 – 42:19
Advice for design founders: define what won’t change and build from core concepts
Ryo’s closing guidance is to identify the enduring concepts that will still matter in 10 years, then build a product system around them. Roadmaps should map back to these primitives, evolving through recombination rather than constant surface-area growth. Aaron connects this to Bezos’ “what won’t change” framing as a durable strategy.
- •Start with core concepts/primitives that define the product long-term
- •Use them to determine the essential first step and sequencing
- •Evolve by refining and recombining, not endlessly adding features
- •Clarity increases as you get closer, but fundamentals should remain stable
- •The core concepts ultimately define what the company is about
