With a background that winds from photography and media studies to the heart of Silicon Valley, Wesley Yu, Head of Engineering at Metalab, brings a unique perspective to building the digital products that shape our world. Having helped craft the product DNA for household names like Slack and Coinbase, he now focuses on the next frontier: the user interface of artificial intelligence. In our conversation, we explore how the fundamental principles of UI have evolved, from the gestural revolution of the iPhone to the complex, real-time collaboration demanded by modern productivity tools. He offers a deep dive into the technical and philosophical challenges of designing for AI, discussing how to create systems that can accelerate human learning, manage shared memory, and query vast, unstructured datasets without feeling invasive or robbing users of essential experiences.
You described a unique journey from photography to leading engineering at Metalab. Reflecting on your time at Y Combinator in 2013, can you share a specific story that ignited your passion for coding and how that creative background now influences how you approach product DNA for brands like Slack?
It was definitely not a straight path for me. I’ve always been a builder, but it took me a long time to find my medium. I started in photography, then media studies, and even produced AM news radio for a while, which taught me how to turn complex ideas into compelling stories. When I moved into content marketing for a tech startup, I found myself at Y Combinator in 2013, and honestly, I had no idea what it even was. But being down in Sunnyvale, surrounded by programmers working tirelessly to build the future—that energy was just intoxicating. I’d never seen so many people so passionate about their work. I tried to learn programming back then and failed, so I figured it wasn’t for me. It wasn’t until my partner started a coding bootcamp and called me one day saying, ‘Hey, I think you should quit your job and do this,’ that it clicked. On a whim, I did it, and the rest is history. That creative and storytelling background is now central to how we work at Metalab. When we’re building a product’s DNA, we’re not just writing code; we’re finding the core story of that product, figuring out how to translate its complexity into an experience that feels intuitive and essential, whether it’s for an early-stage company like Slack was or an established leader like Google.
You mentioned the iPhone introduced gestural inputs and mobile apps created habit loops with notifications. When designing the AI-powered reading app for kids, what was the step-by-step process for building an interface that was core to the experience without feeling invasive like some modern apps?
That project was fascinating because the AI couldn’t just be an add-on; it had to be completely woven into the fabric of the experience. We started by looking at a real problem: nearly 40% of fourth graders in the U.S. are behind in reading, and once they fall behind, it’s incredibly difficult to catch up. The goal was to scale the interaction between an expert reading teacher and a student. The first step was generating completely custom content. Using LLMs, we created storybooks based on a child’s specific reading level, focusing on concepts they were currently learning, like CVC words—cat, rat, mat—or digraphs. The text included words they already knew and strategically introduced new ones. We paired this with generative image models to create unique illustrations for each story. The second, and more interactive, step was the reading experience itself. We built a speech-to-text model that could evaluate phonemic accuracy down to the individual sounds within a word, like breaking “the” into “th-uh.” The interface had to facilitate all of this invisibly. It’s not about flashy AI features or notifications demanding attention. The AI is the quiet engine making the learning personalized and effective, which is the opposite of the invasive, attention-grabbing habit loops many mobile apps rely on today.
You explained how productivity apps created an expectation for real-time collaboration, complicating state management. Can you detail a specific challenge your team faced with this? For example, what technical hurdles did you overcome when implementing features like multiple cursors or shared versioning for a client?
This is a perfect example of how a seemingly simple design choice can have massive technical implications. The rise of tools like Google Docs and Figma has created an expectation that all software is real-time and collaborative. As a user, you just expect to see multiple cursors, presence indicators, and inline comments. The challenge is that this fundamentally changes how you have to think about your architecture. We’ve hit this blind corner many times. For instance, with the rise of serverless architectures, you build systems to be stateless—they spin up when needed and disappear when they’re not. This is efficient, but it breaks down the moment collaboration is introduced. A designer might add a tiny feature, like a little green bubble to show a teammate is online. To the designer, it’s a small UI element. To an engineer, that one bubble just threw out the entire stateless architecture. Suddenly, you need to maintain a persistent state. So, a huge hurdle is planning for that eventuality from day one. You have to ask, ‘Is there any chance this product will become stateful in the future?’ Because the expectation now is that you’re not just getting a task done by yourself; you’re working with others, whether those others are human colleagues or an AI system. Overcoming this means building a more robust, state-aware foundation, even for an MVP, which is a significant technical investment.
When discussing the tool for policymakers, you framed AI as an interface to query unstructured data. Could you walk me through the technical decisions behind using a knowledge graph and graph RAG over a standard vector search, and what specific improvements in query accuracy or complexity you observed?
Absolutely. That project involved a client with a massive repository of unstructured data—millions of government documents, meeting minutes, articles, and directories of people and organizations. A standard vector search, or RAG, is great for straightforward questions like, ‘What are the top health policy headlines today?’ It can find relevant text chunks and synthesize an answer. But the users—policymakers, lobbyists, journalists—needed to ask much more complex, relational questions. For instance, a user might ask, ‘What bills is Coca-Cola lobbying for in 2025, and how much have they spent?’ or something even crazier, like, ‘Which lobbyists used to work for the Department of Energy, and which bills are they lobbying for now?’ That last one is an almost impossible question for a standard LLM and vector search to answer reliably because it requires connecting multiple disparate pieces of information across different documents. This is where the knowledge graph came in. Instead of just vectorizing raw text, we first defined an ontology of the key entities—people, bills, organizations, votes—and their relationships. We then used Graph RAG, which involves getting the LLM to write a Cypher query for a graph database like Neo4j. We found that LLMs are surprisingly good at generating these queries because they’re working with known entities and defined relationships. This allowed users to make these complex, multi-hop queries and get incredibly accurate results that would have been impossible otherwise. It turned a mountain of text into a queryable, semantic network.
You argued that frictionless AI interfaces could accelerate human learning, similar to how marathon running became more accessible. Citing a project you’ve worked on, can you provide a concrete example of how you designed an interface that reduces cognitive load without robbing the user of a crucial learning experience?
The comparison I love is that 50 years ago, running a marathon was an elite feat. The first New York City Marathon had 127 runners, and half didn’t finish. Today, 50,000 people run it. Technology, training, and knowledge made it accessible. I believe AI can do the same for intelligence. The reading app for kids is a great example. The “friction” in learning to read isn’t the struggle of sounding out a word—that’s the crucial learning experience. The real friction, the cognitive load, comes from things like finding material that is perfectly matched to your level or getting immediate, expert feedback. Our interface was designed to eliminate that unproductive friction. The AI acts as the perfect tutor, generating a story that is never too hard and never too easy. It presents the exact concepts a child needs to learn next, in a way they can understand. The system evaluates their reading in real-time, but it doesn’t just give them the answer. It guides them. So, we’re not automating the learning itself; we’re automating the scaffolding around it. We are removing the barriers to entry, so the only impediment to a child’s learning is their own effort, not a lack of access to the right curriculum or teacher. That’s how you reduce cognitive load without robbing the user of the very experience you want them to have.
What is your forecast for the future of AI-generated user interfaces?
I believe humans will remain at the center of interface design for a long time to come. We’ve seen demos of AI creating interfaces on the fly, and while impressive, they miss a crucial point: people know best how other people want to solve problems. Think about a complex, real-world task we designed for: a travel arranger for a reality TV show. They’re booking flights for a huge cast and crew across different locations and times. No human brain can hold all those variables. A human designer understands instinctively how to externalize that memory—how to design an interface that shows who is booked, who is pending, and what action is next. We know how to use progressive disclosure to hide irrelevant information and only show what’s needed at that moment. We can teach an LLM the rules, but teaching it the intuitive empathy for a user’s cognitive state is another challenge entirely. An LLM can verify if a function was written correctly, but verifying whether an entire application truly meets the nuanced needs of a consumer is incredibly hard. That verification has to happen with the market. So, my forecast is that AI will become an indispensable co-pilot for designers and engineers, an incredibly powerful tool for prototyping and execution, but the strategic, empathetic, and problem-structuring part of UI design will remain a deeply human endeavor.
