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

e, if you're going into business by yourself, a lot of people like you're doing it 'cause 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 if you're lowering that cost, it makes it easier for people to, uh, create their own businesses. I'm kind of curious as to how far you can take this. So, um, the. I saw on the rep home page, there's a quote from Reed Hoffman to the LinkedIn, uh, founder trying to clone LinkedIn using Rept. Uh, so I get the feeling you can't quite build like a, a sort of billion person enterprise scale up just, uh, straight away the single prompt.

But like, tell me like, how far can you get with this five coding approach? 

Matt Palmer: 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, um, billion, you know, these are multi-billion dollar businesses built by thousands of people, right?

And you're probably not gonna recreate that in like a couple 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 citing 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. 

Richie Cotton: Okay. Yeah. So, uh, may, maybe one day, but, uh, not quite yet. But I, I like the idea that you can build real things and also, I guess, uh, there's an important takeaway. It'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 a iterative process. You're going back and you're still kind of, you, you're doing the work. It's just a different, uh, a different style of interface I suppose. 

Matt Palmer: 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, it'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 at night, 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 wanna build something to help my business, or to serve like a small group of people, that's a little bit more complicated.

'cause 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 wanna 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 kind of share that with other people, right? So you, you have to reframe expectations, but I also wanna say like, really amazing things are possible like today or this afternoon, right?

Richie Cotton: I love it. Uh, yeah, stuff you can solve in a few hours. Like it can be done by the end of the day and you've got like a real thing that's just, uh, an amazing outcome. I'd like to know a bit about, um, where sort of rep it fits into the technology stack now, because I guess it's, it is one of a, a new category of sort of, uh, I guess do, do you count itself as an idea?

It's like a kind of modern co development tool. I'm not sure what the terminology is. 

Matt Palmer: So I guess it's good to start with what Rept 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 re.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. 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, um, chat interfaces for building apps. Maybe like you go to Claude, you type in like build me an app, you open up chat GBT, it can create like a visual mockup or something That's cool.

It's just not super full featured. And then you have local IDs, right? And these are things like VS Code or some of the other new ai first I ees that are coming out. They were 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, um, ends of the spectrum and rep it 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. If you just go to repla.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. 

Richie Cotton: Okay. So, uh, 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 is gonna do the work for you.

If you are, if you do 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, the broader technology side things? I feel like there's just. Hundreds, and I mean probably, probably this point, thousands of different tools you can choose from if you wanna do software development.

So, uh, what do you need beyond Repi? Like what's it sort of, uh, play with? 

Matt Palmer: 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 Rept 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 Rept. 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 Rept without leaving the platform. We have cloud native serverless Postgres instances.

You can just tie into the apps. The cool thing is when I mention all these services, r Agent R, ai. Has an under 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 rep and now we're adding in more integrations. So for example, if you wanted to build an app that has Gemini or um, Claude built into the app, right?

We can cut UPI 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 rep lit 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 Rept runs in the cloud, you can think about it like a sandbox virtual environment.

You can also SSH into a ripple, 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 cloud code or do whatever. So if you wanna get really complicated, really advanced and just use this thing as a virtual machine or a sandbox, um, and then, you know, build with some of our services, go out and gather services, you can absolutely do that as well.

Richie Cotton: Okay. Nice. Uh, and so if you, uh, need to hook up to the, 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 gonna just hook up to, I don't know, your Salesforce or your, um, your databases and all that, like basically everything else you need.

Is that right? 

Matt Palmer: 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 rep. So you could go to rep 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 could plug it into rept.

It would just work because it's code, right? At the same time, we also have a bunch of prebuilt that work really well. So we have enterprise data connectors, so BigQuery, snowflake, Databricks 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?

Say you're a dev 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 rep led 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.

They build their own internal tooling because they have the domain knowledge and they don't have to ask engineering for these other resources. 

Richie Cotton: 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 wanna do technical things.

So this is kind of taking away some of that, um, I guess, uh, the, the roadblocks for them to work and. It means less cross team interaction than I suppose so because, you know, having like engineering team having to go backwards and forwards with the, with the marketing team, 

Matt Palmer: 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 gonna be low code, it's gonna 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 some tray. And so I think vibe coding and AI is really the unlock there where you can say.

Hey, we're gonna provide like a playground in the box. We're gonna make sure it's safe and put the right permissions on it. And then we're gonna give that to, um, these, uh, experts and they're gonna use natural language to build applications that can serve their teams. And. There are security concerns there.

Rept is, uh, 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. Um, 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.

Richie Cotton: Ooh. So, uh, the security aspect is again, interesting. Uh, I've not really thought about that. Uh, so why might you want like, um. Like, I guess, what rules do you need to have around, like who gets access to, what is it gonna be like, do you control what people can build with, with REIT 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, the security aspects? 

Matt Palmer: I mean, I think all of the above, so on our enterprise solution, have, you know, uh, viewer seats, uh, very granular, like role-based access control. So you can define who has viewer access to apps that you deploy, right? Say I wanna come in, I wanna build something.

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. A view on top of some of your data sources that have very, uh, locked down permissions or, uh, is scoped down to, uh, a certain set of, uh, perms and then I can only build on top of that view, et cetera.

So there are a bunch of different ways to look at it, but we have the potential to enforce all of those things. 

Richie Cotton: Okay. Um, alright. And do you have to control like what people build with things or is that just like, use your imagination 

Matt Palmer: 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 uh, really think through the possibilities there. As I mentioned, you can top down from the organizational, well, hey, you have to be SS Oed in to look at even anything that we build. So that's a good catchall of like, okay, you're probably not going to expose any company data or pass anything sensitive in.

It actually starts downstream with, you know, the engineering team saying, we're not even gonna 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, a solutions engineer, a sales engineer, ours, to think through what that design, uh, that implementation looks like.

Um, 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 gonna go out and build tools.

Uh, 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. The backend is communicating with your data source so you can be a bit more confident that you're not gonna like leak sensitive data in the front end of your application.

Also, our secrets management right, is stored through, um, gcps like Google Cloud's Secrets service. So like there are no do m files they could accidentally just commit to get. 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. They are really just software development patterns and patterns in the enterprise that can make things safer and allow you to build really cool stuff. 

Richie Cotton: 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, uh, I guess it solves the most this sort privacy part, but like someone builds a stupid user interface then, you know, that's kind of on them. 

Matt Palmer: 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 'em access to that data source. You create a, a sanitized view. You create a sanitized table. Um, and that just eliminate me, eliminates the problem at the source. 

Richie Cotton: Okay. Alright. Um, I'd like to take a step back and just think about like what the, the new workflow is. So, uh, you've got all these agents that are gonna be writing the code for you, but like, suppose you come up with an idea for a new application.

Like where do you begin? 

Matt Palmer: Definitely wanna separate like concerns here and how we position ourselves in the enterprise, but then also for, um, 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 gonna need professionals, expert, technical, you know, uh, 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.

Now I'm thinking about how we could implementing that and then making a mockup in rep and showing it to him in real time. And so on the enterprise side, that's just like accelerating this product delivery lifecycle. 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 be, right, 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 or to express that idea.

That's not to say that you can just Right, 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 gonna get better. The tools are only gonna get better. 

Richie Cotton: Okay. Uh, 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 that cross team communication that's the slow part. Usually it's like, okay. Uh. Business person speaks to design person, design dis person speaks to engineer or whatever. And as, I guess if you have a few loops of that, it can be very slow. Um, okay. So, uh, we, we we're going straight into building stuff quick.

Um, I, is that the end of it? You've got your prototype and you're done, or is there another step beyond that? 

Matt Palmer: I mean, I think it depends on what you're trying to accomplish, right? So, uh, you know. I'm gonna 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, um, at your company, you have a good idea and I'll give you a couple of like concrete examples of this. You have a good idea and um, 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. It's not like you can get buy, buy-in, but then you go home for a couple hours, you build a prototype and rep it, and you come and you show something about 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, our partners, I, I, 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. Save 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 somebody drop some, it takes months. It probably is never gonna happen, right? But if you can do it on your own and then roll out a test and prove it.

It's possible. So, um, I'm not saying just like have, disregard for authority or anything, but what I am saying is that, you know, if you wanna 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, um, and take initiative on your own.

And that's what this tool like rep are allowing you to do. Now, the flips of that is like, I have some personal things that I love that I am like hobbies and, you know. I do things outside of work, uh, 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, um, 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, uh, 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? 

Richie Cotton: Yeah. I love it. Um, it's, yeah, sure don't tell, uh, you create something and you get people excited and that's gonna build momentum. So I think that's gonna be. A lot more of a fun way to get ideas going rather than like having a committee meeting. Like you've gotta get people in the room and try, show some slides and try and persuade 'em that way.

So yeah, the idea is to build something and go, Hey, look at this. And then that'll, uh, get things, uh, going. I guess the flip side is if you build something and you realize it's stupid, then that's gonna be a good way to rule out bad ideas. Right. Have you, have you seen those sort of negative use cases? 

Matt Palmer: Man, I'm laughing because have like.

% 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. 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, uh, before I worked at Rept, 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, 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 the next project that I work on is gonna be % better than the last one. Right? And so, um, 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've failed a thousand times. So it is an exercise and, uh.

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 gonna fail a lot. It's try. Same as trying to learn to ride a bike, right? 

Richie Cotton: Uh, absolutely. Yeah. And, uh, out the idea of just like, keep trying stuff. You can learn that way because even if you make mistakes, it's okay.

Build something else. 

Matt Palmer: 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 gonna 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 having 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. 

Richie Cotton: I mean, I, I do quite like the idea of, uh, using to make money as well, but, uh, yeah, doing things for fun, also a good idea. But, uh, you mentioned, um, I mean, 'cause there are so many different ways to fail, so, uh. Have you got some shortcuts with people? Like have you got any tips of like, what are common mistakes, uh, that people make and how might you avoid them?

Matt Palmer: A hundred percent. Yeah. I mean that's like my job, right? Uh, I can't, I can't just use the excuse of, you just have to go out and fail. I have to actually teach people stuff. Um, so, um, yeah, I think, you know, live coding, building stuff with ai, you're still, and a lot of the principles of software engineering that, a lot of principles of just being an engineer or built, they still apply.

And that means thinking through problems critically. Breaking your ideas down. If you come to me and say, Hey, Matt, I wanna build this, this crazy thing. You know, like, I wanna build, I don't know, an app that turns my handwriting into text. I'm gonna ask you, how does that work? And you can't say to me, I don't know.

Right. Like, you have to, 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 gonna 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. I like, I don't know. Go ask ai, right? Go ask rep and rep will tell you. Rep 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, the latency to information is so low because of ai. When I say latency to information, I just mean if you wanna 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, that's how I think about it.

Um, and so, yeah, my advice is to think like an engineer, and my advice is to think critically. And then if you're building a product for one, or if you're building a product for yourself, my advice is to just relentless. Tic, 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 ex incredibly excruciatingly, uh, like, uh, painful attention to detail that will allow you to build amazing things. But that's, that's true of building anything. I think 

Richie Cotton: of that, uh, attention to detail being very critical about output and just getting that, uh.

Those sort of cycles of feedback, I suppose, uh, you know, that you can improve things alongside the eyes of, uh, vibe coating. There's been this rise of this, uh, vibe coding cleanup specialist role. So, uh, I wonder how you avoid having to hire those people. Obviously, we've talked about some of the ideas about just product thinking and, and engineering design.

Um, are there any, uh, like ways you can, I guess, do quality control on your own, uh, your own products on the things that they build? 

Matt Palmer: Yeah. You know, I think that this is, I, I've been working on some larger projects, like purely through a vibe code 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, it can be, it 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, uh, 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, um, 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 in my application? How do I put in linting and like, type checking. A lot of Rept apps are written in, in TypeScript, so it's like not a big deal. But what I'm noticing is that if you can. 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 it'll be easy to consolidate. Logic means it'll be easy to add new features. You chat back and forth with rept 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 hack quality? How do I add in some checks to make sure we're writing this stuff consistently?

You can build that in with rept and then you know, down the line, right? Ideally the agent has access to these tools. AI actually, um, 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 two to three x better results.

And that's, you know, the number there comes from anecdotally, people on Twitter, et cetera. But, um, that's basically the gist of it. I would say if you're approaching a new product. If you're approaching new project as a dev, do all the things I just meant to 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, yeah, I 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, uh, 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.

Richie Cotton: Okay. Uh, so yeah, certainly, uh, 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, then we have to test your work is a good idea. Um, but yeah. Uh. Do you get the, do you get the agents to write the test as well then?

Or would you, um, would you recommend having, like, uh, does it need to be a separate agent from the one that's building stuff? So it's like separation of concerns or, or, or how does that work? 

Matt Palmer: Yeah, so things, the thing about agents is, is mostly context management, context being the information that the agent has asked to.

And so, you know, in rept when you create a new chat, you're clearing out the context. So the way I would approach things in Rept 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 app application. It doesn't have any TE 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 post 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 make sense, right? Because AI does a lot of stuff that to just like appease humans, right? It'll just say, oh, yeah, I, I did this stuff. You can ask questions to verify that things are working the way that they should be. Is this perfect?

Uh, absolutely not. But AI's doing stuff you couldn't have done before. So like, you know, we're, we're doing the best with what we've got here, um, 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 it's better that the patterns are enforced.

Richie Cotton: Okay. Alright. So, uh, yeah, I like the idea that, um, you're sort of asking it to use standard, uh, I guess, uh, coding patterns. So this is like, uh, 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 gonna write a page project specification doc and then say, go do this thing. Like, uh, how sort of. Broken down, does it go? 

Matt Palmer: Yeah, I don't have really, um, I don't think that there's any right answer. I tend to shy away from like dumping page docs into AI because I think it, 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 Rep all the time is they'll go to chat GBT 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, uh, they don't give any details on what their app does.

Chat GT writes some crazy PRD and then they just paste it into Rept 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 rept, that reps capable of using those things.

So 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 gonna build the simplest version of that idea pops, and then I'm gonna start incrementally adding features to, to, you know, expand on that idea. If I wanna create something with a 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 rep it, I enter that prompt in again, I think simple and direct is really great idea to get to something that is a mv, a true MVP, and then I start adding speech.

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, um, 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, um, 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, um, 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. 

Richie Cotton: Yeah. Again, that feels like a whole separate language that, um, 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, uh, show it to ai, you get the language and then you can then feed that into the other AI and, uh, yeah, uh, that can speak. And I would 

Matt Palmer: 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, 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. 

Richie Cotton: Absolutely. And especially when it comes to. Video generation. I, I've seen some of the prompts, like the people like creating all these amazing sort of high quality things that they're, like, they're, 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, uh, yeah, there's a lot of technical language you need in order to write good prompts. Um, so I guess o on that front, uh, are there any other sort of bits of technical language you think a needed, uh, like software development language are useful to know about? 

Matt Palmer: Yeah, and, and like we've, 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 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, 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. Uh, and so I think, uh, testing's important. I think just learning what the architecture of an application looks like. So if you wanna build a full stack app, what does that mean? Real Stack app just has a separate client and a, and a server. And 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 scene.

And these terms, these concepts, uh, these patterns really are the, 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. I wanna build that whiteboard app.

That OCR is my, that, 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. 

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

Matt Palmer: Exactly. I mean, that's a, a super great analogy.

You know, and so it's like, well, why can I go to a baseball game and know everything that's going on? Because I've been watching him playing baseball for, you know, 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, then you know. A couple years really shorter with AI in a couple months, you can get pretty far.

Richie Cotton: Um, alright. So, uh, I'd like to talk about the implications of this, uh, for data teams. 'cause it seems like once you can create, uh, personalized applications, that's kind of, it's almost a competitor to things like dashboards, uh, and spreadsheets. So talk me through how do you think data teams are gonna be making use of, uh, rep uh, building things with ai?

Matt Palmer: Yeah, so I mean, there's the first thing I wanna 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 Rept. 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, 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 case you break to the Postgres database, right? You could have an ETL job that just runs in inside a replot app.

So that I think is really cool and is a solution. Not many people have exposed just yet. Um, 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 ivis are squarely in the target of, uh, ai like vibe coding. We haven't really got to the point where those can be, you know, um, scalable in the sense of, you know, services like Tableau or, uh, Looker, right?

You, you build built, you 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 Rept, which you can do. It's all just like react and like, uh, front end stuff.

Now imagine you have that enterprise connection and your data is underneath that interface, and you can just build an app that, like, you buy code, a unique presentation that's precisely for your use case, and then you implement like custom data from those data sources. This, this storytelling capabilities for someone that, that has access to tools like rep, I think they're, they're unlimited, right?

The, the, the opportunity to tell interact like stories with data. To communicate things in a unique way. Um, so I don't think it's quite to the point where like you're gonna replace Tableau with Repli, but under the hood, like a spreadsheet is just logic. And so. You can build logic with vibe coating.

That's something you can absolutely do using repless. 

Richie Cotton: I say I love that idea of like, you can create your own data warehouse. Probably like, I would say on the rep home base, it was like wan's been like, oh, I just tried to use Rep to Clone Snowflake. We'll see how far it gets. 

Matt Palmer: Dude, I, if I have, maybe if I have like a free weekend here or something, what I really want to do is I wanna like, um, use.

You know, duct DV or something to build like a data lake, uh, in our object storage solution. Use rept to build like a, a daily job that pulls data, extracts it into that, uh, and then transforms it, writes it to like, you know, uh, some sort of like medallion architecture in a Postgres table. Um, and then build a visualization on top of it.

There's reason you couldn't do that. Uh, just like some really good prompt. 

Richie Cotton: Absolutely. Yeah, I guess, uh, all the kind of components, there's gotta, I guess, put in the time to, to build that sort of thing. You said that there are people who are creating presentations in Repli. Uh, talk me through like, uh, can use this for reporting then, and like, uh, I guess the, the communication side of, uh, analytics.

Like, uh, how might you use Rep for, for that sort of thing? 

Matt Palmer: I think, you know, there are a couple things. First you can connect Google Sheets to Repless. So if you're like building out like reports and sheets and you already have the logic, um, we have a connector so you, you know, can pull in private sheets and then build visualizations on top of that.

A lot of what Repless 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, um, 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 Repli to build interactive, um, uh, 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 and rep it 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, uh, you know. Again, sky's the limit if you, it's you're only limited by your own creativity. Um, but these engaging kind of bespoke experiences are all possible with vibe coding.

Richie Cotton: Okay. Uh, I like that idea of, uh, having bespoke experiences, uh, back to the idea of getting people excited about things. So you build that. Prototype quickly, and then you get people, uh, motivated about stuff. That sounds exciting. Uh, so yeah, I, I'm now wondering, oh, could we send that to some customers and, uh, yeah.

See, see if you can get excited about things. Uh, okay. Uh, cool. Alright, so, uh, just, uh, uh, before we wrap up, uh, what are you most excited about then in the month? 

Matt Palmer: Man, there's so much to be excited about. I think, uh, the, 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 three. We have models like Opus four five. 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 four five is doing stuff on these apps that was absolutely not possible six months ago. And so the complexity, uh, continues to, of what you can build continues to increase the, um, the way it looks continues to get better. And now I'm thinking, okay, well, like tools like rept have also gotten tremendously better over the last year and a half.

What does that look like in another year and a half? That when we have models that are two x better, when we have apps like Rep better, two x better. I think you're just gonna be able to, to create and build some really exciting things. And I'm excited about what the future of education looks like and the future of, uh, of building for all these products.

Richie Cotton: That's really interesting because I think with foundation models recently, like if you're just asking sort of general like, uh, like search type queries where it's okay, uh, gimme the answer to this of that, then there's not been that much improvement in the last year. 'cause it's like, well it, it kind of worked already a year ago, but with generating code.

Because this is 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. 

Matt Palmer: A hundred percent. Both in cost and performance, right? Like one of the amazing things is like sonnet, everybody's talking about sonnet.

Uh, three, five through four five, right? Opus four five came out. Nobody really, Opus was kind of limited by the fact that it was a very expensive model. Opus four five is relatively. Cheaper compared to those other, uh, those other variants of Opus. And so now everybody's like, oh, just use Opus for five.

'cause the price came down. Same thing with Gemini. And I have three flashes 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, um, 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? 

Richie Cotton: Absolutely. Now as everyone can wrap up, but that leads me to another question. So, uh, I, I actually don't have a strong sense of how much it cost to build something. Like if you wanting to build your own simple prototype or something.

Like, uh, how much are we talking here? 

Matt Palmer: Okay, so the cool thing about Rep is, you know, it's uh, you know, we have our monthly costs and then you get that cost back in credits. So for most simple apps, it is 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 Repli.

So most of the time it's kind of like you can think about those as being included in your monthly subscription. Um, for very simple apps, again, repli is, uh, 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. Then, uh, 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, uh, a year ago. And so when I think about it, right? Hey, um, 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 rept, 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. R-I-R-O-I. There is crazy, and I think a lot of people get limited when they see the cost and they think, oh, I don't wanna spend money on this thing.

It's an investment you're building, ideally you're building stuff, uh, that then can return value to you through save time or to other people through a product or service. 

Richie Cotton: Absolutely. I mean, yeah, certainly via, if you're gonna make money from your application, then an investment of hundreds of dollars is, is relatively trivial.

Uh, yeah. You're gotta get that back in, in no time at all. 

Matt Palmer: Or if you're gonna save time or help your friends and family or have fun. Right. It's all, all good stuff. 

Richie Cotton: Absolutely. Yeah. Definitely worth a couple of dollars to make someone else smile. Uh, nice. Okay. Uh, so finally, uh, I always want more people to follow.

So, uh, whose work are you most interested in right now? 

Matt Palmer: Yeah. Um, I mean, obviously the Repla team is great, so if you wanna follow our founder, uh, Amjad, uh, or our president, uh, McKay, both really great people, um, from diverse backgrounds. Amjad is, uh, Dian. Immigrant to the United States, built Rept like with hi, 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. Michaela, uh, from Italy also came to the United States, started working in ai, kind of like, uh, did a lot of research there before. Coming over to Rept has accomplished some amazing things for the developers that are watching.

I always recommend, um, because I'm a, I am, I'm a Dev rel. Lee Robinson Dere at Cursor. Uh, like taught, I learned a lot of what I know today through following his content. He does excellent work. Um, Aaron Francis is another Derel, um, who now does his own thing. Uh, 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 Ski, uh, is like the gold standard and uh, 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. 

Richie Cotton: Okay. I love it. I have to say, uh. Deel. Abby, obviously I'm working in a very similar space, so I'm, I'm, I tend to be enthusiastic about this, but yeah, Deel people in general are very good explaining things, so, uh, uh, yeah, always, uh, worth, uh, following more of those.

So, brilliant. Uh, thank you so much for your time, Matt. 

Matt Palmer: Awesome. It's, uh, super great to come on and I appreciate it, Richie.