Ryo compares building software to working with many layers of abstraction and depth. To create something great, you either need to know everything yourself or assemble a team with specialized strengths for each layer. For one person, learning all this requires a long process of trial and error, starting simple and gradually increasing complexity. In a team setting, the process can be even slower. A designer might create a mock-up, but then it goes through product managers, meetings, and multiple people, often resulting in a final product that is only a fraction of the original vision a year later.

New tools like Cursor are changing this dynamic. You can give an AI agent a somewhat ambiguous idea and get something that is 60-70% complete on the first attempt, bypassing many traditional complexities. The paradigm shifts from needing to understand everything before you can build, to being able to create something imperfectly and then iterate on it very quickly. Ryo explains that as these agents evolve, they will integrate with more tools like Figma and Notion, and most importantly, understand the codebase itself, which is the source of truth. This new workflow benefits everyone, from expert coders who use advanced auto-completion to those who are increasingly relying on the agent to build.

Jennifer adds her perspective from her time on the product side, where design and engineering workflows were very disjointed. She notes that Figma helped bring these processes closer by creating a central artifact for collaboration. However, Cursor takes it a step further. Instead of just collaborating on a design, teams can now interact with and test a functional, working artifact from the very beginning.

Over the last 15 years, the process of making software has become highly fragmented. Different roles like designers, product managers, and engineers have split off, each using their own tools, artifacts, and language. Designers might be in Figma, PMs in Google Docs, and everyone operates in their own silo. This creates significant collaboration issues and friction, which only worsen as a team grows. Ryo explains that this disjointed process leads to teams shipping their organizational chart, with different roles often fighting over who is right.

The central, shared truth that can unify these disparate roles is the code itself. An AI tool like Cursor aims to connect and absorb all the different artifacts and formats, using the code as the foundation. The AI agent can synthesize information from the past, like team preferences and code evolution, with the present, such as the current codebase and real-world feedback. It can also incorporate future plans and visions.

This allows for a single tool that can present the same underlying code in different ways, tailored to each role. An engineer might see raw code, a designer could interact with a visual interface similar to Figma, and a PM might view it as a document. The key difference is that everyone is interacting with a unified system, not siloed apps. The AI handles the conversion and integration, eliminating the need for manual synchronization through meetings. This frees up each individual to focus on iterating ideas in the format that works best for them.

With AI agents increasingly acting as coworkers, a key question arises: where does taste come from? Ryo Lu suggests the term "taste" is ambiguous. He views it as a process of selection. This selection is based on a vast collection of past experiences, whether from nature or from human creations. Over time, a person develops preferences and creates a personal boundary defining what they consider good, beautiful, or right.

This process is highly individual and subjective, much like an LLM is trained on a dataset. However, a key difference is that an LLM has seen everything but lacks a genuine opinion. It might get confused and simply follow trends, like putting purple gradients everywhere. The strength of an AI is its ability to produce a solid baseline very quickly. The human's role is to then apply their taste—their self-selected boundary of what is good—on top of that baseline.

Ryo explains that you cannot give an AI a vague, non-specific prompt and expect a perfect result. The human must provide the opinion and direction.

I don't believe you can give the agent something long running or a really non-specific prompt and expect it to give you exactly what you want. It's just not going to work. There needs to be something for the human to specify what is good, what is right, how I want to do it. If you don't put in that opinion, it will just produce AI slop.

The lines between product managers, designers, and engineers are blurring. Ryo Lu views them all as "software builders" or "makers." In the early days of computing, a small group of people, or even a single person, would handle everything from low-level architecture to the user interface. They built the whole product, often without the intense economic constraints of today. This resulted in a more cohesive creation.

Over time, the industry broke everything down into specialized roles to optimize processes and costs. This boxed people into narrow problem sets, causing them to lose sight of the bigger picture: making something better for people. Ryo believes we are now starting to go backwards, in a good way. He shares his own experience of becoming a product designer, where he stopped coding and created mockups that took years to be built, if they were built at all.

New tools like Cursor are changing this dynamic. A designer can now actually build, focusing on their craft and taste while letting AI agents handle the rest. This also improves teamwork. When infrastructure engineers, front-end engineers, and PMs all use the same tool and codebase, they can cover each other's weaknesses and amplify their strengths. The AI acts as a unifying layer, reducing the friction and communication overhead that causes common conflicts.

Jennifer Li asks how this democratization of building tools influences the focus on aesthetics versus function. Ryo broadens the definition of design itself. He explains that design is not just about visuals like choosing a border radius. It's about the entire conceptual architecture of a product.

Notion is a pure conceptual product, meaning every single concept was designed by a person. In Notion it is really just blocks, pages, databases, the workspace and then everything kind of works around these concepts.

Aesthetics and good design exist at every layer, from the UI and brand down to the front-end code and how data is stored. The real beauty of design is putting all these pieces together. The goal is to create the simplest possible system with the fewest concepts and code paths to do the most for the most people.

While Cursor's primary focus remains on professional developers, adjacent users like designers are increasingly using the platform. Ryo explains the approach isn't to build new products for these users, but to offer different pre-configurations and packaging of the same core tool. For example, a designer could interact with an AI agent by chatting with a browser to preview and make visual edits directly, without needing to understand developer-specific functions like cloning a repository.

This leads to a broader discussion about two different software philosophies. Jennifer questions whether the industry is moving from single-purpose apps toward all-encompassing "everything apps" like Notion or ChatGPT. Ryo frames this as a choice between user-centric and system-centric design.

The user-centric path starts from a specific problem for a specific group of people. It's easier initially, but becomes limiting. As you add more features to grow, the simple, purposeful tool becomes complex and no longer serves the original users well. These apps also create silos.

The alternative is a system-centric approach. This involves designing flexible, universal concepts that can be adapted for many use cases. Ryo uses Notion as a prime example. It's disguised as a simple note-taking app, but it's fundamentally a system of blocks and databases. This structure allows it to function as a task manager, a wiki, or anything else a user can imagine.

The challenge with universal apps is that their open-ended nature can be intimidating for new users. However, Ryo believes this is a solvable problem through better onboarding, AI guidance, and smarter packaging. His preference is to build something that can work for everyone, rather than focusing only on a narrow user base.

AI can be seen as a universal interface. At its core, it's a simple prompt-and-response system. This basic interaction can be shaped into many different forms, like a chat box, a sidebar, or a completely new, purpose-built layer. The underlying AI architecture remains the same, but the interface can be adapted to fit different people and their needs, making it feel more comfortable.

However, simply turning every piece of software into a chat box would be a bad experience. Staring at a blank input field requires the user to know what to ask and how to phrase the perfect prompt. A new user might try it once, get a result that isn't what they wanted, and conclude the tool is bad or not for them.

I think there's so much potential where the models today can already do so much stuff for a lot of people. For a lot of use cases we need to design a mechanism to kind of help transform that input output into the form or format or views or workflows of the people today.

The role of design is to create mechanisms that translate AI's capabilities into the existing workflows and formats that people are already used to. This eases users into the new technology instead of forcing them into an intimidating and unfamiliar process. For example, instead of typing a question into a chat box and reading a wall of text, a user might see an autocomplete suggestion they can accept with the tab key, or select a design element and ask for variants that appear instantly. These integrated experiences are often more optimal than a simple chat interface.

Constraints and guardrails can be a friend to creativity. Even with powerful, open-ended tools, simplicity acts as a natural and necessary constraint. There is a limit to how many concepts an individual can process at any given time, which forces designers to prioritize what is most important.

This leads to a layered approach in software design. The core concepts and default settings should be simple, catering to about 80% of users. More complex, power-user features or alternative workflows can then be introduced in secondary layers. This prevents overwhelming the user by presenting everything at once.

The role of a designer shifts from creating a fixed interface to defining the most important concepts and how they relate to each other. The goal is to build a system with a minimal set of abstractions that can handle numerous user customizations. This turns the software from a static tool into a flexible toolbox.

For example, while many coding agents force users into a small, restrictive interface, Ryo explains that Cursor is designed to be highly customizable. Users can create their own modes, choose different models, select specific tools and prompts, and even change the interface colors. The designer's job is to create the underlying system that makes all these permutations possible while keeping the default state simple and accessible.

Ryo Lu's creative process is sporadic and avoids a strict routine. Instead of constantly creating mockups in Figma, he allows for a more fluid approach. This involves writing down thoughts in bullet points, going for walks, sketching, or building code prototypes. He believes in not forcing inspiration and leaving blank space to let ideas simmer.

His inspirations are drawn from a wide range of sources beyond just software. He looks at print design, graphic design, films, music, and art. With a background as a biology major, he also finds parallels in natural systems, noting similarities in how layered systems can be built and interact. Looking at the past is another significant source of inspiration for him.

This interest in past technology led to his Rio OS project, which recreates the feeling of using old Macs and iPods. The project began as a simple soundboard app, a farewell gift for his colleagues at Notion. He decided to style it like a retro Mac OS, placing it in a window with a menu bar. This quickly evolved into a larger project with multiple apps and windows, which he worked on for months.

So that's kind of like the message I want to kind of tell people is like we've been almost doing the same thing over and over again from the very beginning. But maybe given the technical constraints of each era, that's how it ended there and how it came to be. But we kind of carried a lot of these concepts and patterns over to even now and then we are actually still living in it.

The Rio OS includes themes from different eras, like Mac OS System 7, the first Mac OS 10 Aqua theme, and Windows 95 and XP. Ryo found that while the visual styles feel authentic to their time, the underlying functionality is the same. This highlights his central message: the fundamental concepts in software are timeless. He argues that basic applications like paint programs, text editors, and the desktop icon metaphor have not fundamentally changed since their inception in the 1980s. People are essentially using familiar ideas in new mediums.