Software: to vibe or not to vibe?

Vibe coding isn’t software engineering — unless you engineer it

Okay, so there’s AI generating a lot of software... Give it a few well-placed prompts, perhaps with some advanced prompting strategy (SCOT or something else?), and you get a ton of code that can even handle 70-80% of what you had in mind while you were prompting... But are we really sure this is software “engineering”?

Then there’s the big trend at the top of the trend: vibe coding. What is that? Easy! I’m a newbie and I want to build the software I have in mind in a purely trial-and-error, almost evolutionary, manner, hoping that sooner or later I’ll converge on an acceptable solution... How do I do that? Easy! I go to one of the dedicated portals (e.g., bolt.new) or even my favorite GPT and start chiseling away at my program with prompts. Now, let me rephrase the above question: how can I ensure rigorous principles are applied in the formulation of software that is being “born”? It must be said that intrinsically, if we want software to exhibit by construction the properties we like (e.g., security, privacy, etc.), software is not suited to being “born”—that is, to evolving into a structured form from “cells” that aggregate into increasingly interconnected and complex forms—but must be “created.” The difference seems subtle but is substantial.

If by “birth” we mean the process by which software evolves through prompts, just as a morula evolves into a fetus and eventually an individual, by “creating” we must mean a structured software process with the following characteristics: (a) it is operated by specialized personnel, competent in creating what the software must be, exactly as it should be, (b) to do exactly what it should do, (c) exactly in the way it should do it.

In other words, the only way to ensure that the software performs its functions correctly and completely is to carry out the aforementioned creation by following a structured path that starts not from prompts, but from “requirements,” that is, entities that reflect a problem to be solved as clearly as possible, from which—following known design principles—pieces of the solution can be derived that work well for the people who will one day use the software being created.

Because, let’s not forget, software is an automatic system that solves a problem, and this won’t change. At least not for now.

The formulation above is nothing other than the fundamental mission of Software Engineering as a discipline, and so I ask myself: is it still relevant to write or read a book on software engineering these days? It absolutely is. For example, assuming I want to persist with vibe-coding, how can I offer my clients even a shred of assurance that what I’m building makes the slightest bit of sense and that there’s traceability between the tools and prompts I used and the results I obtained that they will see/use? How will I “test” this conjecture?

I’d also add that one day, perhaps as some would say in 40 or 50 years, it’s possible that GenAI will become capable of creating software that exhibits the properties we want “on command”; that will be the day when software stops being primarily an automatism and perhaps becomes primarily a digital individual, who knows... But from what the literature says, we’re not there yet, and no one knows when we’ll get there.

So, rest assured, software engineering is here to stay, at least for now.