Vibing...

Midnight hacker vibe-coding session...

There’s been a lot of discussion about “vibe coding” recently, and I’ve been following this closely — and dabbling a little myself. I’ve also been talking to my colleagues and clients about it. Here are my thoughts to-date.

Note: This is going to be one of my shorter posts. My thoughts are still evolving, as is my knowledge, on this topic.

Vibe coding is NOT ready for commercial products

Specifically, the code produced by AI agents still lacks considerable commercial needs. Everything from input validation, security protections, cross-product UI alignment, SSO integration, etc., etc., etc. There is a lot of “boring” code that needs to be generated in most commercially-shipping products that isn’t always obvious to the user… and intentionally so.

While AI agents can generate a lot of good code, this is best handed off to a human developer to finish it with all of the “extras” I mentioned above. Trying to “add it in” with revisions doesn’t quite work out that well right now. In fact, the more “patches” you attempt to layer on to generated code starts to create more and more bugs. Re-factoring is clearly not AI-ready yet.

And, there’s often a subtle “requirement” or two that is hard for AI to meet right now. For example, there are often multiple products (or applications) that have a common look-and-feel across each of them. In an obvious example, Microsoft Word, Excel, and PowerPoint all have a familiar menu and ribbon user interface that makes them feel like a family. Text-only prompting mechanisms are still too limiting for AI to generate a similar look-and-feel (and behavior) across disconnected code. I haven’t found a way to “vibe” that yet.

Vibe coding IS ready for commercial use

Having said that, I have seen good uses for vibe coding a prototype or some research stimulus to put in front of customers & prospects. High-fidelity prototypes used to require considerable effort from developers to reach that level of fidelity, and the push for mid- and low-fidelity prototypes came to the rescue. Then “no-code” platforms emerged to help reach that level of fidelity, but still consumed a human for some considerable time to create.

Some of the latest platforms (like Cursor) are making it easy to reach high-fidelity quickly without consuming too much time. This accelerates how quickly you can put stimulus in front of a test subject, and how quickly you can pivot and re-test based on learnings. It can be quite valuable.

The same can be said for prototypes to hand-off to engineering for full-scale development. Handing off a PRD document with walls of text and/or a few screenshot mock-ups can be enough for certain use-cases, but handing off a live, working prototype can fill in a lot of blanks and clear-up a lot of ambiguity more effectively.

So, I think “vibe coding” has a strong place in commercial use today. But, like a hammer, it’s best used for nails. And not everything is a nail.

How does this line up with your experience?