How Amplitude built an internal AI tool that the whole company’s obsessed with (and how you can too)

howiaipodcast 9Q9Yrj2RTkg Watch on YouTube Published August 10, 2025
Scored
Duration
40:27
Views
14,308
Likes
208

Scores

Composite
0.54
Freshness
0.00
Quality
0.82
Relevance
1.00
7,632 words Language: en Auto-generated

I started showing a couple of people internally like, "Oh, this is really cool. You got to look at this thing." And then a week later, it seemed like the entire company was using it. Moda is that internal tool that we have that unlocks all of the data that we have internally and then allows us to answer questions to build artifacts like PRDs. >> What I love about these and other PRD generators is you can go from that little snippet of an idea to something much more robust. >> I got to see it and I'm all excited about it. I'm like, when is this going to be pushed so that I can use it? Monday, he added push live. I started showing a couple of people internally. He's like, "Oh, this is really cool." Okay, so this is my challenge to everybody listening. Mark the date. A month from now, I want you all to have your own internal tools just like this or at least a prototype. Welcome to How I AI. I'm Clarvo, product leader and AI obsessive here on a mission to help you build better with these new tools. We've seen a lot of workflows using a lot of tools on this show, but today we have WDE Chambers, chief engineering officer at Amplitude, who's going to show us the tool they built themselves to do all their enterprise search, answer all their business questions, and I think build all their products. Let's get to it. To celebrate 25,000 YouTube followers on How I AI, we're doing a giveaway. You can win a free year to my favorite AI products, including VZero, Replet, Lovable, Bolt, Cursor, and of course, Chatp by leaving a rating and review on your favorite podcast app and subscribing to YouTube. To enter, simply go to how ai pod.com/giveaway, read the rules, and leave us a review, and subscribe. Enter by the end of August and we will announce our winners in September. Thanks for listening. This episode is brought to you by Code Rabbit, the AI code review platform, transforming how engineering teams ship faster with AI without sacrificing code quality. Quality code reviews are critical but timeconuming. Code Rabbit acts as your AI co-pilot, providing instant code review comments and potential impacts of every pull request beyond just flagging issues. Code Rabbit provides one-click fix suggestions and lets you define custom code quality rules using a GRUP patterns, catching subtle issues that traditional static analysis tools might miss. Code Rabbit brings AI powered code reviews directly into VS Code, Cursor, and Windsor. Code Rabbit has so far reviewed more than 10 million PRs, been installed on 1 million repositories, and has been used by 70,000 open-source projects. Get Code Rabbit free for an entire year at codabrabbit.ai and use the code how i. Wade, thanks for being here. >> I am so looking forward to this. Thanks for having me on. >> One of the things that I think is so interesting about how you are approaching AI at Amplitude is you all have decided to build some tools yourself instead of plucking, you know, a bunch of various things off the shelf. And I'm curious what was the internal thought process around this sort of build versus buy decision or why did you go down this path of writing a bunch of code? >> Well, let me start with first um it didn't take us this long to do it. So, um and it's in spare time, people's spare time. They actually put uh what we're going to talk about today. And so, it's probably like 3 to four weeks um spare time of some pretty talented engineers. one that's a little bit uh in the rearview mirror. Two, in talking to a lot of my counterparts and other companies and asking them how they were approaching this and what they were doing, I had it kind of split. About half of them were saying, "Hey, I'm I'm pulling things off of the shelf and using it." And the other half were kind of like, no, the way that you're going to want to use this and how you're going to get more leverage, the more that you can do it internally, as long as you don't invest a lot in, you know, overbuilding it and overengineering it, uh, you'd probably be better off doing it yourself. And so once we got into it, I found that we were able to pull a lot of things off the shelf like glean APIs and things along those lines, which just allowed us to move really quick. And there's not so much of an investment in it that I I worry about if I need to, I will revisit it. I'll throw everything away, do it again. It's really unlocking people and the data that sits in the enterprise that I wanted to do the most. >> That tends to be my whole um theme when building things with AI. It's so fast and it's almost so cheap. I think, you know what, if in 3 months I throw the whole thing away, it will have been worth it anyway. So I can definitely understand that mindset. Okay. So we're going to see this internal tool you built and I'm excited to show it off apparently in the in the free time of engineers over three three to four weeks or at least a little a little sprint. So tell us what MOA is. >> Like a lot of different companies. I think that right now um Amplitude is going through that change of being AI native and wanting to to move really fast. And so, um, I think that in all of those, uh, companies, you need to get access to the data that you have internally. You want as many people as possible to see it. You want to see others being successful with it and say, "Oh, that looks really easy. How could I do that?" Um and so MODA is that to that internal tool that we have that unlocks all of the data um that we have um internally and then allows us to to um answer questions to build artifacts like PRDS things along those lines internally but with the full scope of information that we have access to. >> Great. So you took all of your business data across I'm sure like BI sources and documentation sources and you exposed it in the tool and one of the things you were telling me before we started the show is one of the approaches you took was this social engineering approach which is you went into the decision of what platform Moto would be built on. So can you tell me a little bit about how you incepted the organization with the design of this internal product? the the problem is is everybody's starting in a different place, right? And and so uh you use Chad GPT at home or you use Claude or you use something else. And some people are really advanced and and others are are not. And so how do you create this common language or or this common fluidity, if you will, um around AI? It felt like if we could do something and that made it really straightforward and we took a lot of the complexity and trying to push it down, it would allow a lot of people to be able to engage with it. And so step one, and by the way, um, great minds before me, well, I wouldn't say I have great mind, but like great minds that I can leverage, uh, the folks over at Abnormal Security had built a little agent in Slack that I got a chance to see. And it allowed all their employees to ask really, uh, good questions. And I'm like, oh, that's that's genius. Because if I can see what other people are doing and it's adjacent to the work that I'm doing, I'll b I'll borrow the prompt. I'll borrow the the question or if they've already done something that I can leverage, I'll just use the result on the other side. And I'm like, and that is the right way of doing this. The more that I can make this publicly visible and do real solid work on the other side of it, provide great answers on the other side of it, then it should catch like fire. Well, that's the thesis. Uh the truth is is that one of our engineers had this working on a Friday afternoon. Uh I got to see it and I'm all excited about it. I'm like when when is this going to be pushed so that I can use it? Monday we he had it pushed live. I started showing a couple of people um internally he's like oh this is really cool. You got to look at this thing. Uh and then a week later it seemed like the entire company was using it. Um, it it's it's been pretty incredible. >> I don't know. You might be wasting your talent in B2B. It sounds like you got some consumer thinkers there with how viral this product went. >> It it it's it's helpful. And anything that accelerates your thinking or allows you to get to a deeper truth, all of those things are are are just awesome. And so, if this can help you with that and you can see other people doing it. Uh, true story. Right before I I came on this, I I was talking to one of our sales execs and uh she hadn't heard of Moda yet. And so I was like, "Ah, well, that'll help you answer that question." And her first thing was is she opened up the Slack channel, went in there and she saw a colleague um that's using it repeatedly as as she just scanned down. It's like, "Well, if it's good enough for him, I'm all in." And so I'm like, "Okay, that that's the the social engineering aspect of it. If you can see people more credible or equally credible as yourself having great effect with this, it's it's an obvious thing that I want to use. >> Great. So, let's let's take a look at it. >> Well, as an example, here's today's um thing. And you can already see just how many people inside of the company have already been using it today. So, let me go through and ask Moda to introduce itself. So if I go through and just hey moto what are you doing? Well he's >> chomping on data nom nom. Uh but it'll come back here qu pretty quickly and give an answer and say well I'm modem internal agent. I search internal knowledge sources. I can also search the public. I always site my sources so you can verify the information. You can access me by Slack. There's also a proprietary interface which we'll get into. uh you can even learn more about the implementation and and things along those lines. And so if I wanted to know a little bit more about Moto, let's just ask it to tell us a little bit more about itself. And again, it's just going to go through, parse it, send it out, gather information, and put it back and just say that it was built. We have our own uh little stack that we've built uh to be able to process um AI request um called the Langley framework, but on top of that, you can see that it leverages a lot of the things like Glean uh to be able to to access um certain parts of this, but it can do external search and we we already kind of covered them. Well, what about the data sets that it has access to um internally because lots of people don't have the exact same things that we have, but let's go there. What data sets do you have access to? Well, wait. I'm glad you asked. So, we can get into Confluence, Jira, Salesforce, Zindesk, Slack, Google Drive, Product Board, Zoom, Outreach for um transcribed uh meetings, those sorts of things, even some Gmail, Asauna, Dropbox, GitHub, HubSpot. So, it does not have access to private, personal or restricted uh data sets. It's generally the public ones uh well, enterprise public ones um that we have internally. And so if I just was to go through and say, "All right, well, who is using you?" Completely different way u of looking at it just how widespread is it inside of the company and and how many different groups are using this. >> And so you're product managing your own AI product using your AI product here. >> Well, exactly. because if I can understand where we have any friction inside of the the company um and what types of questions are being asked and and where are people not having success on the other side it's just a simple um process of like okay where did we get the rules wrong where did we how can we helped out with prompting what data uh sets do we need access to do we need to do any grooming of that on on the output side of it but you can see product management engineering sales customer support marketing our CEO um our our head of sales um I've seen our chief product officer in here there's well and you can see it just keeps going even as we're sitting here talking um about it so these are all well I'm even a reference inside of here but you can see that uh lots of different people are using it for lots of different things um internally >> so could you show us one of the common flows that you might somebody might use with with Moto. So, it's pretty good at explaining itself, which is great. And it seems like it has access to a lot of data, but Oh, here we go. And then you can customize it. >> Well, you know, it it's I I want to make sure that I understand everything that's going on with MOA. So, I'm going to actually give it a little bit of attitude. Uh, and let let's go through there. So, I want to go through and actually start. I mean, almost everything that our customers do, they need to understand what's going on. and then they want to make a decision, then they want to act on it. So, we need to do the same thing here. Uh why don't we actually go use all of these data sets that we've got access to to find out um what's going on. I don't know that we actually need to see every the top themes and queries, but maybe it's a good place uh to start. I'm just looking for an insight that we can kind of chase down. >> I think this is great. So I think that thematic analysis and sort of trying to quantify more qualitative or yeah more qualitative feedback is a very common kind of product manager use case. And so anything that can have access to a broad set of business data and do that analysis for you. Oh my gosh, these these descriptions are ridiculous though. >> Isn't this great? really gave you Gen Z slang. >> Bet. >> Bat. It bet. No cap. All right. So, so this is doing something that I think uh would be very popular for a product manager. And so you're saying let's take all this context I have, analyze it, quantify it, and then it actually gives you the scope of it of its research data. So it says it takes the 50 most recent Slack messages. So that's a good resource. But then you're looking for another one with more external resources. So that last query was really about the Moabot itself. But this query looks like it's about your actual product and you're looking for real customer feedback. And this is a very common workflow that a lot of product managers do quite manually. >> Absolutely right. and and so you know go into product board go into Zenesk where things are going to be logged actually go into the transcriptions of conversations that we've had with various um customers and let's get to a point where we believe we know where there's some energy um where people want extensions to the product or want um to improve the functionality of the product like connecting session replay to funnel analysis. That seems like a a pretty good place to dig in. So, why don't we just jump in and see what MOD's got to tell us about that. >> Got it. So, you're taking this wide funnel of data analysis trying to figure out what are the sub themes and then you can use Moda and say, "Okay, I've picked plucked a sub theme. Give me even more more data around it." And do you think that's a a useful flow for folks? Basically like start at a pretty wide data top of the funnel and narrow narrow in. Is that how you approach things? >> Uh I I I think it's useful when you're going through and saying like, okay, what what could I learn from this? What's something that that's new? And so this was me trying to start at the very top and say, okay, let's go in and dig into well, let's start say what are people asking for? And then if people are asking for for this, let me make sure that I uh believe that you know what what they're actually asking for. there's actual quotes, there's details behind it that I can look at. And we could even ask the opposite um of this. And so there's plenty of conversations that come through in this of where you can see um specifically, you know, from Zenesk and um from Zenesk, from an outreach call. And so you can see the details of specifically what somebody is asking for and what they're trying to do inside of that, which gives me a a sense of like there's some heat here. >> As an AI founder, you're used to sprinting towards product market fit, your next round, or that first enterprise contract. But speed isn't enough for AI startups. Buyers expect security, compliance, and transparency from day one. That's why serious AI startups use Vanta. With deep integrations and automated workflows built for fastmoving AI teams, Vanta gets you audit ready fast and keeps you secure with continuous monitoring as your models, infra, and customers evolve. AI innovators like Langchain, Writer, and Cursor scaled faster and closed bigger deals by getting security right early. with Vanta. Listeners can claim a special offer of $1,000 off Vanta at vanta.com/howi. For somebody who is building a products for product managers, I know there's a whole cottage industry that is trying to build SAS products for what you just what you just showed on this in internal tool. And I'm curious if your product managers have by and large been quite happy with Moda of their as their source of insights or if you feel like there are pieces that this kind of general purpose internal tool is missing maybe to serve this specific use case better. >> I think that um a a lot of product managers that are here take this as a way of getting access to 100% of the data and seeing what AI would generate for it. And if it comes back and it doesn't match their instincts, they'll dig in. Um, and if it does match their instincts, then they'll look for more more detail inside of it. And so I think that for the most part, we have a lot of product managers using it to great effect. And I'll go into to more detail on how it actually um does this. Um, we have a proprietary interface. Actually, let's jump over there. Yeah, I would I I would love to see that because I think my next question is like how does it work behind behind the scenes for folks that say, "Well, I got I got a smart engineer in 3 weeks. How can I have this too?" I'm curious how you've approached building this a little bit more detail. >> Yeah. Then and then the the nice part is you can even ask Moda um on how it works. We we have a framework that we've used internally and we have both a little bot that sits in Slack that can call out to that framework. But you can see that I can go into a web UI and basically be able to access the the same thing. In this um flow, we've actually got a lot more capabilities that are associated with it. And so we can go in and create uh PRDs as an example. You can ask anything you do do deep research on it, but you can create a PRD that then allows us to take some piece of this and uh go in even deeper. And if I was to go in, you can kind of look at just jumping into GitHub. Uh, right here's the YAML that kind of defines the the highle how we would do a glean search on ask anything. Uh, we could go back up and even look at the PRD orchestrator on this side. And you can see, you know, how it starts with a prompt and is able to sort of dig in a little bit more based on what you're trying to do. If it needs more details, it's going to ask you for that. It's then going to take all of this and break it down of where it will break things into let's make sure that we do proper problem exploration, solution exploration, detailed requirements that come out the other side. We like to move as quickly as possible to a prototype. And so if it can do prototype generation or at least the prompts that then we can plug in uh we can copy and paste into Bolt or you pick your lovable uh v0ero uh pick your your favorite and be able to move it around. Then we can get through that uh fairly quickly and then it will just go through using the glean API will get access to a lot of the content and be able to do a query. And so it we use that as um part of our rag to make sure that we go get the right content and then pass it off and it's able to evaluate all of that and come back with a much better answer. >> Yeah. I have a couple technical questions because as a builder I'm just so curious here. So it sounds like you're using the Glean API for a bunch of your enterprise search. So that simplifies a little bit the data access and controls and all that piece the rag piece of it. Then you've built these two kind of alternate interfaces which is the Slackbot or or the web UI which is nice. And then it seems like you've built also some kind of specialized tools in terms of kind of the general chat deep research chat or this PRD flow. And then just looking at that GitHub if you don't mind pulling it up again. I'm so curious who got this good at writing prompts because this is a this is a well ststructured prompt. And I think one of the things that is very mysterious to people right now trying to build something like this is they vaguely know the s like a sense of like tool calls. They vaguely know about instructions but no less about like these sequential instructions or multi-tool or parallel tool calls. And I'm just curious how your team upleveled or upskilled on how to build great prompts, how to build great agents. Was that just learn as you go? >> There was part of it that was learn as you go. I mean, we we've got a couple of talented folks that have a lot of experience with AI, and so I think we were able to use those, but also AI is a good tool to use for building prompts. And so, you can just recursively ask AI to give you better prompts or things that would allow you to focus on very specific things that you want in the results set. And AI will actually generate the prompt for you that you can use. You'll probably have to edit it a little bit, but it does pretty good job on its own. >> And then how does your team improve improve this over time? Is it open to anybody to do a pull request on it? Is there a team that owns it? How have you set it up operationally? >> Yeah, we've we've set it I mean it's all checked in to GitHub. Um most of our engineers can can check it out. Even um product managers and designers can probably do the same uh to it. Uh we've had designers that are contributing to this and product managers who are contributing to this. We're currently going through an AI week uh this week of where there's a lot of things that are going on. One of my vibe coding ideas is I want to be able to add NCTs in addition to PRDS uh to all of this and see if I can do it totally on my own. >> Okay. Well, speaking of PRDs, is there any way I could get you to create a PRD with this flow? I'd love to see that. >> Let's let let's do it. I was going to go through here and say, uh let's go through I'm going to see if it will take it as is. Uh let's actually go through and create a PRD. >> So for people listening in our Slack flow, we we got this insight that people wanted session replay attached to funnel steps, which makes total sense. And so now we're taking that idea and that context and going into the create PRD prototype flow in Moda um which is asking us what we want to build. >> So let's just give it the the prompt that we had as um an answer to a previous question and see if it's able to expand on that. >> Yeah. And again, for folks listening, this is one sentence. The customers want to see session replays directly linked to funnel steps so they can watch where users drop off or convert. And what I think is so powerful for product managers is they're really uh convinced themselves for for many years that you needed many more sentences than that to convey what kind of product you need. But what I love about these and other PRD generators is you can go from that little snippet of an idea to something much more much more robust. Yeah. And it's going to go through its stages and it's going to think a little bit and it's going to generate things. So I'm just going to very quickly jump over and say this is kind of what it will produce and it also produces all of the PRDs in a place that where anybody can go look at them and see the output of it. But it will talk about the problem exploration. It will talk about the actual uh solution exploration. and it will talk about the detailed requirements that come through on top of it and then it will go through and it will generate um things that you need to do to generate a prototype on it. So you it'll give you all of the prompting that you need to do it. In this specific one, they took those prompts and actually fed it fed it to Bolt, to Figma, make to Vz0ero just to with the same exact uh prompt, see what different systems would actually suggest as a a great prototype that that you could interact with. And is this the product manager that's taking the output of this automatic PRD generator which includes prototype instructions and then they're just copying and pasting that into the prototype tool of their choice and then comparing the outputs and putting them in a confluence dock for people to look at and >> they don't even have to put it in a confluence. Yes, that's exactly what they're doing. Um on on the other side of that for everything else it will generate and put it into the confluence document. It still looks like it's still thinking about it here, but that's exactly what happens here. And as soon as this comes back, we'll look at some of the results that are associated with it and go create our own prototype uh from it. >> What I like about the design of this internal flow is it's clearly multi-step without user interaction, which is quite quite interesting. And so instead of this sort of iterative, do you like this? Do you like this? Do you like this? Do you like this? Seems like you've built something that you're pretty confident is going to get you close to what you want with very little human intervention. Of course, you can come and edit it in here, but I'm curious if that was an intentional choice or what drove that sort of kind of decision to say just get it all done at once. We we decided I mean it is a multi-step process but one of the things that you can do is you can go in here and actually say oh I don't agree with something in here you can create a comment um associated with it and then you can tell it to go re-evaluate things and so you're not stuck with the answer that you got u based on your ability to comment you can actually go and change things pretty rapidly. So if you don't think it got it right, like the downstream consequences are are fairly minimal because you can just go to as high up in the stack as possible and say, "Well, the problem isn't right. Let me actually change some things along this. Just regenerate everything that's beneath it and you can just keep going down the stack as you need to." >> So I have to ask you about the um AI generated product document elephant in the room. As somebody who's thought about this for a long time, >> you've thought about it a long time. >> I've thought about it a lot. You have created five beautiful detailed assets in I don't know three minutes. Does anybody actually read them or do they just click right to that prototype and say yes this is what we want? We we do review them and matter of fact if you go through and you look at like the detailed um requirements almost every document that we produce on um this side will have a review segment that we go through and so we'll have people go through actually look at the problem statement look at the um solution statement and we actually go through a review process to make sure that we agree and honestly if if the person who is doing the generating hasn't also done some follow-up queries to say, you know, what are the cons on this? And is there evidence that suggests other answers would be better? And even when you get to the prototyping uh phase, what are the multiple solutions that you looked at? What did you generate from a prototype perspective so that we can see three different variations, maybe four different variations on the other side? And that will and that will force you to change your prompt as well. And so all of this you you or at least I don't feel like we've gotten to that place where you can just go yellow. You're going to have to it it's going to be an assist. It's actually going to speed up things and in many cases it gets it perfect, but you can't assume it's going to. You actually have to apply critical reasoning to see where it may have failed you. >> I'm so curious because again, you've compressed a lot of work. You've compressed user research, quantitative, qualitative research, idea generation, PRD generation, prototype generation into a very small compressed timeline using all the business data that you have built by an internal tool. I'm curious what the downstream effects you're seeing in the product and engineering and design organizations when something like this can get done so quickly. Are you are you building more things? Are you getting more ideas? Are you getting better ideas, worse ideas? I'm curious your point of view of what this is changing. >> It's definitely changing the velocity number one. Um and and so we see that in you know 6 months ago, 8 months ago um you know we're an agile shop. We move pretty quickly. Um you know we we employ a lot of scrum and and able to sort of iterate through uh things pretty quickly. But even then you you would say that there was somebody who was out there doing the research and needed to try and put it into a document so that other people could review it. And then when other people would review it, you would uh actually then move it into design and somebody on the design side of things would uh use Figma to actually build some mockups and things along those lines, which then would get handed over to engineering for inspection and trying to figure out like, okay, how do I turn this design into something that's working code on the other side? That could take weeks. And and I I think the best case is that it took a couple of weeks. Well, maybe maybe you could get it done in a week. And now we can actually put those three different roles together and actually produce that in a single meeting where we're going through and using MODA or um other tools along those lines to actually say let's go find evidence. Do we find customers are actually asking for this? Okay. um you know like what's the right context to provide to Moda to make sure that that we got it right or can it provide us that context by searching through all of the enterprise data that we've got and we'll get to a prototype in a very short period of time. So now when we do product review sessions the PRD is a part of that but oftent times we're looking um to get to the prototype as quickly as possible and work backwards from that. Do you feel like you have more ideas than capacity to execute or are you keeping up speed on the engineering side because you're using all these AI engineering tools? I'm always wondering, you know, where there's a misbalance in the force where it comes from um because you sit on a lot of prototypes and then I know you have a complex product. I'm just curious how you approach building those. it does move around a little bit and that we'll find that um if we're really trying to figure out a concept, you know, maybe Moda plus some uh prototyping tools can actually get you most of the way there. If it's something that is a product direction or a entirely new product, um you're probably going to need to go do some market research. Um, if it's something that is UI heavy or, you know, deeply integrated with a part of our product, uh, we'll probably need to slow down a little bit and and give design the time to actually go through and make sure that they've they've like stitched it all together and you can make sure that it's complete coherent thought. So, it's a little all over the place uh, depending on the type of project and the work that we're looking at. And then I can see how because I I love this idea and I've I've spoken about it before that product design and engineering can all be done in a single meeting and this you know single flow. I'm curious, do you see your team swapping roles? Like, do you see engineers going, "I'll write the PRD." Or PMs being like, >> "Absolutely, >> let me let me put up a PR." >> Absolutely. And uh we've actually intentionally done that at times of where we've said, "Okay, you're going to take on a different role." And so once um we even had a demo where we had uh like the designer being the engineer, the engineer being the product manager, the product manager being the designer kind of in the role to just show like how you could work through it. It was hilarious. It it was fun, but it was actually very functional. Um the designer actually got into cursor and was able to to extend some things in cursor. uh the engineer was able to come I mean very very good product thinker any anyhow uh but they were able to come up with like the right PRD and the right requirements uh even the product manager that that was there was able to um get in and do a better multiple iterations on a design until they actually found something that that hit the sweet spot. >> This is a workflow I have not heard before. So for people listening, I want you to do it. I want you to take a Friday morning, bring your team together, screen share, and do a little roll swap because that's it's genius just to show it's possible or see where there are struggles. Um, see where there's opportunity. I'm also sure it gives empathy between the teammates saying, you know what, what you do when I say just vibe code it, maybe I'm being a little silly or when I say we can just make the prototype, I understand now why why we have UX designers. So, it's a nice it's a nice skill development workflow, but I bet it also brings the team kind of closer together in terms of empathy and respect for each other's craft. >> Empathy, respect, and uh just like fluency in each other's craft and how AI can help with that. >> Okay. So, you're setting the you're very calm, but you've set the bar very high. So, just to recap, um, you've told us that you don't have to buy it off the shelf. Just pluck a couple engineers in a couple weeks and build build this thing by yourself. No big deal. It'll just have all your enterprise data in it that you can query on demand anytime you want. Uh, you built it in Slack and a UI so that your whole team can both access it as well as see each other's use of it and kind of learn from that. And then you've built these specialized tools. And of course, you know, our audience's favorite is going to be this PR data prototyping tool that kind of takes the best of all those workflows and puts them together for a purpose-built reusable flow that can get your business something that you really need faster. No big deal. All while running an amazing company that tons of product people just just love. Right. There there's a fair amount of truth. I mean uh I I I may have minimized uh like how much work it was, but like honestly it was not a bunch of engineers fulltime working on this for quarters or anything along those lines. It literally was um four weeks and part-time with a few engineers. >> Okay, so this is my challenge to everybody listening. Mark the date, put a month ahead and from a month from now, I want you all to have your own internal tools just like this or at least a prototype. Okay, wait. I am going to send you on your way in just a few minutes. But let's wrap with a couple lightning round questions. My first is we've talked a lot about product and business data, but you're a builder running engineering organizations. What are you excited about on the engineering side? What are you nervous about? Kind of what are your thoughts on all this AI powered coding? Honestly, I I've never worked at a place where uh it felt like we had tech debt under control and everything was fine and we didn't have too much surface space. Every company has those challenges. This just gives us a way of being able to deal with those things much more effectively moving forward. There's work that we have to do on our side to make it uh more AI friendly so that AI can do more work on our side. But this is going to give us the ability to do so much more for our customers. I'm truly excited. Take the same engineers and multiply their value uh based on these tools and and just think about what we're going to be capable of doing. I'm genuinely excited by what this means for us. >> Yeah. And I'm glad you called out tech debt and all those challenges that engineering orgs have because one of my pitches to software engineers is like reduce toil, get rid of misery. You know those corners of the app that you hate but you tolerate because you do not have time. Exactly. >> Now you have a tool that you didn't have that you didn't have before on those. So I think that's a great call out. And then you have built and your team has built such a structured full of personality internal assistant. But I'm curious what is your strategy when you have asked Moda to generate a PRD you know five times it's not doing the right thing. It's not listening or Chad GBT or whatever your frustrating AI tool of choice is. How you know what's your prompting strategy? How do you get it to listen? I have a few different strategies. One is I swim upstream. It's like where did it start to go wrong and like let me edit that and actually go through and and and see if I can generate a different result on the other side. I always feel like it's it was an input problem on my side. So if I can figure out where it started to go wrong, let me change that and put it on a better path. Uh, number two is I'll just give it feedback as we're going through it in a nice way because uh, you need to be nice to your AI. U, but I will go through and and say, "Hey, I this didn't quite hit the mark. Um, I was looking for something that felt a little bit more X or Y. I needed more detail here. I want to be able to use this to describe it to my grandmother. I want to um have multiple use cases or I want to hear the customer's voice come through in this a little bit more concretely. Um I feel like the more that I can give it context but also tell it what I needed out of it um after multiple rounds you'll either figure out what it needed um or it'll figure it out on its own and help you get there. Well, I'm going to give you a compliment because both of those strategies speak to a very good engineering leader. One, I was like, "Oh, you just go back to the last good commit and you start over again." And two, how you described giving feedback to an LLM is exactly how people want feedback from their manager. So, that came came through loud and clear. All right, Wayade, this has been so fun. It's really interesting to see this um behind the curtain, see how a company like Amplitude has built this themselves. some tools that can be really practical for their their team. How can we find you and how can it be helpful? >> Uh LinkedIn is probably the best way to find me personally. Um and I will say, you know, there's going to be some news coming from Amplitude on uh um some Aentic Solutions. Stay tuned. Um it's going to be a lot of fun. >> Amazing. Well, thank you for being here. I appreciate it. >> Awesome. Thank you. >> Thanks so much for watching. If you enjoyed this show, please like and subscribe here on YouTube, or even better, leave us a comment with your thoughts. You can also find this podcast on Apple Podcasts, Spotify, or your favorite podcast app. Please consider leaving us a rating and review, which will help others find the show. You can see all our episodes and learn more about the show at howiaipod.com. See you next time.

Summary

Amplitude built an internal AI tool called Moda in just a few weeks of spare time, enabling employees to access enterprise data, generate PRDs, and prototype products quickly. The tool uses a Slack interface and web UI, leverages Glean for enterprise search, and allows for multi-step AI workflows that reduce engineering time and improve team collaboration.

Key Points

  • Amplitude built Moda, an internal AI tool, in 3-4 weeks of part-time work by a few engineers.
  • Moda unlocks access to all internal data sources (Confluence, Jira, Slack, etc.) and allows employees to ask questions and generate artifacts like PRDs.
  • The tool uses a Slack bot and web UI, making it visible and social, which drives adoption through peer usage.
  • Moda leverages Glean API for enterprise search and uses a proprietary Langley framework to process AI requests.
  • It enables multi-step workflows including deep research, problem/solution exploration, and prototype generation.
  • Users can generate PRDs from a simple idea, which then auto-generates prototype instructions for tools like Figma, Bolt, or V0.
  • The tool includes a review process where teams evaluate AI-generated outputs for accuracy and completeness.
  • Engineers can contribute to the tool's development via GitHub, enabling continuous improvement.
  • AI-generated content is reviewed by humans; it's a powerful assistant but not a replacement for critical thinking.
  • The tool has increased product development velocity and enabled role-swapping exercises to build empathy across teams.

Key Takeaways

  • You can build powerful internal AI tools quickly using existing APIs and frameworks, even with limited time and resources.
  • Make AI tools visible and social by using public interfaces like Slack to drive adoption through peer usage.
  • Use AI to automate multi-step workflows like research, PRD generation, and prototyping to dramatically increase team velocity.
  • Always review AI outputs critically and use feedback loops to improve prompts and results.
  • Empower your team to contribute to AI tools by making them open-source and accessible.

Primary Category

AI Engineering

Secondary Categories

AI Tools & Frameworks AI Business & Strategy Programming & Development

Topics

internal AI tool Moda enterprise data access AI for product development PRD generation prototype generation AI agent social engineering role-swapping tech debt engineering productivity AI in enterprise AI workflow automation

Entities

people
Wade Chambers Claire Vo
organizations
Amplitude CodeRabbit Vanta Abnormal Security
products
technologies
domain_specific
products technologies frameworks

Sentiment

0.85 (Positive)

Content Type

interview

Difficulty

intermediate

Tone

educational entertaining inspirational technical business-focused