Yehuda Katz (he/him)

Fun fact: the internal codename for Heroku Vibes was "Heroku Garden".

The story of Heroku with Adam Wiggins, Heroku Co-founder and former CTO (Changelog Interviews #513) This week on The Changelog we're joined by Adam Wiggins, co-founder and former CTO of Heroku, for an exclusive trip down Heroku memory lane. Adam and Jerod are both tremendous fans of Heroku and belie...

PS: If you're in the mood for a deep dive about the original Heroku vision and the history of Heroku Garden, the Salesforce acquisition and the pivot to platform as a service, I could not recommend this
@changelog.com podcast with @adamwiggins.bsky.social enough: changelog.com/podcast/513

We have a lot of work to do to really deliver on that vision, but I'm extremely excited about the prospect of creating something that can finally deliver on the earliest Heroku vision of making software development accessible to everyone.

But the crucial thing is: it's a starting point, not an ending point. It's a way of getting something that works (like Rails scaffolding, iykyk) and solves a real problem, and building it on a platform with enough sophistication to support your software development journey.

Not only a way to prototype and build apps without having to know anything about setting up a local development environment or how to deploy to production, but an accessible onramp to building applications that doesn't require learning to code.

But with the advent of AI tools, we finally have the ability to fully deliver on that vision.

That vision was ahead of its time (we were still living in a pre-Atom, pre-vscode, IE-driven world), and Heroku pivoted to stripping away the deployment papercuts. That was the right move at the time and it was world-changing.

The Heroku Garden vision stripped away nearly all of the papercuts that stopped people from getting an idea out of their head and into production. Not just deployment pieces, but even getting a local development environment set up so you could build the app.

Over a decade ago, Heroku started out with "Heroku Garden", the idea that we could smooth out the onramp for programmers by creating an environment for building out their app in an in-browser editor and immediately deploying it for real.

We can make the gap between "can generate an app that works well enough to be useful" and "can edit the copy in the code myself" much, much smaller.

And once you're editing copy in the code, you're off to the races.

But there's a huge space in between! Everyone who's tried to iterate with an AI on copy changes has experienced the feeling of "Can I just making this freaking change myself?!".

I think people tend to think of vibe coding as the new no-code. Either you're a programmer and you're in an IDE, or you're not a programmer and you're making every edit by using natural language to talk to an AI assistant.

I think a good way to think about Heroku Vibes is that it's an accessible onramp for people to get something real working on a real platform. And then, if they want, they can start to evolve the code that they generated, and have the full power of Heroku to help them get there.

That's very much an _aspiration_ for this project, but the first release was focused on the meat-and-potatoes of getting everything wired up and working well, and I'm hoping to have a lot more to say about this as we implement features that make that vision a lot more real.

I don't just mean "we should collaborate on specs and then have the AI autonomously do the work, and then you write another spec and have the AI autonomously break half of what you liked in the first place."

I mean actual back-and-forth iteration as you go.

3. The word "collaborative" in the marketing tweet isn't an accident. We still have a lot of work to do to realize this vision, but I personally believe strongly that the status quo with AI generation is _far_ too one-shot and not nearly collaborative enough.

2. When you're happy with your app in Vibes, you can transfer it to a normal Heroku app and get the full power of the Heroku software development lifecycle (GitHub integration, review apps, pipelines, CI/CD, etc.)

Even if something isn't already supported, there's a good chance Vibes can figure it out by leaning on a decade's worth of people during nearly anything you can think of on Heroku.

A few things worth pointing out:

1. Vibes has the ability to do most things that a normal Heroku app can do (build backends, create databases, accept config vars etc.), which is a real superpower.

This is what I've been working on! This tweet is of course the marketing way of describing it ("game-changing"!) and this is very much a first release, but I'm so excited about the overall vision for this thing.

As we get older, there's a lot of stuff we were excited about that go by the wayside because we make choices to invest in "grown up" skills rather than fun skills. We stop playing and start working.

The best thing about AI is letting us explore things that are just *fun* and *playful* again.

I teased it for a second in my EmberFest keynote, but something interesting is coming from Heroku. Watch this space...

It's truly mind boggling to me how big of an impact Claude's confident wrongness around the current time has on all manner of things.

The splash damage is enormous but it's *just* subtle enough to go unnoticed.

We did a bunch of extensions in Graffiti and I wonder about the overlap. there's definitely gaps around nesting and composition that should be fixed (I'm very supportive)

Man I sure as hell tried. I'm not convinced the difficulty proved it's impossible but between Rails API and JSON:API (both of which had some success but nothing like what you'd need), I don't underestimate the difficulty anymore.

I'd love to see it.

Especially given that frontends and backends communicate over standard HTTP, the real shame is that there's not a stronger conventional frontend and something better than GraphQL to standardize communication.

I wish I knew how to market something like that. It's like a TV/VCR hybrid. It's very hard to build something with such amazing ergonomic benefits that it's worth giving up on the ability to choose the right option for you on either side of the divide.

And the framing of "context engineering" is just very very "one shot" (figuring out how to ask one time and get the results you want), even if the people talking about it don't really work that way.

The nice thing about collaborative styles is that they give you a lot of opportunities to clarify.

And to a certain extent, it's axiomatic: getting the right results from an LLM requires providing it with the right context.

But that doesn't tell you anything at all about how to structure your communication with the LLM to efficiently get it the right context at the right time.

"Context engineering" sounds good because it sounds like a recipe for success and it sounds "serious".

That's partly because "context" really is the rock bottom of how LLMs work, and smart people are saying it, so it seems like it must be true.