Y Combinator Startup Podcast - Replit CEO Amjad Masad: Coding Agents, Autonomy, and the Future of Work

Episode Date: July 22, 2025

Amjad Masad started Replit to make programming accessible to anyone, anywhere. What began as a tool for learning to code has grown into a platform pushing the limits of AI-assisted software creation and recently surpassed $100M in ARR.On The Breakdown with Tom and Dave, Amjad shares the journey from his early days in Jordan, working on open-source projects, to leading Replit through major pivots from "teach a billion people to code" to "let anyone build software." He discusses the evolving nature of programming, the future of work, and the next generation of human-computer collaboration.

I think that like dystopian view of AI or AI as like taking all our jobs and all of that is like not correct. And I think the future of work is more human, is more interactive, is more multimodal. Once the making of things gets easier, the bottleneck goes back to like how many ideas you can have. I wouldn't put learning code as the top thing. I would put learn to make things. Learn to make things with code, learn and make things with video, learn to make like anything with AI. Welcome back to The Breakdown. I'm Dave, this is Tom, and today we're joined by Amjad Massad. Amjad is founder and CEO of Replit, which was a YC 2018 company.

Welcome to the show. Thank you. So today we want to talk about kind of your beginnings in helping people learn to code, what you're doing now in replacing a lot of that work, and then where we see the future going in terms of how people make things. So Replit started, I guess, in 2016. You were in YC in 2018. You started out as a tool to make it really easy for people learning to program

to set up development environments purely on the web. But now you're really taking off in AI-assisted coding. Tell us the latest. Yeah, so the mission has always been to make programming more accessible. Then we sort of, you know, after YC, we sort of updated it to be a little more ambitious. We start talking about a billion software developers. And it just sounded absurd at the time. And this was all pre-11.

right? Yeah, Priil, there was a moment of time, I don't know if you remember that, but in the 2015 AI hype, there was like a bit of an LP, natural language hype as well. There's a bunch of AI companies that ended up being just like humans behind the scene. They all went broke, but there was like a glimpse of potentially doing NLP on code. So we had an idea that, you know, it's probably coming. I even had it in my in my seed deck that like at some point, like we'll collect enough data to like trained models. It wasn't until like GPT2 in 2020 that it felt it felt like it was going to be possible. So we, you know, we had we had built all these primitives like the development environment, the sort of hosting environment, all the other stuff around it. And it felt like if we just

like added like AI agents, like it will be able to orchestrate all this stuff and it'll be, it'll be really great. But agents were like every time we tried them, I think the first time we tried like 2021, didn't work, 22, it didn't work. And then 2024, like, early in the year, we just felt like it's getting close. Even GPT40 could, like, be coherent for, like, two minutes. Somehow just ended up doing a big bet. The company was not doing super well.

Yeah, I was about to ask, was there like a bet the company moment where it's like we were teaching people to code? Now we're no longer doing that. Now we're going to enable everyone to build apps. Yeah, yeah, yeah. We had grown the company quite a bit. and we were burning way too much money,

and we decided to do a layoff. And so we cut perhaps 50 people, and then another 15, 20 people left. And so we were like less than half of the company. And so I just put everything on a rep, that agent. I just felt like this is the thing. It has to work. It felt like it was close.

I don't know. I was just like burned the boat's kind of moments. It's just like, we got to do this. I mean, it's, I felt like this was, the thing that would make the company work. And honestly, like if Claw 3.5 hadn't come out mid-us building agent, we would have probably failed. Because like I said, like, GPT-40 would stay coherent for two or three minutes. Claude 3.5 was the first one that like could work for like, you know, five to 10 minutes and actually, actually were. And the co-generations are.

And that's sort of the approach that I think is most successful for startups, kind of building on the very edge of what is possible. You start out on a mission. It's like, the technology is not quite there yet. You start building and you sort of, you skate with the puck is going. Yeah. It sort of catches up with you. Yeah. And you want to keep, keep doing that. Totally. Yeah. Yeah. Yeah. I remember you came to speak at YC like six months ago right after you had launched this. And at the time, you said, we're very far from fully automated software development. Do you still feel that way? No, not at all. I mean, I feel like I've, you know, every time I make sort of some kind of prediction, it feels like bold and like, you know,

But I've been consistently wrong and the way things are moving is a lot faster. Just the level of autonomy. Like I said, like maybe 3.5 was like 5 to 10 minutes, like 3.7 perhaps can get up to like four to five minutes an hour. The 4.0 in the system card and opus, they said they made it work for seven hours. Wow. Seven hours. That's incredible.

That's always been the limiting factor for making agents. is like, can they stay coherent? Is the context length actually useful to reason over? If an LLM can work for seven hours, that's basically like a human worker. Yeah, and presumably they're working at much faster speed than a human would do. So they're kind of completing perhaps a week's work in those seven hours. The only thing that I think is missing at a big limiting factor for actually automating a lot of work is computer use. Computer use kind of sucks.

Yeah. I'm sure you've tried it. And this is the difference between Replit agents. really giving it one prompt going all the way in an app versus having to kind of babysit it a little bit and like test with it. We had a company in the last batch called browser use that's work in browser automation. And another one called Pig, which is doing the same for Windows desktops.

And I think advice I would give founders today is taking either browser use or that Windows automation with Pig and trying to apply that into enterprise into a vertical industry. The moment the technology works, those two companies, are just going to... Totally. And I think we're like weeks or perhaps single-digit months away from it working really, really well. And so now is the time to get started using those technologies. Absolutely, 100%. And this is what we're focused on. So, you know, Replit Agent V1, V2 was a huge jump in autonomy. V3 is the most autonomous thing. So we're already working on it. And the interesting thing for us is the

underlying technology and how it would enable autonomy. There are like a few important things. One is you know, being transactional, the ability to roll back is very important. So you would want, you'd want it to be safe for agents in the same way that GITs made it safe for human programmers to kind of experiments and create branches, whatever. You want the same thing for agents. Like if an agent kind of messes up a DB migration, it should be able to roll back. And also it should be able to sample across different paths. I think this is very, very important for autonomy. me. If you look at, like, for example, when Anthropic publishes their Swee Bench score, they publish one with that sampling and one with sampling, and it goes from 70% to 80%.

And so this is the idea that you sort of, you spawn multiple agents. Each one will take a shot at it, and then you figure out which one works and choose that branch effectively. Yeah, we built a infrastructure that is fully transactional and moves in lockstep, meaning the file system is a snapshot based file system. The DB is a snapshot based DB. And so as you're, we're making commits to the entire system, including the virtual machine as you're going. And so what we can do is also we can we can fork it and branch it out. So if we had computer use that's working well, you can you can just like right now what they do with the sampling is they do, they have some kind of judge that does ranking, which, you know,

It's not a true verifier. A true verifier is a test, right? And a computer-use test. So you can sample out and really pick the best branch that's actually working. That's incredible. And repeat that on and on, and reliability gets really, really high. So fast forward six or 12 months. You're not spawning one agent.

You're spawning, is it five or ten or a million? Like how does it? I think this is where it's going to get interesting, which is you'd want to give the user the ability to set to compute budgets. I think we're starting to see that with the O-style models of like, here's how much budget. But look, I mean, if you give us $1,000, we'll spend them. If you get it. That's really cool. I've not thought of that before.

But the idea of like spawning multiple branches and then just picking the best one. And being able to do that in parallel. The human brain doesn't naturally work like that. We think sequentially. We can't. It reminds me of this legend. I don't know if this is actually true. But at Apple, when Steve was running it, he would intentionally have teams doing basically the same things.

and then see which one did the best job. It's like, I've heard opening I does that now. Interesting. I've heard that like the Codex project like had multiple different teams. So in the literature, you'll see that small models sampled

will beat larger models. So Sonnet sampled is probably better than opus. Companies haven't tried that where instead of hiring one senior engineer, you hire like 10 junior engineers. They're like giving them the same task. And then. It's just very expensive with humans, but with LLMs, it's relatively cheap.

You can just do that. Do a hundred of them and just pick the best one every time. So how are people using Replit Agent? And who are the people using it? You know, it goes back to sort of our early vision that if you make programming easy, then more and more people would want to do it. Actually, this is one of the first thing that PG and I sort of connected on. Before we got into YC, actually, PG found us on Hacker News.

And so we started this email relationship. And so he told me there's like a super linear relationship with how easy programming is versus how many people would want to do it. The optimizing function of RAPLIT has always been like just keep lowering the barrier to entry. And that's how you grow users and you grow customers. Right now, basically people from kind of every walk of life we've seen users. Product managers tend to be a very great use case and users for us. And we've had customers, product managers, who are able to make significant impact on the business without talking to engineers at all, like running AB tests or optimizations or things

like that. I mean, it's empowering. I mean, it gets us to think about the really the seams between these roles, like, you know, product manager, designer, engineer. We actually just created a new product group. And typically, you know, product, you know, head of product has a bunch of like product managers reporting with them. But we're actually having, this group has designers, engineers, and PMs.

And the ideas that are all using AI all the time to prototype. In some cases, go all the way to production. There isn't this sort of waterfall model where, you know, there's a lot of inefficiency, you know, communication problems between these different teams. they can move incredibly fast. I think that starts to change how tech companies work. My experience of this was whenever I was working a startup, the list of ideas and the backlog would always be infinitely long, basically,

in the bottomnet was always engineering time. And now I'm doing my own personal projects. I write my to do list or my idea list, and then I get to work and the idea just get done. And suddenly the bottleneck is like my ability to have ideas. Yeah, yeah. And it's just such a weird experience looking at a to-do list. It's just empty being like, what do I do next?

I've heard from a team that has like a really large Rapplet deployment in their company that their founders using Rapplet. And that's stressing the engineers out because, oh, I did this in a weekend. Like, can't you do it? What are you guys a show for yourself? And so are these previously technical people or non-technical people, they're building the first version? Are they deploying that production or are they giving it to engineers and say, hey, build this?

Like, what do you see typically? We advise to like work with engineering, but that doesn't always happen. I think it's understandable that a lot of PMs and designers want to go straight to users. What we're seeing is they go to like beta users and test users, and I think this works really well. But in some cases, they just like put it in production. And so right now we're having discussions with all these companies, especially the engineering leaders are unhappy about this. Like who's on call for these services?

Who's responsible for the bug? Who's responsible for it? There's a lot of questions that are coming up. The obvious answer to all these questions is like agents. responsible. So what's the limiting factor today? I buy code a thing and I'm like yoloing into production. Like what are what are the engineers typically object? Like what's going wrong? Security is a big one like LLMs are fallible like like humans are. They tend to write some there's some components that they do terribly at. Like for example off like they all kind of suck out. They all

use like, you know, old methods of assaulting and hashing. And so that's been, that's been a big sticking point. And we've seen a lot of examples out there right now of some catastrophes. Luckily, it hasn't been, like, there hasn't been a major catastrophe. I think it's coming. But there's been like solo founders who would leak, you know, API keys or would make it really easier to get around the login, security protections. And there are a lot of tools out there that are, like, really not trying to take responsibility for that and saying, oh, it's the user's problem, the user's fault. For us, we think that as a platform that is marketing

for the non-developer, you actually have a responsibility. We're trying to take away some of the things that we think LMs should not do today. So off, for example, we have a built-in off. So if you go to Rappler and just say, add off, it will pull in an off component that we built from scratch. It has CAPTC on it, it has all the security bells and whistles, so you don't have to worry about all of that. We integrate with your database. You have a user management portal on your site.

As much as possible, building it in these components that are tricky, I think payments are the other one. I don't think you'd want the LLMs to kind of do the payments. And they're not that different, right? Like the sort of checkout, you know, you might have a one-time checkout, you might have subscription, pay as you go. But they're not unlimited versions of payments. So there's like two or three or four. And this is, the analogy is today humans don't write their own version of payments or their own version of off. They use providers that have built these components already.

So it seems like we're seeing the same thing play out. And that's the best way to do it. Yeah, 100%. And then the other thing we added, we partnered with as a great security company called Semcrup. And so right now, when you go to deploy a Replit app, we run a security scan. We run a code security scan. And we give you like a report of warnings and errors and things like that. and the agents can try to fix them for you.

Okay, and so security is one of the big kind of bottlenecks to fully deploy into production. I can imagine there must be other things that coming down the line, like sort of scalability, looking for like N plus one database queries, performance bottlenecks. What do you have in your mind like a clear set of blockers that need to be overcome before this is truly like one click to deploy? Yeah, I mean the biggest one is just going to be humans like social. Like, you know, there's just going to be mistrust. And I think it's just going to have. has to play out. So, you know, leaving that aside, like, enterprises has to adapt to all of

this stuff. Having some way to also scan for scalability, like figuring out, you know, like doing fuzzling or whatever it is or having some kind of adversarial agent that's, you know, trying to break your app. I think, you know, that's one big thing. I think integrating with the company's ecosystem. So one thing we're adding is the ability to bring in your design system. That's cool. So in addition to kind of us providing these components, if you go in any company, they have a lot of these components built out. As RAPL is getting deployed into these large companies, how can we hook into their internal systems? This makes me think about the kind of spectrum of these different coding tools. On one of the spectrum, you have kind of what I would call the power tools, the cursors, the windsurf that let developers use this as a way to amplify their efforts.

And on the full other end of the spectrum, you have more of the like consumer facing, hey, if you're want to make an app, like you can now make an app. And it sounds like you guys are kind of in the middle. You're helping companies get stuff done, but you're doing it for people who don't look like the traditional developer. How do you see this world playing out? Are there going to be in different tools or will we converge to one place on that spectrum? AGI is a convergence, obviously. But leaving that aside, it's really hard to plan for that world. I think that the battle for how to incrementally make engineers more productive is just, it's an obvious one. The market there is obvious.

There's a lot of companies going after it. Both the application companies like Curser, the underlying model companies are trying to go there. I mean, you know, Clod code is competing with Curser. Curser uses a clod. I think it's a bit of a bloodbath there. But the market is obvious and the market is really large. I would guess that there's going to be more of a consolidation there. Maybe it's not one, but it's probably two or three at best.

I think the sort of the market we're in is a lot larger. So the addressable humans is a lot more. We're talking about a billion, but it could be more. Like really any knowledge worker should be able to solve problems with software. My conception of Replit right now is what we want it to be as the universal problem solver. you'll solve problems in your personal lives or, you know, solve problems in your work and all of that. And so I think that market is, it will probably be like a little more diverse and I think companies will kind of figure out where they slot in. We're trying to

solve autonomous programming with the focus on the non-engineer. We want you to not worry about security, not worry about systems, not worry about any of that. We want you to really come in with your ideas to replet and be an agent's manager. And we're trying to do it in a way that is like as human as possible and it kind of fits into into the workflow. One big difference between engineers and sort of non-engineers, be it executives or product managers, you're not on your desk like eight hours a day. Mobile is a big part of that.

We have like a really great mobile app and we're thinking about this way of like ambience building. Maybe you start an app on your in your desktop. go away with your phone, you're in boring meeting, you get a notification from the agent saying, you know, I'm done with this, do you want something else? You get out of texted. And so we're trying to kind of build that thing. Yes, a question I had related to that point is about the user interface. So for something like cursor or windsurf, it's pretty obvious. The primary UI element is like the code. You see code, you have a little chat window, but primarily it's about diffs. It's about

kind of changes to code. And for a tool like Replit, the primary interface is like the graphical user interface. You know, it's the buttons and the fonts. Whizzy wig? Yeah. You see what you're building. Exactly. And that's great for building user interfaces.

But when you're trying to build more complicated sort of logical flows, I found it a little bit difficult because I couldn't, there was no way I couldn't see the code. I can't visualize what's going on behind the scenes and it's sort of, it's almost a black box. Fast forwarding here, if you're trying to build more complex internal workflows, how do they, how does a product manager or an operations manager or a big company visualize that workflow and kind of logical branching that happens. Yeah. So if you look back in the history of computing, there was always this vision of visual programming. It never worked very well because ultimately it's about Turing completeness.

Like these systems are not universal computing devices. And now we go to Kodgen. Obviously Kodgen is Turing complete, but you're interfacing with it primarily via natural language. Natural language is fuzzy. It's really hard to know whether it's It's doing the right thing. I think the synthesis of these two things is probably coming where you are interfacing with natural language, but you can, instead of like just staring at code, there's maybe an interface or like a different view on top of code. You can imagine being able to, do you know small talk?

Yeah, so small talk is this. It's the first object-oriented programming system. and, you know, Alan Cave would say it's like, it is actually OOP where everything comes after it is not. But the interesting thing about it in small talk, you can actually, the way you interact with code is not via files, but via objects, via like logical objects. And so there's some kind of prior arc there. And I think the world we're headed in where there's some kind of abstraction over

code that allows people to like understand it. Yeah, I think that's really interesting. There's something, there's like an open space there, whether it's like pseudo code, which looks like English, but it's a little bit more structured or a visual drag and drop. I don't know if it's... Yeah, I think back to building products with a team of engineers, designers, and other folks, the interactions that I would have as the product lead with those teams was verbal. It would be written, like abstracted ideas.

We would draw stuff on the whiteboard together. We'd make system diagrams. We'd look at the results of the app, and we would test it and point out, like, oh, this thing is broken. That's too slow. And it feels to me like that sort of interface. which is very multimodal and very flexible, is probably the best end result. Like, I think we will get to something like that

where the author of products will be doing that, but the teams they're talking to are not other humans, their agents doing these things. Has there been an attempt in sort of PM land to have a little more formalism around communication? Yes, and I would not say it's been good. The main thing is just like the PRD, right? The product spec, right?

And it's just become, in my opinion, oftentimes a performative work artifact that you create just so that you can have a thing to get your promotion, right, if you're at a big company. But they're not actually that useful. To me, the most useful interactions are just these like whiteboard conversations, right? What do we want it to do here? Oh, we got to think about that. Oh, we didn't consider this.

Okay, let's rethink this whole thing. Like those sorts of conversations. Yeah, I can play a role in that as well. So I, you know, this sort of granola that allows you to kind of record meetings and they released this like team version that like all the meetings gets transcribed and go there. And they have a mobile app right now where like you can put on the table and like it's trying so. So I was thinking maybe we should go granola maximalism where look you shouldn't fight the trend in which companies are becoming increasingly oral as supposed to like written.

And because like you know people are talking on Slack, people are in meetings, people like are communicating via prompts with agents. But you would want a set of AI tools that is actually like creating that, that, that record in the background that's like searchable and organizable and all of that. Yeah. I wonder when we'll have our first AI in, like, all of meetings. You know, you're jamming with your designer and the AI like chips in and says, well, how about this idea?

Yeah. And this is where I think the like dystopian view of AI or AI as like, taking in all our jobs and all of that is like not correct. And I think the future of work is more human, is more interactive, is more multimodal, is more fun in my opinion. YC's next batch is now taking applications. Got a startup in you. Apply at Ycombinator.com slash apply.

It's never too early. And filling out the app will level up your idea. Okay, back to the video. All right. So last time we chatted, you had launched Replit Agent and things were growing really crazy. I imagine that has continued. Anything you can share there? Maybe soon we'll share some numbers, but since Rapid Agent launch, we're growing 45% compound monthly average. These are like metrics that we tell YC companies during the batch when they have a base of like no users to try to achieve.

And you're doing this at larger scale. Yes. But you know, it put a lot of strain on the company. Our systems were still relatively small. I feel like it can get to your head and you can start optimizing. for the wrong thing. It's very easy in AI to increase ARR while users are not happy because they're spending a lot more and not getting the results. And in some cases, maybe it shouldn't grow that fast because you'd want users to get a better experience for less money. So it's one thing that we

try not to obsess. We actually don't have ARR goals at Replit. We have more product goals, retention goals, just like other methods. Yeah, I consider the sort of bad pattern with some AI company. You grow top line revenue very, very quickly, but the churn is like approaching 100%. And eventually that just catches up. And the gross margins are horrible, too. And so it's like, you know, the more growth you have, the worst the company is doing financially. So how do investors see this space? You must have talked with a bunch.

Can they tell the difference? It's all kind of a blur for them. Because investors, when they, I mean, I'm just going to generalize here, but when they start looking at that space, they'll use everything for three minutes. And everything for three minutes looks the same. So I think it will start to clarify and these products will start to, as opposed to, converge, diverge more with the different focuses in the areas we're talking about. I think over the next year, it'll be like a little more clearer. But I think a lot of them are just like, you know, super, when we're talking to them, they're super confused.

They don't understand these systems. They don't understand where they're going. I think that's a great segue into the sort of technology underlying some of these tools. I'd love to dig in a little bit deeper. We've seen some announcements from cursor and windsurf about how they're kind of layering, whether it's Claude or Gemini or the Open AI models, with then their own layers on top,

the fast-apply APIs, stuff like that, fast-apply models, I guess. Can you give us an overview of how it works at Replit? Yeah. A lot of it is you're patching problems with the underlying frontier models. Yeah. So the reason fast supply was important

because none of the models were doing it very well, at diffs. Can you explain what what supply is? When you're trying to like edit a file as an LLM, the best thing to do is to like create a, create a diff. But these models are actually not very good at creating nifts. They're actually not very good at counting the lines in the source code. So they get confused about a lot of these things.

So for a while a lot of companies were just like rewriting the entire entire file. And so diff for non-technal users is sort of like remove these three lines and inject these other three lines instead. So find and replace almost. That's right. That's right. And so you needed some way to make the model generate something of a diff, but it's actually not good enough to merge it. And so you need another model to actually do the merch. Instead of rewriting like it's a thousand line file, just like output the entire thousand lines. It's very slow. It's very expensive. So you prompt the model to be as lazy as possible.

But in that case, it's really hard to apply. So you need another model. that's like doing the application. You can train a model or you can use Gemini Flash or some of these smaller, smaller models. And so in some cases, you need to train a model or fine-tune a model to do a better job at it. In other cases, you just also patch a bunch of other models to do it. It's engineering. It's engineering as supposed to like research, I would say. And I noticed you guys don't expose the underlying model to the user with other tools like

Kirst and WinSurf. There's a drop-down. It's like, I want to, you know, let's just... see what Gemini thinks of this problem. You don't do that. Why is that? A big part of our research efforts is in e-vals. And I think this is like an underrated part of like, you know, AI coding.

So we spend a ton of time evalling new models, writing evils, generating evils, just data crunching, trying to figure out what the users are getting or feeling. We built a lot of systems to try to understand how these systems are performing. The moment of New Frontier model lands, we are evaluating almost immediately. Jim and I, for example, like a couple months ago, we're making the rounds. Really great model. Really awesome at like one-shotting, in some cases better than Claude. Egentic work wasn't like a tool calling at, you know, some of the things like that.

But users just see the hype and they're like, oh, like, give me Gemini. How much notice do you have? Do they like drop it on you and you're like scrambling? Or do you have like days or weeks before that to try to, you know, test it out? Well, we have good partnerships with these companies. We have a great partnership with Google. We have a great partnership with Anthropic. Even with Open AI, we have a close relationship.

So a lot of them give us a heads up, give us some early checkpoints. And we try, we kind of play with all of them. And in the case of Anthropic, we're always like the first day kind of launching because we end up building. A lot of times we're sort of, and spinning where they're going. Yeah. Because you kind of like, you can tell like three. 3.5, 3.7, there's some direction. You could tell like where 4.0 is going to land. It's so you start architecting the systems. But, you know, ultimately a lot of our engineering efforts still infrastructure.

Like the distributed network file system, the snapshot based network file system, like it took us two years to build. Like there's nothing off the shelf to do that. A lot of the security stuff is really, really difficult. Like Replit is one of the few places in the world where you can get like a virtual machine in the cloud, you know, by just like creating an account. And there's like a, it's really hard to kind of run this and protect against us. You have crypto miners, you have all sorts of stuff like that. And Replit also uses Nix OS under the hood. Nix OS is a like fully declarative, also transactional operating system generator, as it were.

We have like this multi-terabyte hard drive in all the different regions that we have compute that that that cached all the packages in the, in the world. world and that gets attached to every container. And again, all of that, I mean, I keep coming back to this idea of transactionality. Like, you would want the system to be fully functional. You would want it to be, you would want it to be safe in order to like experiment with something, go back, do the sampling with agents. So really a lot of the, a lot of the work is just like the engineering of this infrastructure.

And it's like not as a parent, not as sexy as sort of like, we're trained this model. here's the, but I think this is where you can build like a bit of a lead. Yeah, when VCs talk about moats, the thing that I translate it to in my head is what is the compounding advantage that you might be able to achieve, right? It's not really a defensive moat. It's more just, I'm ahead. And by being ahead in some vector, it allows me to continue to move faster. That's right.

And it sounds like this is a great example of that. True moats are often not obvious until like decades, perhaps many decades into the company. you would have to know what Netflix is mode, but obviously they have one. Like Disney tried to compete with them and everyone was like, you know, down on Netflix, but turned out they have a mode as this content production system that they built. So, Amjad, you started with the mission of like making it easier for people to learn to code. You've accomplished a lot of that. Now you're pushing the envelope of what it even means to code.

I've got young kids. I want them to be productive creators in the world. What should I tell them? to do. Should they learn to code? What does that even mean? Look, I think if you want to go the like professional software developer route, I think getting a computer science degree and like learning fundamentals makes sense. But if you want to be a creator, if you want to be a journalist in this world, I don't think it's necessary anymore to learn a code in the more like traditional ways of learning the code. I think you pick it up by osmosis almost. Like go to replet and, you know,

and start using it. And at some point, you're going to run into some issue where you're going to have to look at code or you're going to have to look at logs. Just by being resourceful, having to Google around and all that, you'll start picking it up. And by the way, this is how our generation kind of learned how to code. When you were talking, I'm like, that's what I did.

Yeah. Yeah, and somehow it just became very industrial and very formal over the years. Like, the way we made web apps is like you just like start a notepad with a, you know, HTML file and now you have to like learn like webpack or whatever. It's like, so I think the future of work is not really clear. What is, you know, we can sort of like have some, like, you know, idea of like where the world is headed. And so with my children, I want them to have like as broad, based knowledge as possible. I want them to be as generalist as possible.

I want them to be as generative as possible, like being able to, like, create a lot of ideas. Because once the making of things gets easier, the ball and like, goes back to like how many ideas you can have. And so I wouldn't put learning code as the top thing. I would put learn to make things. Learn to make things with code. Learn and make things with video. Learn to make like anything with AI. And so what do you think happens with SaaS generally? If we're very soon able to say, create me a version of Google Calendar or clone docket sign, What happens to SaaS, do you think? We have stories today of a lot of people replacing hundreds of thousands of dollars worth of SaaS with Replit.

They heard a story from someone who, you know, they got quoted $150,000 for a piece of software. He went and made it in Replit, sold it to his employer for $32,000, cost him $400. dollars. Companies that have a platform developer community around it and plug in an ecosystem and things like that, I think those are safe. You're not going to be able to vibe code Salesforce. I think the vertical SaaS is in trouble. And I think it's already, my guess, it's already probably showing in some of the metrics. Okay. Last question. What advice would you give to founders starting out right now? You know, the best advice is what we, what you actually pointed out earlier is work on the edge of what's possible because one evolution of AI

or models will make your business viable and sell only your first in the market. I find it rare to see founders that are actually like sitting down trying to actually predict the future and maybe that's something that was ill-advised in the past, but I think right now trying to actually figure out where things are headed is very, very important skill to have. So like make some prediction, figure out like how to create a like a crappy product that would get better immediately as you switch the model. I mean, computer use is a great example. It's been absolute pleasure, I'm Judd. Thank you so much for coming on. Pleasure. Thank you. See you next time. Thanks.