thoughts

the value of ambient non-chat AI experiences

June 19, 2025

As I have been deeply building with AI and observing how AI is being integrated into products, I've noticed some patterns in how this technology has become part of almost every software out there, especially the software used in the workplace:

  • The interaction model with AI in almost every single app is a chat interface — mimicking the equivalent of asking another person. Little innovative thinking has emerged on this interaction model since the first day that ChatGPT was launched
  • The main context gathering happens through a pull (or on-demand) motion, where users need to explicitly prompt the AI each time they need help, rather than the AI understanding their ongoing work context. This narrow approach misses the rich, multi-modal signals that could inform AI assistance—what users are looking at, how they're navigating, what files they're opening, their typing patterns, and more.

While these patterns have led to unprecedented adoption of AI technology and tools in the past few years, one thing I still question is whether AI tools have the needed context to successfully deliver value in sticky, long-term ways for people. These patterns are likely due to the fact that we are still in the early stages of figuring out how AI should integrate into our daily lives.

Moving forward, I think some of the most important things we can do include:

  • Bake AI into existing workflows and patterns that people are used to — most software already give users the tools to point-and-click (e.g. selecting and dragging text in a document), and there is more opportunity to tap into those interactions more deeply.
  • Make it so that AI is running in the background, always collecting context through multiple modes and channels, and giving people superpowers in more ambient ways, before people even have to ask or think about what AI can help them with

What excites me about this direction is that it feels much more natural to what humans are used to — we don't interact with the world by typing questions into a chat box. We look, we point, we gesture, we navigate through spaces, and the context from all of those lead to the output that feels the most valuable. The products that will get not just amazing adoption, but also amazing retention will probably be the ones that can deliver on these.

the evolution of product building roles with AI coding tools

June 10, 2025

With AI bridging the gap between natural language and programming language, more people beyond engineers have begun contributing to codebases and "vibe coding" — essentially writing code through conversation and iteration rather than traditional programming. As AI models get better, and improvements in code reviews and testing follow, more and more people will prototype, build, and ship new experiences to customers.

This shift in who can code is already changing how product teams work. As a result, I hypothesize there to be a shift in functions and roles in engineering, product, and design teams, initially starting in the tech industry. I believe product management, product design, and product engineering roles are going to merge into a single role — probably called something like "builders" — where they spike across a set of skills that collectively make them effective teams to build amazing products for users.

A simple categorization of these skills might look like:

  • Technical architect — understanding systems, data models, APIs, and how to build scalable solutions
  • Conceptual architect — thinking about the conceptual system users have to comprehend to use the product, and how every new addition to the product fits into that system, understanding how the system solves the user problems
  • Taste maker — setting the bar for high craft and quality in the experiences delivered to users that looks and feels exceptional

These are not mutually exclusive skills — most people will develop strength in one of these, a smaller subset will excel in two of them, and rare individuals will excel in all three of them.

However, I think the benefit of this classification is that there will be more fluidity in what people can do for each project, and even make it easier to pickup new skills before the next project. For one project you might play the equivalent of a product engineer, and for another project play the equivalent of a product designer.

What excites me about this is that people will no longer be rigidly stuck in what their role definition expects of them, likely product manager or designer, but will be able to focus more on how they can contribute to building the best products for their customers, based on what is needed at any given moment.