The Future of Software Creation with Replit CEO Amjad Masad

**Amjad Masad** (0:00)
I was asked to talk about the future of software. So a lot of this talk is going to be about what we're doing at Replit, where we think the future software is headed, and some kind of trying to make some predictions or try to think out loud about really what the future holds. My mental model for our business and really for the moment we're in today, if you think back on the future, on the history of computing, mainframes were kind of the first mainstream computing devices, as mainstream as it gets back then. And to use a mainframe, you needed to be an expert. And then PCs came around, and initially PCs were kind of toys. You bought a Mac and you did Mac paint and things like that. There wasn't real business use case. I mean, people like made fun of Apple at the time.
Until the Excel Sheet. The Excel Sheet was the first software that was actually useful on computers. And now PCs run world economy. Like they, actually if you go to a data center, it's also only PCs. It's x86 computers. So you go from something that was used by a small group of experts that had to have a lot of training to something that started sort of as a toy and is used by everyone. Same thing with software engineering. Like the modern software engineering career, you can sort of trace it back to the 70s with the rise of maybe Unix and the C programming language. That's when people started kind of being trained to become software engineers. You still needed four, five, six years of college education. You need another two or three years of training on the job to be able to actually do the job very well. I think today, software is going through the same transition from something that only experts do to something that anyone can do.
And this is what we're really building Replit for. I've been working in Replit for like almost nine years now, and our vision has always been to solve programming, to make programming, make it so that anyone can write software. So we built an IDE, we built language runtimes, we built an online sandbox environment, we built deployments, we built cloud services around all of that. And then when AI came on the scene, we realized that the ultimate expression of our mission is to make it so that you don't have to code. Code is the sort of bottleneck to actually getting a lot more people making software. So around, you know, late 23, early 24, we decided to put all our resources into agents. At the time, agents sort of barely worked, but you could tell by looking at a few benchmarks that were headed there. So SuiBench is a software engineering benchmark. It is basically a collection of issues on GitHub from major repositories, and the unit tests and pull requests sort of end state of those issues. And the way you test an agent is you put it in an environment and have it solve some of those issues. You could tell, like, in 22, sort of, it barely worked. 23 started sort of working. And you could tell early, sort of early 24, we were on this trend where you could tell that software engineering is getting automated, or, like, big parts of software engineering is getting automated. And now we're probably, I think this is, like, a little outdated. We're, like, at 70, 80% sweet bench. Now, if this benchmark gets saturated, it doesn't mean that we automated all of software engineering. But we're on our way to make really useful, arguably, it's already here, really useful software engineering agents. And by the way, this is true of any agent. If any of you are building sort of agents' startups, just like really believe that it's coming, really, really. Like, I keep telling my team we need to be okay with building crappy products today. Because two months down the line, the models will get better, and your business, your product will suddenly become viable. So today's kind of the moment for agents. So Replit kind of went all in on agents. But agents that can write code is actually the easy part. The hard part is the infrastructure around it. Sometimes I call it the habitat for which the agent lives in. So what you need is you need a virtual machine, ideally in the cloud, ideally not on your computer, because agents can actually also mess up your computer. They could do a lot of scary things. So it needs to be sandboxed. It needs to be scalable. If you're running a product like Replit, you need to be able to scale up to millions of users. And you need to be able to support every language out there, every package out there. The way software engineering agents are trained today is they're trained on standard Linux environment. They need to be able to use the shell. They need to be able to write to files, read files. But they also need to be able to install packages, either system level packages, Linux packages, but also language packages. In many cases, agents want to actually use more programming languages. And so a lot of environments today where people are trying to build agents are very constrained. But what you want is an environment as open as possible, similar to the kind of environments that software engineers work in. So what kind of other things you need to ship real software? You need deployments, you need databases. Really think about everything you do as a software engineer, and all those tools need to be accessible to software engineering agents. So actually, I saw early today, if you were at Karpathy's talk, he talked about how the coding part is the easy part, so similar to the points of making. But he talked about all the different things that are really unsolved. But in reality, we actually solved a lot of them. So Replit out of the gate comes with auth. Agents are actually not very good authentication. It's better to use a service, built-in service. So Replit, actually one line of code, we turn on auth. So when you ask Replit agent to integrate auth, it will actually just use Replit auth. It will just like basically turn on a setting. And then you have user authentication, you have user management. Those users information are being stored in the database. You can also obviously deploy the app. You can link a domain to it. We have secrets management, secure ways of kind of using API keys. We have background jobs. You know, a lot of applications need to be able to run continuously in the background, especially in this era of agents. Storage, again, you know, agents need to be able to store things. They need to be able to grab things from the web, images, documentation, whatever, and store them for the application to use them in the future. Few other things on the roadmap, universal model access. So it's really a pain right now to ask the model to like, to ask for an application that can generate and that can do something with the images or videos. You have to figure out which model to use. You have to go get an API key and do all of that. Pretty soon, any model that you ask for at Replit will be just available in your app directly. We'll handle the billing and the API integration, all of that. Payments is very important. Payments not just for your users to pay for your application. Say you're building a startup on Replit, you're an entrepreneur, you obviously need to collect user payments. But also, I think sometime in the future, you would want your agent to have some kind of wallet to be able to go pay for services. So let's say your agent decides that it needs a tool integration in Replit or whatever system you're using doesn't have a tool integration, it should be able to go put in its credit card and provision that service in the background. A more radical idea is that your agent needs to be able to hire people. For example, if it hits a CAPTCHA and it doesn't know how to solve a CAPTCHA, it should go and task grab it and ask a human to go solve the CAPTCHA for it. Whatever it is, there's a lot of tasks that you still need humans for, and you would want your agent to be able to have money to pay for services. And similarly, agent to agent, you would want your agent to be able to go on the market and find other agents it can hire. Too many YC startups are building agents, sort of agents for accounting, agents for sales. And so you need your software engineering agents to be able to integrate those agents as well. So I know a lot of people think of MCP as such an agent to agent tool, but actually MCP is a more traditional RPC protocol, so it's not really going to solve this. Another model on our sort of business or technology is think about sort of the level of autonomy. So when I started working on what Replit would become like years ago, perhaps seconds ago, the state of the art code assist was a language server, right? That's IntelliSense if you're using VS Code, and you can think of it as level one autonomy. If you think about the sort of drive assists in self-driving cars or like in cars, it would be kind of the lane assist. That would be the first level. AI code completion co-pilot, that would be level two. Level three is what we worked on when agent, when Replit agent first launched. Agent V2, I would call it almost 3.5. It can work up to 10, 15 minutes on its own, but it still needs your input every now and then to test the app and make sure the app is working.