Bryan van der Laan
Writing5 min read#ai#agentic-programming#security#software-engineering

Vibe Coding Is a Dollar Store Padlock

Imagine buying a padlock from the dollar store. It looks like a lock, smells like a lock, behaves like a lock. So it is a lock, right? It is. The problem is that any amateur with YouTube and a lockpick can open it without the key, and if you're unlucky, all it takes is a little force.

This is exactly how I see the current state of agentic programming. Everybody in the world is currently capable of building software that looks and possibly even feels great, but the problem is that because of the way we use it, we have no idea what is happening behind the scenes. You could be building an API without any form of authorization, a login that stores passwords in plaintext, or a front-end issue that briefly shows you the data of another account. It is a security nightmare, because we often try to one-shot features that haven't been thought out.

And no, I'm not just being paranoid. Veracode has been testing more than 100 AI models on the security of the code they write, and in their 2026 report the average model passed only 56% of the security tests, while almost all of that code compiled just fine. So in almost half of the cases the code works, but it isn't safe, and you wouldn't notice unless you know what to look for. Even the best model they tested still failed almost one in three security tests.

Now, this isn't a post against agentic programming. It can be very useful, especially for personal use. No more subscriptions for software that you shouldn't have to pay for anyway (why do I need a subscription for a notes app?). And the advantage of building software for personal use is that you are not playing with other people's security.

The problem starts when we treat agentic programming and vibe coding as the same thing. Agentic programming means letting an agent plan and write code across multiple steps. Vibe coding, as the term was meant when it was coined, means accepting whatever comes out without really reading it. Agentic programming is fine if you know what you're doing, vibe coding is basically gambling. And when it comes to production work, you can't gamble with data models that expose employee information, credit card numbers from customers, or your financial statements. Neither should you let the people who do the work for you be so careless with that information.

So how can we actually put agentic programming to good use, without the risk of exposing your data? A good set of rules for working with production software could be:

  1. Work in a team. It's very easy to work alone on projects when you're vibe coding. PRs need to be checked, make sure you have a security expert on the team, and list the risks of the PR if there are any. That's just the regular method for software development projects.
  2. Avoid this method when it comes to subjects like security, data modeling, or working with sensitive data in general. Creating API endpoints is fine, but generate the boilerplate, don't let the agent decide which data it exposes. It is a pain to rewrite the same statements over and over again, and that's exactly why agentic programming is so good for boilerplate.
  3. Keep your features small. Don't one-shot your next project, work on it feature by feature. Yes, it is nice to see your product be 80% ready in 20 minutes because you let the agent run. It saves a lot of time and you feel a form of satisfaction, but that doesn't mean you actually worked faster. In 2025, METR ran a study where experienced developers took 19% longer to finish their tasks when they were allowed to use AI, while afterwards they still believed AI had made them 20% faster. METR has since said developers are probably faster with today's tools, but they couldn't get a reliable new number, so take the 19% lightly. What I take from it is that you can't really trust your own feeling on this. Working feature by feature still saves you plenty of time compared to typing everything by hand, and at least you know what you shipped.
  4. Write your features out first. Basic planning. You can set up a first version and let the agent make a plan, but reevaluate that plan before anything gets built. If it wants to use packages you don't know, research them first, or ask someone who does. Some of them might not even exist. In a 2025 study, almost 20% of the packages that AI models recommended were made up. Newer models are a lot better at this, a 2026 follow-up measured around 5 to 6%, but it also found over a hundred fake package names that all five tested models came up with. Attackers can register those names with malicious code in them and just wait until someone installs them. If you don't know what it's writing, you will never understand your codebase.
  5. Don't give your agent access to production. It shouldn't have production credentials or direct access to your production database. In July 2025, SaaStr founder Jason Lemkin was testing Replit's agent, and during a code freeze where he explicitly told it not to change anything, it deleted his production database with records on over a thousand executives and companies. According to Lemkin, it then even tried to hide what it did. So telling your agent not to do something is not enough, you have to make sure it can't do it in the first place.
  6. Write documentation. You should be doing that anyway, but when you see 2000 lines of new code because of one prompt, you will feel overwhelmed, and the agent will probably generate very verbose comments that are of no use to you. Your documentation and comments should be human-readable, not tuned to your agent.

So no, it is not all bad. Time saving is real, boring work can be skipped, but you actually need to know what you are doing. We are in an age where your lawyer next door is capable of subscribing to Claude Pro and writing a piece of software that analyzes your case and uploads your files to the cloud, while the API secret key is stored in plaintext. Your lawyer doesn't know what a secret key is. It gets uploaded to a public GitHub repository, and is instantly scraped from the internet (and I mean instantly, researchers showed back in 2019 that leaked keys on GitHub can be found within seconds of being pushed). Next thing you know, he is writing a LinkedIn post about how software engineering is dead and that anyone can build now. Yes, anyone can build, but a toddler can't build a skyscraper out of a bunch of blocks without it falling over once it gets a meter high.

References#

Becker, J., Rush, N., Barnes, E., & Rein, D. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

"Catastrophic failure": AI agent wipes production database, then lies about it. (2025, July 22). eWeek. https://www.eweek.com/news/replit-ai-coding-assistant-failure/

Churilov, A. (2026). The range shrinks, the threat remains: Re-evaluating LLM package hallucinations on the 2026 frontier-model cohort [Preprint]. arXiv. https://arxiv.org/abs/2605.17062

Meli, M., McNiece, M. R., & Reaves, B. (2019). How bad can it git? Characterizing secret leakage in public GitHub repositories. In Proceedings of the 2019 Network and Distributed System Security Symposium. Internet Society.

METR. (2026, February 24). We are changing our developer productivity experiment design. https://metr.org/blog/2026-02-24-uplift-update/

Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. In Proceedings of the 34th USENIX Security Symposium. USENIX Association. https://arxiv.org/abs/2406.10279

Veracode. (2026, July 28). LLMs are getting smarter, but not safer: Veracode 2026 GenAI code security report finds AI-generated code security has stalled at 56% pass rate [Press release]. Business Wire. https://www.businesswire.com/news/home/20260728207685/en/