Retool is an enterprise AI AppGen platform for internal software development, allowing you to create apps, agents, and workflows with any LLM, datasource, or API.
David Hsu previously joined the podcast to complain about maintaining internal tools.
Connect with David on Twitter.
Today’s shoutout is for user Waseem Wisa, who won a Populist badge on their answer to Sass compiler throws 'undefined mixin' error when mixins are kept in seperate folder.
TRANSCRIPT
Ryan Donovan: If you're building anything with voice AI, check out Assembly AI. Their multilingual speech-to-text and understanding models are insanely accurate. Handles speak your IDs and integrate directly with LLMs. You can get $50 in free credits at assembly ai.com/stackoverflow.
[Intro Music]
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I'm Ryan Donovan, your humble host today, and today we are talking about, you know, a small topic, the changing nature of software engineering, and what software can do thanks to the AI revolution. So, my guest for that today is returning guest David Hsu, CEO of Retool. So, welcome back to the show, David.
David Hsu: Thanks, Ryan. Excited to be here.
Ryan Donovan: Yeah. So, since you've been here before, we'll skip the preamble. If people wanna find out your origin story, they can go to the previous episode. So, obviously, everybody has seen AI kind of change what is possible in software, and so, who is now a software engineer?
David Hsu: Yeah. So, I think the software industry has gone from a period of very little change, honestly, for the past maybe 10 or 20 years, to undergoing a pretty phenomenal transformation in just the last 18, 24 months, and I think in two ways; one of which is the nature of software engineering, or who is a software engineer today
Ryan Donovan: Mm-hmm.
David Hsu: Before, it used to be in order to build a functional web application required a lot of skill and knowledge. You needed to know how to code, but you also needed to know a bunch of, you know, facts about, oh, well, you know, redux is how most people manage state today and React. What is React versus View? Should I use Heroku versus AWS? All these facts, basically. So, that, I think, the nature of what it means to be a software engineer is changing, is one. And the second is the nature of software itself is changing, which is, software used to be able to do fully deterministic things.
Ryan Donovan: Right.
David Hsu: And so, if you wanna multiply two numbers together, great.
Ryan Donovan: Easy-peasy.
David Hsu: Yeah. But if you want a software to compose you a song, software will definitely not be able to do that.
Ryan Donovan: Right.
David Hsu: And now, today it can. And so, sort of, the total addressable market, or sort of what problems you can solve with software, I think that's shifted pretty fundamentally, and I think over the next few years we're gonna see this boom in software creation. I think we talk about digital transformation, or companies talk about digital transformation. That was kind of the first wave of software, is digitizing things. I think this next wave—is probably gonna be even a larger wave—is thinking about what tasks can software do that used to be sort of more human-like, actually. And so, there's a sort of automation wave, I think that may put all of us out of a job, myself included. So, it's a little scary to think about, but those are, I think, two pretty massive changes.
Ryan Donovan: Yeah. Well, let's start with the changing face of the software engineer. With vibe coding and AI agents, software has been a lot more accessible. Some people have even said, you know, the new programming language is English. Do you think that with everybody being able to create software, you know, are they gonna be able to create competent software?
David Hsu: Great question. I think with the products today, the answer is no, and I think we see this with the Bolt, Lovables, Repless of the world, where it's really remarkable that a non-engineer—I have friends who are non-engineers—or now able to build pretty complex web applications to go track their personal lives, to help their kids learn math, whatever it might be. You can now build a program, which is awesome, and this technology is incredible. But when I look at what percent of software is this kind of, I would say, almost like a 'toy application' versus a production application, most software in the world is built by larger companies for production use cases.
Ryan Donovan: Right.
David Hsu: It's a pretty shocking fact about software, but actually most software is internal facing, which is kind of surprising to most people, and the reason, if you think about it, is that if you think about most companies, the Fortune 500, for example, what percent of those companies are software companies? Not very many, maybe 10% of them. And so, 90% of the Fortune 500 actually hired a lot of software engineers. And all they do, day in and day out, is they build production internal software to go run their business. So, whether it's you picking up a prescription from CVS, whether it's you ordering something from Amazon, or you know, you getting on a flight to fly to New York, for example, there's so many internal tools, and internal tools really run the world, if you will.
Ryan Donovan: Right.
David Hsu: When I look at– is vibe coating gonna get us there? Or you can generate these kind of– would I trust vibe coating to generate software that allows you to pick up my prescription? The answer's definitely not, I would say. And so, I think that's actually something pretty fundamental missing there. But the answer, I think, is no. So.
Ryan Donovan: Yeah. Well, I think it's interesting, you know, you talk about the internal tools and I think when people talk about the sort of ' citizen developer' that vibe coding and these AI agents enable, it's like, yeah, I create a little batch script or a little tool for myself, but what is the– you know, we're not even gonna talk about product software yet, like, the one you sell for money. What is the gap between that, you know, tool you create for yourself, and the tool that is for the company for arranging prescriptions?
David Hsu: Yeah. Well, I think the stakes are a lot higher. You've probably seen it, I think it was a headline not too long ago, where I think Replit dropped someone's database.
Ryan Donovan: Oh yeah.
David Hsu: And, you know, they were not too happy about that because all the data was lost now.
Ryan Donovan: Right.
David Hsu: But that's an example where I think that the issue is that a lot of these products today are built on top of JavaScript. What I mean by that is it's outputting just raw JavaScript or raw React code, and that's great for a software engineer, actually. And this is why I think Cursor, and actually, Claude Code, are extremely effective, and so, I actually did not include them in this category. And they're vibing, but it's almost engineers vibing. So, I think that's different. That's just quite safe because the engineer can actually read the code and understand what is going on. I think the real danger is when you have these non-developers using products that output code, it's really hard for them to look at that and be like, you know– let's say you have this statement, it's this drop table.
Ryan Donovan: Right.
David Hsu: A non-engineer reading that is like, 'I don't know, seems reasonable. Let me run it. Let's see what happens.' Or, as an engineer would say, 'oh, drop table, you know, hold on. Maybe we shouldn't do that just yet.'
Ryan Donovan: Right.
David Hsu: And so, that's the example where I think just the base layers, if you will, or the abstractions of the primitives that these non-developers are using to vibe code, is just too low. It's almost as if, you know, let's say Claude code outputted, let's say, assembly for you. If it outputted assembly, I would probably say, you know, that's useful, I suppose, but it's actually pretty hard to read, pretty hard to debug. You know, theoretically, I'm a CS major, you know, so I wrote assembly, you know, 10-20 years ago, but I don't remember. It's very detailed, it's very low level.
Ryan Donovan: Mm-hmm.
David Hsu: And so, that's kind of what it's like to be a non-engineer now, actually using this vibe coding product. It's almost like a software. If you're a software engineer, imagine if Claude Code outputted assembly. It's like, 'well, that's great. You know, I guess I run it, and I think it works, right? But it's kind of risky,' right? And so I think for engineers, actually, Claude Code is great, but, I think for non-engineers, these products really need to evolve, and I think that's where I think Retool has a big role to play, I think.
Ryan Donovan: Hmm. Yeah. That's an interesting comparison that, you know, a lot of programmers working on compiled binaries, right? Their code is compiled into assembly or machine code, but it is a more deterministic process, right? You know what this compiler's gonna do. Everybody's finding undefined behavior and xing it out. How do we get to that point with, you know, the sort of vibe coded JavaScript? Or can we?
David Hsu: So, this is my point of view, but I open to being challenged on this. My sense is that you'll really need to put a lot of guardrails around what is possible in a vibe coding way, especially for non-engineers. And then, I think that actually will be the evolution of the software engineer's job. And what I mean by that is I think the era of software engineers hands-on coding things is pretty much over. You know, I think it's 2025, at least for internal tools. I think it's definitely over. And what I mean by that is, instead of the software engineering typing in a keyboard, 'let me go write this code for this internal tool,' I think that software engineer's job is gonna change. Instead, it's gonna be, 'I'm almost like an architect. How do I go build the guardrails or the foundations to allow these non-developers to go build internal software?' The problem right now with a lot of this vibe coding, especially these consumer products, is that there are no guardrails. And so, drop a database is very simple. You will drop databases. Whereas I think if you can allow these developers to build guardrails or higher-level primitives so you can imagine, for example, in the company, you say, 'hey. This is the React component that is the customer view. And if you are a non-engineer looking to visualize customers in a one-by-one basis, you will always use this customer component. And by the way, here's an ORM for you to use where here's the customer object. And the customer object that's defined as this stuff in our Postgres database, plus this stuff on our Databricks database, plus the stuff in Salesforce,' for example. And once engineers define these higher-level primitives, then non-engineers can actually work quite safely. You can even say-- the engineer can say—, 'hey. Non-engineers cannot ever drop databases by this, because now they've worked by this ORM, for example. And so, I think the issue with a lot of these vibe coding products is there are no guardrails, there's no engineer in the picture at all. And so, when there's no guardrails, no higher-level primitives, and it's just outputting raw code, it really is quite dangerous. And so, that's Retool's whole thesis in this sort of vibe coding revolution: is that we think vibe coding is an amazing technology and it's working really well for, I would say, more play or prototype applications, right now. But the real opportunity is if it could transform how internal software—and again, more than half of all software is developed, you really need these guardrails. And if we can provide these guardrails, allow engineers to define these guardrails in a safe way, then non-engineers can actually build pretty interesting applications.
Ryan Donovan: Mm-hmm.
David Hsu: I think maybe one analogy I'll give here is with business intelligence, or BI, which is, today, if you ask any engineer, or you asked me, to go build a BI dashboard, the first thing I would say is, 'oh, let me go use meta base. Lemme go use Tableau. Lemme go use Looker.' I'll use any BI tool.
Ryan Donovan: Right.
David Hsu: And the reason I use BI tool is so I could just focus on the exact thing that I need to write, which is the 10 lines of SQL in order to go build my chart. I don't wanna work with the database drivers, I don't wanna work with the authentication, I don't wanna work with the authorization. I don't even wanna work on the front-end charting components. I just want all that done for me, and all I do is SQL.
Ryan Donovan: Mm-hmm.
David Hsu: And with that, you can actually see now a lot of data people, even non-technical people, can go learn a bit of SQL, and they're able to build pretty compelling charts, and actually go analyze data. And I think that kind of revolution is gonna happen for applications, as well. Today, applications are being built– I mean, it's like, if you vibe coded a BI dashboard, it would probably have bugs all over the place, and no one does that. Everyone just says, 'hey, why don't you vibe code headlines of SQL that have that run on top of Tableau,' for example.
Ryan Donovan: Mm-hmm.
David Hsu: That's kind of what we're trying to do with all applications. That's the idea.
Ryan Donovan: It sounds like we've gone from sandboxing dangerous code to sandboxing dangerous coders, and part of the solution, it seems like you're proposing this greater and greater componentization of the software itself. Is that accurate?
David Hsu: Yes, that's right. And I think the issue is that it's just so low-level today. So, I'll give you an example that I think we as developers might take for granted, which is, let's say that you're building internal tool and you're building a flow, and when you press the submit button in the form, you want to disable that button because you don't want people mashing it five times and submitting the form five times, right?
Ryan Donovan: Right.
David Hsu: You know, very sensible. But to do that in React is actually a lot of work, actually. So, the first thing you need to do is you did import a state management library Redux, probably. Yeah. And so you say, "hey, you know, when I press the button I wanna set 'is fetching to be true,' and then I want to fetch, and then I want to go send the post request. And then when the post request comes back, then 'is fetching is false,'" and so then the button can be enabled again. So, when 'is fetching is true,' the button should be disabled. That's actually a lot of logic actually, if you think about it.
Ryan Donovan: Right. Sure.
David Hsu: At least for internal tools, there's kind of no reason why a button should ever be pressed more than once, if you will. Now, that's not true for all software. If you're in a video game, for example, you can imagine, 'hey, actually mash the button five times.' Maybe it's a good thing, actually. You want people to mash the button five times, for example. And so that's, I think, an example where if you scope the problem down, if you say, 'hey, we're not interested in all software, we're only interested in internal tools or internal credit applications,' you could say, 'hey, buttons should always automatically be disabled upon clicking actually,' and that HTP request is firing up until it's coming back. It should be disabled. So, that's an example where React is almost like Assembly in that way, right? It's not optimized for any particular use case. It's optimized for all of program, just like Assembly, you know, to some extent is. But just like we moved away from Assembly, I think we're gonna move away from React one day, as well, to these higher-level languages. Especially such that these non-engineers are able to not shoot themselves in the foot because the non-engineer does not wanna worry about Redux sustain management. I mean, that's way beyond, even for a lot of programmers, they don't wanna think about functional programming, about how to fold states, you know?
Ryan Donovan: Right. Just disable the button. Whatever you need to do, just disable the button.
David Hsu: Exactly. And so, I think that what you said is correct is that we need higher-level primitives, if you will. We need higher-level ways of doing things in programming instead of just writing Assembly, right?
Ryan Donovan: Yeah. And I wonder, you know, with the sort of LLM-driven vibe coding, code gen, what the possible way to do that is. I could imagine some sort of caching of features, some sort of, you know, retrieval, augmented generation, or something. But I wonder if you have ideas of what the mechanics of that guardrail looks like?
David Hsu: Yeah. So this is what we're doing, so I may be a bit biased here, but I really feel it's gonna unlock, I think, tomorrow's developers. So, to give you an example, one feature we're working on right now is we're calling a 'security engine,' and what the security engine does is it allows you to actually semantically tag data across your organization and then be able to say, 'hey, these certain tables of data, or within that table, these columns or these rows, should never be visible to these certain Okta groups.'
Ryan Donovan: Mm-hmm.
David Hsu: And this actually allows you to get to the point where any application you generate is actually, from a data perspective, at least secure by default. And so, what I mean by that is, today if you give a non-developer, you say, 'hey, here's production access to my database, and you could go crazy, build some vibe, codes of apps,' that's pretty dangerous, right? Whereas, if you can say, 'hey, the SSN column in my user's table should never be viewable by these Okta groups,' then you can say, 'hey, no matter how you build this application, because application runs on the retail platform, we guarantee that the SSN will never be exposed to these Okta groups.' And if you think about it, that's actually a much better way of doing security. You know, you kind of want those guarantees at the data level rather than the 'trust the developer' level. If you think about where security is today, honestly, a lot of security right now is 'trust the developer.'
Ryan Donovan: Right.
David Hsu: And what I mean by that is, you know, it's kinda like, I hope the security vulnerability is caught within a poll request. If it's not caught, it goes to prod, and you might get hacked, actually, or SSNs get leaked, and it happens all the time, actually. And really, I think that's already broken. But you add to that developers that you may not be able to trust, that may not know what they're doing in the future– it really blows up. And so, I think sort of sandboxing, or having these rules that allow developers to operate—or tomorrow's developers to operate—with total freedom, and even when they have total freedom, they still can't mess up. I think that is what it's gonna be, so it's almost like constraints lead to freedom, if you will.
Ryan Donovan: Yeah. Well, how Orwellian. No, it's user access control, right? Like, for your client users, you don't give them access to all data. There's a, you know, an application layer, there's data access, and then this seems like it's sort of gradations of that. You apply that to developers, quote unquote 'developers,' in this case.
David Hsu: Yeah.
Ryan Donovan: So, let's talk about some of the other side of the conversation we started – the greater automation. So, you mentioned automating a song, or something like that. What do you see as the change that has come to software itself?
David Hsu: So, my sense of the software market over the last, let's say 20-30, or so years is that there's been a lot of processes that were fully deterministic. What I mean is, you know, do A, then do B, then do C. If it used to be done by a human 30 years ago, a large majority of those things are now done by software. Not all, so, you know, it's not like we're totally digitally transformed, if you will, but a lot.
Ryan Donovan: Mm-hmm. Yeah.
David Hsu: Pen and paper is starting to go away in more and more industries, so it's pretty clear a lot is being digitized. However, most companies today, when they cannot digitize a process, they insert humans into that process, and so maybe it's a human judgment is required. So, maybe you're extending credit, you're approving a mortgage, maybe you need to verify an ID, for example. And so, the human needs to take a look at the ID and verify is it the right person? It's things like that basically. So, that's one example. Another category of example might be some creativity is required. And so, maybe the first categories are on verification—you don't trust the machine totally. The second is on creativity, which is, 'hey, what is our company's strategy this year?'
Ryan Donovan: Mm-hmm.
David Hsu: I'm calling someone on a sales call, and I need to convince them to buy my product. You know, it's kind of hard to encode that deterministically in software. And so, you have a human; you have human salespeople do it. And I would say creativity is another example. And I think what we're starting to see in our customer base now, today, is that LLMs, especially at these specific tasks, are starting to become very, very effective. And so, for example, to take the sales use case, now SDRs can actually talk on the phone, or I should say LLM SDRs can actually talk on the phone, actually. You know, latency is not amazing right now. It's maybe one or two seconds, but it's actually pretty workable at this point, and technology is only getting better. Latency is gonna go down. It's gonna get to the point where I think that, from a sales perspective, from a support perspective, you can actually go talk to an LLM on the phone to answer your questions about the product, maybe purchase product if you have, you know– it's pretty cool. And so, that's the example where I think that the total addressable market of sort of what software overall can do is probably gonna grow by 3, 4, 5 x, I think. So, an explosion, if you will in software. And previously, I think the question was, ' can I build software to accomplish this task?' The answer was no. Now, a lot of the time, the answer will be yes. And so, I think it's more so than ever before. It's great to be a software engineer, actually, because software engineers are sort of on the forefront of leading this charge on how can we go apply software engineering and LLMs that go solve these pretty fuzzy, vague problems, if you will. So, I think that's a pretty big revolution, and I think we're still so early in it.
Ryan Donovan: Yeah.
David Hsu: I think you're not really seeing LLMS show up in the labor numbers just yet, but I think you will, and once you start seeing it, I think it's gonna be pretty scary, to some extent, but also–
Ryan Donovan: It's gonna be weird times.
David Hsu: Pretty illuminating, another extent. Yeah.
Ryan Donovan: Yeah. You talk about the LLM creativity and I think, you know, it's gonna have some creativity, and it has a pretty good alignment with human preferences overall, but the sort of creativity that produces is like statistically valid, right? It's a data-driven creativity. Do you think LLMs will sort of stay at that? Like, here's the sort of mediocre first draft, or whatever it is, have a domain expert come in, or do you think it's possible for them to get to a domain expert level?
David Hsu: Yeah. Let's see. So, a few thoughts here. What is, I think, on the creativity aspect, I do agree with you. You know, I've never read anything generative about LLM where I'm like, 'wow, that was incredible.' You know? I don't have that feeling yet, at least from a sort of stylistic perspective. But actually, most work is not that highbrow, to be honest.
Ryan Donovan: That's fair. Yeah.
David Hsu: What I mean by that is–
David Hsu: A lot of work is pretty mediocre. Yeah.
David Hsu: Yeah. You know, I, for example, read a lot of fiction and I love fiction, but most work is not, you know, Nobel Prize-winning fiction, if you will. And you know, will LLMs get there? I'm not sure, to be honest, but it doesn't need to get there to generate a lot of economically valuable work. And so, the two things I was gonna say– so, that's one point. The second is that when you scope an LLM down to one particular task, give it the right inputs, what we're seeing with our customer base is that actually does incredibly well, oftentimes better than a human, especially if you include how fast the LLM actually works. And so, to give you an example, one thing that we've started doing Retool is I have a recorder for all of my meetings. I think we use Whisper, and we basically transcribe, at least for all my meetings, I transcribe them, and then I save them, and then, actually, at the end of the day, I can go comb the meetings with an LLM. So, that actually is quite effective. And, you know, in the past, when I would try to use LLMS to do some work, it would be very tough because it would not really have context. It doesn't really know what happened, doesn't really have access to our documents, doesn't really have access to our meetings. But if you give it access to meetings, if you give it access to documents, it actually then has a lot of context. Now, context engineering is pretty tough. You don't wanna give it too much context, so you don't wanna overload it, but if you're able to give it the specific right context, the right documents, the right meeting transcripts, it's actually surprisingly effective. Is it better than me? I mean, honestly, in some cases, it's probably better than me at my job, honestly. But even a case where it's not better than me, maybe it gets to 80% of what I would do, but it does so way faster. And so, when you think about sort of, in some cases, you know, quality does matter.
Ryan Donovan: Mm-hmm.
David Hsu: But a lot of the time, actually, I would very easily accept 80% quality in two minutes. You know, rather than 100% quality in five days, you know? So, I think when we think about it that way, I think when you give the LLM the right inputs, and when you consider what it's doing, not just from a, you know, is the work exactly as good as what I would've produced, but also if you look at the time, if you look at the cost, then it starts looking really pretty scary because, honestly, albums are quite good.
Ryan Donovan: Well, in terms of information retrieval, and summary, and synthesis, it's pretty amazing. I've used it for some research before, too, and it pulls information faster than I could, I'd be digging through stuff–
David Hsu: Same. Yeah.
Ryan Donovan: But, you know, the final draft stuff, that's where I sort of always want a human in the loop, right?
David Hsu: I think a lot of great works, artistically at least, you know, has some sort of surprise element to them, and you know, LLMs are not very surprising right now. So, I agree, I think that final step, but honestly, I don't know if surprise or delight is really a factor of most work being done in a knowledge work setting.
Ryan Donovan: Sure.
David Hsu: You know, when I go read a document, I'm not like, 'that was an awesome document because I was so surprised,' you know, I couldn't necessarily say that.
Ryan Donovan: ' What a delightful feature spec!'
David Hsu: Yeah. I mean, sometimes I do feel that way, but oftentimes, you know, it's like, does it solve the customer problem? And honestly, I think an LLM is gonna do a better job synthesizing customer feedback than any one individual PM, especially when you factor in how much information it synthesizes over, and how fast they can do it.
Ryan Donovan: So, I think your spicy stat from the pitch was 10% of all work would be automated by 2030, I think it was. Can you talk about what work you think that'll be?
David Hsu: So, the context for that is, we have released this product called Agents. So, maybe I'll just explain that very quickly.
Ryan Donovan: Yeah, yeah, sure.
David Hsu: And I'll come back to this. So, what an agent is—this is a standard terminology today in LLM engineering—so, it's what's called a React-style agent. So, it basically reasons and it acts. And so, it reasons by, you know, basically, you give it some input and you say, 'hey, your goals transform this input into this output,' basically, and you are given these tools to do so. And so, the LLM basically thinks, you know, 'how do I get from this input to this output?' It's like, 'okay, well, you know, given these tools would be apply this tool first, then I apply this tool, then I apply this tool, and then maybe I'll get to my output.' The really cool thing about this that was not possible before LLMs, at least, is that this is actually not deterministic. Before you could have workflows, you could say, 'hey, you know, do A, do B, then do C, and A is computational. You know, B is computation, C is computation.' And yes, you know, that's just code, right? Run it top to bottom. Now, with this LLM, with agents at least, you have these tools, and you think about what tools you should use to accomplish this outcome. And that's, you know, a pretty weird engineering way of thinking about it.
Ryan Donovan: Sure.
David Hsu: It's kind of what a human does. If you asked a human to say, 'hey, go solve the support ticket,' the human would say, 'okay, well, what tools do I have in my disposal?' Or, 'hey, go run this company's strategy.' The human would think, 'okay, well,' let's say I'm a consultant, you know, I work at McKinsey, I'm like, 'okay, how do I run this company strategy?' Well, probably first, I want to gather data. I wanna understand the current strategy. Is it working? Is it not working? So, then I look at the data, and then I say, 'okay, well what's the competition doing?' You know, so, maybe I look up a competitive research tool, you know, do web search, whatever it is, and then eventually, I use a writing tool to go produce the end result, basically. And so, that's the product, basically. We think it's quite remarkable, and it's actually growing very quickly. And on the current rate, it's growing at, we expect to automate actually 10% of US labor by 2030, actually using this product.
Ryan Donovan: Right.
David Hsu: So, that's pretty cool. But what I mean specifically by that is—I suppose you know why it's growing so quickly, is—I think a lot of work, if you think about it, can basically be broken down in this way. And here's an, I think, example that would really resonate with a Stack Overflow audience is if you think about why applications like Cursor and Claude Code are so effective, the reason is that they are agentic, autonomous. And they have tools. And what I mean by that is you could actually do everything that Claude Code does just with the ChatGPT application, right? So, you could say, 'hey, you know, ChatGPT, write me this code.' It writes you the code, you copy it, you paste it to your IDE, you run it, you get an error, you copy the error back, you go to ChatGPT, you say, 'I got this error. This is still a problem. Do this again.' And so, you know, you're kind of going back and forth. Now, actually, that is what Claude Code basically is doing. But Claude Code is doing the copy page– it's not doing any copy because they're writing directly the IDE, but the idea, basically, is that it is able to just do things for you on your behalf. And then, it realizes that if you're telling it, 'hey, you know, I ran it and got an error,' it runs it itself. It's like, 'oh, I got an error, so lemme go do something.' And so, I think the remarkable thing-– this is why it's, I think, most developed in a test, Crystal or Claude Code is so much more effective than copy-pasting out to ChatGPT.
Ryan Donovan: Right.
David Hsu: But if you think about most knowledge work today, the way that most people use ChatGPT—most knowledge workers use chat, myself included—is we're copy and pasting in and outta ChatGPT all the time. And so, if you could imagine bringing something like an agentic, let's say, Claude Code way of doing things, but you attach it to all the context you have, you attach it to Google Docs, you attach it to all the tools, you have all the systems, Salesforce, you attach it to service stuff, attach to all the systems that you use, then you could almost imagine there's a similar revolution to be had, if you will, for all other jobs, not just software engineering. And that's basically what Retool agents, the product, is. So, we allow you to go custom build tools, and then now LLMS to actually go use those tools to actually go do things in your business. And so, there, if you think about it that way, the software developer's job, I think, has changed so much over the last six to 12 months. I think that similar revolution is gonna happen very quickly in the next 18 months to all of the jobs once we empower software engineers to be able to build these kinds of agents, which is what our product is designed to do.
Ryan Donovan: Yeah. I mean, to go back to something you said earlier, it does sound like there's gonna be a slightly scary reconfiguration of what work is for, you know, folks like us. So, you know, hopefully, we'll all come out the other end. There'll be, you know, political solution for technological turmoil.
David Hsu: I'm honestly a little worried about it because I think you see some of the consequences of manufacturing jobs disappearing in the US, and now maybe they'll come back. We'll see. Whether or not it's a good thing, I'm not sure. But if knowledge work disappears in the US, I mean, we're not left with much. You know, if the service economy is gone, then there's not too much. So yeah, we'll see. I think it's a scary time, but I think that for the next few years, at least, I think software engineers will have so much work cut out for them, because all this stuff will need to be built by software computers.
Ryan Donovan: It is the time of the show where we shout out somebody who came onto Stack Overflow, dropped some knowledge, shared some curiosity, earned themselves a badge. Today, we're shouting out the winner of a populous badge- somebody who dropped an answer that was so good, it outscored the accepted answer. So, congrats to Waseem Wisa for answering 'Sass compiler throws 'undefined mixin' error when mixins are kept in seperate folder.' If you're curious about that, we will have an answer for you in the show notes. I'm Ryan Donovan. I edit the blog host of the podcast here at Stack Overflow. If you have comments, concerns, topics to cover, please email me at podcast@stackoverflow.com, and if you wanna reach out to me directly, you can find me on LinkedIn.
David Hsu: I'm David Chu, CEO of Retool. If you wanna find me online, I'm D-V-D-H-S-U on Twitter, retool.com is where you can find Retool, as well. Thank you for having me.
Ryan Donovan: All right. Thank you very much everyone for listening, and we'll talk to you next time.