Learning is not a spectator sport

Prolog: I’m using the tweets in this post to demonstrate that what follows in this post is already a reality, not just an “old man yells at cloud” story :-).  But I stress, the tweets serves as examples, not as a call to action to go attack these developers, their companies or their product(s).

Vibe coding is .. well .. I suppose I can just let an AI tell you 🙂

and of course, it seems to be attracting a lot of attention currently. Every day I log onto Twitter or Bluesky, my feed is inundated with people building solutions at insane pace with some carefully chosen prompts

“Just vibe-coded a new UI for …”

“Just vibe-coded a new SaaS to do …”

“Just vibe-coded a new shopping app for …”

etc etc.

But here is my concern. Take a moment to think how these AI models were trained to be “coders” and what data they had to work with. The vast majority of internet content out there for coding is typically focused on the things that developers love most, ie, the functionality of the application. Things like a cool UI, or snappy performance and the like.

You know what does not get a lot of attention? All the “boring” stuff – authentication, security, access rights, and many of things that differentiate a play thing that you might build on your home server, versus an application that is ready for enterprise deployment.

So when your large language model (LLM) happily spits out your application code for your new cool idea, I suspect there’s a very good chance that the model has extensive knowledge how to build the UI, and also perhaps the basic functionality, the CRUD elements of the data management, because all of those things are well documented out there on the internet, aka, the training data for your LLM. But your LLM probably also has a pretty rudimentary understanding of the security demands of an enterprise application.

Which means you end up with tweets like this:

or tweets like this:

Don’t get me wrong. I’m excited for the productivity gains that vibe coding will probably yield for the developer community. But I like think of the code that results as being similar to the young, impressionable intern you hired for your IT department. They’ll work long hours, be happy to crank out applications, but won’t have those years of experience that has taught us (often the hard way) that security is an aspect that needs to touch all layers of an application. One lesson we all learn as we transition from intern/junior developer to seasoned IT professional is that no matter how whizz-bang your application looks and feels to customers, those customers will probably desert you if they discover you’re being frivolous with their data and its security.