Vibe Responsibly

Designers and PMs are vibe coding applications and shipping them. Some are handing them to engineers to deploy. Some are deploying themselves. I think this is good. But only if you take it seriously.

When everyone on a team can build, something shifts. You stop throwing work over the wall and arguing about requirements. You stop feeling like a cog executing someone else’s vision. A designer who can build understands the constraints. An engineer who can design understands the goal. The team stops bickering about the seams and starts focusing on what actually matters: the user experience. Generalists building together beat specialists working in sequence. I’ve seen it.

Vibe code is probably full of warts. I’ve written a lot of it. It works until it doesn’t. Security holes you didn’t know to look for. Edge cases the vibe didn’t surface. Logic that made sense in the moment and is incomprehensible three weeks later.

Shipping software isn’t just about the code. It’s about who maintains it. Whether it’s tested. What telemetry exists when something goes wrong. What the failure mode looks like at 2am when nobody who built it is around.

Vibe coding doesn’t make those questions disappear. It makes them easy to ignore until they aren’t.

The standards don’t change because the author does. Your code still needs tests. It still needs to follow conventions the team can grok. It still needs to fail gracefully and surface errors when it breaks. Those aren’t engineering formalities. They’re the difference between software and a prototype someone forgot to label.

Vibe coding feels like a superpower. You’re moving fast, shipping things, cutting steps that used to take weeks. That feeling is real. The consequences of cutting those steps are also real. They just show up later.

Read the code you ship. Review it. Understand it. It’s painstaking. Sometimes it’s tedious. Do it anyway. That’s what shipping software actually means.