Vibe Coding // BRXND Dispatch vol. 76

Go forth and feel the vibes.

You’re getting this email as a subscriber to the BRXND Dispatch, a newsletter at the intersection of marketing and AI. We’re hosting our next BRXND NYC conference on September 18, 2025 and currently looking for sponsors and speakers. If you’re interested in attending, please add your name to the wait list. As space is limited, we’re prioritizing attendees from brands first. If you work at an agency, just bring a client along—please contact us if you want to arrange this.

Last week, a client asked me if I’d join a meeting they were having and spend 10 or 15 minutes talking about “vibe coding.” To the uninitiated, here’s how most people were introduced to the term by Andrej Karpathy, a legend in the world of AI (and the first person I ran into that really got me excited about AI 15 years ago). On February 2nd, he Tweeted:

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

That was a few weeks before Claude 3.7 and Claude Code came out, but even then the quality of “composer”—now agent mode—in Cursor to write code felt like it had exploded (as I wrote last week, I think a lot of this had to do with linting). But Karpathy wasn’t talking about using AI to help write code. Github Copilot was the first commercially successful LLM application, and many of us have been AI-assisted coders for years. Instead, he was talking about something new entirely: the ability to YOLO a codebase and just have the AI make magic.

If you check out Three.js, a 3d engine for JavaScript, on X, you’ll see numerous examples of people “vibe coding” games.

Things have only gotten crazier since Karpathy’s original tweet. The quality of the new models, particularly reasoning models like o3-mini, Claude 3.7, and Google’s brand new Gemini 2.5 Pro, means that a whole new type of work is possible. For someone who has never written any code at all, it’s now very reasonable to take something that exists in their head and deploy it from scratch in an hour. As Kevin Scott, Microsoft CTO, said a few years ago, with AI, the impossible is now merely hard, and what was hard is now easy.

But it’s also worth noting that “vibe coding” and AI-assisted coding are not the same thing. Though many software developers are still waiting out AI (less every day, I assume), many of the most talented (like Karpathy) have found ways to integrate themselves with the tools and amplify their output. Simon Willison, an incredibly talented developer, has been writing tons about this topic, recently publishing, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)”. Here’s how he explained the distinction:

Let’s contrast this “forget that the code even exists” approach to how professional software developers use LLMs.

The job of a software developer is not (just) to churn out code and features. We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future.

We need to consider performance, accessibility, security, maintainability, cost efficiency. Software engineering is all about trade-offs—our job is to pick from dozens of potential solutions by balancing all manner of requirements, both explicit and implied.

We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.

If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial.

I definitely agree with that sentiment. Having spent a huge amount of time with AI coding tools over the last year, I can no longer imagine a world without them. Having an AI to take over the work I don’t feel like doing because it’s tedious is a massive boost to productivity. This isn’t vibe coding because you really have to look at the code that comes out the other end if you want to maintain a stable codebase you can work with over time. Managing this complexity is also where I think linting comes in: I have found that the better the hard-coded ruleset I have for how code should be structured and organized, the better the AI does.

But I also very much agree with Willison that this is a net positive: the more people who can build things and use code techniques to solve problems, the better off we are. While this might be scary if your job is to write code (and it probably should be), that’s just the moment we’re in at this moment.

Finally, because it wouldn’t be enough to just write this as a post, I obviously built a site on vibes alone. So, go forth and feel the vibes.

If you have any questions, please be in touch. If you are interested in sponsoring BRXND NYC, reach out and I’ll send you the details.

Thanks for reading,

Noah