"Vibe coding" and "vibe marketing" get used almost interchangeably now, like they're the same trick applied to two different jobs. I don't think they are. One of them breaks under pressure. The other one is the pressure test.
What Vibe Coding Actually Is
Andrej Karpathy coined the term in early 2025, and it stuck because it described something a lot of people were already doing:
"I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works."
You describe what you want, the model writes the code, you paste it in and see if it runs. No architecture diagram first, no tests written up front, often no real read-through. It's fast, and genuinely useful for prototypes and demos.
It also falls apart once the system has to hold together under real load:
- The logic doesn't compose. Two pieces that each "mostly work" don't necessarily work together.
- Security is whatever the model happened to include, which isn't the same as whatever the app actually needs.
- Context gets lost between sessions, so the fifth prompt quietly contradicts the assumptions the first one baked in.
That's not a knock on the tools. Vibe coding optimizes for "does this run." Production software needs "does this hold."
What Vibe Marketing Actually Is
Marketing was never trying to hold together the way software does. It's trying to make someone feel something in the two seconds before they scroll past. That's a taste problem, not a correctness problem, which is exactly where "vibe" stops being a liability and becomes the point.
You're not debugging a feeling. You're deciding whether it lands.
Why One Breaks and the Other Doesn't
Code has a ground truth: it runs or it doesn't, and no amount of vibe changes that. Marketing doesn't have a compiler. It has an audience that either stops scrolling or doesn't - and that response actually is a vibe.
Same starting move, describe an outcome and let a model produce it, completely different failure mode.
Where Chromatic Fits
I'd rather explain how we built this than pitch it. Chromatic is a workspace, not a single generator - you're producing video, images, characters, and product shots across whichever model actually suits the shot (Nano Banana 2 and Seedance 2.5 cover most of it, Veo 3.1 or Kling 3.0 for specific motion, Runway Gen 4.5 when you need tighter camera control, and the list keeps changing, which is sort of the point).
The part that took the longest to get right wasn't model access. Anyone can wire up an API key. It's Light - the assistant you talk to instead of writing prompts. Tell it what you're making and it steers whichever model fits. After a week or so of working with your brand, it starts holding onto your palette, framing, and tone without you re-explaining it every session. Turn that into a Skill and it's reusable - the next person on your team gets the same output without redoing the groundwork.
That's the actual bet: model access is a commodity now, so the workspace that remembers what you're trying to make is the product. See how it works.
So, Should You Vibe?
Depends what you're building. If it's a backend that has to be correct under load, don't vibe your way through it - that's what tests and code review are for. If it's a campaign that has to make someone feel something before they scroll past, vibe is the whole job.
Vibe coding breaks things because software needs structure. Vibe marketing works because taste was always the structure.
