I've Rescued 10+ AI Projects Built With Cursor — Here's What Always Goes Wrong

In 2024 and 2025, millions of people discovered that AI coding tools could take them from idea to working prototype in a weekend.

Cursor. Claude Code. GitHub Copilot. ChatGPT with a code interpreter.

And it was true — to a point.

The problem: "working prototype" and "production-ready application" are completely different things. AI coding tools are exceptional at the first. They are genuinely dangerous at the second — not because they write bad code, but because they write optimistic code that assumes everything works.

I have been called in to rescue over 10 of these projects in the last year. Here is what I find every single time.

---

What "Vibe Coding" Actually Produces

Let me be clear: I use Cursor and Claude Code myself, every day. They are incredible for moving fast.

But there is a pattern I see repeatedly:

1. Founder builds prototype with AI tools in 1–2 weeks
2. It works perfectly on their laptop
3. They demo it — works great
4. They try to launch
5. Things break

The last 30% of a software project — the part that makes it production-ready — is precisely what AI tools struggle with. It is not glamorous. It is error handling, security, performance under load, proper logging, database indices, environment management.

AI tools will happily write you code that works in ideal conditions and silently fails in the real world.

---

The 7 Patterns I Find Every Time

1. No error handling anywhere

AI-generated code tends to be optimistic. It assumes API calls succeed, database queries return data, and users do exactly what is expected.

Real production code needs to handle failure at every external call:

// What AI tools write
const result = await openai.chat.completions.create({ ... });
return result.choices[0].message.content;

// What production code looks like
try {
  const result = await openai.chat.completions.create({ ... });
  if (!result.choices?.length) throw new Error('Empty OpenAI response');
  return result.choices[0].message.content;
} catch (err) {
  if (err.status === 429) { /* rate limit — retry with backoff */ }
  if (err.status === 500) { /* server error — use fallback */ }
  logger.error({ err, context: 'openai_call' });
  throw new ServiceError('AI response unavailable', 503);
}

In production, API calls fail. Rate limits hit. Databases time out. Without error handling, your app either crashes silently or shows users a raw stack trace.

---

2. Secrets in the codebase

I cannot count how many times I have seen this committed to a public or semi-public repo:

OPENAI_API_KEY=sk-proj-...
DATABASE_URL=mongodb+srv://username:password@cluster.mongodb.net/...
JWT_SECRET=mysecretkey123

Sometimes the environment file is not committed, but the key is hardcoded directly in source code:

const openai = new OpenAI({ apiKey: 'sk-proj-abcdef1234...' });

If your repo is ever made public — or if GitHub's secret scanning bots find it — your key is compromised within minutes. I have seen clients receive $3,000 OpenAI bills from this exact scenario.

---

3. No database indices

AI tools write the query. They almost never create the index.

// Fine with 100 users
const user = await User.findOne({ email: req.body.email });

// With 100,000 users and no index on 'email':
// This scans every document — takes 2–8 seconds per query
// While it runs, no other requests can use that DB connection
// Your server appears to hang

Every field you query on in production needs an index. This is one of the most common reasons a working prototype collapses on launch day.

---

4. Synchronous blocking on the main thread

// What AI tools write
app.get('/process', (req, res) => {
  const result = processLargeFile(req.body.file); // takes 3 seconds
  res.json(result);
});

Node.js is single-threaded. While this function runs, no other requests can be handled. With 20 concurrent users, requests queue up and the server falls over.

Fix: offload heavy work to a queue (BullMQ, etc.) and process asynchronously.

---

5. Memory leaks that only appear under load

// Common AI-generated "performance optimisation"
const cache = {};

app.get('/data/:id', async (req, res) => {
  if (!cache[req.params.id]) {
    cache[req.params.id] = await fetchFromDB(req.params.id);
  }
  res.json(cache[req.params.id]);
});

This cache grows forever. After a week in production, your Node.js process is consuming 4GB of RAM and gets killed. The process restarts, users see errors, and you are baffled why it "just stopped working."

---

6. The RAG pipeline that works in demos but fails at scale

This one is subtle and specific to AI-integrated apps.

Demo: 50 test documents, 10 prepared questions. Works perfectly.

Production: 10,000 documents. Users ask questions you never anticipated.

What goes wrong:

• Demo used ideal queries. Real users use synonyms, abbreviations, typos.
• Chunk sizes that worked for 50 docs create retrieval noise at scale.
• No re-ranking step — top cosine similarity result is not always the right answer.
• No confidence threshold — the model answers even when retrieval fails, with hallucinations.

---

7. Rate limiting on the wrong layer (or not at all)

Too aggressive: Rate limiting by IP address. Problem — multiple users from the same company share one IP. You block your entire client.

Not at all: One bot hits your chat API endpoint 2,000 times per minute. Your OpenAI bill is $600 by morning. This actually happens.

---

The Myth: "I Can Just Ask AI to Fix These Problems"

When a vibe-coded app breaks, the instinct is to ask Claude or Cursor to fix it. This is where things get genuinely dangerous.

AI tools fix what you show them, not what they cannot see.

• You show Cursor the error. It fixes that function. It breaks something in a module it did not read.
• The new code works locally. Fails in production for a different reason.
• You prompt-engineer your way into a deeper hole.

I have seen codebases where this loop has gone 50 rounds. The result is a patchwork of partially-applied AI suggestions with no coherent architecture underneath.

AI tools are amplifiers, not engineers. They amplify a skilled engineer's velocity. They amplify an unskilled approach's chaos.

---

What Rescue Actually Looks Like

When I take over a vibe-coded project:

Days 1–2: Audit Read the entire codebase. Document every problem. Prioritise: security first, then data integrity, stability, performance, and maintainability.

Week 1: Critical fixes Secrets into proper environment management. Critical security patches applied. Error handling added to all API endpoints. Database indices created.

Week 2: Stability Heavy operations moved off the main thread. Memory leaks fixed. Rate limiting implemented properly. Logging and monitoring added.

Week 3: Quality Test coverage for critical paths. RAG pipeline re-architected if applicable. Documentation written.

Result: An app that runs in production without you watching it nervously.

---

Should You Use AI Coding Tools?

Yes. Absolutely. But with clear awareness of what they are good at and what they miss.

AI tools are excellent for:

• Scaffolding new features quickly
• Writing boilerplate code
• First-pass implementations you review and refine
• Explaining existing code
• Generating test data

AI tools need human oversight for:

• Security-critical code paths
• Database design and query optimisation
• Error handling and edge cases
• Performance under concurrent load
• Anything handling money or authentication

The best workflow: use AI tools to get to 70% in a day, then bring in an engineer for the rest.

---

If your project is in this state right now — do not panic, it is fixable. Most of the issues above are solvable in 1–3 weeks.

Book a free audit — I will review your codebase, tell you exactly what is wrong, and give you a prioritised fix plan. No commitment required.