Introducing Heroku Vibes

Narrator
Hello and welcome to Code[ish], an exploration of the lives of modern developers. Join us as we dive into topics like languages and frameworks, data and event-driven architectures, artificial intelligence, and individual and team productivity. Tailored to developers and engineering leaders, this episode is part of our Deeply Technical series.

Jon
Hello everyone! My name is Jon Dodson and I’m an engineer working for Heroku. I’m a big Heroku super fan and excited to talk to you about what awesome stuff is happening at Heroku. And today is one of those special days, we’re part of something special, and that’s the launch of Heroku Vibes. And to talk all about Heroku Vibes I’m joined by my friend Mauricio Gomes. Hey, Mauricio.

Mauricio
Hey, Jon, thanks for having me.

Jon
Awesome. Okay, so we’re going to get right into things. Mauricio, what is the best advice you’ve received from someone in the software industry?

Mauricio
So I’ve been in the industry for 20 years now or so, and I can’t remember if I got this advice directly from someone or if I read about it, but it was something along the lines of: read a lot of code, and especially in the early phases of your career, like your first 10 years, write a lot of code. I still really believe in that. I think there’s so many things you can paper over, so many deficiencies you may have, or you think you may have, just reading and writing a lot of code. You learn new ideas, you learn how to solve new problems. It creates new folds in your brain, I imagine.

Jon
[Laughs] Probably.

Mauricio
I think as you get later in your career, though, probably switch to reading more code, just helping your peers, things like that. But I think that’s good advice still, even in this age of AI.

Jon
I totally agree. One of the things that I think is still really important before starting anything on any project is understanding what the project is and the code that you’re diving into is, to help craft the best approach to that. So yeah, I like that a lot.

Mauricio
Also timely, right? Like I think with AI, knowing exactly what you want upfront and thinking about it is still super important.

Jon
I think so. As you mentioned AI and understanding, I think it’s even easier to understand with AI. When I get into my editor, I’m just asking questions, you know what I mean? Like, how does this work? What happens here, what’s going on? And it’s really good at that. So, my grepping-fu is a lot less than it was. But the AI can really help you there. So, what’s the most surprising thing that you’ve learned as a developer?

Mauricio
Ah, that’s tricky. Probably for me is, I think we were doing all this Linux stuff and apps and web apps and databases, and we kind of missed that software is part of everything. I don’t mean the self-driving cars and the airplanes and trains and things like that. The protein folding stuff that’s kind of emerging, the theorems about the universal computation and things like that. And it’s just really surprising how much of the universe is algorithmic.

Jon
Yeah, I agree. So Heroku was founded with a mission to simplify application development and deployment for developers. So, looking at Heroku today, how do you look at that mission now?

Mauricio
Yeah, it’s been a long journey. We started way back in the web 2.0 days and the mission there was to allow you to focus on your apps. Yeah, I think we still do a really good job of doing that. That’s why we have been lucky enough to be around for so long. When you deploy on Heroku, your team calls can probably be measured by how much you’re talking about Kubernetes or control planes and things like that, versus how much you’re talking about your actual product. That’s our measure of success.

Jon
Yeah, okay.

Mauricio
I think we’re still doing a good job there. There’s lots of things. There will always be things we could be doing better to make that experience more frictionless for new customers, for existing customers. But I think we still hold that as our North Star and my team calls? We’re not talking about a lot of these operational things, so it’s been quite nice.

Jon
Yeah, I agree. It’s interesting when you talk about early on in your careers, and I was thinking about when I first started off building web applications, you’d always have to get a server, whether it was regular hardware, and then you could later get it in the cloud, and then you had to worry about load balancers and databases and backups and these are things that I just don’t think about as much anymore because it’s solved. Yeah, happy to work at Heroku and have those problems solved.

Mauricio
Yeah, and I think one key difference too is, it’s not just about automating these processes. Because I think if you automate them that’s great, first of all, but if you automate them, you’re still responsible for them. You probably automated back when you manage these systems? You automate the backups. But if it doesn’t back up, it’s still on you, right? With Heroku, the difference is, we carry that pager as well. So if it doesn’t back up, it’s on us and we’ll fix it. So I think that’s something that I think our customers still value from us and we’ll continue to provide it.

Jon
Yep. So Heroku Vibes is the release of the moment, so let’s get into that. So Mauricio, I’ll start with a fun story about the first time I used Heroku Vibes. So when you internally shared the Vibes link with Heroku folks, I thought of a fun app to create, and Vibes took what I wrote and deployed the app to Heroku and it was really fun. I was really struck with how fun it was. So later that day I was talking to my girlfriend and I was like, I created an application today. I told Vibes what to do. It created the app and deployed it to Heroku, and it’s awesome working at Heroku because we’re building the future, I really felt like I was able to touch it, it was kind of like when I first used a smartphone, or the first time I actually deployed to Heroku. So it’s a cool thing to see something so incredible at Heroku, so thank you for building that. And for everyone that doesn’t yet know what Heroku Vibes is, can you tell them?

Mauricio
Yeah. So it was a huge team effort. We, cross-team, front end, marketing, everybody jumped in here. And what it is it’s, I think the industry term would be it’s a vibe coding tool. If you’re not familiar with what vibe coding is, it’s a term to describe a process where in plain language you ask the system to build you an application. So, it doesn’t matter really what the application is. It could require a database, it might not require a database. But you ask it in plain language and you don’t even have to be super detailed. So the system will go off, plan on how it can accomplish the task. So maybe you ask it to generate an app to track your walking schedule or something like that. It will kind of come up with a plan. It will interpret the details, right, like as a software engineer, one of the things you’re most familiar with is how specs deviate in practice and things like that. So naturally, if you’re just going to ask for something in plain language, your specs are going to deviate. And so it’ll do its best to kind of figure out what you meant. And it will run it by you. And if you think you’ve captured what you’ve wanted it to build, you say build it and it builds this app basically that tries to solve the thing you asked for. You can go back and forth with it. This color doesn’t look right, or I didn’t mean like that, I just want Monday through Friday, can you get rid of the weekend days there? Go back and forth as much as you need to kind of refine it and get it to the place where you kind of expected it to be. That process, turns out, is kind of fun.

Jon
Yeah, yeah it is.

Mauricio
Yeah. Even the seasoned developers, it’s fun to create some apps, some toy apps, maybe that you’ve been meaning to create but didn’t have the time to. Well, we are looking at the future as well, and we want to support that use case. We have this metaphor that we’ve been talking about within our team. You know how Apple for a while had a one button mouse? A lot of power users hated this, but the idea was the UI could be entirely operated by a single button. In some of their mice there, all the default mice, had a single button. So as a UI developer, you couldn’t make it complex enough to require a right click. You could have right clicks and context menus, but it couldn’t be the only path to solve the thing. And so, for Vibes, one of the things we’re doing is thinking about that. Is this a right-click feature or is this a left-click feature? We want the entire experience to work with left click. So if you’re getting started with programing, or you don’t even know what programing is, that’s fine. You’re just getting started, it’s a left click for you all the way through.

Jon
Yeah okay.

Mauricio
And as we as we think about like how do we layer and how do we show you code? How do we talk about PRs and that process? Those are some of the right-click features. And those are the things we’re going to be introducing to the product.

Jon
Oh okay. Interesting. So how is Vibes different from other AI coding tools?

Mauricio
So for us, Vibes is natively Heroku. You mentioned how it’s able to build and deploy to Heroku. With Vibes, there’s no artifact that you have to copy and paste somewhere or host somewhere. It doesn’t spit out commands for you to run. It just does all those things. So because we built it on top of Heroku, when you vibe code the app, it’s already deployed. It can have databases, it can have Redis or Heroku Key Value Store. We’re going to add probably inferencing to it. So where you could build AI apps on this system. And you don’t have to think about AI providers or keys or things like that. So that’s what we wanted to build, is the platform built right into the vibe coding tool. If we talk about longer term, we can talk about a little bit how we think that could play out for power users as well.

Jon
Yeah, that’s really interesting because when I started using Vibes, I went from an idea to sending my girlfriend an application that she can use on her phone. Hey, that was incredible. Everything else was just magic. Was taken care of. Idea to app. I mean, it’s magical. So, what’s the core problem you’re trying to solve for Heroku users? Is it about application creation speed, complexity, or maybe something else?

Mauricio
Yeah, I think it’s probably a hybrid of a couple things. I wouldn’t say it’s a core problem, but Heroku, as you mentioned earlier, the git push Heroku was that magical experience for me. For you as well, it sounds like.

Jon
Absolutely.

Mauricio
For a lot of others. Especially if you did it the other way. If you did that VPS and you’d set it up in Nginx and config files and things like that, and then you git push Heroku and it’s like it’s done. It’s I can click on it. So we’re thinking git push Heroku, well we’re thinking vibe coding is going to be a form of a new git push Heroku, right? And it’s the same magical experience you asked for this thing, it’s done. I can copy and paste this link and share with my friends. So we’re looking at that and kind of bringing that next generation of users, partially because we think the space for software is going to get so much larger, but the space for operations and the resources for operating these apps isn’t going to get larger.

Jon
Right?

Mauricio
So you have more software, but the same amount of resources to manage that software, you need a Heroku-like platform behind it. And then I think the other piece of this is kind of what I was alluding to before, whereas build the core engine for Vibes in a way that we want to layer this in to other processes throughout Heroku and get more into that operation space. So this could be things like, yes, you vibe coded an app in Rails 7. Now Rails 8 is out. Who’s gonna upgrade that?

Jon
Yeah, right. Good question.

Mauricio
Right. We have these problems today with our current software. Dependency management. You get too far behind. It becomes really painful. So, we’re thinking about that as well.

Jon
Save me from this, Mauricio. Save me so much work.

Mauricio
Let me tell you what we’re going to do. We have a three-point plan [laughs].

Jon
Okay well, I hope so because it’s so much work for our team. Oh my God.

Mauricio
But we do see this engine now tapping into that space and allowing kind of participating in that lifecycle process, the stuff that comes after you vibe coded something. How can we help you upgrade your dependencies? How can we help you upgrade your Heroku stack or your frameworks version number? We upgrade Postgres releases once a year, an amazing database, but every year you gotta go in there and do this little dance. We’re looking at those spaces. I think the operations piece of this world. The software continues to grow and multiply, the operations piece is going to continue to be super important, and I think Heroku can still continue to do a really good job there.

Jon
I hope so man. Hope so. So, AI-generated code can be a bit of a black box. How does a developer maintain control? Are they getting a fully finished app or more of a starting template they can then customize?

Mauricio
So they aren’t getting a fully finished app. And then one of the things I didn’t describe about Vibes is so you get a fixed number of projects and you can delete projects, and then you free up a slot and then start over. But you can also transfer that project to yourself to your own Heroku account. And that also frees up a slot. But once you transfer it to yourself, you can then download the code and then it’s yours. You can use whatever editor and whatever process you normally use to edit apps. Now, the complexity of the project is going to depend a lot on how much time you spent. So the AI will actually put in a good amount of effort. We see apps take 7 to 12 to 13 minutes depending on the complexity. It can generate APIs, we’ve seen it generate APIs, error pages, it does health endpoints.

Jon
Oh nice. Oh that’s great.

Mauricio
Yeah. So it’s going to be kind of a balancing act of what’s the demo wildness you want, versus the completeness.

Jon
Yeah. The production readiness, right?

Mauricio
Yeah. Exactly.

Jon
Awesome. So this question contains a mild spoiler for Jurassic World Rebirth. So buckle up y’all. Buckle up. So if you’d like to watch that film entirely unspoiled, skip ahead a few minutes such that you can watch your dinosaur movie in peace. So, in the recent film Jurassic World Rebirth, there was an early scene where a dinosaur scientist was eating a Snickers bar in a clean room. So I’m not sure eating a Snickers bar would be allowed in a clean room environment, but I guess it’s a movie about dinosaurs coming back to life, so we’re not talking about a huge attempt at accuracy. So the dinosaur scientist was eating a Snickers bar, and after he finished, the Snickers wrapper fell to the ground and was sucked up by a vent in a large metal door. So that wrapper caused the motor mechanism inside the large door to break down, causing dinosaurs to escape. Now what seemed odd to me in the scene wasn’t the Snickers product placement, that made sense. What seemed odd to me was that some engineer put a motor that runs a huge metal door inside the door. Now, Mauricio, I’m no structural engineer as we know, but to my understanding, large motors that move huge thousand-pound metal doors would be better built outside the door. How could you build a motor inside a door that could move it? Wouldn’t it be too small and get way too hot? Anyway, I’m most likely thinking way too much about how doors are made in dinosaur movies. However, as software engineers, we’ve seen code that feels like someone put a motor inside a door that easily breaks, and you might think, what is going on? This seems entirely wrong to me. Some call this technical debt, cruft, or legacy code. I’m curious how you look at code like this in the projects you’ve worked on, and how you account for technical debt in the projects that you have?

Mauricio
Yeah, I like this metaphor of the steel door.

Jon
Dinosaur doors, no!

Mauricio
I think we typically call it technical debt in the teams that I’ve worked on and I think the goal I think let me state the goal. The goal is you spend about 20% of your team’s effort on technical debt related things. Now, that doesn’t mean one day of the five days of the week or something like that, that would be ideal. But there’s realities, there’s product goals, there’s delivery dates, and things get pushed. Usually tech debt gets pushed. You know you’re implementing a system in a way that is not the most optimal way, or you’re missing this log or something like that. I think it’s totally fine to go back and fix it. You know if you are losing the battle to technical debt.

Jon
Yeah, yeah, yeah.

Mauricio
You get unexpected breakages. So it’s like you changed the documentation and now CI fails. Right? You change the copyright date on the home page, on the front page, on the website, and the database is offline. These are things that should not be happening. It’s indicative of some other brokenness and it’s time to maybe declare bankruptcy and stop shipping new stuff, and take a serious look at what we’ve built there. The door thing? You know, man, I think that missed peer review as well. Oh well.

Jon
Well, if a Snickers bar can cause dinosaurs to murder everyone, I really do think they missed some quality on that. One of the things that I do on projects is when I’m in the code, when I’m touching it, and I’m making time for it, and I know there’s something in there I want to change, I’ll do that there. I don’t typically make time as a project and be like, okay, now it’s time for paying down technical debt. It’s always in a thing that I’m working on because I think that it’s a lot easier to get a good eye on quality in there. So you’re in the code and you can test it and you know you’re going to be clicking through it and stuff like that, so I think that sort of helps me understand that, because I found that entire sprints dedicated to technical debt, I don’t know often where the success is there, but I can find the success when I’m working on something, so.

Mauricio
And they’re hard to justify. You’re the kind of teammate I think everyone loves to have.

Jon
Aww, I hope so, I hope so. We were on a team before, so I hope you liked it. Alright. So a big part of using Heroku Vibes is updating your application from prompts. Can you walk us through a scenario where a user says, now make this button a different color, and how does that translate to new code deployment? Something the user probably doesn’t see a lot, but how does that all work?

Mauricio
I think this is actually where we started letting users into Vibes, and a lot of users would still make the one prompt and then look at the app and say, oh great, I wish couple things were different, but this is great, cool project. I think you’re missing out on the big piece here, which is that back and forth. It’s never going to get the exact thing you had in your head. It’s not going to deliver it. But we know this from all the laws. It’s like English isn’t precise enough or whatever human language isn’t precise enough to determine all of the different nuances that you probably want for your project. So you go back and forth with the AI. It will update the app. We support both scenarios where while you’re chatting with it, you basically have this isolated instance at your behest running these AI prompts, cloning your repo and things like that, making changes to your code base. After you leave the app, that instance, that virtual machine obviously gets destroyed, but you can come back. You can come back, edit your project, ask for more changes. And what it will do is it will clone your repo, spin up a new a new new VM for you to do its work, and you can still go back and forth. The way it’s built into Heroku is that as you make these changes, it will deploy them. It actually uses like Heroku CLI currently, git pushes them. And as you ask for these changes, it actually updates in real time in the Heroku Vibes front end, you’ll see the app change, you wanted it from blue to green or whatever, boom, you see your change there and you can keep iterating. That’s a key part of this, and the deployments and updates and things like that are handled automatically by Vibes.

Jon
Yeah. Interesting. So, one of the things I’ve been thinking a lot about, because I watched this video recently, there was a presentation for some folks that were working for OpenAI, and the point they made is that development is essentially changing. It used to be that we could express ourselves in code, and the code was the artifact, but now maybe how we communicate to AI and the requirements or the specs that we communicate to AI is the artifact. That’s interesting. And the more that you talk about Vibes and how we’re communicating to AI, it’s interesting because I think that the more precise we get, I think the AI can get closer to what we think, but even, I’m wondering how precise we can get before we actually just start talking code again, you know what I mean? But I definitely think anything that we’re talking about now, in the future with AI, we need to get a lot more precise, I believe. What do you think about that?

Mauricio
Yeah, I think that’s a really great insight. I don’t know if we’ll get more precise. I just don’t know if we have it in us, maybe.

Jon
Yeah, right. Fair enough.

Mauricio
But I do think they’re on to something. But I would say like this, maybe. So early on when we were getting these various ChatGPTs and were just integrating basic ChatGPT into kind of our developer workflows, one of the things it started being used for was like, hey, I can read your div and I can generate your pull request summary, and I can generate the title of your pull request. It’s like, oh great, this saves me time, right. And another example of that is you could actually ask your coding agent today to generate docs for you.

Jon
Yeah.

Mauricio
It does a really great job of generating API docs, read your code. And so it’s like if you can generate docs on the fly, and you can generate PR descriptions on the fly, do we need those anymore? Do we need to automate that process, right? If I’m integrating with the software I used to read your API docs, but now if I ask you for API docs that are missing and you go ask AI to generate it for me, I’m gonna ask AI to read it so they can implement a client. What are we doing, right?

Jon
Yeah. That’s a really good point. I think it’s never been easier for AI to understand a code base in seconds so I think that’s a really good point, should all be on the fly or should we generate in advance, that’s a really good way to think about it, I don’t know I guess we’ll see.

Mauricio
Yeah, I just say that because I think that’s where we’re starting to see change. It wasn’t obvious that these processes maybe didn’t need to exist, and we’re seeing the change there.

Jon
So in terms of security and best practices, how does Heroku Vibes handle things like dependency vulnerabilities or secrets management?

Mauricio
Good questions. Dependency management is that stuff we’re looking into. That’s going to be when we hit the 1.0 and we open up Vibes to everyone. We’ll have some indication of how it can help you. And then in terms of the secrets management, that’s also an area where we’re focused on that will land for GA and so Heroku has this concept of config vars. They’re really environment variables, right, that are exposed to your apps. And we’re going to be providing ways for users to drop in those config vars right from the Vibes interface without having to stream it through the bot or anything like that so it doesn’t get logged. You know, use Heroku’s already secure backend for storing those kinds of credentials, and you mostly won’t need to touch those it will manage your databases and things like that for you. That would be useful though, if in Vibes you’re creating maybe a Spotify client or something, and you need a Spotify API key you want to drop in there. So those are things where we’ll kind of like handle that for you.

Jon
Heroku Vibes could fundamentally change how a team estimates project timelines. How do you see managers and team leads integrating this into their sprint planning and development cycles?

Mauricio
Yes, I hope it does. I hope even tools like it. One of Heroku’s fundamentals, I think Adam Wiggins, one of the founders of Heroku, wrote something like this. I’m gonna butcher it because I don’t have it in front of me, but it’s like an idea is cheap, a prototype is worth a lot more. And prototypes now are getting cheaper. I think that’s what we’re talking about here. And so there is a lot more room now to spike and generate prototypes of this concept you may have in your head. Everybody can do it; product managers, team leads, sales teams can generate these things and kind of show you what they’re asking for. So I’m really excited to see where that all ends up.

Jon
Yeah I know we’ve talked about this, you and I before, but for me the thought that hack weeks will never be the same again is really exciting. If any team of any configuration could have a hack week project regardless of how technical you are, and I think it means that you could generate multiple hack week projects and internally at Heroku I am so excited to see the next hack week. It should be off the hook. It should be incredible.

Mauricio
And maybe participation from non-engineers right.

Jon
Yeah, I hope so I hope so. Do you know how to write words? You’ve gotta hack week. You can have ideas. You can have a project.

Mauricio
Do you know words?

Jon
I hope you do, I hope you do. So, do you think products like Heroku Vibes will change how full stack developers work?

Mauricio
I think so, I think so. I think one of our missions with Vibes and at Heroku has always been to empower, and people aren’t always developers, they don’t start their life being a developer, thinking like sometimes people will say like, I was born to be a developer. Cool, but this job didn’t exist 200 years ago. So, so guess those people weren’t born to be developers. We wanted to continue to lower that bar for entry, but also make it to where the time you spend is focused on that idea, that project, that product, whatever it is you’re building, and not on the other things. And so I think we’re making even more inroads than we have in the past, where we took away the operations burden from you. But I think we’re able to do a little bit more now. And that’s where Vibes is starting to get into. What I hope to see is that this is the second broadening of the scope. There’s a big growth in engineering, software engineering in particular, around like the web 2.0 era that continued through mobile and cloud. I hope that comes back with new kinds of software, and with Vibes and things like that I think Heroku can still be that platform where new folks come to run their apps.

Jon
Here, here. So, final question. Looking five years down the road, how do you see Heroku Vibes evolving?

Mauricio
Yeah, so hopefully we continue to do well on that mission I just mentioned. So we’ve got new developers coming in. I hope where we start succeeding after this initial wave is going to be the continuation story. You’ve deployed, you’ve made edits, you’ve changed it from blue to green. Great. It’s Postgres, it’s Postgres 17, now it’s 18, now it’s 19. Great. How are we helping you to keep that app running? How are we running a couple steps ahead of you to talk about scaling your Dynos up for load. How are we keeping you secure? How do you know what software you’re running on your stack? All those things are just general platform features that, when combined with AI, are going to be really great. But I think the key point is that we just need to continue to make our platform better, and all of the AI stuff will just follow along. So that’s our mission still is to keep evolving Heroku and Heroku Vibes will become a lot better for it.

Jon
Mauricio, I wanted to congratulate you and your team for launching Heroku Vibes in beta, and I wanted to say thank you for talking to me today.

Mauricio
Thank you so much, Jon. This was a lot of fun. Go try out Heroku Vibes.

Narrator
Thanks for joining us for this episode of the Code[ish] podcast. Code[ish] is produced by Heroku. The easiest way to deploy, manage, and scale your applications in the cloud. If you’d like to learn more about Code[ish] or any of Heroku’s podcasts, please visit heroku.com/podcasts.