#343 Vibe Coding and the Rise of the Non-Developer Builder with Matt Palmer, Developer Relations at Replit

Generative AI is transforming industries at an unprecedented pace. But as AI changes how you or your team work, one thing is clear. Your skills also need to evolve. At datacamp, we offer everything you or your team need to adapt and thrive with AI. Whether it's business users looking to get the Most out of ChatGPT and Copilot, or developers and data scientists looking to fine tune models, you can learn the entire AI skills spectrum on Datacamp. Power your AI transformation today. Start learning@datacamp.com.

One thing that people don't understand is like writing software comes with a lot of responsibility, especially if you share it with people, right? You are responsible for what that software can do and what that software can expose. And so if you're building on top of other people's data, that's a really big weight that you have to like, think about and think through very, very deliberately if you're going to go out and build tools. The thing about agents is, is mostly context management, context being the information that the agent has access to. So. So the way I would approach things in replit is I would have one agent working on the features and then, hey, it's really time to add in some tests. Here I create a new chat. Now you're in kind of a fresh context. You enter plan mode, you say something like, hey, I just made this great application. It doesn't have any tests, right? I want you to go through it, use a critical eye. Agent's gonna implement some tests, it'll run them, it'll tell you what it did. Now it's your responsibility as the builder to go through and make sure what it did makes sense, right?

Welcome to Data Framed. This is Richie Fiber. Coding was Collins Dictionary's word of the year for 2025. The idea is straightforward. When creating software, instead of writing code yourself, you describe what you want and AI agents write the code for you. The capabilities of the underlying tech have increased dramatically in the last few months and that means the boundaries of what is possible keep shifting. On top of that, the development workflow has been completely upended. And it's very different depending on whether you're a software developer or if you don't have a coding background. Helping us figure out the new way of creating software is Matt Palmer, developer relations lead at replit. Matt helps the REPLIT community build better software. He moved into the AI development space from a background in product analytics and data engineering. On top of this, Matt is the instructor of the Data Camp course Vibe Coding. With Replit. Let's learn how to Vibe Code. Hey Matt, welcome to the show.

It's great to be here. Appreciate you having me.

Yeah, great to have you here. So to be honest, I need some motivation. So talk to like what's the coolest thing you've seen? Vibe Coded.

Yeah, so I think it's, it kind of depends. It's all relative. Right. So I've seen some really amazing non developers build tools for their businesses, for their jobs really just to make their lives better or their friends and their family. Right. So recently I saw a doctor build an app to help him with his practice. So. So help him kind of manage his patients. Saw another doctor actually just yesterday build an app with some interesting concentration curves around dosing for specific peptides which was amazing. And so those are more practice specific. But then I've also seen independent contractors build apps to help them with their business to make tens of thousand dollars of dollars a month and even an interactive AI movie that someone generated. So everything kind of ranging from media to business to entrepreneurship, all that stuff gets me really excited because it's super practical and I can, it's impacting people's lives.

I love those examples. I mean particularly the stuff for entrepreneurs. I think a lot of people, if you go into business by yourself, a lot of people like you're doing it because you want to do that particular thing, not because you're a web developer. So it's almost like an extra cost on like getting started with business. And what if you're lowering that cost? Just makes it easier for people to create their own businesses. I'm kind of curious as to how far you can take this. So the I saw on the Replit homepage there's a quote from Reid Hoffman to the LinkedIn founder. He's talking about trying to clone LinkedIn using Replit. So I get the feeling you can't quite build like a sort of billion person enterprise scale app just straight away with a single prompt. But like tell me like how far can you get with this five coding approach?

Yeah, you know, so I don't think that there's a definitive limit. I think it's kind of determined by your motivation and kind of how far you're willing to take it. But I also think it's important to set expectations. Right. So apps like LinkedIn, Billion, you know, these are multi billion dollar businesses built by thousands of people. Right. And you're probably not going to recreate that in like a couple of weeks by yourself yet. But if you think about like the indie dev space or apps made by one person or Apps made by a small team of people, you can absolutely recreate the logic of those applications. And then if you're willing to invest weeks, months of learning and building into making something more complex, I think it's well within the scope of, like, building an app that serves thousands, tens of thousands, hundreds of thousands of people, depending on what the logic looks like. So I think really exciting things are possible, but people just need to kind of reframe expectations. Right. We can't just replace an entire company with you and some AI yet.

Okay, yeah. So maybe one day, but not quite yet. But I like the idea that you can build real things. And also, I guess there's an important takeaway that's not just, okay, I've written, like, a single prompt, and it's building this thing for me. It's like, there is definitely. It's an iterative process. You're going back and you still kind of. You're doing the work. It's just a different. A different style of interface, I suppose.

Yeah. You know, and I think it's important also to. To consider, like, the scope of. Of the applications that you're building and who you're building them for. Right. If I'm building a tool just for me, maybe I have this one thing that I'm doing every day that's really annoying and manual. I can build that in an hour. Right. And I'm the only one using it sometimes maybe it breaks. It's a little. A little finicky. I work on it over the course of a few days, a few weeks, to a point where I can use it every single day, you can do that immediately. Right. So if you're building for yourself what I like to call, like, personal software, that's a hundred percent, you can get that done. If you're thinking more about, hey, I want to build something to help my business or to serve, like, a small group of people, that's a little bit more complicated because now you have to think through what they're seeing when they engage with the app. And that introduces a whole nother, like, sort of layer of complexity. If you're thinking, I want to build something for millions of people, that's where things get really hard. So you can absolutely build amazing things. And especially for yourself if you just have an afternoon, that's, I think, where you start. That's where I start a lot of my projects is, can I make something that makes my life better? And then can I share that with other people? Right. So you have to reframe expectations. But I Also want to say, like, really amazing things are possible, like today or this afternoon. Right.

I love it. Yeah. Stuff you can solve in a few hours. Like it could be done by the end of the day and you've got like a real thing that's just an amazing outcome. I'd like to know a bit about where sort of replit fits into the technology stack now, because I guess it's one of a new category of sort of, I guess. Do you count yourself as an ide? It's like a kind of modern development tool. I'm not sure what the terminology is.

So I guess it's good to start with what repl.it is and where we came from. So the company's been around for six or seven years now, and we did start as an ide, an IDE that runs in your browser. So if you're unfamiliar with the term IDE interactive development environment about, you know, five or six years ago, you go to Repli.com and you could write code in the browser. And so when the AI wave kind of came along over the past year or two, we pivoted into being an IDE for AI for agents. So now it's a place where you go to your browser for agents, for AI to write the code. Now the cool part about that is that under the hood, all of the functionality of like writing code and everything a developer could do is still there, which is what gives us a leg up. It's what makes our tool so powerful, is like, basically you have the same potential that a developer would have, but it's AI that's using the tool, not you. So I like to think about it in terms of kind of like three main environments. You have chat interfaces for building apps. Maybe like you go to Claude, you type in like, build me an app, you open up ChatGPT. It can create like a visual mockup or something that's cool, it's just not super full featured. And then you have local ides, right? And these are things like VS code or some of the other new AI first ies that are coming out. They run on your laptop, which is great, but they're built for developers and they can be complicated. And even if you get something that works, the question is, how do I take that and make it online, make it available for everybody, add in like a database or somewhere to store images, like these complex services that are typically gated to developers. And so you have those two kind of ends of the spectrum. And replit is, I'd like to think, the best of both worlds. Somewhere in the middle, it has all the complex tooling that a developer might use. It lives in the browser. You just go to replit.com, so you don't have to configure languages, packages, environments, all that for you. And it allows you to build and then share things instantly. So it's all in the cloud, it's a lot simpler. And you can deploy something in a morning that would be otherwise very complicated to learn and figure out how to deploy.

Okay, so I do like that kind of dual purpose then. So if you don't have that kind of coding background, you know, you just like call an agent. It's gonna do the work for you. If you are, if you have that sort of development background, then you kind of get a bit more into the weeds and things. Where does it fit in the kind of, the broader technology stuff? I feel like there's just hundreds and I mean probably, probably this one. Thousands of different tools you can choose from if you want to do software development. So what do you need beyond replit? Like what does it sort of play with?

Yeah, you know, so I think we like to market ourselves as an all in one solution. Our goal really is to be a place where you can go to replit and then build something super fast. And the way we do that is by bundling a lot of these technologies together. So a good example, you can go to replit, we have a runtime, so you can run pretty much any language you want, or you can chat with AI to write code in that language. But then you can add postgres databases directly into relet without leaving the platform. We have cloud, native, serverless postgres instances. You can just tie into the apps. The cool thing is when I mentioned all these services, our agent, our AI, has an understanding of what lives in your app, right? So if you say, why is my database broken? It'll write queries, it'll introspect over your database, it'll like add columns, it can do all of that stuff. It can set the database up for you. So we have databases, object storage built directly into the application, authentication secrets, management, all of these services where it's like, okay, cool, this stuff lives in replit. And now we're adding in more integrations. So for example, if you wanted to build an app that has Gemini or Claude built into the app, right, we can cut API key and you don't even have to worry about setting any of those things up. So if you're not a developer, right, if you want to Add services, typically you have to go get an API key, integrate that with AI like it, there's a lot of stuff that can go wrong there. We can just handle that for you. So we really think about it like, hey, how do we bring everything into replit to make it as simple as possible for builders to come and you know, create something amazing, especially if they've never done any of that dev work before. Now if you're a dev, because replit runs in the cloud, you can think about it like a sandbox virtual environment. You can also ssh into a repl, like into our environment. It's actually there's a lot of really complicated stuff you can do that's fun. You can use a terminal inside the environment to run things like claude code or do whatever. So if you want to get really complicated, really advanced and just use this thing as a virtual machine or a sandbox and then, you know, build with some of our services, go out and get other services, you can absolutely do that as well.

Okay, nice. And so if you need to hook up to, I guess the rest of your enterprise stack, like if you're building something in your place of work, you got integrations then and that's going to just hook up to, I know, your Salesforce or your, your databases and all like, like basically everything else you need. Is that right?

A hundred percent, yeah. So like if you're number one, if you're a developer, anything you can do with code you can do in replit. So you could go to Replit agent, say hey, research the Salesforce API to build this thing on top of my CRM. It'll do that. And then you just get perms and an API key and you can plug it into replit. It would just work because it's code, right? At the same time we also have a bunch of pre built integrations that work really well. So we have enterprise data connectors, so bigquery snowflake data bricks that just sit on top of your data stack. So now say you want your marketing team to be able to. And this is really how we think about it, right? So you're a device and you want your marketing team to be able to build ad hoc dashboards, internal tools, whatever, on top of your data sources. You can create a replit enterprise, give that off to your marketing team, add in the appropriate permissions to make sure your data's safe and then they go out and they vibe code, a bunch of cool stuff and they build their own internal tooling because they have the domain knowledge and they don't have to ask engineering for these other resources.

Nice. So this is kind of the self service dream where you've got all these sort of commercial teams that may be a bit less technical, but they want to do technical things. So this is kind of taking away some of that, I guess the roadblocks for them to work. And it means less cross team interaction then I suppose because you're not having like engineering team having to go backwards and forwards with the marketing team.

I think about a lot like the promise of low code tools maybe five years ago that I don't think was really ever fulfilled. Right. It was like, oh hey, this thing's going to be low code, it's going to democratize, you know, business logic and all of these things. And all it really did was make you have another engineering team that maintains the low code tool and then that breaks. Right. And so I think vibe coding and AI is really the unlock there where you can say hey, we're going to provide like a playground in sandbox. We're going to make sure it's safe and put the right permissions on it and then we're going to give that to these domain experts and they're going to use natural language to build applications that can serve their teams. And there are security concerns there. Replit is very security first and I think if you look at the space what the most security first company out there and for example like we have SSO on top of the entire stack. So you could say anything people build has to be behind two factor authentication, single sign on. Right. So we can kind of gate all of those resources to your team and enable those ICs to generate really amazing apps.

So the security aspect is kind of interesting. I've not really thought about that. So why might you want like, like I guess what rules do you need to have around, like who gets access to? What is it going to be like do you control what people can build with repit then? Or is it just like do you control what projects they have access to or who can edit things? Like how do you worry about this sort of these security aspects?

I mean I think all of the above. So on our enterprise solution we have, you know, viewer seats, very granular, like role based access control. So you can define who has viewer access to apps that you deploy. Right. Say I want to come in, I want to build something and then I want certain members of my organization to access the final product but not the code. We can do that. Right? Say you want to gate the data that I have access to as the person building, we can do that as well, right? You, the dev can configure, you know, a view on top of some of your data sources that have very locked down permissions or is scoped down to a certain set of perms and then I can only build on top of that view, etc. So there are a bunch of different ways to look at it, but we have the potential to enforce all of those things.

Okay, all right. And do you have to control like what people build with things or is that just like use your imagination.

Anytime you go out and you say, hey, just build whatever you want, you have to be very careful, right? So as somebody within your organization, you have to really think through the possibilities there. As I mentioned, you can top down from the organization. Well, hey, you have to be SSO'd in to look at even anything that we build. So that's a good catch. All of like, okay, you're probably not going to expose any company data or pass anything sensitive in, but it actually starts downstream with you know, the engineering team saying we're not even going to give you access to sensitive data, but we, we will give you access to some data. And so that's where like you can work with a solutions engineer, sales engineer, ours to think through what that design, that implementation looks like. And it's an interesting problem, right, because I think a lot of one thing that people don't understand is like writing software comes with a lot of responsibility, especially if you share with people, right? You, you are responsible for what that software can do and what that software can expose. And so if you're building on top of other people's data, that's a really big weight that you have to like think about and think through very, very deliberately if you're going to go out and build tools. But you know, some other things that we do, the apps that we build are full stack applications. So by default the front end is separate from the back end and the backend is communicating with your data source. So you can be a bit more confident that you're not going to like leak sensitive data in the front end of your application. Also our secrets management, right, is stored through gcps like Google Cloud Secrets service. So like there are no env files they could accidentally just commit to git. So there are things like this that we do that kind of follow along with best practices and development for these applications that make our apps just safer inherently. But then there are patterns that you can enforce that are really just software Development patterns and patterns in the enterprise that can make things safer and allow you to build really cool stuff.

Okay, so you start off with like, okay, we're locking down like the access to like the right data and things like that. So that keeps, I guess it solves most of the sort of data privacy part. But like someone builds a stupid user into face, then deal, that's kind of on them.

That's how, that's how I would think about it. Right. And you know, I come, I come from a data engineering background, a data analytics background. And it's like, look, if you don't want somebody to see something, you just don't give them access to that data source. You create a sanitized view, you create a sanitized table and that just eliminates the problem at the source.

Okay, all right, I'd like to take a step back and just think about like what the new workflow is. So you've got all these agents that are going to be writing the code for you. But like suppose you come up with an idea for a new application, like where do you begin?

Definitely want to separate concerns here and how we position ourselves in the enterprise, but then also for consumers. We see ourselves as not a replacement for developers, but the fastest way to prototype and build something like real. Right. And so my standpoint, I think the standpoint of a lot of people at the company is you're always going to need professionals, expert, technical, you know, people that can implement these ideas. But what we're enabling in the enterprise is rapid prototyping. And what we see is our, you know, customers are going into meetings, talking with stakeholders and then building prototypes of the ideas during the meeting, which is insane. Right? So hey, you know, I'm in a meeting with my CEO and he has this cool idea and I'm, I'm like the head of product and now I'm thinking about how we could implement that and then making a mock up in replit and showing it to him in real time. And so on the enterprise side that's just like accelerating this product delivery life cycle. And we're seeing companies ship so much faster because there doesn't have to be this handoff to the design team, this handoff to the product team, this mockup like that takes weeks or months, right? It's just, hey, I'm a product thinker. I'm thinking about the impact and the user flow and the experience and I can make a prototype and then use that prototype instead of doing some weird argument or back and forth process that takes Months. So that's one thing on the consumer side, right? I think, you know, kind of the sky's the limit. You're constrained more by the domain logic and your understanding of these systems than you are by technical expertise or skill. So it used to write, hey, I have a really great idea. To express that idea, I have to go through code. Well, now you don't really have to go through code to express that idea. That's not to say that you can just write, go out and replace all the software developers, but it is to say, make your ideas real and show them to people. And I think down the line, you know, the models are only going to get better, the tools are only going to get better.

Okay, that's very interesting, like the different sort of flows. But if you're an individual or if you're an enterprise. So I like the idea if you're an individual, it's just like, well, I need to be able to figure out how to code this. But in an enterprise it's like, it's like cross team communication. That's the slow part. Usually it's like, okay, business person speaks to design person, design person speaks to engineer or whatever. And as I guess if you have a few loops of that, it can be very slow. Okay, so we're going straight into building stuff quick. Is that the end of it? You've got your prototype and you're done, or is there another step beyond that?

I mean, I think it depends on what you're trying to accomplish. Right. So you know, and I'm going to continue to answer these both in the context of an individual and in a business, because I think they're both super interesting. I think there are a lot of lost ideas out there. There are a lot of ideas that are really that die because everybody's busy, right? And so if you're at your company, you have a good idea and I'll give you a couple like concrete examples of this. You have a good idea and you go and you talk to somebody at lunch and you're like, hey, this would be really cool. And they're like, yeah, that would be cool. That's the end of it, right? You never hear anything else about that idea. You know, it's not like you get buy in, but then you go home for a couple hours, you build a prototype in replit, you come and you show some that idea. You can get a lot of consensus, you can get a lot of excitement around something by proving what's possible. And so I think that's one thing Taking it a step further, what we've seen at companies, you know, with some of our partners, I don't think I can name names here, but there are companies out there where PMs have gone out and built prototypes and then implemented those prototypes and saved the company like millions of dollars in production. Right? They built a more efficient algorithm for matching, basically buyers and sellers in a marketplace. And, you know, how do you prove that in the workplace? Like, I don't know, you go to your boss, you get approval, you have so many drops, takes months, it probably is never going to happen. Right? But if you can do it on your own and then roll out a test and prove it, it's possible. So I'm not saying just like, have disregard for authority or anything, but what I am saying is that, you know, if you want to go prove something and then show people, that's a really efficient way to get consensus. And sometimes you can just prove that an idea is a really good idea by yourself and take initiative on your own. And that's what this tools like replit are allowing you to do. Now, the flip to that is like, I have some personal things that I love that I like hobbies and, you know, I do things outside of work. Hard to believe. I know. I'm always thinking, hey, how do I make this better? Or this, this thing is really hard for me to understand, or this is, you know, kind of boring for me to do this tedious task. Can I build something that makes my life better? Right. And so an example is fitness. I'm like, working on some exercise stuff specific to, to my, like, workout routine, and I'm able to build tools that I don't see a solution for in the marketplace that solve unique problems to me, and that just makes a big difference in my life. And if I have a hypothesis that, hey, there are other people out there like me doing this thing, maybe I'm a part of a community or I'm involved in some, like, discord group or Reddit subreddit or whatever, I can go build a tool for those people, right? And then eventually create something that people really want. And that's the whole, the whole idea, right?

Yeah, I love it. Yeah, sure. Don't tell. You create something and you get people excited and that's going to build momentum. So I think that's going to be a lot more of a fun way to get ideas going rather than like having a committee meeting. Like, you've got to get 10 people in the room and show some slides and try and persuade them that way. So yeah, I love the idea of build something, go hey, look at this. And then that'll get things going. I guess the flip side is if you build something and you realize it's stupid, then that's going to be a good way to rule out bad ideas, right? Have you seen those sort of negative use cases?

Man? I'm laughing because I have like 90% of what I build is stupid, but it's okay, right? And I get people that come to me and I think that they're constrained by this like paralysis that like, oh, what if I build this thing and it doesn't work? What if I waste time? What if it breaks? What if people don't like it, et cetera. And that's a really common mindset I think for any new, I would say builder or creative. I think it's very easy to get into that mindset. I'm a self taught engineer. Before I worked at replit, I was a data engineer. And it's super easy to say, hey, I'm doing the wrong thing, you know, I'm gonna make this, it's gonna break, nobody's gonna like it, et cetera. The builder mindset is I'm just gonna try and I'm gonna put my best out there and then I'm gonna share it with people and whatever happens, happens. And, and the next project that I work on is going to be 1% better than the last one, right? And so I think everyone should just start. There are a thousand projects I've thrown away, but every single one of those projects there are things that I learned about how I could improve on them in the next project, right? And so now I go in and I build stuff and I give demos and people are like, oh man, wow, how did you do that? How did you know to use this library? How did you know to, to, to tell AI this thing? It's like actually because I failed a thousand times. So it is an exercise and it's the same as being an entrepreneur. It's the same as trying to, you know, fix a clock or learn something new. You're going to fail a lot. It's same as trying to learn to ride a bike, right?

Absolutely. Yeah. And other idea of just like keep trying stuff. You can learn that way because even if you make mistakes, it's okay, build something else.

And that, that's why I say to start with fun, right? Because if, if I'm like, oh, I'm interested in this thing, I'm going to try, it's not about appeasing anybody else. It's not about making money. It's not about becoming, I don't know, some kind of millionaire or something. It's about fun and it's about doing something because you're interested in it and you're much more likely to stick with things that way.

Absolutely. I mean, I do quite like the idea of using it to make money as well. But yeah, doing things for fun, also a good idea. But you mentioned, I mean, because there are so many different ways to fail. So have you got some shortcuts for people? Like have you got any tips like what are common mistakes that people make and how might you avoid them?

100%. Yeah. I mean that's like my job, right? I can't just use the excuse of you just have to go out and fail. I have to actually teach people stuff. So yeah, I think, you know, vibe coding, building stuff. With AI, you're still building stuff. And a lot of the principles of software engineering, there are a lot of principles of just being an engineer or build, they still apply. And that means thinking through problems critically, breaking your ideas down. If you come to me and say, hey Matt, I want to build this, this crazy thing, you know, like I want to build, I don't know, an app that turns my handwriting into text. I'm going to ask you how does that work? And you can't say to me, I don't know, right? Like you have to just sit down and think, oh, well, how would it work? Right, well, okay, there's, there has to be an interface for, for writing things down. There has to be something that's going to process the text. And as soon as you start thinking like that, there are follow up questions. How do those two components work? I mean, maybe you don't know. Like I don't know, go ask AI, right, go ask Replit and Replit will tell you. Replit will give you an informed response. But then you can't stop there. You have to be even more critical and say, is what it's telling me true? And then you double down on those questions and you just go down this rabbit hole now where the latency to information is so low because of AI. When I say latency to information, I just mean if you want to know something, you can know it instantly. So as many questions as you can come up with and just ask AI and learn as much as possible, you can just like do that now, which is actually ridiculous. I've never seen anything like it. So if you think in terms of systems, you break problems down from first principles and then you just relentlessly learn and ask questions. You can really do anything. I, I don't know how I became a motivational speaker, but, like, that's how I think about it. And so, yeah, my advice is to think like an engineer. My advice is to think critically. And then if you're building a product for someone or if you're building a product for yourself, my advice is to just be relentless, pedantic, brutal, product thinker. I go through these apps I'm building and I'm like, this is terrible. This is terrible. How do I make this better? How do I make this easier? This button doesn't look good. Right. And it's just this incredibly excruciatingly, like, painful attention to detail that will allow you to build amazing things. But that's true of building anything.

I think attention to detail and is being very critical about output and just getting those sort of cycles of feedback, I suppose, in order that you can improve things. Alongside the rise of Vibe coding, there's been this rise of this Vibe coding cleanup specialist role. So I wonder how you avoid having to hire those people. Obviously, we talked about some of the ideas about just product thinking and engineering design. Are there any, like, ways you can, I guess, do quality control on your own, your own products, on the things that they build?

Yeah. And, you know, I think that this is. I've been working on some larger projects, like, purely through a Vibe coding, like, lens. I was really have been pushing myself, like, hey, can I build something really complicated just by using these tools? And what I see is that still, if you just try and just prompt your way into an app, once you get to a certain level of complexity, it gets really hard. And this goes back to what I talked about, like learning. If you do that, you start to learn what the problems are. Right. And it can be. Can be tricky to intuit, but what you'll notice is, oh, hey, AI is writing disconnected pieces of my app. Right. You say, hey, put a button in here on a really complicated app, it'll just slap that button in, but it'll be, it'll do so in a way that doesn't fit into this career application or that gives you data that doesn't match up with what you're seeing elsewhere. Right. And so what is the solution to that? Well, the solution is a traditional, like, software engineering solution, which is that you have to think about the architecture of your app or how it's being built. Right. You can also do things like give agents tools to check the work as it's going along. And so this is not like a satisfying answer for people who have never built anything before. It takes a little bit of learning, but it is like how do I put in patterns into my application, how do I put in linting and like type checking? A lot of replit apps are written in, in Typescript, so it's like not a big deal. But what I'm noticing is that if you can, you know, think about the architecture upfront of what you want to accomplish and then you can prompt AI and say, hey, how do we build this thing in a structure? That means that it'll be easy to consolidate. Logic means it'll be easy to add new features. You chat back and forth with replit in like plan mode or something. You can get to a solution and then you say, hey, how do I add in, write some like checks to make sure that the code is high quality. How do I add in some checks to make sure we're writing this stuff consistently? You can build that in with replit and then you know, down the line, right. Ideally the agent has access to these tools. Actually this has been proven right. AI loves to use things to check its output. So you can give AI tools to check the output, whatever that looks like. You get like 2 to 3x better results. And that's, you know, the number there comes from anecdotally people on Twitter, et cetera. But that's basically the gist of it. I would say if you're approaching a new project, if you're approaching a project as a device, do all the things I just mentioned, add in testing, add in linting, think about the structure, think about the architecture, document everything, right? Make markdown files with just notes of exactly what you want, exactly where you've been, all of these things. Have the AI organize that for you. If you're non technical, do the same thing, but just ask questions and learn about what these things are. Or you know, you know, use those general guidelines that general architecture, document everything and kind of work towards the system where you're consolidating logic, you're keeping things nice and tidy.

Okay, so yeah, certainly learning about testing, that seems like it's one of those just universally important skills. I mean, I guess not even in software development life in general, knowing how to test your work is a good idea. But yeah, do you get the, do you get the agents to write the test as well then? Or would you, would you recommend having like, does it need to be a separate agent from the one that's building stuff so it's like separation of concerns or how does that work?

Yeah, so things, the thing about agents is, is mostly context management. Context being the information that the agent has access to. And so you know, in replit, when you create a new chat, you're clearing out the context. So the way I would approach things in replit is I would have one agent working on the features and then, hey, it's really time to add in some tests here. I create a new chat. Now you're in kind of a fresh context. You enter plan mode, you say something like, hey, I just made this great application. It doesn't have any tech tests. Right. I want you to go through it, use a critical eye and then think through a plan of like what you would test and how you would implement those tests. Agents can implement some tests, it'll run them, it'll tell you what it did. Now it's your responsibility as the builder to go through and make sure what it did makes sense. Right. Because AI does a lot of stuff that to just like appease humans. Right. It'll just say, oh yeah, I did this stuff. You can ask questions to verify that things are working the way that they should be. Is this perfect? Absolutely not. But AI is doing stuff you couldn't have done before. So like, you know, we're doing the best with what we've got here and is a way to consolidate logic. I've built some pretty complicated applications through trial and error, but then also learning to relentlessly ask AI to use patterns, document those patterns, and then ensuring through linting, et cetera, that the patterns are enforced.

Okay, all right. So yeah, I like the idea that you're sort of asking it to use standard, I guess, coding patterns. So this is like standard structures of code. And then also it's documenting what it's doing. Actually on that note, documentation I wanted to. Do you have any tips on like how you go about writing good prompts for the agents? Is it like, do you have short natural sentences or is it like I'm going to write a 50 page project specification doc and then say go do this thing. Like how sort of broken down does it go?

Yeah, I don't have really. I don't think that there's any right answer. I tend to shy away from like dumping 50 page docs into AI because I think it can pretty easily get distracted or do things you don't want it to. A good, a good example of that is what I see people do on Replit all the time is they'll go to chatgpt and they'll say, write me a prd. I don't know who popularized this, but some somehow this got into the zeitgeist. They say, write me a PRD for my app and then they don't give any details on what their app does. ChatGPT writes some crazy PRD and then they just paste it into replit. And then they come ask me why their app isn't working and I'm like, what original thought did you put into that application? Do you understand anything that's going on? The answer is no, right? So if you're gonna write a prd, you have to make sure that that PRD lines up with the technologies on replit, that replit's capable of using those things. You have to make sure that you, like, understand services that are going into this thing, right? Like as builders, this is our responsibility. So I prefer to work towards an MVP and then slowly build on top of that. I think it mirrors, right, like if you're a dev. If I'm a dev, I sit down on a Saturday, say I didn't have access to AI, what would I do? I have an idea. I'm going to build the simplest version of that idea possible, and then I'm going to start incrementally adding features to, you know, expand on that idea. If I want to create something with AI, I think for in terms of the most simple direct prompt that I can give to get to an MVP for what I want, I go to repl it, I enter that prompt in again, I think simple and direct is a really great idea to get to something that is a true mvp and then I start adding features. So that's how I approach things. One thing that I'll say is that design is usually good to address upfront. So if you have particular opinions about the way things look, it's a really good idea to incorporate those into the initial prompt. Because as soon as AI starts building a bunch of different components, it gets hard to consolidate those things. And when I think through how I speak with AI to design it is in a condensed language. It's not verbose, it's not. There's not like a ton of detail. And I use design terms, I use design language that AI can understand. If you're not a designer, if you're not a front end dev, it's really good to start as you build, understanding what different things mean. So maybe you build an app or you go onto a website and you see that it has rounded buttons and you're like, oh, I really like what those buttons are. You take a screenshot, you ask AI, describe the design system behind this button and maybe it says, oh, hey, that's actually a pretty flat minimalist design with a slight border radius, which is the curve around, around the button. Right. And then you say oh, if I say flat minimalist, slight border radius, this would be the result and that's how you start to learn to prompt for design. Yeah.

Again, that feels like a whole separate language that you could spend years learning. I'm sure designers do, but I like the idea that you can just give a, get a screenshot, show, show it to AI. You get the language and then you can then feed that into the other AI. And yeah, that's going to be.

And I would say it's the same thing. If anybody here has ever prompted for image generation, I think this is a really great example because prompt for image generation is such a wacky, like it's, it requires such a different type of thinking. Like you say, oh, make me an image of like a cat and you get this crazy thing and then you have to be like, oh, make me like a hyper realist image in, you know, you start to very quickly learn you need to use like cinematography language to get accurate image control. It's exactly the same thing. You kind of have to be a mini domain expert in these different subjects.

Absolutely. Especially when it comes to video generation. I've seen some of the prompts like the people like creating all these amazing sort of high quality things like they're talking about like oh, do it in the style of like this particular model of camera and all these like short framing things and you have to sound like a real director. So yeah, there's a lot of technical language you need in order to write good prompts. So I guess on that front, are there any other sort of bits of technical language you think are needed? Like software development language are useful to know about.

Yeah. And like we've are we honestly we've talked about some of them. Right. Like architecture, first principles, thinking, testing, linting. These are all software terms and you might be watching this, you might feel intimidated. Think about those terms the same way you'd think about, you know, learning how to prompt for video. Oh, okay. Well, in order to have a sustainable kind of like approach to building this code base, I need to maybe spend an hour or two understanding what testing is and the frameworks that an agent would implement for tests and the types of tests that I could implement and how that would tie into my long term goals. Right. And so I think testing is important. I think just learning what the architecture of an application looks like. So if you want to build a Full Stack app, what does that mean? Well, Full Stack app just has a separate client and a server. The client is like what you see in the browser, what you interact with. Maybe what you're watching this video on the server is like all the processing that happens behind the scenes. And these terms, these concepts, these patterns really are the building blocks that you're going to use to assemble your ideas into a complete solution. And so as you learn this language, as you start to understand what it means to be an engineer, this is how you get to the point where you say, oh, I want to build that whiteboard app, that OCR is my. That converts my handwriting into text. Well, I need a client, I need a server, I need a database. And this is how. Right. This is how you start to learn the flow. It doesn't happen overnight. Like, I wish I could tell you that, like, I learned all this yesterday, but, like, it takes. It takes time, but you can get there. Absolutely. Yeah.

I'm certainly learning jargon can feel intimidating. I suppose it's the same as, like, if you follow a sport that is like. Like every sport has so much jargon in. So it feels like it's easier than learning about a sport in general.

Exactly. I mean, that's a super great analogy, you know, and so it's like, well, why can't I go to a baseball game and know everything that's going on? It's because I've been watching and playing baseball for, you know, 30 years at this. It's like, oh, I don't. Didn't expect to know all the rules on day one. But if you get interested in it in, you know, a couple of years, really shorter with AI in a couple of months, you can get pretty far.

All right, so I'd like to talk about the implications of this for data teams, because it seems like once you can create personalized applications, that's kind of. It's almost a competitor to things like dashboards and spreadsheets. So talk me through. How do you think data teams are going to be making use of replit and building things with AI.

Yeah. So, I mean, there's the first thing I want to say for data teams. Former data analyst for data engineer. I haven't had time to do this because the focus has been on other things. At the moment, you can build an entire data warehouse inside replit. Like, again, it's a virtual environment. You could build A self contained ETL solution, right? Like it is again just an environment. Theoretically we have object storage, right? So say you wanted to put like fricking some parquet files up top, do some data transformation. There's a postgres you've ranked to the postgres database, right? You could have an ETL job that just runs inside of Replit app. So that I think is really cool and is a solution not many people have experienced just yet. The flip side, which is like BI and visualization, I think that, you know, similar to the sort of low code, no code solutions, BI viz are squarely in the target of AI like Vibe coding. We haven't really got to the point where those can be, you know, scalable in the sense of, you know, services like Tableau or Looker, right? You, you build, built, you build, create primitives and you build on top of those primitives. But for ad hoc dashboards, for ad hoc analysis, for custom visualizations or decks, we see a lot of people that are like Vibe coding slides or presentations in Replit, which you can do because it's all just like react and like front end stuff. Now imagine you have that enterprise connection, your data is underneath that interface and you can just build an app that like you Vibe code a unique presentation that's precisely for your use case and then you implement like custom data from those data sources. The storytelling capabilities for someone that has access to tools like Replit, I think they're unlimited, right? The opportunity to tell, interact like stories with data, to communicate things in a unique way. So I don't think it's quite to the point where you're going to replace Tableau with Replit. But under the hood like a spreadsheet is just logic. And so you can build logic with Vibe coding. That's something you can absolutely do using Replit.

I say I love that idea of like you can create your own data warehouse. Probably like I would say on the Replit homepage it was like Sridhar Ramaswamy has been like, oh, I just tried to use Replit to clone Snowflake. We'll see how far it gets.

Dude, I, if I have, maybe if I have like a free weekend here or something, what I really want to do is I want to like use, you know, DuckDB or something to build like a data lake in our object storage solution. Use Replit to build like a daily job that pulls data, extracts it into that and then transforms it, writes it to like you know, some sort of like medallion architecture in a postgres table. And Then build a visualization on top of it. There's a reason you couldn't do that. Just like some really good prompting.

Absolutely. Yeah. I guess all the kind of components are there. You just got to, I guess, put in the time to build that sort of thing. You said that there are people who are creating presentations in replit. Talk me through, like, can you use this for reporting then? And like, I guess the communication side of analytics, like, how might you use replit for that sort of thing?

I think, you know, there are a couple things. First, you can connect Google Sheets to replit. So if you're like building out like reports and sheets and you already have the logic, we have a connector so you can pull in private sheets and then build visualizations on top of that. A lot of what replit's writing is like React and Typescript, and that's really good for front end. It's really good for building interactive websites. So you could just think about it like you're building an interactive website about any sort of data and that effectively is, you know, a presentation of some sort. We also have access to a lot of different, like charting libraries, et cetera. So those are some ways, you know, you could use replit to build interactive experiences and like, tell stories. I think this is really great for, you know, like consultants. If you're doing, like you're working on a customer fork for a client, you can create a template in Replit and then deliver something that is not a deck, that is fully interactive, that they can hover over, like, elements and like explore. Right. That is much more impactful than sending somebody a Google Doc. And so I think, really, again, sky's the limit if you. It's. You're only limited by your own creativity. But these engaging kind of bespoke experiences are all possible with vibe coding. Okay.

I like the idea of having bespoke experiences. We're back to the idea of getting people excited about things. So you build that prototype quickly and then you get people motivated. So that sounds exciting. So, yeah, I'm now wondering, oh, could we send that to some customers and. Yeah, see if we get excited about things. Okay, cool. All right, so just before we wrap up, what are you most excited about then at the moment?

Man, there's so much to be excited about. I think the thing that continues to surprise me is how much better the models are getting. So even if you look six months ago, a year ago, like, a lot of the stuff AI was designing did not look very good. Maybe it was like, partially functional. It just like, wasn't that appealing. Fast forward. Now we have models like Gemini 3. We have models like Opus 4. 5. The outputs just kind of look like almost pretty good off the bat. And so now I'm like, well, okay, what does this look like in a year? Same thing with the backend functionality. Opus 4.5 is doing stuff on these apps that was absolutely not possible six months ago. And so the complexity continues to, of what you can build continues to increase the, the way it looks, continues to get better. And now I'm thinking, well, like, tools like Replit have also gotten tremendously better over the last year and a half. What does that look like in another year and a half when we have models that are 2x better? When we have apps like Replit that are 2x better? I think you're just going to be able to create and build some really exciting things. And I'm excited about what the future of education looks like and the future of building for all these products.

That's really interesting. I think with foundation models recently, if you're just asking sort of general search type queries where it's okay, give me the answer to this or that, then there's not been that much improvement in the last year because it's like, well, it kind of worked already a year ago, but. But with generating code, because it's such a complex problem, this is where like the foundation model effort is really kind of, it's still benefiting and the underlying tooling does seem to be still getting a lot better. So there is still scaling in that.

Direction a hundred percent, both in cost and performance. Right. Like, one of the amazing things is like Sonnet. Everybody's talking about Sonnet 3.5 through 4.5. Right. Opus 4.5 came out. Nobody really. Opus was kind of limited by the fact that it was a very expensive model. Opus 4.5 is relatively cheaper compared to those other, those other variants of Opus. And so now everybody's like, oh, just use Opus4.5 because the price came down. Same thing with Gemini Div 3. Flash is like outperforming Gemini Pro and it costs like a sixth of the price or something on, you know, certain tasks. And so I was like, oh, wow. Not only can we use these extremely high powered models, but they're also just very cost efficient. And so then it just becomes like, okay, well how much stuff can we give to this thing?

Absolutely. Now I said we were going to wrap up, but that leads me to another question. So I actually don't have a strong sense of how much it costs to build something. Like if you're wanting to build your own simple prototype or something, like, how much are we talking here?

Okay, so the cool thing about relet is, you know, it's, you know, you have our monthly costs and then you get that cost back in credits. So for most simple apps, it's just included as a part of the monthly subscription. So again, it's like you pay per month, and then you get that amount in credits on replit. So most of the time, it's kind of like you can think about those as being included in your monthly subscription. For very simple apps, again, replit is an advantage because you can just like, deploy those things. You don't have to waste tokens asking questions, figuring out all the connecting pieces. What I'm seeing is like, it's on the order of magnitude of a couple bucks for something simple, and then for something like maybe a little bit more complicated that you're using for yourself, order of magnitude of, like, tens of dollars. For something that, like, many people are using, we're talking order of magnitude of hundreds of dollars. For, like, professional applications, I would say, like, thousands of dollars. The. The thing that I want people to keep in mind, though, is for all these apps, it would not have been possible. I could not have done this a year ago. And so when I think about it, right, hey, if I wanted to build this by myself, it would take weeks or months. I might not even get there. If I wanted to pay a software developer, it would cost tens of thousands of dollars. Now I can do it with replit, build tools for myself on the order of magnitude of like, tens of dollars that save me hours. I can build tools that maybe I can sell for hundreds of dollars. ROI there is crazy. And I think a lot of people get limited when they see the cost and they think, oh, I don't want to spend money on this thing. It's an investment you're building. Ideally, you're building stuff that then can return value to you through save time or to other people through a product or service.

Absolutely. I mean, yeah, certainly via if you're going to make money from your application, then an investment of hundreds of dollars is relatively trivial. Yeah, you got to get that back in no time at all.

Or if you're going to save time or help your friends and family or have fun. Right. It's all good stuff.

Absolutely. I mean, that's definitely worth a couple of dollars to make someone else smile. Nice. Okay, so finally, I always want more people to follow. So whose work are you most interested in right now?

Yeah, I mean obviously the Replit team is great. So if you want to follow our founder Amjad or our president Michele, both really great people from diverse backgrounds. Amjad is Jordanian immigrant to the United States, built Replit like with his wife and his brother family, kind of started business and now it's grown into what it is today, which is an outstanding story. Michele from Italy also came to the United States, started working in AI, kind of like did a lot of research there before coming over to repl. It has accomplished some amazing things for the developers that are watching. I always recommend because I'm an, I'm. I'm a Devrel Lee Robinson. Devrel at cursor, like taught. I learned a lot of what I know today through following his content. He does excellent work. Aaron Francis is another Devrel who now does his own thing. And then for maybe semi technical, non technical builders there are some like pm, I guess influencers or content creators that make really great content. Lenny Rudzky is like the gold standard and Peter Yang is another excellent resource to kind of like keep up to date with these tools. If you're coming from a semi or non technical perspective. Okay.

I love it. I have to say Devrel, I mean obviously I'm working in a very similar space so I'm tend to be enthusiastic about this. But yeah, Devrel people in general are very good explaining things so yeah, always worth following more of those. So brilliant. Thank you so much for your time Matt.

Awesome. It's super great to come on and I appreciate it. Richie. Sam.