The 5GL Is Here. It’s Vibe Coding, And It Will Harm Your Business.

When I was in graduate school an exciting area of research in Computer Science, and especially in Information Systems was how fourth generation languages (4GL) would enhance developer productivity and reduce bugs and rework. 4GLs, like SQL and PHP, offer a higher level of abstraction that allow developers to focus on what they are writing, rather than spending most of the time on how, as in 3GLs (such as Rust, C/C++, Java, Perl, and so on).

Today, we have a 5GL, and few people seem to even think of it as a 5GL, or even as a language. Guess what? It is English, or any other natural language you type into an LLM to produce 3GL or 4GL code. Every day, millions of people are typing 5GL  into a vibe coding front end to a Large Language Model (LLM) and out comes 3GL code that in many cases the person who typed the prompt cannot read and understand. This is a critically important moment for Security Professionals and Executives because it upends everything we thought we knew about software security. 

In 1982, one of my (much later) graduate school advisors, Gordon B. Davis, published a paper at the Hawaii International Conference on Systems Sciences titled “Caution: User-Developed Decision Support Systems Can Be Dangerous To Your Organization.” I’d provide a link to it, but all I have is the original proceedings and a scanned copy. A variant of the paper was published in the MIS Quarterly (MISQ) in 1984 but MISQ has sold all its early editions to Springer and Springer famously charges exorbitant amounts for access to the papers. If you want a copy, email me. 

Prof. Davis’ paper was a seminal paper in Information Systems and it couldn’t be more important today, 44 years later. The abstract reads:

There are significant advantages in having users design and implement their own decision support system (DSS) applications: it overcomes the shortage of information system development personnel, it eliminates the problem of information requirements determination by an “outsider,” and it transfers all implementation processes to the user. These are important advantages and they are obtained immediately. However, user-developed systems have inherent short- and long-term dangers that seem to be overlooked in the enthusiasm to implement the user-developed capabilities. 

If you replace some of the now-archaic language (e.g. “decision support systems” with “vibe coded” and “outsider” with “developer”) I think you can see where I am going with this. AI and vibe coding enables companies to rush headlong into the exciting future of end-user developed systems and greatly improved productivity; and greatly increased security risk. 

The promise of vibe coding is that it democratizes and accelerates software development. “Citizen builders” can now build their own applications rather than wait for an engineer to do it. Vibe coding also multiplies the productivity of the engineers themselves. They can provide natural language instructions and the LLM writes the code. Engineers who used to be able to write 30,000 lines of good code per year are now producing 2.5 million lines of code in the same amount of time. People who have never written a line of code and who can’t read it, are now writing complex agents that retrieve and process data they may not even have known existed until the tool told them about it. Or perhaps, didn’t tell them and just did it. AI enables us to exponentially increase the security and stability risk to the organization in much less time!

The entire landscape of information security is shifting under our feet and information security leaders must not wait to process and adjust to what this means. Of course, it’s not all gloomy. AI will change our efficiency as defenders in making us faster and possibly more accurate in detection and response. That’s good because it also democratizes access to our vulnerabilities as attackers can also be far more effective by weaponizing AI. However, there is another area that is fundamentally shifting as I write this, that I have not seen enough people talking about yet. 

For years, we have focused software security practices on design and code reviews, with some tool support from SAST and DAST tools. We rely on developers to code review each other's code and we rely on manual reviews by software security experts. However, all those things are designed to review 3GL (and 4GL) code. The output of those processes rely on a developer who can understand those outputs and fix what they found, not a developer who can’t read the code they “wrote”. The input to those processes relies on a manageable volume of code, and proper design documentation. The volume of code is increasing by orders of magnitude, and the design documentation is either a conversation with an LLM or an auto-generated document that distills that conversation. 

This means our whole approach is losing relevance.Manual reviews no longer are feasible. First, a non-professional builder won’t review the code because they can’t! They don’t read code. There are also a lot more of them than us, so we cannot possibly keep up with the volume they will produce if we rely on software security experts to review the output the way we have been. 

Developers can now produce 10,000 lines of code per day. At that rate, the code is dispensable. It will run once and then never again. By the time the code review gets to it, it’s already no longer relevant but the security problems it created may linger for years. Even if it does go into production, with the expectation of multiplied productivity from AI, we can’t afford to wait on code reviews, analysis tools, or manual fixes. 

It is no longer reasonable to assume engineers can review their own code, or have anyone else do it. That’s a task for an LLM now, which is somewhat redundant if the LLM that produced the code is actually competent at doing so. By the end of this year, or in 2027 at the latest, I expect that the best LLMs will have a near perfect record of producing code that accurately reflects the developer’s intent. That means that tools like SAST and DAST that operate primarily on 3GL and 4GL code may only end up verifying that the LLMs can produce somewhat bug-free code. That’s good, but probably won’t be that relevant. The function of these tools can simply be part of the LLM, if they are needed at all. 

However, does the fact that the code accurately reflects the developer’s intent, and is relatively bug-free mean it is safe? The most complex and sinister security issues have always been logic or design bugs, or legacy solutions. Those are introduced before the LLM turns a prompt into code. They come from the prompt itself - the 5GL. People ask for things they think make sense but that actually don’t. If a developer asks the LLM to build a system that takes extremely sensitive data, does some ineffective security transformation on it, and stores it where it shouldn’t go, will the LLM say “nah, that doesn’t sound great”? If they do not know how to design a persistence layer that is not brittle and unscalable, they won’t know to ask for one. Will the LLM give them exactly what they asked for? At the scale and speed of vibe coding, we likely will not catch this until it is too late. By the time we are in the middle of an incident, we will have to troubleshoot a code base nobody has ever seen. 

We are now in a world of 5GLs - although we call them prompts. We must shift our mindset and our security tools, left. It will very soon be nearly irrelevant to review code. The LLM will have that ability built in. What we need to worry about, shape, and guide is the prompt. That’s where the actual bugs will be introduced. At the scale these tools are used, we cannot rely on scaling this process with people.We need to shift security left and we need to weaponize AI to do it for us.

What the industry needs today is a new kind of expert: one that can embed automated security reviews into the development process between prompt and LLM-produced code. We need to seed the vibe coding tools with prompts and knowledge to analyze the user-provided prompts - the 5GL - to assess their safety, reasonableness, and compliance with company policies. We need to prevent the bad code from being produced by the LLM in response to the prompt in the first place. The only way to do that is at the 5GL layer. This completely changes our world. It also means we have to control which tools are used to produce our code. The reality is that you can vibe code a basic vibe coder in an afternoon. In a year, you will be able to do it over your lunch break. Organizations must ensure that the tools people use to build software have guardrails included that operate at the 5GL level, not the 3GL and 4GL level. It’s too late by then.

End-user developed systems truly are dangerous to your organization.