The Collapse of Product Teams: How AI is Rewiring Ideation to Execution

Keyvan Azami, David Kossnick at UXDX USA. Video: https://youtu.be/89-O_plY7_M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

New superpowers and blurring roles

[00:00:08] David: Cool. Well, I'm David Kossnick, head of AI products at Figma. I'm really excited to be chatting here with Keyvan about how design is changing as a process, along with product management and engineering and the whole stack of how things get made, thanks to AI. To kick it off, maybe you can tell us a little bit more about yourself and your team, and also what you're seeing in terms of how work is changing.

[00:00:31] Keyvan: Absolutely. Thanks for having me here, UXDX. I'm Keyvan. I've been at Google for a few years. I'm one of the many senior engineering managers there, and my current role is in AI for education, despite my title; I had recently changed. My focus is mainly on how we adapt our AI tools for better learning. I think the main thing that I see changing, like everybody else, is that we all have some new superpowers. We've got the ability to create. A lot of us could create before, but now we can do it faster, more efficiently, more effectively. As a manager, I spend a lot of my time in meetings, conversations, discussions, so the amount of time that I had hands-on keyboard was limited. Now I can make things as I think about them, and by the end of the day I feel like I produced something. I don't know, there's something about that.

[00:01:36] One problem that is associated with it, though, is that it's hard to disconnect from it, because I want to come home having finished the thing. But it's definitely a superpower. I see it for our product managers, I see it in our UXers. It's really cool to be gathering around a living concept, as opposed to static slides or documents. How about yourself? How are things evolving at your end?

[00:02:02] David: Roles are definitely blurring. I actually recently had a baby, about eight weeks ago. Thank you. I went on parental leave, and I came back six weeks later, and it was like the entire company had changed. The reason was we finally opened up connectors for Claude. Before that you could use Claude in a much more generic way, like, "Help me brainstorm this idea." And suddenly I had GitHub access, Slack access, Figma access. Hex, it could pull our product analytics. Statsig, it could look at our A/B tests. And I was like, "Oh man, this is crazy." Basically every PM at Figma in the last month has now shipped a pull request to production. The vast majority of product requirement documents were first drafted by Claude, when it was pulling in other context and brainstorming with chat. So even for PMs in my area, the day-to-day is just so different now than even a month ago. I'm curious, are you seeing specific examples of other ways people are changing the tools and blurring lines as well?

[00:03:11] Keyvan: I think we can operate between the cross-functional teams a little bit more fluidly. The stringent handoffs from idea generation to prototyping to execution have definitely blurred quite a bit. The speed to get to prototype is just incredibly faster, which is amazing. Being able to show stakeholders, show a potential segment of users, maybe even do UX research on it really quickly, and iterate on that, is dramatically different compared to maybe a year ago. I still see a bit of a gap, or maybe quite a bit of a gap, between a prototype and production. I think it's great that you're seeing more of that. Depending on your ecosystem, the product sets, the user base, there's still a bit of a block in terms of getting things through large CI/CD pipelines, making sure the quality's there for mass use. But I think we're making inroads towards that as well.

[00:04:24] But brainstorming, being able to have a conversation and talk about three different prototypes that one of our UX designers built and one of our PMs and one of our engineers built together, we now have three more things to talk about than we had. And because we didn't spend as much time building it, I feel like we're not as attached to it as well. We're happy to rip it apart and start again and iterate faster, as opposed to that bias you sometimes had: "I spent two weeks building this thing, I'll just tweak it a little bit." That's not the case. We can be very, very drastic about the changes that we make in reaction to user feedback.

Who owns the final call when everyone can build

[00:05:08] David: One thing we're seeing a little bit in the industry in general is, as roles blur, more and more people can collapse the stack as a builder, and there are some interesting dynamics that have come from that. Everyone makes a prototype, and it's a designer's job to own what the visuals look like. Those situations can get a little sticky on who makes the final call on taste, who makes the final call on which of these we double down on. One thing we've started to see a lot internally is that it is great for everyone to explore. It's also great to have more resources for doing rapid research, so we don't get hung up in big debates; you can very quickly take a prototype and do some validation, understand what works and what doesn't, so any next conversation has a lot more meat on the bones.

[00:05:52] But also, at the end of the day, still having extreme clarity in terms of ownership of areas. Engineers own the code. Every code directory is owned by a list of people, and it's a mark of pride to earn ownership over a directory; you've committed a lot in it. So even if a PM is committing code to that directory, you own it. And in the same way, at Figma, designers own the final set of interfaces. So even if lots of people are coming with ideas, they still hold the torch. But I think that is being navigated very differently at different places. So I'm curious, how do you deal with the ambiguity of, when everyone can try their hand at everything, what sticks?

[00:06:33] Keyvan: I see a very similar paradigm: engineering owns the produced software, designers own the design, the look and feel, the experience. Product owns the full-on life cycle of it: what are we building, why are we building it, how are we building it. I think there are still very specialized skill sets that complement each other. Looking at the commerciality of a product is still something that a lot of product managers own and drive. Does this make sense? Does this fit the market? Test the market. What are the best practices for accessibility and all that stuff? That's knowledge that's within our UX community. How do you run controlled studies with our users? Again, our UX researchers. Engineers: how do you scale something across multiple geographies, a large user base? How do you scale an engineering team?

[00:07:33] If you ask one of the coding agents to build a certain application, and you didn't tell it what the size of your organization was, how many engineers would be working on it, you would probably get something that is not optimal for your organization. So you need to give it a lot of context. If you had 100 engineers working on a system, you'd design it very differently than if you were a startup with one or two people working on it. Those are judgment calls that we still need to make. Having said that, I think there is more blurring happening, and in smaller firms and startup land that blurring is definitely happening faster and more prominently. In larger companies with more legacy systems, more complex code bases, obviously that's harder, and that's going to take time. How the future will look, I think we'll have to see. It's hard to crystal ball that completely.

Context and Figma's PM operating system

[00:08:30] David: I just want to underline your point around how important context is. One thing we built internally at Figma we call the product manager operating system, or PMOS. It basically packages some of those connectors I was talking about with a whole bunch of internal skills, and tries to distill a lot of context about Figma's organization, Figma's values and best practices into something that any of the PM team can use to navigate questions in any of the different disciplines or domains, to reason about the code base through the Git connector, or to do simple data analysis that gets you 80% of the way to as good a result as a data scientist, but in three minutes.

[00:09:08] One thing we've seen about this context is it's so valuable that this PMOS has basically gone viral within the company. The next cohort that found out about it were engineering managers, also very strapped for time, in meetings all the time, trying to figure out what's going on in the organization. Now most of the engineering managers also use this PMOS to stay in a much more rapid loop on synthesizing, debating, understanding and navigating that extremely valuable context, which in a lot of cases is hard to give to AI in a well-structured or formatted way.

Evals and test-driven development

[00:09:39] Keyvan: I'm curious, you mentioned a lot of your PMs are actually submitting pull requests. How are you performing evals and testing, and quality?

[00:09:50] David: We've been chatting a lot about how the stack is changing and the process is changing. I do think there's a whole topic of how we should work now that everything is collapsing. In my mind, for AI-first products, evals are the number one thing for that. If you're working on something that's a chatbot, or has AI built into it, how do you know if you're going in the right direction? A new model drops: should you use it or not? Someone adds a new skill: is it actually helping or not? You change the system prompt, you give it a new tool. These things are very slippery, because it's so organic and non-deterministic. So we've invested a lot in terms of tooling and process and culture in evals, short for evaluations, for those who aren't familiar. It's basically people sitting and creating examples and grading what good looks like for AI.

[00:10:40] We have what we call golden eval sets for key use cases. We have a product called Figma Make, as an example, which is our prompt-to-prototype tool, and we have a canonical set of use cases: you bring in a screenshot and this type of prompt, here's what good looks like. You bring in some structured frames and this type of prompt, here's what good looks like. And we have humans and tools and AI grade these things as we gear up for new releases. At times it feels tedious, but it's also the kind of work that is craft in this AI era. What does a good response look like when you ask an ambiguous question? It's actually a hard question, and humans disagree about what a good result looks like. That's why I think it's so important, in this collapsing of the stack where every function is changing the agent loop, to have one shared surface for the team to be able to look at and iterate on quality.

[00:11:36] Keyvan: I think test-driven development has always been a good design pattern. Now it's becoming almost essential. You're working with stochastic models, you're working with uncertainty. Even telling the agents, "Hey, go build this thing": how do you know it's actually done it? You can obviously go and test it, but wouldn't it be nice if, when the agent said it's done, it's actually close to completion? That's where you need to design the evals, design the tests up front, to at least give it enough direction to design it the right way. Having that eval-forward mindset, I think, is super critical. And it protects you when there's a new version of a model, or you change your model altogether, different model providers. How do you make sure it continues to work without having to repeat the entire cycle? So I think it ends up having benefits from multiple facets.

[00:12:36] David: With AI picking up, a lot of people compare it to an intern or things like that. These things sometimes work really well, sometimes less well. I do think it's a return to best practices for the tech industry. Design docs have never been more important. That is really great context that you could give a human or an AI. Unit tests, integration tests, never been more important. And I also think, as coding becomes better and better, it moves into being an implementation detail, and all the time will get spent on key decisions and key choices. I think those will happen in surfaces where you have a lot of context and you can play out all of the different branches and weigh the trade-offs well.

[00:13:21] One of my favorite things in the PMOS, actually, is to point Claude at part of our code base and ask it to create a FigJam diagram of the architecture for me. It'll use our MCP hook and make a whiteboard-style set of connected nodes explaining it. And I'm like, "Wow, this is really helpful. What if we change this node here? How would that influence the architecture?" And have a conversation with it. I expect, as these models get better, that will be how you drive a bunch of the architecture decisions. It'll be that type of design doc debate: "Hey, why don't we do it this other way?"

[00:13:51] Keyvan: I think that dynamically generated documentation is really powerful. I often use our agentic coding tool, Antigravity, to say, "Hey, can you explain this piece of the system to me?" Documentation can be outdated, so being able to look at the code base and synthesize a quick summary for me, so I can get my head around something, is quite powerful.

Agents as users

[00:14:17] In that vein, how do you think about content and agents, especially in the context of agents as users, consuming documentation, consuming design diagrams, mock-ups?

[00:14:36] David: It's a wild time. Agents definitely are users for every business today, whether you realize it or not. When someone asks Gemini or ChatGPT what products they should use for XYZ use case, that agent is deciding if it should answer with your product or not. So the future of SEO is SEO for agents. How do you teach the agents what your product is good for or not? I think that's not just true at the macro search level; it's true at granular levels as well. Claude Code has a bunch of MCP tools that I can use, like the Figma one, and how you describe that tool to the agent is critically important. If you have anything ambiguous or confusing about when it should use the tool, that user, which is the agent, is not going to use it correctly.

[00:15:26] So we've been thinking a lot about what it means to design well for agents, and not just for agents, but for their teams too. When you have an agent enter the canvas, how do users understand what it's doing? How do they interact with it, even if they didn't invoke it? How do you have this multiplayer environment where some of those players may not be people?

[00:15:47] Keyvan: I have an anecdote to share. I've been telling my children about agentic coding. I have twin sixth graders, and Aiden was like, "Hey, I want to create an app." I was like, "Great idea." And he was like, "How do I do it?" I said, "Well, you need to write a bit of a spec. You need to sit down and describe what you want to do." It was interesting to see him iterate on creating a Google Doc of the things that this thing needed to do. Then we fed it into the coding agent and saw the output, and then realized what he needed to iterate on. We got the work done. I was his engineer and he was the product lead. But it made you think: if you don't work with this on a regular basis, how do you approach it for the first time? What are the best practices for designing that initial prompt, for structuring your instructions? And you could easily see that I missed a third of what he was asking for, and he had to go back and say, "Well, you didn't do this, you didn't do this." And then he apologized the entire way. So I think there's a bit of an art and science that's still developing around this.

Agents as members of the team

[00:16:59] David: I'm curious, where do you see agents fitting into org structure and team structure at Google in the future?

[00:17:06] Keyvan: A lot of us are having a personal agent that is able to do some stuff for us, historically with information seeking, but now actually taking actions. I've got one that helps me with my calendar. As I'm traveling to California next month, it can pretty much arrange my entire week and draft emails to people that I need to meet, which I proofread and send. I can also get it to start off some of the prototyping ideas. I'm on the go, and it's, "Oh, I really want to prototype this," and it can get started, set up my development environment. As a manager, one of my problems was always that by the time I set up my development environment, I'd get too busy to actually do anything useful. Now it can just automate all that process for me, and I can get started on idea implementation.

[00:18:03] I recently added one of the agents into one of our team chats, and I think it's interesting for it to be able to help discern things. You see a bug, and it says, "Oh, I see that as well, I can see that in the logs." But it's still very much assistive. The question in my mind, the thought experiment, is at what point you can treat that agent as a member of the team. So here's a hotlist, and the agent will say, "I'll take the first two," and then the next person says, "I'll take the next three." I don't think we're quite there yet. But it's quite likely we will get to a place where the first draft will be done by an agent, and the engineers or the product designers will look at the next iterations of that. How are you seeing a bit of that at your end?

[00:18:56] David: For sure. I think we're definitely seeing lots of first drafts done by AI. An engineer I work with, I sent a pull request last week that merged into production, and he was like, "I just asked AI to look at it and it looked fine, because I'm getting 50,000 lines of code a day to review, and there's no way I'm actually going to read this whole thing." I think that's becoming pretty normal now. So I think it puts more pressure on tools like testing, as you said, tools like people playing with the staging release, tools like having your alpha group of trusted testers to make sure everything's good. And tools like aligning up front and having really intentional debates and discussions on which direction we want to go, so that before we kick off a lot of building, we're feeling good about some of the key decisions.

[00:19:43] I know there's a lot of debate and conjecture about whether the PM role is going to go away, whether engineering is going away, what's happening to design. I personally feel like more and more things will move up the stack, and it's such a fantastic time for design as a result. It's a time for craft, it's a time for strategy, it's a time for exploring branches and thinking through different user personas and cases, and doing all of that at lightning speed, at the highest fidelity that's ever been possible. So I'm really excited about the 10x engineer being even more true in design, where you have the 100x designers who are the visionaries and the leaders, who can carry that torch so much further, so much faster than they ever used to before. And in that process, totally reinvent what kind of products everyone uses. We could go on for a while, but I think we might want to leave some time for questions.

[00:20:41] Keyvan: Let's do it.

Q&A

[00:20:43] Host: All right, great. We're going to start the Q&A a little bit early, so go ahead and throw up the barcode, although most of us probably have it at this point. Fantastic. By the way, as a former engineer, I love the concept that the code is the documentation, and it basically always has been. But now we've got a machine that can read it pretty fast, so I like that. Although if you call every function manager or processor, which is what one of my engineers used to do, it's really not that helpful.

[00:21:14] Okay, so: could you walk through how your teams have set up AI tooling such that non-developers can ship production code that has product analytics in it? This is what I love, because we're talking about agents that can help with building and launching, but launching is not the end point. If we want any kind of system that's going to be a full circle, the agents have to know if it's been successful. So I love that this question's got analytics. Have you attached any kind of end point that determines success? Because launch is not success, in my mind.

[00:21:48] Keyvan: I would start by saying that the key word in that question is quality. What is high quality? Can you define that? I think if we can define that, whether you design an eval suite for it or whether you can describe it sufficiently, that's the starting point. If you can't describe how you would measure it, then the agent has no chance of making sure it's of high quality, because that's just completely subjective. So I think we've got to get there. I think it's not too difficult, if you build an application, to build the right analytics. The gotchas are around making sure that the right things are captured, and only the right things are captured. I think there was a talk on data privacy. There's a lot of that type of stuff that goes on as well. We want to make sure we build these applications responsibly, so there needs to be some level of judiciousness there. What do you think, Dave?

[00:22:47] David: I think this question's a little bit like asking designers about design systems: how do you ensure consistency with your design system when random people are making new designs? Well, in design systems you have linters, and you can check some of these things based on rules. You also often have written guidelines for design systems that explain in natural language when to use a button and when not to use that button. I think the same is true for engineering, where you're going to have written guidelines that explain: here are our libraries of choice, here are the packages we use for monitoring, for observability and for logging, here's the database we use, here's our deploy policy and what agents are allowed to do and what needs humans to do. And then you're going to have a layer of checkers and linters on top of that, which run automatically with every PR and say: how many new tests did you create for each thing that you did? Are you using the right libraries for this? I think we're early in that motion getting spelled out, but I'm optimistic that it'll work well.

Q&A: uncomfortably excited

[00:23:47] Host: Are you more inclined to let things go that make you feel a little more uncomfortable, or are you creating these systems so that when things go out you actually feel really comfortable? When we move fast there's always this pressure, and you two appear to be in charge of things, which means you have the ability to stop it or let it go.

[00:24:08] David: I used to work at Google, actually, earlier in my career, and Larry Page was the CEO back then, and he used to say, "We're striving to be uncomfortably excited," because if you're comfortable, you're not pushing hard enough. So I'd say I'm uncomfortably excited. We're definitely not comfortable. We're trying so much that's new in terms of workflows and tools, and the technology is changing so fast, but the promise is also so tremendous, so I think embracing it and figuring out what works and what doesn't is just so valuable right now.

[00:24:39] Host: What about you, Keyvan?

[00:24:40] Keyvan: I agree. I think we're excited. I've had 25 years in the tech industry in different roles, dating myself here, but I definitely think this is probably the most exciting period in my career, or the most exciting advancement that I've seen. So from that respect, I'm all in. But also, as you were saying, engineers are responsible for the software, for the code, for production stability. So we have to feel confident this thing is going to go out there and stay out there and satisfy users, in a controlled environment, and regulators, and everything else in between.

[00:25:27] Host: Comfortable with that? Or are you letting it go even though it may not hit all those people?

[00:25:30] Keyvan: I don't think we're YOLOing it. The thought process here is that the discomfort comes in: have we covered the right amount of edges?

[00:25:41] David: I think with the number of lawsuits that Google has endured in its history versus Figma, you can just tell the difference. Figma's just newly public, not even six months, and it's like, "Ah, we're good."

Q&A: how Figma is dealing with the new tools

[00:25:52] Host: Okay, so speaking of uncomfortably excited, you saw the question that's up there. You knew coming to the stage you were going to get this question. Everybody's voted it up. How are you at Figma dealing with all these new tools?

[00:26:03] David: I'd say we're excited.

[00:26:06] Host: You're excited? Uncomfortably?

[00:26:08] David: Uncomfortably. We think design is so important, and we've thought for a long time it's just such a critical part of the process that has been underserved and under-loved. So I think it makes sense that as engineering becomes a solved problem, and it's faster and faster to produce code, all the time spent and energy will go to design, which is deciding what to build and why, and how it should look and feel, and how it works. So I think there are going to be more design tools going forward than there have been, and I think that's great for design and designers. I think there'll be some specialization, some that might be more for last-mile production design versus early-stage ideation.

[00:26:52] At Figma, our view is that, one, it's very hard to be a collaborative surface for teams, and those teams and their agents, and we're really excited to be that. And two, it's really hard to marry design and code and to be able to go back and forth between either of these. So we've been doing a ton on both of these efforts over the last couple of years, and I think we have an awesome trajectory ahead. So I'm really excited about Figma. Design is growing. I would also say this is not a zero-sum game market. More and more people will design. To your example earlier, with your kids building things: my seven-year-old has shipped three video games using Figma Make. He's a game designer. He knows nothing about code; he can barely type on a keyboard. And I just think we're in for a wave of everyone doing more design, and as such it's an awesome opportunity for all the tools.

[00:27:52] Host: Are you getting any sleep?

[00:27:55] David: Not much, but that's mostly due to my baby.

[00:27:58] Host: Oh, double. Double situation. People said that when brands started selling online, it would cannibalize the sales in their stores. I'm speaking from the beginning days of e-commerce, when I was building an e-commerce store. And of course, what did people do? They bought more. I think this is the paradox we've been talking about as something gets easier. Whether it's a welcome or unwelcome competitor, something like Claude Design has probably invented a million designers in a couple of weeks. And these million designers are in the market, and everyone's a click away. So these tools are really out there for everybody. I think creating more market is probably just fantastic for those who are in that market, even though it's really scary, I'm sure.

Q&A: prototyping is thinking

[00:28:49] Okay, so this top question is really important. There's this concept that when you iterate with something, it's actually a thinking process. The phrase would be "writing is thinking." I definitely believe prototyping is thinking, and you can think of it as externalizing what's in your brain. I bounce it off the machine, the machine shows me, "Oh, that's not what I wanted. Oh, that's not what I wanted." How do you see speed versus that level of thought? You're both thinking about your teams, and you want to move fast, but maybe they're just becoming idiots. They're smart people, but their ideas look like they came from idiots. How do you balance the thinking and the speed?

[00:29:27] David: I don't think prompting is the final interface. I think it's a great way to get started and to engage, but there's really a spectrum from designing every pixel to be exactly right to vibe CEO-ing: describe the thing and go solve it. Right now our tools are bad at letting you go across those levels of abstraction. You have to pick a lane: "All right, I'm going to be in the prompting lane," or, "I'm going to be in the design-every-pixel lane." I think there's a tremendous opportunity to be able to go much more fluidly back and forth, because the reality is that writing is thinking, and so is drawing, and there's a time for both. Sometimes, when you're just getting started, you have writer's block, you just want to get a sense of the universe, and then you want to hone in. The double diamond exists for a reason. You want to diverge, you want to converge, you want to diverge again, you want to bring teammates in with new perspectives and go in a different direction. So I think it's both.

[00:30:25] I think AI slop will certainly exist, and human slop will also certainly exist. A hammer doesn't make someone a better builder. It does mean a bad builder could break something more easily. That's why it's so important that, as these tools get developed, we create cultures and process to also train people on them. And it's why things like Figma Make are public to your team by default. So if someone comes into it, they can see exactly the whole thread, and which things were changed by hand, and which ones were prompted, and where they brought in frames because they wanted it to be just right. So everyone can get a sense of, "Oh, this is how you got to this good a result."

[00:31:05] Keyvan: I like that interchangeability between prompting and a more creative way of interacting with the design. In addition to what you said, I think you can still think very critically about what you're building, in steps. I can't possibly describe everything that I want from even a prototype in one paragraph. My brain is wired to work in steps: what are the building blocks, what are the LEGO pieces that I need to gather? So I still go through this process, but instead of having to worry about lines of code, now I think about big chunks of functionality. I start thinking, "Okay, I want to have such-and-such user interface, I want to have this kind of data gathering, I want to have this type of authentication," and let it turn out those pieces, and then I start assembling it together. So don't start with War and Peace as your prompt, because first of all it's probably not going to work. The model's going to lose some focus along the way. There may be some contradictory things in there. So bring the structure as well. But as you say, there are going to be other versions of this that may become even more efficient or more fluid.

[00:32:23] David: I can't wait for all of you designers to build better interfaces than the prompting we've got.

Q&A: rapid fire

[00:32:30] Host: Okay, let's do some quick rapid fire, because we're running out of time and there are great questions. How do you get 10x designers driving vision if PMs are going to cut them out?

[00:32:38] David: By having better vision.

[00:32:40] Host: Mhm, okay. Keyvan, do you have this issue?

[00:32:44] Keyvan: I think with ideas, we need a lot of ideas, because we can turn them into prototypes. So therefore we need to be able to come up with more.

[00:33:01] Host: All right. So they both believe in the market of ideas. Excellent. How do you navigate non-design stakeholders getting attached to visual prototypes early in the process? As we build more, people get attached quicker. How do you deal with the people in the business who, in my experience, once they see a vibe prototype, actually think it works and actually exists? How do you deal with them?

[00:33:16] David: Two parts. One, validate with users. Users trump internal stakeholders in terms of what they want.

[00:33:22] Host: Before you get to the stakeholder?

[00:33:24] David: Either. Early and often is best. But go back to ground truth: is it solving someone's problem?

[00:33:31] Keyvan: Right. I think you can obviously ask the stakeholder or user to think differently, not be stuck on a particular point, but the alternative is that I go back and iterate, an hour later, a day later, whatever. So the lead time is a lot lower now.

Q&A: keeping the fun

[00:33:50] Host: Okay, let's end on this question. This is a great question. Some of this is taking the fun out. So how can we keep the fun? I know it's a hard question. What is Jim saying? Anyone can make it. It feels like we're just becoming reviewers; we're watching the machine. A lot of folks here got into this business because they have the desire to make things.

[00:34:15] David: For me there are different sources of fun at different times. The thing that I find most fun is imagining a thing, and then having it be real, and seeing someone love it and use it. That is my happy place that keeps me excited to keep building. And I think for me there's some nostalgia with the new tools, where I don't know them as well and they're unpredictable, and I like doing everything by hand still. But there are ways in which they can shorten that path to happiness, and I think that's the part where I'm like, how do I have my cake and eat it? How do we make these workflows better so you can do both?

[00:34:56] Host: David's bringing back the fun. What about you, Keyvan?

[00:35:00] Keyvan: I think it's got to be fun. As you said, I think you use your skills to the utmost level that you can, and use the tool as a tool, to get you there faster, but not at the cost of giving up your talents, your skill sets, your experience. I use it, but I have three agents working on three different things. That's kind of fun. I don't have to get stuck on one thread. And then I make judgment calls along the way.

[00:35:30] Host: Excellent. Thank you so much. Round of applause for David and Keyvan.

[00:35:34] David: Thanks for having us.