If you give an AI a vague prompt, it will give you a confident answer. And that confidence will cost you a weekend of debugging.
Last month I decided to test how far I could push an AI agent. I didn't want to use it to write a simple function. I wanted it to build an entire backend feature from scratch, end-to-end.
The feature was a standard requirement: A CSV export endpoint for user data.
I opened my AI tool, cracked my knuckles, and typed a prompt that took me exactly 5 seconds to write:
"Create an Express API endpoint that exports all user records from the database into a CSV file and returns it for download."
Thirty seconds later, the AI spat out a perfectly formatted controller, a well-written database query, and even a utility function to convert JSON to CSV. It looked elegant. The variable names were clean. It compiled immediately.
I felt like a 10x developer. I pushed the code, merged the PR, and deployed to production.
And then, within 10 minutes, the support tickets started rolling in.
The Illusion of Perfect AI Code
Here is the thing about AI: It doesn't know what it doesn't know.
Because I didn't give the AI any context about our system, it made three massive assumptions that completely broke production:
1. The All Users Security Nightmare
I wrote "exports all user records." The AI did exactly that. But wait I work on a multi-tenant SaaS. "All users" means every single user across every single company in our database.
An admin from Company A downloaded the CSV and suddenly had the names and emails of Company B. It was a massive data leak because I forgot to tell the AI, "Only export users belonging to the authenticated user's organization."
2. The Memory Explosion (OOM)
The AI wrote a beautiful query: const users = await db.user.findMany(); followed by mapping over the array. It worked perfectly in local testing where I had 50 users.
In production, we had 2.5 million users. The server didn't just crash; it had an Out-Of-Memory (OOM) error because the AI tried to load 2.5 million records into memory simultaneously. I forgot to tell the AI, "Use a streaming approach or pagination."
3. The CSV Injection Vulnerability
The AI did a simple join(',') to create the CSV. But users can enter their own names. If a user named themselves =SUM(1+1) or =cmd|' /C calc'!A0, Excel would actually execute that formula when the admin opened the CSV file. I forgot to tell the AI, "Sanitize the data to prevent CSV injection."
None of these bugs were the AI's fault. The AI did exactly what I asked.
The failure was 100% mine, because I gave the AI the "What" but not the "Where" and the "How."
The Context Debt is Real
This experiment taught me one massive lesson: AI is not a mind reader. It is an incredibly fast, highly obedient intern with amnesia.
When you don't give the AI the full context of your system, its architectural rules, and your security boundaries, it writes code in a vacuum. And code written in a vacuum is just technical debt waiting to explode in production.
We spend so much time arguing about which AI model is smarter GPT-4o, Claude 3.5, Llama 3. But a smarter model wouldn't have saved me here. Even a genius model can't guess that I'm using a multi-tenant database with millions of rows.
How to Fix It: Context-Driven Development
If you want AI to actually save you time (and not get you fired), you have to stop writing Twitter-style prompts and start writing Context-Rich prompts.
Here are the 3 rules I now follow:
1. Share the Database Schema
Don't just say "user data." Paste your Prisma schema, your TypeORM entities, or your SQL table definitions into the prompt. AI is amazing at spotting relations when it can actually see the tenant_id foreign key.
2. State the Constraints Explicitly
If your system has rules, write them down.
"Assume the table has 2 million rows. Use a streaming approach."
"This is a multi-tenant app. Always filter by organization ID."
3. Define the Edge Cases Before You Prompt
Tell the AI to be paranoid.
"Assume users can input malicious strings. Sanitize all CSV outputs."
"Add rate limiting to this endpoint."
The Ultimate Question: Prompts vs. Models?
We are living in a golden era of AI models. They are getting exponentially smarter every six months. But my production incident proved that a brilliant model with terrible context is still a disaster.
So, I want to ask you:
Is better prompting more important than better AI models?
Will we eventually reach a point where AI knows our codebases so well (via RAG and local indexing) that we don't need to prompt perfectly? Or is "Context Engineering" the real skill of the future?
Drop your thoughts in the comments below. I'd love to know how you handle giving AI the right context!
Top comments (4)
the multi-tenant one is scary because the code looks completely fine. it compiles, tests pass, and you only find out a customer from another company got someone else's data. do you think agents should ask clarifying questions before touching anything with auth or data scoping, or is that on us to spell out every time?
Ivan exactly. That's the scariest part it passes all the happy path tests because the test data only has one tenant. It looks completely innocent until an admin downloads someone else's data.
To answer your question: I think ideally AI agents should absolutely ask clarifying questions before touching anything related to auth or data scoping. If an agent sees a User model, it should ask, 'Is this multi-tenant?' before writing the query.
But in reality, right now, the burden is completely on us. Because if I forget that my system is multi-tenant, I'm not going to know to tell the AI. And if the AI doesn't know my architecture, it won't know what to ask.
Until we have agents that can ingest our entire architectural context and proactively flag security boundaries, we have to spell it out every single time. It's exhausting, but it's the only way to survive right now.
Do you think agents asking 10 clarifying questions upfront would actually be helpful, or would it just slow us down?
This is easily one of the most honest and practical articles on AI-assisted development I’ve read recently. The multi-tenant data leak scenario you mentioned is genuinely terrifying because on paper, the code looks absolutely flawless and passes all standard unit tests.
To answer your question: Right now, 'Context Engineering' is absolutely the real skill. Even a GPT-5 or Claude 4 cannot guess business logic or hidden multi-tenant architectures unless we feed it that context. However, I believe the future isn't just about us writing better prompts, but rather tools evolving to map our repositories automatically (like advanced codebase indexing/RAG). Until then, your 3 rules should honestly be pinned on every developer's desk who uses AI. Great write-up Harsh.
yash thank you so much! That means a lot. The multi-tenant leak is exactly the kind of bug that keeps me up at night because it's completely invisible to unit tests. You are 100% right about the future being RAG and automatic codebase indexing. We are currently in this awkward middle phase where the models are incredibly smart, but they are completely blind to our architectural reality. We have to manually feed them the context that a proper indexing tool should already know.
Once tools can automatically map the entire repo and understand the relationships between tables, Context Engineering will become much easier. Until then, we are stuck playing the role of the AI's memory!
Glad you liked the 3 rules. Hopefully, we won't need them forever!