By now, you’ve heard of “Vibe Coding” or you wouldn’t be reading this. In a nutshell, it’s asking an AI to develop code for you. It started out harmless enough with one shot games that were pretty incredible to generate and play.
The problem is that it evolved. Now, you have enterprises doing the same thing with millions of lines of code. Just because AI can do it doesn’t mean it should be done. Same logic applies to my coffee, I can drink 3 cups of coffee in one sitting DOESN’T mean it is a good idea. Speaking of time for a refill…
Why Your Login is Broken
When an AI generates code, it often prioritizes making it work over making it secure. It looks for the most common way a task is done in its training data, which often includes outdated or insecure “quick and dirty” examples.
Here is a classic example using a login lookup.
1. Insecure AI-Generated Code
The AI might generate a simple string concatenation because it’s the most straightforward way to build an example.
Python
# INSECURE: Simple string formatting
def get_user(username):
query = f"SELECT * FROM users WHERE username = '{username}'"
# An attacker could enter: admin' OR '1'='1
# Resulting in: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
return db.execute(query)
The Risk: This is a textbook SQL Injection. Because the code just “vibes” the user’s input directly into the command, an attacker can manipulate the query to bypass passwords or delete the entire database.
Congratulations, your users are never going to trust your application again.
2. Secure “Vetted” Code
The secure version uses Parameterized Queries. This forces the system to treat the input strictly as data, never as part of the executable command.
Python
# SECURE: Using parameterized inputs
def get_user(username):
query = "SELECT * FROM users WHERE username = %s"
# The database driver handles the input safely
return db.execute(query, (username,))
Why “Vibe Coding” Fails Here
Lack of Critical Thought: The AI isn’t “thinking” about the threat model; it’s just predicting the next likely character in a string.
The “It Works” Trap: Both snippets look identical to a non-technical user because they both “work” and log the user in.
The Context Gap: The AI doesn’t know if this code is for a local “one-shot” game (where security doesn’t matter) or a healthcare database. AI does not know the whole context, even if you granted it permission to view all of the code.
Redundancy and O(n) Complexity
A common AI mistake is re-calculating or re-fetching the same data multiple times because it “forgot” it already had access to it, or using an inefficient search method because it’s the easiest to write.
1. Inefficient AI-Generated Code
Imagine an enterprise app checking if a list of users has “Admin” permissions. The AI might generate a loop that hits the database for every single user.
Python
# INEFFICIENT: The "N+1" Problem
def check_admin_status(user_list):
results = {}
for user_id in user_list:
# AI makes a separate database call for every single user
is_admin = db.query(f"SELECT is_admin FROM permissions WHERE id = {user_id}")
results[user_id] = is_admin
return results
Why this fails: If you have 1,000 users, you just made 1,000 database calls. This is a “vibe” that works fine with 5 test users, but it crawls to a halt in production.
2. Refactored Optimized Code
A human engineer (or an AI prompted specifically for optimization) would consolidate that logic into a single, efficient operation.
Python
# OPTIMIZED: Batch processing
def check_admin_status(user_list):
# Fetch everyone in ONE call
all_admins = db.query("SELECT id FROM permissions WHERE is_admin = True AND id IN %s", (tuple(user_list),))
# Use a set for O(1) lookup time
admin_set = {row['id'] for row in all_admins}
return {user_id: (user_id in admin_set) for user_id in user_list}The Difference Between AI and Engineering
The first example is what we call row-by-row processing. In the AI’s “vibe,” it thinks: “I need to check a user, so I will ask the database about that user.” Then it repeats that thought for every person in your list.
The bottleneck isn’t the code; it’s the travel. Every time the code hits db.query, it’s like sending a courier across town to ask a single question. If you have 1,000 users, that courier is making 1,000 separate trips. Your application will spend more time waiting for the “trips” to finish than actually processing data. This leads to high latency, server timeouts, and a terrible user experience.
The Reality Check
AI is great at writing syntax, but it is often terrible at system architecture. It doesn’t “feel” the lag of a thousand database calls; it just sees that the code returns the right “True” or “False” during a quick test.
As the human in the loop, you have to be the filter. You’re the one who realizes that while the AI-generated code works fine at 2:00 PM with one test user, it’s going to absolutely tank the server at 9:00 AM on Monday when the whole company tries to log in.
If you aren’t refactoring and reviewing what the AI spits out, you aren’t just “vibe coding” you’re just shipping technical debt. Just like those three cups of coffee, the initial rush feels great, but the crash is going to be expensive.
Let us know if your organization has run into issues like this. We would love to hear about it. Email us: info@itknowledgebases.com
Tell us what this has done to your environment Good or Bad. With this info we plan on putting out content aimed to help solve or inform people of the dangers and ways to aid against this issue and learn what is working for people. Not everyone can afford a developer, so people are choosing to build with AI. We can steer them in the right direction.
If this post interests you, I highly encourage you to pick up a book to explain system design better than I can:
A Philosophy of Software Design, 2nd Edition: https://amzn.to/41U0Js0
You may enjoy this article: AI Vendor Security Questionnaire: 40 Questions to Ask Before Using ChatGPT or Copilot
Leave a Reply
You must be logged in to post a comment.