The 'Vibe Code' shift promises to outsource code generation behind conversational text interfaces. We don’t know what security impacts will be felt by making this shift, but we can use the past as prologue. We can look at previous technological waves and known critical factors in software security to predict potential pitfalls.
There are many patterns of AI-assisted development emerging, and terminology on AI-assistance is also quite fluid. First, the points discussed here are aimed at the most autonomous and LLM-driven forms of Vibe Coding, the move from pair to peer, and second, the lack of pattern definition itself is even more reason to have this conversation.
When a new technological paradigm comes along, it promises limitless prosperity and exponential productivity. The hype train leaves the station and rounds the curve of technology adoption. Once we're past the trough of disillusionment, mass adoption hits. Much, much later, the security impacts are better understood. We’ve seen countless times that security misses the train and is merely considered as an afterthought. The popular visual of the tech adoption curve is missing a key geographic metaphor: the vulnerability valley.
As an example, Amazon Web Services (AWS) Simple Storage Service (S3), launched on March 14, 2006. Use of the public cloud storage service has grown astronomically since then. However, S3 Buckets were only made privately accessible by default on April 5, 2023. In that 17-year gap, the cloud customer was fully responsible for having the knowledge and expertise to change the default and secure the stored files.
As organizations shift infrastructure to the cloud, provisioning and maintenance is outsourced behind control plane Representational State Transfer Application Programming Interfaces (REST APIs). This has created an incredible productivity revolution for the cloud consumer. Unfortunately, that interface shift also comes with ‘shallow defense’ baggage – sometimes resulting in avoidable damages because the industry missed the human side. Oftentimes, cloud resources were provisioned insecurely with poor defaults or haphazard configuration, and many of these gaps continue to be exploited today.
In today’s Software Development Life Cycle (SDLC), the point where the software engineer first submits their work, the pull request (PR), is the first point where they claim the code works, does what it intends to do, and doesn’t break anything in the process. The assumption is baked in that the submitter fully understands the submitted code and trusts any party that is included by reference or import.
Does a Vibe Coder write the code contents of the PR? No, as the code agent assembles a body of work based on the prompt, but the Vibe Coder asserts that the code meets all requirements, both functional and non-functional. If AI-written code is not attributable to an individual author, we lose all benefits of attribution entirely. It is difficult to imagine that AI platforms would be found liable for vulnerabilities they introduce via generated code since the accountability trail is murky at best. Even if they were, the consequences to organizations that blindly trust them could be significant, ranging from egg-on-face to loss of IP or data, to loss of customers or revenue, or even litigation.
Software engineers of various levels of expertise will be expected to stand behind the quality of code which they did not write.
Common Secure SDLC controls require code changes to be reviewed for function, accuracy, and security by trained, senior, non-author personnel. The reviewer must sign-off that the change meets requirements. We haven't made a similar requirement of software engineers because it's always been assumed that they understand what they submit. This is another poor default.
Engineers today will pervasively copy code from Stack Overflow answers or open-source projects, but it’s done at snippet size, a few lines at a time. We take for granted that the engineer’s intent and the resulting function are the same. If code assembly is scaling from Stack-Overflow-copy-paste to multi-module-LLM-based-evocation, we should explicitly require that all non-imported code is understood, essentially reverse engineered, and attested to by the author/submitter. Doing this would mitigate the risk that the gap between intent and result becomes too big to manage. A future where Vibe Code is the norm, and less code emerges from the engineer directly, must not lose the beneficial circumstances inherent to today’s software lifecycle.
PR etiquette is subjective. There are different opinions on whether a complex feature should be in multiple PRs, or if multi-part PRs are poor form. Should code have good comments or be written in a self-documenting fashion? I can tell you from years of developing, and attending developer conferences and user groups, that PR conversations can become a passive aggressive minefield. Long argument short: huge PRs are a train wreck.
Why? Code Review complexity grows significantly with PR size. The reviewer must understand the reason for the change, the actual change, the difference between those two, and the gaps between all of that and the overall project standards. The pressure to trust without verification rises as deadlines bear down on the reviewer, even more so when the author is a decorated senior. The risk of the reviewer making a mistake and misunderstanding the actual impact of the code increases with line count.
Now take one step back. There is no difference between a reviewer staring at a massive PR and a Vibe Coder looking at pages of code that have just spouted out of a Large Language Model (LLM). Each has the daunting task of interpreting the code to a benchmark of understanding and confidence. When both author and reviewer are human, they can discuss the thought process behind the code and possibly make it easier to digest complexity. Agents, however, are built to match and satisfy. Will engineers be able to tell when explanations do not line up with submitted code? The incentive, particularly for more junior resources, to understand the code only at a high level before passing it on, becomes a significant risk.
I'm not saying that AI-Written code can't be safe, but I am saying it that we shouldn’t assume it will be. Today’s secure development control was not built on tomorrow’s interfaces. As mass adoption of LLM-generated features expands, negative trends will emerge along with it. We can, however, learn from history. We can map out the resulting SDLC when given these features and remix existing controls to cover new gaps. The software industry has built up a muscle memory over decades and formed sensible practices to improve code security. In pursuit of higher rates of productivity, we should not run the overall process off the rails.
We can, potentially, come out of the valley unscathed.
AI is transforming development—don’t let security fall behind. Use trusted frameworks, set clear expectations, and measure what matters. Interested in learning more about the topic? Message us directly and we will have Adam get in touch.
About the Author
Adam Krieger is a Principal Security Consultant with Online Business Systems. With a background in software development, cloud architecture, and distributed systems, and a certified CISSP, CSSLP, and CISA, he is driven to improve the way we build confidentiality, integrity, availability, and privacy into our applications. Adam has over 18 years of experience as an IT Professional and possesses a wide range of skills that enable him to perform in multiple roles while covering diverse platforms and security initiatives.