Start Vibe Coding

Vibe coding is emerging as a new subculture of software development - one that emphasizes the environment, mindset, and creative flow of the developer. "Let the AI do the thinking, I'll do the vibing" they say. Rather than adhering strictly to rigid methodologies of writing well-planned and structured code, thinking in levels of abstraction, trying to remember what polymorphism is... you sort of, well, just feel your way through it. (Based on ~the vibe~, of course)

What is Vibe Coding?

In a single sentence: using AI to code your entire project from the ground up without writing any organic code of your own.

Essentially, vibe-coding is yet another layer of abstraction in programming. Just as Python abstracts away a lot of the details and complexities of C, vibe coding abstracts away the few complexities that Python might offer. You, as the vibe coder, are able to focus almost entirely on the high level aspects and features of your project, rather than being caught up in the details.

Not having to focus on reasoning out each low level line of code removes the largest bottleneck in programming: the programmer themselves. As an engineer, you can accelerate your development by 10-100x by keeping your thoughts high level. But that's not even the best part.

Easy Access to Complexity

One of the most significant benefits of vibe coding is its democratization of software development. By abstracting the development process, this new culture invites people from non-technical backgrounds. Lots of software engineers will tell you this is a bad thing because they want to gatekeep their forbidden knowledge: building "hello world" in Rust.

But realistically, a lower technical barrier to entry means that people with big ideas can play around with their own ideas. This, in turn, is likely to usher in cool experiments, new designs, better customer focus, and more business-forward thinking. Funny enough, you'd be hard pressed to find examples of these things across grassroots apps today. (Guess why - just take a wild guess)

With AI plugins like Cline and AI-driven IDEs like Cursor, it becomes possible to prototype a genuinely useful application in hours. Hence, anyone with a practical solution to a problem can produce a POC, show it to their friends, and recruit a few potential customers... in just a single day. And they can do all this with relative confidence and ease. (The daunting part comes with setting up an AWS account and navigating the console)

The Downsides

While vibe coding presents a lot of advantages to product innovation and the continued adoption of technology, along with enhanced accessibility, it's not all unicorns and rainbows.

The main concern with vibe coding is that future "engineers", 10-20 years down the line, won't know how to program at all. All they'll do is write prompts, and when something breaks, they'll spend 10x more time on debugging than necessary. Additionally, by almost completely abstracting the nuances of application code structure, their understanding of their own software may barely reach past a surface-level. (This is a recipe for even more band-aids-and-duct-tape SaaS startups than we have today)

That being said, this may not be a bad thing. Under the hood, even nowadays, most software is pretty ugly. So, if engineers in the future have more bandwidth to focus on high level concepts like scalability and resilience from the start of their careers, then maybe their applications will hold up better than the ones of today. Honestly, who knows? Could go either way.

It's Art

As the software industry continues to evolve, the barrier to entry will likely get lower and lower. Hence, it's reasonable to expect that vibe coding might pave the way for other, new practices that further help bridge the developer, the product, and the user. After all, the "vibe" part of the vibe coding is all about focusing on building something useful while ignoring the nitty-gritty like data types, inheritance structure, and other annoying concepts they teach you in CS101.

Ultimately, vibe coding brings us closer to viewing product development as a form of art... and the developer as the artist... and I would argue that this is not a bad thing.