The Changelog: Software Development, Open Source - Pivoting to Retool (Interview)

Episode Date: July 17, 2025

David Hsu from Retool joins Adam to discuss how he built Retool. From the pivot in YC, to building the most widely used internal tools platform, to now being the platform for AI agents in the enterprise—on this episode we cover David journey from YC to building agents for the enterprise.

What's up nerds welcome back. This is your favorite podcast. Yes, the changelog. We feature the hackers, the leaders and those building up the platform for agentic internal tooling. Yesterday we're joined by David Shu co-founder and CEO of Retool. Big fan of Retool as you know, big sponsor of our podcast, and finally, on the podcast at full length, David Shue. We cover the humble beginnings of Retool,

how they've iterated to become the platform for internal tools for enterprises everywhere, this new shift of AI and how they've leveraged agentic tooling to make Retool an agentic internal tools platform so cool. A massive thank you to our friends and our partners over at fly.io. Yes, that's the home of changelaw.com and it can be your home too. Learn more at fly.io. Okay, let's do this.

Let's do this. Well, friends, I'm here with Damian Schengelman, VP of R&D at Auth0, where he leads the team exploring the future of AI and identity. So cool. So Damian, everyone is building for the direction of Gen.AI, artificial intelligence, agents, agentic. What is Auth0 doing to make that feature possible? So everyone's building Gen.ai apps, Gen.ai agents. That's a fact.

It's not something that might happen. It's going to happen. And when it does happen, when you are building these things and you need to get them into production, you need security. You need the right card trails. And identity, essentially authentication, authorization, is a big part of those card trails. What we're doing at OZero is using our 10 plus years of identity developer tooling

to make it simple for developers, whether they're working at a Fortune 500 company or they're working just at a startup that right now came out of Y Combinator, to build these things with SDKs, great documentation, API first types of products, and our typical Auth0DNA. Friends, it's not if, it's when, it's coming soon. If you're already building for this stuff, then you know. Go to Auth0.com slash AI, get started and learn more about Auth for Gen. AI at Auth0.com slash AI. Again, that's Auth0.com slash AI. We're here with David Shu, founder of Retool, big fan.

David, as you know, I know a lot of our audience is, founder of Retool, big fan. David, as you know, I know a lot of our audience is probably users of Retool. They are aware of Retool because you've been a sponsor for many years, but we haven't had you on the podcast officially yet, so come on, let's get you on here, right? Let's talk about your past, your present, and your future. What do you think?

Yeah, excited to be here. We've been a big fan of the changelog. So big fan of y'all as well. Obviously, I think I think we may have been like the earliest of days with Retool. I think you're around seven years old, roughly. I was in preparation for this conversation. I kind of wanted to go back in time a little bit, not so much to bring up like the old ways of things, but I kinda wanna revisit that initial video that I found on your website. I think it's on your about page, if I recall correctly. It's somewhere, I don't know,

it's somewhere on the Retool website, but I found the initial, no, actually it's on your Y Combinator profile page, that's where I found it. And I'll link it up in the show notes, but it's the initial pitch that you gave, I think is the initial pitch. So take us back there. We know what Retool is for the most part today, but

tell us about those humble beginnings in that video. Yeah. Wow. That was a while ago. I think that was around probably 2017 or so we first got started. So we first started Retool, So we first started Retool, my co founder and I, we were both pretty lazy engineers, you could say, and we were tired of rebuilding internal tools all the time. Both of us had started a previous company before this, that didn't really go very far. We spent so much time building internal tools at that company. We thought there's got to be a better way. Why are we sort of reinventing the wheel every single time? Why are we populating tables, getting data from our database,

figuring how to build crud forms on top of that table? It was just so much work to do something really pretty simple, just crud on top of our database. And so that's where the initial idea of a Retool came from, is could we, as lazy engineers, build a better way a faster way for engineers to build internal tools. So that's where the idea first came from. So we went through YC and around 2017. And initially, it was pretty slow. When we try to explain Retool to people, people

want to understand what Retool was. Why would I use something like this? I'm pretty happy writing code from scratch. Why would I use a product like Retool? So it was pretty uphill for a long time. And I remember pitching VCs was very difficult because we tell them we're really focused on engineers. And they would say, why are you focused on engineers?

Why don't you focus on democratizing programming? That feels way sexier. So it was really a happy to go more into detail than any one of those. But it was uphill for a long time. I think what's wild about hearing that is that is the narrative roughly for this podcast, hopefully is where you began and that story arc of what got you here. And today the here is a lot of agentic stuff. is where you began and that story arc of what got you here. And today the here is a lot of agentic stuff. We'll obviously talk about the new AI platforming

that you're doing nowadays, but it's kind of interesting here in that initial sentiment to build for engineers given, and democratizing programming basically, given where we're at today. Just wanna throw that in there, but let's go back there. So it did seem like even initially, if I'm being honest, it did seem like even when we were first part

of that sponsor poll, I don't even know when it was. It certainly wasn't 2017. I wanna say it was like 2018, maybe 2019, if I can recall correctly, that we began to work together. And I thought, okay, internal holes make sense. It seemed like it, but I recall also that you mentioned back in the YSC day that you had another batch, they call them batches for everybody listening. So when you go through YSC, they're called batches.

You got, I think summer and winter batches. And you go through this Y Combinator incubation process as a two person, three person, whatever number person team. And at the other end, you hopefully come out with, you know, funding or opportunity and things like that. And so they call those batches. And so when you were in that first batch, I recall you saying that Brex was also a part of that same batch, which is kind of funny

because you guys are both in this moment unicorns, right? But in those moments, you are just simply, you know, a hair on the potential of a unicorn. You know what I mean? Like you are not the futuristic thing that you are today. Go back to that moment where you were bringing on larger talent like that even like larger opportunity like Brex. How did you go from building and solving these problems like that to solving their problems? And why was it uphill?

It was really cool actually. I think the so we were part of the winter 2017 batch and I think it's been one of the best batches for I think YC over the past few years. So actually, Brex is a part of that. Rippling was also a part of that batch. We were part of that batch and a few others too. So it was really awesome seeing a lot of these companies that today are so successful so early. I remember when we first talked to Henrique and Pedro from Brex, they were just two guys starting a company.

I think actually in the moment, in the batch, I think they were actually building, I think VR software, if I recall. And at the end of the back, they're like, oh, actually we pivoted into working on corporate cards for startups. And I remember thinking, well, good luck with that. It doesn't seem like a market to me. But they've obviously done incredibly well and say, well, so it's really cool to see batch.

We succeed in that way. But yeah, they're so talented as founders. Was it part of that batch process? They began like you'd mentioned they pivoted during the batch process, which is really, maybe you can speak to the details here, but it seems like some folks may go into Y Combinator with a pretty clear idea. And then that incubation process simply hyper focuses them on that product development, the user research, you know, the networking, whatever it might be happening in there. And then some folks come in there with an idea that morphs dramatically.

Can you speak to that? Was that at all retools scenario where you pretty laser focused on your first one and you just iterated that incubation process was really a baking process of the real product. Yeah, so actually my co-founder and I actually were working on a different idea at the very start of YC actually.

It was a P2P payments company based in the UK. And it turned out that a P2P payments company is not a particularly good business, especially when you are losing money every time someone sends money. And so it was a negative argument business. We were losing money pretty fast. But the lucky thing was, as part of building that product, we built a lot of internal tools. And you can imagine the kind of internal tools a P2P payment company would build. It's tools to go manage fraud, tools to go approve signups, tools to manage underwriting. And so we built a lot of internal tools.

And so we were actually quite lucky that through that process, we learned that, as lazy engineers, building internal tools was really pretty challenging. And it's an incredible amount of work required. And so that's actually where the idea for Riquel came from was entirely based on the fact that we had worked with a different startup prior to that, actually. And so through YC, we really refined that idea. And we were lucky that as part of YC, there were many other companies part of the batch, such as Brex, such as Replace, just many other companies too. And I think Brex was probably our first, maybe second, something like that, maybe a first top or first five customer for us.

And I remember talking to Pedro Henrique about it, at the founders of Brex. And as they were working on their credit card company, they had a very similar challenge to us with our PDP payments company, which is building a credit card company is very operationally complex. And so we told them about our story and they were very interested in a product like Retool because it could save them

and allow save them a lot of time but more importantly allow them to scale a lot faster. Today it's hard to say what percent of time Brex spends on building internal software but it's probably half of the surface area of Brex is internal facing and so having a product like Retul that allows them to move a lot faster, adapt quickly to changes, launch new product lines a lot faster. I like to think that we played a small role in Brexit success, which is really exciting to all of us here. Yeah. So that gives folks a context. I think most folks get this, but just to be super clear, what would you consider an internal tool? What exactly is internal tooling?

Yeah, so a really surprising fact about internal tools is that more than half of the software in the world is internal facing. When people first hear that stat, they're generally pretty surprised because a lot of software engineers, we work in Silicon Valley. And Silicon Valley's job

is to go build software for other people. So if you look at traditional Silicon Valley companies, Airbnb, Google, Netflix, et cetera, these are all Silicon Valley software companies. Google's a software company that builds a software platform that connects advertisers and consumers. Same with Meta, same with Facebook, same with Airbnb, same with Uber. And so pretty much most software engineers at these Silicon Valley companies are building external facing software,

the core product for Airbnb, Netflix.com, Google the search product, et cetera. But if you think about most companies in the world, most companies in the world actually aren't software companies. If you go look at the Fortune 500, for example, probably 10, 20 of them are software companies. 480 of them are not software.

96% of the Fortune 500 are not software companies. And, but they actually hire a lot of software engineers. And pretty much all these software engineers do, day in and day out, is build internal tools. And so we think of internal tools as basically business applications that help you run your business. That's not being used by your end consumer, if you will. And it's actually the majority of the software

in the world, actually, which is pretty surprising. So you have a lot of companies that are not traditionally software companies that are writing more and more software internally. They're not buying their software from a vendor. They're not buying it from a box. They're not buying it from maybe even a SaaS where that's kind of internal, but it's more of a service at that point. So it's not like software they're maintaining.

It's just something they buy for the most part of some sort of subscription. It's a month or a quarter or a year. How did you go from this place where you were building this P2P payment company, learning that internal tools kind of suck to rebuild over and over and over and learning that this whole entire world existed? Did you discover it during the process of Y Combinator? Because you mentioned the pivot.

Was that when you sort of like, okay, this clearly has got negative margin. We've done this thing several times. Let's not build these internal tools anymore. What if you build a platform that does it for other people? Is that kind of how it worked out? Yeah, to be honest, it was mostly internal conviction driven. My co-founder and I were engineers and to us it was obvious a product like this should

exist. And so to be honest, even before doing any market validation, we built it for ourselves. So as part of our previous company, actually, we had built an internal version of Retul actually ourselves, because we were just engineers that liked building things. And when we were thinking about what to work on next, this became one of the major ideas, what if we productize this? And it wasn't talking to Brex and talking to some other customers that we realized there was a really big opportunity here. So another one of our, maybe customer number three or number four, is this company called Tyco Electronics. And Tyco gives you a sense of how large the market is,

you a sense of how large the market is, which is when we first launched Retool, Tyco Electronics, a customer of ours now, a person named Alessio came inbound and said, hey, I'm really interested in using Retool. And we were trying to understand what kind of internal software do you want to go and build? How much internal software do you actually build every day, every year? And we were shocked that a company like Tyco Electronics, I think it's Fortune number 250 or something like that. So it's solely in the middle of the Fortune 500. So an average Fortune 500 company. They, every year, spend around half a billion dollars building internal software, which to us was shocking. We thought, you know, we were working on Retool and it was a cool thing for us to, for engineers to use, cool thing for us to use to go build a few internal apps every now and then.

But when we heard that Tyco spent half a billion dollars every year building internal software, we realized the opportunity here was ginormous. And specifically, we didn't believe the half billion dollar number at first, but if you do the math, it actually makes sense. So Tyco as a company has, I think, around 120,000, 130,000 employees. And of those 130,000 employees, around about 2% to 3% of them are software engineers. So they have around about 2,000, 3,000 software engineers. And if you do the math based on the average software engineering salary of let's say 200k per year, 200k multiplied by 2000 software engineers actually comes out to $400 million every year that they're spending on software engineers.

And Tyco has no external facing software, pretty much all their buildings, internal tools, day in and day out. And so that gives you a sense of how large the market is just for one single company. So we heard that. That was really pretty shocking to us. And we realized that, oh, wow, when we were interviewing more and more customers, we realized that actually the majority of software in the world is internal facing. And the majority of internal software kind of looks the same, actually. It's pretty much just buttons, forms, tables, drop downs on top of Postgres databases, atop of Salesforce, stuff like that. And so that's when we realized the opportunity for Retool really is rather large. And we were really excited about the mission of potentially changing how developers built

this large class of software. When did you personally see like a new piece of software be built on top of Retail and you personally had this, oh my gosh, what do we build moment? I mean, because if you've, if you were tired of the old way, which was from scratch essentially, and you could build on top of retail with maybe an API key, sprinkle some code here and there for Postgres or some database calls, you know, things like that. When did you personally feel like, oh my gosh, this is the next big thing? It was probably a few separate moments.

One moment was actually when Alessio, that customer from TE, described Retool as similar to BI, but a much larger opportunity. And what he meant by that was, if you think about BI, which is actually a parallel space to Retool, to internal software, today, if you ask any engineer, you ask anyone really to go build you a BI dashboard, BI is business intelligence. So maybe you say, hey, give me a chart of signups over time, for example.

If anyone asks me that, my first reaction is, oh, I'll go use a BI tool. I'll go use Tableau, I'll use Metabase, I'll use Power BI, whatever it is, I'll go use that. Because if I want to use a product like that to build that chart, all I have to do is to go write a few lines of SQL, drag a chart on, and I'm done. It's so simple. I wouldn't consider building that from scratch. To build a BI dashboard from scratch, I would probably have to go build or go import some database drivers, I have to go build an authentication authorization framework, I have to go find

a bunch of front-end charting libraries and try to debug them and see which one is best. Then I'll find out, oh, it's a little bit slow, so I'm gonna go build a caching layer. It's so much work to go build BI dashboards from scratch, and no one does it today. And so when Alessio said, hey, actually, this is just like BI, except there's 10x, honestly,

more use cases than BI, that's when the idea really popped up in our heads. Wow. This is a product that is like to blow, but five, 10 times larger actually in terms of opportunity. And the fact that half all software is internal means that one day half of all software could be built in this way, which is really exciting. So that was one moment. Another moment was when another customer actually made an analogy to AWS, which she said that they had gone all in, this company had gone all in on AWS. This was maybe in 2016 or something like that, so a little bit earlier.

And the way that she viewed it was AWS saved her a lot of time and her company a lot of time, which is instead of building your own data center, try to figure out how to go manage racks of servers. When a power supply blows out, you have to go manage the, you have to go figure out how to go replace the power supply. When a hard drive spindle fails, go replace the hard drive. Now all they do, now all of, now we all do today is we use AWS. We press a few buttons and servers magically appear. And if we want to go launch into a new region AWS. We press a few buttons and servers magically appear. If we want to go launch into a new region, we'll press a few more buttons and we'll launch to another region. All this sort of commoditized or this undifferentiated heavy lifting, I think is

what AWS calls it, has been commoditized. We as Retool and that company, doesn't have to worry about having to go worry about all this heavy lifting anymore. We just go move a lot faster actually because AWS is handling all this stuff for us. The analogy she gave is Retail is kind of like AWS, but the AWS of the application layer, which is there's so much stuff in the application layer that is so bespoke right now that you have to build from scratch. When you're building a neural tool today, for example, you have to worry about what table library should I go and use? Okay, I'll go use this table library. Oh, that's not quite right. Okay, I'll go

find this other table library. Oh, this table library doesn't come with virtualization. So when I have load big data into it, it's actually quite slow. Okay, now that I have that built, okay, now I have to go worry about authentication authorization. Who can actually go use my application? How do I go hook in with single sign-on, for example? okay, now I have to go worry about authentication authorization, who can actually go use my application? How do I go hook in with single sign on, for example, oh, now I need audit logs, because I need to go verify what's something what something that happens, I want to know who did what, for example, there's so much crap that you have to deal with just

to get a simple crud dashboard going. And it's so much work. And so the idea that retail can sort of commoditize all that away, such that the engineer can focus truly on what is unique or differentiated about what they're building, I think is so powerful. So that was maybe a second moment, too. So I think it's a few moments like this with customer, you see customer use cases, the customer built customers go build things that you could not have imagined. And they actually go pitch a product back to you in ways that you

couldn't have imagined either. That's I think what was really validating for us for us to realize, wow, this is a really large opportunity for us to go change how developers really go build software. One thing you did say though, was that it was a remind me if I'm paraphrased, I'm going to paraphrase, I I think I think you said that it was uphill Was the way described it like to describe how it was to raise awareness for retool to Preach the mantra of you know, don't build your own internal tools

Use a platform like retool to make it 10x faster, etc How long did you spend or are you still in that phase where it's still kind of hard to it's still still sort of uphill in a way or Hard to sell Retail and to help people understand that this is a real problem or this is a real Solution you all solve very easily I would say it's gotten a lot easier recently, especially with ai which is helpful Uh, but the early days I think many people just weren't sure. Should I go trust a new company like Retual? Today, Retual has tens of thousands of customers at this point. And so-

Trust is too easy now, yeah. Yeah, companies ranging from NBC all the way to the US Army, all the way to Amazon, to companies like that all trust ritual now. So that helps quite a bit. That's great. But the AI has actually been a real tailwind for us too, because now a lot of people are really looking at, can I go adopt new ways of building software? The ways that we used to build software are no longer cutting it are there better ways. So that's been quite helpful too. So it's been less uphill recently, but the first few years really was a lot of educating the market and a lot of explaining to people why this is better than building software from scratch. How has Retool changed over the years? Has it always just been like internal tools

and just incrementally getting better? Have you added more, you know, user interface styles? Where has been the advancement of the platform over the years? Yeah, the advancements we're most proud of really are around AI over the last three to six months, honestly. So just a few months ago, a month and a half ago, we launched this product called Retool Agents, which really builds on top of a lot of the platform

that we've built that has enabled customers to go do some pretty incredible things. So in particular, so in Retool, to use Retool, to go build a front-end application, basically can build the front-end, but then you build a, you know, you write a bunch of queries to connect it to your databases, to your APIs, stuff like that.

And one idea we had around six months ago, this is just really an idea at that point in time, was what if we could expose all the tools that you have built in your company and Retool, and expose them to an LLM. That could be really powerful because that could allow the LLM to go do some pretty incredible things in your company. The thesis came from, the main idea here basically is we think that if you look at the power of LLMs today, LLMs are really quite smart.

I think they've conclusively passed the Turing test. So I was a philosophy major in college, and back in the day, we would debate, how do you know if an AI is smart? What does it mean for an AI to be smart? And I would say a good amount of philosophers thought, to this point still believe, that if an AI could pass the Turing test, that we would consider that smart or intelligent. The Turing test is basically, if you're talking to an AI,

can you distinguish the AI from a human? And today with LLMs, you really can't. If you talk to any state-of-the-art model, whether from OpenAI, from Anthropic, DeepSea, Kalama, honestly, they sound more human than humans actually a lot of the time, actually. And so they've conclusively passed. Like at this point, I think we can all say that AIs sound just as human, if not more human actually than even humans do. So that's great. But when we

look at how much value are people getting out of these LLMs today, it's really pretty limited. And it's really just one use case. It's really all just around chat. And it's kind of surprising that if the LLM is able to do everything or, you know, basically pass as a human, why is it that we've invested so much energy and money as an industry into AI, and yet there's just not that much ROI today? So to give you an example, I think over the past few years,

the industry collectively has invested somewhere between a trillion and $2 trillion into AI, which is a lot of money. A lot of that has gone to GPUs and to training models, et cetera. But if you sum up all AI revenue in the market today, AI, which is a lot of money. A lot of that has gone to GPUs and to training models, etc. But if you sum up all AI revenue in the market today, I think it's maybe around 20, 25 billion dollars. So that's like a 2.5% ROI based on how much money we've invested, which is pretty surprising. Yeah, it's kind of shocking, actually. And our thesis was,

it's not actually about how smart the models are, the models are plenty smart. It's actually about what the models can actually go and do. Which is, when you use chat, the model can't really do anything. I use chat frequently, for example, to go help me write things in Google Docs. For example, what I'm doing is I'm just conversing within my chat, GPT app, not to copy and paste it into the Google Docs. Or if I'm just building a slide deck, for example, to go copy paste the data into a slide deck, and

then oh, actually, it's not quite right. So let me copy paste it back again. So much work going back and forth. And so the idea is, elements today are plenty smart, really, we just have to give it the arms and legs for it to actually go do things. And this is, I think, what's so powerful about something like cursor, about the idea like cursor, which is theoretically, if cursors didn't exist, you could theoretically do or copilot didn't exist, you could do what copilot does with just chat GPT. You, Hey, you know, I'm going to go copy paste this code from my ID, paste it in the chat. You know, I have it right in and then copy paste it back. Oh, but it doesn't work. Okay. Let me copy paste the error message.

Okay. Let me copy back again. And theoretically that would work. But you can see how cursor or copilot is so much better. The fact that you can expose the IDE capabilities to an LLM actually allow the LLM to go do everything makes your life 10 or 100 times better actually. And yet if you look at how non-developers, most of the world is using Chatch BT today or using LLMs today, that's what they're doing. They're kind of pasting back and forth, actually. And so our idea was, can we go expose all these at LM and allow it to actually do things in your business systems? So it could actually go run queries, your Postgres database can actually go refund customers and stripe, you can actually go modify

Salesforce has to go send emails on your behalf, for example, if we could do that, that would almost be like a cursor for everything, basically. And so we shipped that a month and a half ago. And the reception has been really positive. So we can talk more about that. But that's probably what we're most proud of shipping, I think, over the last few years, is this product, Retual Agents, which, yeah, it's really quite powerful. It is powerful. It kind of goes back to the initial framing, which was, you know, the investor had said,

why would you focus on developers and our engineers? I think he may have said assuming gender, but yeah, I think you get in this place now where AI is kind of everywhere. It's table stakes. Like, can you really be a modern day software platform like Retool and not have AI focused features? I think the answer is hard no, right? But you didn't just simply add AI like you had said with chat. I'm really curious how you do it in a way because it's non-predictive, right? When we do generative AI, when we use LLMs, we can predict to some degree what it's going

to do, but it's non-deterministic, right? What comes out is non-deterministic. How do you unleash that on what I would potentially consider the crown jewels of all crown jewels, which is the internal software of Fortune 500 companies. And if you've got even a small majority of Fortune 500 companies as customers, then when you unleash that kind of thing to that kind of audience, there's got to be some concern. How do you do, how do you roll something like that out that's non-deterministic in a way that covers your butt? Is the easiest way to ask that question.

Yeah, so this is the power behind this formal software called agentic software. So this is what basically what cursor is and many other products are, which is the core idea of a agent. Today, the most popular architecture for agents is called a react style agent. So react style agent is basically a reasoning and an acting agent. And so what it does is that the alum reasons that it acts. And the way it acts is you give it

tools. So you say, hey, you can go search the web, for example, or you can, in the cursors case, you can go modify some code or you can go run some code, for example. There's this open AI product called Operator, which is a good example of this, which is, Operator is basically an agent with one tool, which is it can go browse the web. And it's pretty cool, actually.

You can tell it to go do things. So you can say, hey, go buy me a pair of shoes in this particular size, this particular color. And you can watch it go do things. It says, okay, well, let me think about what to do there. Okay, well, I'm going to go visit this website. I'm going to go search up shoes, this color, this size. Click this link. Okay, great.

Oh, that's the wrong size. Okay, let me go back, actually. Let me go click this other link. And so you can sort of watch, reason, let me go back actually, let me go click this other link. So you can sort of watch reason and act basically. And what we've discovered is, to what you're saying, something like that, OpenAI Operator is pretty effective in a consumer context. So if you're trying to buy a pair of shoes, buy a t-shirt, for example, it could be good at that. But in an enterprise context, it's actually really, really bad at it. And the reason is the one tool that it has, web browsing, is such a non-specific tool. For example, if you tell an operator, you can try this yourself actually, to go onboard

an employee that just joined yesterday, for example. What it's going to do is it'll go and search, how do I go onboard an employee that joined yesterday? And it's to go find like a WikiHow article. That's like, okay, great. Well, a WikiHow article says to go on board an employee that joined yesterday as I go do these things. And that's not what you want to do at all.

You know, if you work at a company like Amazon, for example, there is one right way of onboarding an employee, which is you have to go add them to workday. You have to go send them a laptop by Amazon logistics. You have to go do this. You have to go do this. You have to go do this, you have to call these very particular API endpoints. It's not let's go browse the web and go Google, you know, how do I onboard an employee? And so that I think gets at the power of an agent, which is with this kind of architecture of reasoning and acting. What you can do is you can actually

outsource the reasoning to the LLM. But the acting needs to be deterministic. And that I think is the power of something like Retual Agents, which is you can go build these deterministic tools inside of Retual. In fact, our customers have built millions, if not tens of billions of tools for agents to go and use. And so, for example, for a company like Amazon, they've built tools to say, hey, here's how you go on board. Here's how you go on board,

here's how you go add someone to Workday is you call the Workday API endpoint with the first name, the last name, the SSN and the address, for example. Great, okay, that's the first thing you got to go and do. Here's how you set a laptop, this is called this custom internal API that we've built, maybe a node or wherever else,

and it expects these parameters, expects the first name, last name, address, and computer model, for example, as well as you know, the start date. So we know, you know, how fast to ship that laptop, for example. And so once you've formalized those tools, then what you tell the alum to do is you say, Hey, LM, don't just go browse the web, you know, do whatever you want. Instead, you only, hey, alum, don't just go browse the web and do whatever you want. Instead, you only get these five tools

and then to go onboard this employee. And then the AI is so much more accurate. And so in our testing, our AI is so much better when you give it these very specific tools. And then I think it's the power of a platform that allows you to sort of give the non outsource the non determinism to the AI. But really you want to minimize that really want to maximize determinism. Yeah. And to do that, you need a sort of tool building platform, if you will.

Well friends, I'm here with a new friend of mine, Harjot Gill, co-founder and CEO of CodeRabbit where they're cutting code review time in half with their AI code review platform. So Harjot, in this new world of AI generated code we are, we are at the perils of code review, getting good code into our code bases, reviewed, and getting it into production. Help me understand the state of code review in this new AI era. The success of AI in code generation has been just mind-blowing, like how fast some of the companies

like Cursor and GitHub Copilot itself have grown. The developers are picking up these tools and running with it pretty much. I mean, there's a lot more code being written. And in that world, the bottleneck shapes of code review becomes like even more important than it was in the past. Even in the past, like companies cared about code quality, had all these pull request model for code reviews and a lot of checks. But post-gen AI, now we are looking at, first of all, a lot more code being written.

And interestingly, a lot of this code being written is not perfect, right? So the bottleneck and the importance of code review is even more so than it was in the past. You have to really understand this code in order to ship it. You can't just wipe code and ship. You have to first understand what the AI did. That's where CodeRabbit comes in. It's kind of like a, think of it as a second order effect where the first order effect has been Gen.AI

and code generation, rapid success there now as a second order effect, there's a massive need in the market for tools like CodeRabbit to exist and solve that bottleneck. And a lot of the companies we know have been struggling to run with especially the newer AI agents. If you look at the code generation AI, the first generation of the tools were just tab completion which you can review in real time. And if you don't like it, don't accept it. If you like

it, just press tab, right? But those systems have now evolved into more agent-ic workflows, where now you're starting with a prompt and you get changes performed on multiple files and multiple equations in the code. And that's where the bottleneck has now become code review bottleneck. Every developer is now evolving into a code reviewer. A lot of the code being written by AI. That's where the need for CodeRabbit started and that's being seen in the market. Like CodeRabbit has been non-linearly growing. I would say it's a relatively young company, but it's been trusted by 100,000 plus developers around the world.

Okay friends, well good. Next step is to go to coderabbit.ai. That's C-O-D-E-R-A-B-B-I-T.ai. Use the most advanced AI platform for code reviews to cut code review time in half, bugs in half, all that stuff instantly. You got a 14 day free trial, too easy, no credit card required,

and they are free for open source. Learn more at code rabbit.ai. So you have the idea of an agent which is some sort of demarcated name and role. So add new employee. Let's just say that's the that's the agent's name and it has a task of X but it's only got limited tooling so it's kind of like saying get to Rome, right? Everybody says this is an old adage, how do you get to Rome? Well all roads lead to Rome, right? But what if only five roads lead to Rome and those are the only five roads you had access to, you can only go to Rome, right? You cannot go to, I don't know, where else was this popular back in Roman days, some other city, right?

How do you get there? Well, you can't because you don't have access to those roads. You can't go there. You can only go to Rome. Yeah, totally. And so we've discovered it's just so much more effective that way. And if you look at actually, for example, this is what cursor is so effective too, actually, is cursor when you go use agent mode, it only has a few things that can do. And so it's not, you know, just endlessly Googling and, you know, let's Google for this, let's Google for that, let's see what happens. It says, well, I only got a few things, I got to modify the code, I got to run it. So let's see, you know,

I got to go modify the code and run it. Oh, I got this error. Okay, well, let me go fix that error. So by constraining the AI, it becomes substantially more effective. But also by giving a tool to actually go do things instead of telling you to do things, which is actually if you look at what chat GPT what people are using chat GPT for, it's actually kind of crazy how inefficient it is, which is today, the way I use chat GPT is I copy and paste so much stuff in into and out of chat GPT. And to some extent, it's almost like I've become the API

for ChachiBT, right? I've sort of become this manual worker just doing what ChachiBT tells me to do. Whereas you could glue ChachiBT to actually doing the work and give it to the tools, the arms and legs to actually go do the work. You could just sit back and drink a beer or something. You know, it'd be so much more effective.

For sure. What you're reminding me of, and maybe this isn't something you're already on too, is I've been more, For sure what you're reminding me of and maybe this isn't something you're already on to is is I've been more as a business owner. I have more exposed to The idea of systems right I can I will tire out I will I will Procrastinate as an individual like just me as Adam Unless I can build some systems. I cannot scale my enterprise or lack thereof,

let's just say, we're not a big outfit. But in order to scale beyond the one, which is me, to do the same job I do, to begin to hand off parts of it to somebody, I can't do that unless I build some version of systems. We use a lot of Notion. We don't really use a lot of Retail, honestly. We don't have a lot of internal software, but a lot of stuff we're doing in Notion in

this kind of ways. But what you're making me think of is really how systems is what's crucial, and they've already built. So if you're a deep or even shallow-ish customer retool, you've got a couple internal tools, right? And if you can systematize those things, the agent, I imagine agents are similar to systems or systematizing these things, it's a form of automation.

Now you have the same software you've built out for yourself in your enterprise doing certain things, whether it's an adding an employee or updating a BI-like dashboard that's built in Retool, et cetera, you essentially need to trust what's happening there. How do you then expose not just this agent world, but this ability to create systems for these enterprises?

Because I gotta imagine if you got, you know, one or multiple internal tools, the next thing you want to think about is how can I systematize around these tools? Is that the way they've also been thinking about this? Is this been sort of like build an agent, automate some things? How do you sell this idea to these folks? Yeah. So the great thing is that for a lot of the

distinguished customers, they've built millions of tools already. You know, every API you have, every database table you have to some extent, every single query you've written is a tool that you can now expose to an LLM in this controlled way to actually go and do things. But I think this is where the industry really is going, is how can we compose or build the tools such that we can expose them to LLMs

that have LLMs decide which ones to use to actually go automate more and more and more work. I think tool building is going to be a critical skill, if you will, and thinking about the level of abstraction that would build tools is at very high level, is at very low level, is going to be really interesting. We see our customers today, for example, those that have built thousands of retool apps, for example, and actually composing agents, in fact.

And so an agent scales up to probably a dozen tools or so. But what you can do is actually build agents that have other agents as tools. And so maybe an agent has 12 other agents as tools that it could call and says, hey, it was this kind of problem, we'll call this agent. And then this agent says, okay, well, is this particular subtype of problem, I'll call this agent and that agent has itself 12 tools that actually uses. So I think this kind of Mandelbrot-like way of scaling complexity is really going to be pretty, I think, going to be how AI automates more and more labor over the next two, three years. How long have you been working on this agentic platform?

What do you call it? Do you just call it Retool Agents? What's the proper nomenclature I should use to reference it? Yeah, Retool Agents. The way we pitch it is we basically say, hey, have you heard of cursor? Great. I've heard of cursor. Well, the reason why cursor is so effective is because it's an LM with tools that can actually go and do things. So it can sort of reason and actually act. And

that is such a powerful loop. The reason you can give it an LLM. Yeah. And if you could do that for all other assets in your business, such that it's not only developers getting more effective, it's your HR team getting more effective. It's your finance team getting more effective. That is so powerful. But actually, the people building all these agents are still developers, actually, which is really cool, because in order for an agent like this to work, you have to build the tools, and the tools have to be built by developers. So I think the importance of developers actually, if anything, has gotten more important over

the last six to nine months for us. Can you give me a glimpse into the kinds of agents being built? Can you expose any one customer or anybody, any particular specific scenario that gives us some clarity? Yeah, sure. So what pretty cool use cases we have a customer who has actually built an agent to go replace management actually inside their company, which is really cool. So they have a sales team, actually, that is doing a lot of cold calling. And for them, it's important for the salespeople to be getting

feedback in a timely manner on, hey, you could have done better here. Here's, here's what you did really well, actually keep on doing that. And you can think of it, it's pretty interesting because as a sales manager, it's actually hard to go and listen to all the calls your salespeople are doing. Because if your salespeople are working, let's say 40 hours a week, it's actually hard for you as a sales manager to be supervising and to be listening to eight times 40. So 320 hours of calls happening every week. And so what this customer has actually done is they've actually built an agent actually to go manage this team of salespeople, where the agent actually after every call finishes goes and analyzes that call, and that thinks about it gives feedback actually on hey, this could have gone better.

But you did a really good job here, keep on doing this, etc. And then actually, in future calls can actually provide in context, while the salesperson has the call, you can actually give them live feedback, tell them what to say actually. So it's really pretty cool seeing the power and what you can do actually. And I think a lot of jobs actually, if you think about sort of an agent doing this, the agent's actually probably doing a better job than the manager was before actually, because the LLM is able to take in a lot more information, actually, than an ordinary humanist, than I am actually able to. And so I think really leaning into what LLMs are good at, which is consuming information, summarizing information, but that's actually a large percentage of knowledge work, actually. A large percent of my job, actually, is doing those kinds of tasks. And so I think

in the future, we're going to see a lot of I have a labor market is really going to change quite a bit. When agents become more and more powerful, have more tools, and actually go do things in your business, like giving feedback, writing performance reviews, stuff like that. I think some of these things, you know, I'm thinking this case in particular, there's some things that, that I, I'm personally okay with and ready to hand off to something that isn't,

let's just say, isn't me delegate is the easiest word that everybody uses, right? It's the actual proper word. And I really don't care at necessarily how that task gets done, whether it's a little like crash nation and it just solve itself or somebody else does it or literally now some version of a robot or machine or AI can do it for me. I don't I don't really have that problem and one case in particular. I think what you just mentioned, which is a great example is where a salesperson is attempting to do

their job, which is to you know, sometimes it's selling, but sometimes it's just simply warming the waters of an opportunity. It's just answering questions, providing feedback, providing knowledge, and they need somebody else's support, whether it's a manager, a technical salesperson, somebody more knowledgeable with a bit more experience or depth, and if I, not so much if I can remove them, but if I can speed up my personal feedback

loop, if I'm in that role, attempting to warm the waters of an opportunity, not just simply sell, but I would want those answers to be fast. One, and two, I think my manager over time might get over my third or fourth request of how do we do this or what do we do there? You know, that person will gain, will just grow tired of me potentially even like individually me and then my question or just generally answering questions like that of people like me even if it's their job, they may just be like, this is not,

this is not a good use of my time, if they come to pay me for, for example. And so in those cases, I'm kind of happy to let those kinds of things go to the agents. You alluded to this, and I think we all sort of see it coming in a way, is this major shift in the labor markets which we're just not able to truly predict yet. And here I am sitting with someone who may be in the levers of time.

In the levers of time, David Hsu, co-founder, CEO, Retool, all the things you do could be responsible for the labor market change. How do you feel about that? Has it always been just whatever it takes to innovate? How do you sit at that wheel, so to speak? Yeah, I think there's gonna be a enormous change in the labor market, especially for knowledge workers, myself included, over the next few years,

because like we're just talking about, honestly, LLMs are really quite smart at this point and in many cases can do a better job than I can. Actually at consuming information, summarizing information, even making decisions at times. Maybe they're less biased than I am, for example. So I think there's so much potential there. And you add that to what you said, which is I think ultimately we're outcome oriented. I think businesses, business owners, we're outcome oriented. We don't actually care. Even all employees, I think we're all, as long as the work gets done, whether it's done by a human or a robot actually

doesn't really matter that much if it's being done to a high quality. And oftentimes with robots can be done to a higher quality faster than humans. So that I think is from a philosophical perspective a little bit unsettling. But the way I think about it, and perhaps this gets to your original question, is I think it really is a... I think in the short term, it's going to be painful in the sense that we're going to have to adapt. I think the labor market will have to adapt, a lot of humans will have to go and adapt. But those that really embrace AI, I don't think it's something you can really hide from at this point. Those that embrace AI, the builders that are able to go build the building blocks such that their companies

can really leverage AI, I think those are the ones that are going to do really well over the next few years. And we see so many examples of this in our customer base today, where someone takes action and they are able to go write some SQL queries, they're able to go build some building blocks, build some tools for LMS, and they go automate a whole process, and they get promoted three times in a few years. I think those are the people, the sort of action-oriented people that are hands-on keyboard able to go do things. I think there's going to be a premium to that in the market over the next few years. But I also think

in the long-term, it will lead to a lot more abundance. And so I think Democrats have been talking a lot about this in California around an abundance agenda. But that's ultimately what I think AI will do for us is there will be enormous deflation, where the cost of providing a lot of services will go down. And that will allow humans to go afford a lot more of those services, which would be really cool. So I think overall, it's going to shake out really well, overall for humanity in the five, 10, 20 year timeframe, but there's going to be a lot of, I think, pain and gain for those that can leverage AI. There's going to be a lot of gain for those that can really leverage AI for the next few years. And a lot of pain for those that can't and end up having to retool themselves or to move to a different job family. So yeah, it's going to be a pretty interesting somber few years.

Yeah, certainly, certainly a possibility. I can see a lot of things shifting, but even I kind of come back on this. And this is this example multiplies well, potentially. I could be wrong. Is that in the case back to the manager giving feedback directly to people? Over time I'm going to get slower at it potentially. You know, I'm not going to be the best at it. I may give some attitude. You know, I may not give the best response and

you know, that really is like the context and the intelligence of the response can still come from someone like me feeding essentially the LLM context so that a salesperson or an AE or however you want to categorize that person or title them, they're able to leverage my knowledge, but without me having to be present to literally hand spoon, hand feed it to them, you know, on the case by case basis. Like to me, that seems, I'm cool with that. I'm cool with that.

Let's dig into the specifics of like, I'm thinking of, there's probably a certain situation or certain framework or parts to internal tools that every company needs of some shape or form. Is there a stampable blueprint, so to speak? Your company, you likely have these kinds of needs for these kinds of internal tools. You should come to Retool and build them. And then on top of all that, we're going to give you smart AI to react and take action and reason on all this stuff on top of this platform. Is that how close is that to being the reality where you just have like here, take this and it's done where you don't have to individually build each one. You can sort of like template.

You don't have to individually build each one. You can sort of like, templatize what it is to have an internal tool set for your business. Yeah, a lot of that is happening today, where especially for smaller medium sized companies, a lot of our templates work off the shelf, which is how do you do customer support, for example, how do you automate that?

Well, you have to plug in your intercom database, plus your Salesforce, then you give that to an L you have to plug in your intercom database plus your Salesforce and give that to an LLM and it's actually pretty capable of answering your docs page maybe. Maybe you vectorize your previous support tickets and it's very good at answering support tickets actually already. So that's the template that we have on our website that you can check out for free yourself. And so that's going pretty well I would say, especially for smaller or medium sized companies. For the largest companies like the Amazons

or the US armies of the world, there it gets tougher because their templates don't necessarily work because Amazon is not going to just adopt a sort of how someone else does something. They have a very specific way, to go back to employee onboarding, for sure. They have a very specific way, you know, to go back to employee onboarding, for example, they have a very specific way of here's how our workday is set up, it has these columns. And these are the required fields to go out and do employee to workday, for

example. And there's no way that anyone else can really tell them how to do that. It's, you know, sort of proprietary to Amazon, if you will. So I think that the this is why I think the developer skill set is so important. So I think that the this is why I think the developer skill set is so important. But I think that the developer plus the line of business or understanding the requirement from the line of business, the context is going to be ever more important, if you will, which is I think the sort of skill of translating a

requirement into code, that I think is a bit commoditized. And we start, we're starting to see that already with AppGen products like ours, or AI IDEs like cursor or copilot, for example, that literal act of coding is less interesting nowadays. But the ability to go interview stakeholders to go understand, okay, well this is the API in particular I should use. That skill is, I think is gonna be really, really important.

At least for the next few years, I think. And so, yeah, that's the most important skill set, we believe. I think so too, it's interesting. I've seen the templates. I just didn't think that they were that expressive. I didn't think it would be expressive to an enterprise, that's for sure, but when you look at your audience,

you have the idea of, I think, a lot of startups or a lot of upstarts that began and started to scale up now, so to speak. Brex is no longer a startup right there, as old as you are, so they're knee deep and they're good to go, but they're still using Retool. There's no template to say, out the other end, Brex, but if I'm a particular kind of company,

for example, a grocery store, maybe there's particular things that a grocery store might need. How frequently does a grocery store open up? Probably not too frequently. So it's probably a bad example. But let's say like a barber, or a nail salon, or a massage therapy, or let's say like a barber, right? Or a nail salon or a massage therapy or let's say a golf studio or a range where you can

go hit golf balls. There's bespoke different unique businesses, but they all have employees. They all have probably payroll. They all have unique things that each and every business has. Has it ever been wise or does your template sort of cover that chasm so to speak? So it says you're starting a new business, start on Retool. Like don't build these tools yourself. You're probably going to use, you know, these four or five web services. Let us complement that with Retool. Is that something you do? Yeah, ish. But oftentimes no, actually. So the way we think about it is there are times when internal tools are really quite

valuable. And I think for large companies, for example, Amazon, internal tools are, this is why Amazon is such a successful company, is due to the internal tools they've built. And so it's so important for you to, same with Brex, for example, same with Ramp, another one of our customers, same with Stripe, for example, same with ramp and other one of our customers, same with Stripe, for example, internal tools are the lifeblood of their business. To be honest, if you're a barbershop, you probably don't need the world's best internal tools, you can

probably go use some barbershop management software, a CRM built specifically for barbershops, and you're probably fine, honestly. If you're a cafe, for example, probably you should go buy Square. And with Square Terminal, you can manage your POS, you can go manage your inventory and that works great for you. So we really think that,

we don't think Retool's the right fit for everyone. We think Retool is the right fit if you truly need custom internal software. The good news is there's a lot of custom internal software being built across the world every day. It's half all software, but it's also not 100%. And in many cases, you would actually be better served just by buying something off the shelf. So that's something we're pretty honest with ourselves about and pretty honest with our customers about too, which is if you're a cafe,

probably just go buy Square instead of trying to build your own POS system. It's going to be a lot of work and honestly not going to get you a much better result than just buying Square. For sure. Yeah, I think what I mean is like, you know, obviously, you know, a barber is probably going to use Square. My barber uses Square, for example. Love Square, by the way. I always enjoy using Square, whether I'm, you know, at the barber or a coffee shop. I always love it. What I was thinking was more like, you know, I'm going to use something like a square.

I'm going to use something like a, like a Shopify to do some version of commerce. And so because of that, you can assume certain things about the kind of business I'm running. And so you can compliment that tooling cause there's integrations and because there's, you know, some tooling that might be bespoke to me that makes sense to build inside a retool. I was thinking that you may have made some inroads there where you can sort of predict a set of internal tools for a business.

I just, I'll stay a lot on that. That'd be kind of cool. That'd be kind of cool. That'd be kind of cool. I think so. Cause I think there's some opacity. Well, there's some opaqueness to, and some opacity level to Retool where it's kind of hard. You know, there's a lot of abstract.

You can go and look at some of your templates. You can go and sort of see some things, but I've never seen a fleet of internal tools beyond what I've built for myself, which is like maybe one or two. It's nothing that's beautiful or amazing. And so I was thinking, is there a way to give me a glimpse behind the scenes

to like a fleet of tooling and how much of that fleet of tooling do 80% of the companies that use Retool always build? Is there a Retool for Retool essentially? Yeah, totally. We see our customers building a lot of pretty similar internal apps. But to give you a sense of company like Brex,

but I think they have to be around a few thousand tools that run inside of Retool. Coinbase is another example, I think a few thousand tools that run inside of Retool every day actually. So yes, there is a good amount of overlap. I think we could be doing a better job showing off some of these use cases. But to be honest with AI, I think a lot of this becomes maybe a little bit less important too, because with AI, nowadays in Retul, you can go describe the problem that you have, and we'll build you

an app for that actually pretty quickly. And we pull on the knowledge that we have of all the expertise that we have. And so that I think is pretty powerful too, is with AI you almost have to think less about or you don't need to see examples anymore. For example, with chat GPT, you can go say, hey, I'm going to upload an image, style it in this way. And it's not like, oh, I need to see examples of this. It's just, oh, well, here's my image, if you will, because it happens so quickly now. So that I think is quite cool, too.

And I think we should do a better job showcasing that website. Yeah, interesting. I guess we'll run the subject. What about your internal tooling? I mean, you obviously probably use Retool to build Retool. So you got to have a ton of your own tooling built on top of Retool. Like can you give me a glimpse into some things that you may have built or things that make sense for you to build over the years?

Yeah, we have so many cool tools built in Retool. So we have one called Retool Home, which is inspired by Stripe Home. It's basically this internal, it's for employees of Retools to use. And you can log on and you can actually go see other people. It's like an internal company directory. You can see fun facts about them. You can see the people generally record a video when they first joined Retools. You can go see that. There are fun games you can play in there, like how many Retools can you recognize in a row, for example. We have a decision log in there so you can see what are decisions that have recently

been made, for example. So it's really cool. So that's one example of an internal tool that we've built inside of Retool. A lot of our customer tooling is built on top of Retool. So if we want to go, for example, reset someone's password, add credits to someone's account, pretty much all of that is built in Retool. A lot of our finance tooling is now built in Retool, which the finance team loves, because it is much more robust

than using Excel spreadsheets for doing a lot of this. Oh, for sure, gosh. It's pretty cool, yeah. A large portion of Retool, probably 70% of Retool runs on top of Retool, so. I love a spreadsheet, but, uh, not always, you know, not always. I mean, there's times that I'm like, can I just get back to the simple spreadsheet? We can organize things a bit differently, but then there's times I'm like,

you know what spreadsheet is not that kind of cool. It's, I'd rather have something better, something better, especially when it's really hairy. Like when you have, um, multiple tabs, thousands of rows, hundreds of formulas, it's really hard to parse what is going on. But I think a lot of those spreadsheets, honestly, over the next few years are going to go away because AI is going to make with Retool and our copilot product, for example, building apps is going to be so easy that a lot of those spreadsheets that should have been apps are in the future going to be apps. Yeah, I wonder. And then I wonder about how do we, you know, how does that world connect?

Because it's nice to have a random bespoke app, but at least I know where my spreadsheets live and I can query them. I can search them. I can history them. And maybe you'll eventually have that kind of stuff too. But then I think like, gosh, now I've got applications that are, that could have been spreadsheets simplified. Now they're full-fledged applications. Maybe I got them at a special URL and I got to manage the domain and DNS and other stuff like that. Or there's just a simple URL schema inside a Retail that makes it easy to go to customer.retail.com slash whatever.

Maybe it's like that. I don't know. How do you how do you manage a world once you've got a few of those bespoke apps versus spreadsheets? I think bespoke apps are much easier to manage spreadsheets because spreadsheets you basically have no guardrails. There's files maybe on the cloud, maybe on your computer. That's it. It's hard to do version control on them. It's not true to collaborate on them even.

So I think it's pretty easy. But I think a file based sheet is less easy. Yeah, but even Google Sheets is hard to tell cell history, for example, someone accidentally found a cell that becomes quite cost. So I think apps are honestly way better than spreadsheets. Well, in some cases, simple spreadsheets make more sense than apps. But I think as app building becomes way easier. Yeah, there's going to be a lot more apps, I think.

Okay. So today, am I able to go into Retool today? This shows just how naive I am about how Retool works. So bear with me. Despite y'all sponsoring us, despite me should know a lot more. This is, this is maybe TMI in a way. Can I go into Retool now and tell it what kind of application or what kind of tool I want to build or what I need? I have a Postgres database or this or that. Can I describe the problem today and it builds me the application today in Retail? Partially. We are launching that later in August.

So today you can build large parts of your app. You can go write queries, you can go build some UIs, but it's not a full end-to-end experience yet. This is our next big launch coming in August is actually launching a full end-to-end way. It's like App Gen, basically. So it's something similar to Bolt or Lovable, where you can just say what you want and it builds the whole app for you. But what's going to be really incredible

is the fact it's two things. One is that we can actually build on top of your existing data sources. What we found is with many of our customers, like Amazon and others, Amazon has a lot of databases. They use Snowflake internally, they use RDS, they have so many places where data lives.

And for them, they're not really interested in using something like Bolt because Bolt is really great for prototyping. It's great for generating a new application from scratch, but how often are you truly generating a new app on top of new data where you have no data really? Not very often actually. In most businesses, the data already exists, but you want to build an app on top of that. That is where I think Reholt is really going to shine.

We're going to be the first product in the market that allows you to go generate applications on top of pre-existing data. Whether it's in Postgres, Snowflake, Databricks, Salesforce, or Stripe, you can actually go generate an app entirely based on that, which is going to be really cool. The second thing is that because we're so focused on internal software, we'll give you a lot of things right out of the box, like authentication, authorization, audit logs, stuff like that. And so you can then say,

hey, actually these apps could only be usable by these people or by usable only by these octa groups, actually, which could be super powerful. So we imagine catalyzing a wave of application building with this product, this copilot product. It's coming in August. So we're pretty excited about that. Interesting.

Yeah, I'm not familiar with all these details of what's coming. I just assume it was already there, but apparently it's coming. So you'll be able to generate a full-on retool application from scratch, which is essentially what a lot of other platforms are already doing, but you're saying on top of a database.

When you said that, I was thinking, okay, so will you be able to, what will you be able to do, I suppose, by just looking at the database? Will you take a lot of the prompt and context of what to do, but can you also just say, hey, look at this database and generate the screens that should manage this kind of database. Like, is that gonna be that easy to generate?

Or what are some of the processes in Garboil's gonna be when you do that, do you know? Yeah, totally. So what's gonna happen is once you've connected database or an API even, the LLM will realize, oh, I have all these API inputs I can hit or all these tables that I can pull data from. And so then it's kind of what we're talking about before.

Valum is so much more powerful, so much more correct, when it actually knows the shape of your data, or is actually able to interact with your database. So the apps it generates look much better, but also actually work immediately. And it can go straight to prod because of the security, guardrails, stuff like that. So we're're really there's no product in the market that allows it to do that right now So we think that's really quite powerful Interesting. So is this a leak you're doing here on the podcast right now? Or is it was what are you doing? I actually don't know if I'm allowed to talk about but we're pretty excited It's gonna be in trouble right now or what it's coming just next month. So I hope I'm not in trouble

But we're really really pumped about it. So, okay. This is to me, this is the cool part. Honestly. I mean, I like the idea of what you've already released. I like the idea of reactive where you have reasoning and you have action in terms of agents. But to me, this is the coolest because, uh, it's for what you just said there,

which was the, when you said the agent can only have certain tooling. because it's for what you just said there, which was the, when you said the agent can only have certain tooling. So the accuracy of the predictive of what it will do is so much more guardrailed from being into be true versus false or a hallucination because you've given it parameters. And so I think about the same things.

Like if I'm building on my real data or my real API endpoints, then the LLM inside of Retool, before it even builds out the thing I'm building out, I can have a conversation with it about my API endpoints. I can discover it as a maybe juniorish or up and coming developer for the company where I'm learning more and more about the different systems. I can plug into Retool given I have Auth and given I have whatever

to build out whatever tooling I need to and begin to query the database and the API to learn even and maybe to ask it, hey, we have this problem. How can this internal tool that we need to build solve it? What API endpoints will we use? I imagine like that to me is that's where you want to be at. And as you mentioned before, the, the accuracy level, uh, is, is high because you've literally got the API and the endpoints and the details there. The context is so clear versus abstract.

Yeah, exactly. So we think that a lot of the AppGen products in the market today are quite good at UI generation or prototyping, which is awesome. That's very valuable, but it's hard. As far as we can tell, no one is really using these AppGen products that go straight to production because in the end, they're not very robust, especially if you're an enterprise. It's very hard to get the stuff. It's hard to deploy it in the end, they're not very robust, especially if you're

an enterprise. It's very hard to get the stuff. It's hard to deploy it in your cloud, for example, it's on top of your data, there's no security. So that's all really quite challenging. I think for us, we think the opportunity is if we focus specifically on internal software on top of your data, can we go build an AppGen product that not just generates UIs, but is immediately actually usable, you can actually deploy it to your customers.

And I think with all the context we have for your data from other apps you've built, we can do that. And so we're really excited about that opportunity for us. Does that change Retool at all? I mean, I know since the beginning, it's been internal tools, and you can sort of like, you can expand the umbrella of what internal tools means to the point where it just means software. But does this change the trajectory at all of retail? Does it take you from an internal tools company to something that's, or does that even bottleneck you from the true potential you can achieve?

Yeah. So we've thought a lot about how this changes for our customers. And our hypothesis right now is today, most developers are the ones that are quote unquote, hands on keyboard coding. And so the developers the one building the application today, maybe by AI, but they're still building it, you know, it's still you that is building it. What we see in the future is we think that developers or today's developers will move to more of a software architect kind of role

where they'll be building a lot of the building blocks for AIs to use. So for example, maybe you work on the API endpoints, maybe you work on the data schema because that stuff is really important. But for the actual application building, you don't need to be doing that anymore. It's gonna be either the AI or even lines of businesses

actually building and generating applications based on your building blocks. And so we have this concept that we're internally calling Tomorrow's Developers. And the idea there is today's developers are the ones that have both the skill and the knowledge to go build applications. But tomorrow's developers may just have the skill

and not the knowledge actually. What I mean by that is, my wife is actually a good example of someone like this, which is, she was an econ major in college and she wrote some MATLAB in college. And she was able to code. She was able to think in a coding-like way, if you will. But if you go ask her to go build a web application, she would be pretty overwhelmed because there's

so much going on. It's so complicated to go build a web app today. You have to worry about what front-end framework do I go and choose? What state management library do I use? What are the pros and cons of using something like Heroku or Vercel, for example, today versus AWS? Should I use a VM or should I go use an all-in-one platform? Should I use SuperBase or should I use Postgres?

What's the difference? It's so complicated. There's so much knowledge that is required to go build an application. And so we think that these kinds of people with AI and with software architects, with software engineers becoming software architects, building the building blocks, if you give them the building blocks and you give them AI, they will be able to build really powerful applications directly, they can actually directly

use. And so that's kind of our vision is we think that software engineers, their role will change a little bit. And a lot of these line of business people that can learn SQL can pick up SQL will now be able to ship secure applications and actually build them themselves and actually use them in production. So yeah, it's gonna be a pretty exciting next few years, I think. It would be interesting to think about, to use your idea of tomorrow's developers, somebody who has the skills,

meaning they understand how to leverage the power of an LLM or however that evolves to be talked about, whatever lexicon makes sense to say LLM. They had the skills to do so, but they don't have the knowledge of how to build software necessarily. this, you know, to be talked about, whatever lexicon makes sense to say, LLM, they can, they have the skills to do so, but they don't have the knowledge of how to build software necessarily. They may not even have the, they may have some knowledge on how to build software, but not how to build software for, or internal software for the company that they work for, right? They don't have a full understanding, but they can use the platform to query and

learn and then actually build. And if you give it enough, you know, enough of the security measures, like you mentioned authentication, authorization, if that's already baked into the way things work, then it's pretty easy to give people more and more trust when it can be either just taking offline or regenerated differently in such a rapid manner. We used to have a fear, I suppose, of shipping software

because the cost and time to change or to blame or to fix or to redeploy was more time consuming, to put it bluntly. And now it can be a lot less time involved there. So maybe that speed to deployment is what's changing things to, to make it more trusted. You know, it'd be kind of cool to be this future tomorrow developer, not really have the skills to do software development, but have, or the knowledge, but have the skills

to conduct an architect based on feedback and learnings to deploy something to prod and not really be a software developer. That's kind of what I think about, honestly. Yeah, we see a lot of data teams doing that now with Retool. I think that we're pretty far from total non-technical people being able to do this because I think if you don't know how to write SQL, if you don't know how to debug, it's going to be a little bit challenging for you to go build full stack applications. But if you are able to write SQL and you have software architects or today's software developers

becoming software architects building you the building blocks, then absolutely, I think it's going to be really quite powerful. Interesting. All right, David, tomorrow's developers, I should say. Can't wait to ship some stuff to them and get some cool stuff. Anything left? Anything left in closing? I know we're, I think we got like maybe one-ish minute left.

I just realized we're right at time here. What's left that I have and I asked you that you want to leave on the table here? I think we covered a lot. We covered agents, we covered copilot, we covered tomorrow's developers. Yeah, I feel pretty good, yeah. Yeah, right on. Glad to finally have you here.

Big fan of Retwe as you know. I'm just such a fan of enablement like you've done. Like I don't personally in my small business have a vast need for internal software, but I know a lot of teams who do, and I've used, what's kind of cool actually to circle it back is I used a vendor onboarding form recently and I can tell it was a retail application I was using.

That's awesome. I was like, okay, cool. Yeah, I was, because we, you know, we're sponsored, so we do with a lot of different brands who work with us and whatnot. And so we have to do vendor onboarding and who are we, where do we live, you know, not're sponsored. So we do with a lot of different brands who work with us and whatnot. And so we have to do vendor onboarding and who are we, where do we live, you know, not so much live, but like where we work kind of thing.

And I have to share some data with them. And I filled out a form and it was a Retool, it was Retool application as an intake form for them. I was like, that's pretty cool. That's pretty cool. That is really cool. Yeah, awesome. Yeah, after all these years working together,

finally circled black personally to use, uh, some internal tools from retail. All right, David, thank you so much. It's good to have me on. Yeah. It was a lot of fun. Such a fan of David, such a fan of retail. And it's so cool to see how software is shifting, how Retool is in the perfect position to add agents on top of internal tools for all these businesses, all these platforms, all these teams using Retool to build out their internal tools. This is a great example of not bolting on AI. This is a great example of how AI has taken a new turn, a new shift, a new everything for a platform like Retool.

I find it amazing. I don't know about you. So take stock. What can you do differently? How can AI change the way you build, what you build and the platform you're building? And you may not know this. This may be news to you.

I hope not, but we are gonna be live in Denver next week. Learn more at changelaw.com slash live. $15 ticket or it's free if you're a Plus Plus member. It's better. Yes it is better. changelaw.com slash plus plus or changelaw.com slash live. Live in Denver baby. It's gonna be fun. Okay big thank you to our friends over at Auth0, our friends at Code Rabbit, and of course our friends and our partners at Fly, fly.io. Check them out, Auth0.com, coderabbit.ai, and of course, fly.io.

Of course, a huge thank you to our friend and our Beats master in resident, Brake Master Cylinder. Brake Master's gonna be live in Denver by the way. Live tracks in the flesh in person. Break master cylinder. Don't miss it. Okay that's it. This show's done.

We'll see you on Friday. Thanks for watching!