Have you ever shipped a vibe-coded app, watched it work perfectly in production... and then watched it silently corrupt data for three weeks before anyone noticed?
That's not hypothetical. It's the #1 failure mode of AI-generated code — not crashes, not errors, but silent wrongness.
I've been building an AST scanner for AI-generated code and ran it against hundreds of repos. Here are the 5 patterns that appeared most consistently — and that every linter I tested completely missed.
1. The Fake Save (MISSING_WRITE)
# AI writes this — looks fine, passes code review
def save_user_preferences(user_id, prefs):
validated = validate(prefs)
result = {"status": "saved", "user_id": user_id}
return result # WHERE'S THE INSERT?
The function looks like it saves. It returns {"status": "saved"}. Your logs show "saved". Your tests pass (they just check the return value).
Meanwhile: nothing is written to your database. Ever.
This pattern — MISSING_WRITE — shows up when you ask an AI to "add a save function". It generates the validation, the response structure, the error handling... but forgets the actual INSERT or UPDATE.
Why AI does this: Language models are optimized to produce plausible code. A function named save_* that returns {"status": "saved"} is statistically very plausible. The model has no runtime to verify the database was actually written.
2. The Async Lie (FAKE_ASYNC)
# Your AI made this "async" — it isn't
async def fetch_user_data(user_id):
conn = get_db_connection() # blocking
result = conn.execute("SELECT ...", (user_id,)).fetchall() # blocking
return result
Your entire async event loop just blocked. On every request. The async keyword is there, but there's no await — so Python runs this synchronously while every other coroutine waits.
Under low traffic: unnoticeable. At 100 concurrent users: your server response time spikes 10x.
I see this constantly in FastAPI and async Django projects where the initial scaffolding was AI-generated. The model adds async because it's "the modern way" without actually making the I/O non-blocking.
3. The Dead Caller (DEAD_CALL_RESULT)
def analyze_and_report(data):
security_check = run_security_analysis(data) # returns critical findings
performance_check = run_performance_analysis(data) # returns bottlenecks
return {"status": "analysis complete"} # both results just... evaporated
The AI called both analysis modules. Both returned results. Then it threw them away.
This happens when you ask an AI to "integrate module A and module B and return the results." The model understands it should call both modules. It doesn't always understand it should use what they return.
Your analysis pipeline runs. Your users get {"status": "analysis complete"}. The actual findings: discarded.
4. The Hardcoded Truth (HARDCODED_TABLE)
# AI "optimized" your database query into this
def get_category_config(category):
CONFIG = {
"electronics": {"tax": 0.08, "shipping": "fedex", "warehouse": "CA"},
"clothing": {"tax": 0.06, "shipping": "ups", "warehouse": "NY"},
"books": {"tax": 0.00, "shipping": "usps", "warehouse": "TX"},
# ... 15 more categories ...
}
return CONFIG.get(category, {})
This started as a database query. The AI "helpfully" inlined the data for "performance."
Now when your business team updates tax rates in the database: nothing changes in the app. When you add a new category: developers have to find and update this hardcoded dict. This is a maintenance bomb that gets worse with every passing month.
5. The Input/Output Divorce (INPUT_OUTPUT_DISCONNECTED)
def personalize_recommendations(user_id, preferences, history):
# ... 40 lines of sophisticated-looking processing ...
recommendations = get_trending_items() # ignores all parameters
return recommendations
The function signature promises personalization. The implementation delivers the same trending list to every user. Every time.
The AI generated all the right parameters, all the right variable names, impressive-looking processing logic... and then quietly ignored all inputs when actually computing the result.
Why Linters Miss All of This
Traditional linters (ESLint, pylint, flake8) analyze syntax correctness. These bugs are syntactically perfect. There's no missing semicolon, no undefined variable, no type mismatch.
The bug is semantic: the code doesn't do what its name and structure promise.
Catching these requires intent analysis — understanding what a function should do based on its name, parameters, and context, then verifying the implementation actually does it.
How to Catch Them
I built AINAScan specifically to detect these patterns using AST analysis across 9 languages. It looks for:
- Functions named
save_*/store_*/write_*with no actual DB write operations -
async deffunctions with noawaitcalls - Module calls whose return values are never referenced in the return statement
- Large hardcoded lookup tables that should be DB queries
- Functions where input parameters have zero impact on the output
Quick test — free API key vg_free_test:
curl -X POST https://pleasing-transformation-production-90c2.up.railway.app/v1/scan \
-H "X-API-Key: vg_free_test" \
-H "Content-Type: application/json" \
-d '{"code": "def save_user(data):\n return {\"status\": \"saved\"}", "language": "python"}'
The Uncomfortable Truth
Vibe coding is genuinely amazing. I use it daily. But the speed advantage evaporates the moment you spend a week debugging why your "save" function wasn't saving.
The fix isn't to write everything from scratch. It's to add a fast automated check before every deploy — the same way you run tests, you should run semantic pattern analysis.
The bugs above each took less than 200ms to detect with AST analysis. They would have taken days to find in production.
Found this useful? I'm writing a series on vibe coding failure modes. Next up: the 3 async patterns that silently kill your API under load.
Top comments (1)
"Which of these have you hit in production?
MISSING_WRITE got me once — save function
returning success but never writing to DB.
Cost us 3 days of debugging."