Any idiot can write code. “Vibe coding” is just the new pasting code from stack overflow. For that matter, a lot of LLM generated code probably came from stack overflow.

Your value as a developer is not in your ability to rapidly pump out code. Your value is in your ability to design and build complex systems using the tools at your disposal.

As an industry, software engineering has not yet been forced to reckon with the consequences of “vibe coding.” The consequences being A.) the increasing number of breaches that will occur due to poor security practices and B.) the completely unmanageable mountain of technical debt. A lot of us have been here before. Particularly on the tech debt front. If you’ve ever been on a project where the product team continually pushes to release features as fast as possible, everything else be damned, then you know what I mean. Creating new code is easy. Maintaining old code is hard.

Everything starts out great. The team keeps blowing through milestones. Everyone on the business side is happy. Then, a couple years into the project, strange things start happening. It’s kind of innocuous at first. Seemingly easy tickets take longer to complete than they used to. The PR change logs get longer and longer. Defect rates skyrocket. Eventually, new feature development grinds to a halt and the product team starts frantically asking, “what the hell is going on?”

A question to which maybe one or two of the more, senior devs respond, "Well, uh, we have a lot of technical debt. I mean A LOT. We’re having to spend tons of time refactoring just to make minor changes. And of course, unplanned refactoring tends to introduce bugs.

The product team gets an expression on their face like Wyle E. Coyote as the shadow of a falling ACME anvil closes in around him. At this moment, they have two choices. Option A.) develop a plan to mitigate the existing tech debt and realign the dev teams objectives to help prevent this situation again by focusing on quality over quantity. Option B.) ignore the problem and try to ram feature development back on track by sheer force of will.

Only one of these options will achieve meaningful outcome and it’s not “B”. Unfortunately, in my experience that’s often the chosen option. The product team does not understand that while Option A impedes feature development, it’s only temporary. Option B impedes feature development permanently.

We’re going to see a very similar cycle with vibe coding. It just takes time to materialize. Personally, I think the tech debt for vibe codes projects will be compounded due to the sheer verbosity of LLM’s and the fact that no one actually understands a vibe coded project well enough to fix it.

That said, these issues are rooted in hubris and ignorance. Failure to appreciate the “engineering” part of software engineering. This is not something you alone can change.

The AI hype is going to disappear. Probably sooner than later. Just like every other tech hype cycle before it. But, LLM’s are probably here to stay so we have to make the best of it. I don’t usually use LLM’s for code generation. There are better tools for that already. I do use them frequently for research. Honestly, using an LLM with search incorporated is often a lot faster than scouring dozens of websites to figure out how to do something. You still have to take the information with a grain of salt as much as you would with anything on the Internet because LLM’s have no understanding of the text they spit out and will feed you incorrect information without missing a beat.

If I were you, I would focus on quality over quantity. Closing tickets faster is pointless if you’re introducing a bunch of new bugs. If your bosses don’t know that already, they will learn it soon enough.