Vibe-Coded Prototypes: How to Harden Them

The Scenario

You used AI to ship a prototype fast. It works. Users are signing up. But now you’re worried:

• Is it secure?
• Will it scale?
• Can I maintain it?

You’re right to worry. Prototypes optimized for speed rarely ship production-ready code.

The Gap

Here’s what AI-generated code typically lacks:

1. Error Handling

What AI does:

const user = await db.users.findUnique({ where: { id } });
return user.email;

What production needs:

const user = await db.users.findUnique({ where: { id } });
if (!user) {
  throw new NotFoundError("User not found");
}
return user.email;

Fix: Add null checks, try/catch blocks, and graceful degradation.

Antipattern: According to Release It! by Michael T. Nygard (2018), failing silently or returning undefined for missing resources creates cascading failures. Explicit error handling with typed exceptions enables better observability and recovery.

2. Input Validation

What AI does:

app.post("/api/users", async (req, res) => {
  const user = await createUser(req.body);
  res.json(user);
});

What production needs:

const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
});

app.post("/api/users", async (req, res) => {
  const data = CreateUserSchema.parse(req.body); // Throws if invalid
  const user = await createUser(data);
  res.json(user);
});

Fix: Use Zod (or similar) on all external inputs.

Security Rationale: OWASP Top 10 (2021) lists “Injection” (A03) as a critical vulnerability. Server-side validation with schema enforcement is the first line of defense against injection attacks, SQL injection, and malformed data exploitation.

Reference: OWASP Foundation. (2021). A03:2021 – Injection. https://owasp.org/Top10/A03_2021-Injection/

3. Authentication

What AI does:

const token = jwt.sign({ userId }, SECRET);
res.cookie("token", token);

What production needs:

const token = jwt.sign({ userId }, SECRET, { expiresIn: "1h" });
res.cookie("token", token, {
  httpOnly: true,
  secure: true,
  sameSite: "strict",
  maxAge: 3600000,
});

Fix: Secure cookies, expiration, and session management.

Security Best Practices:

• httpOnly: Prevents JavaScript access, mitigates XSS attacks
• secure: HTTPS-only transmission, prevents man-in-the-middle
• sameSite: “strict”: CSRF protection by preventing cross-origin cookie transmission
• Short expiration: Limits damage from token compromise

Reference: OWASP. (2021). A07:2021 – Identification and Authentication Failures. https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

4. Database Queries

What AI does:

const users = await db.users.findMany(); // Returns ALL users

What production needs:

const users = await db.users.findMany({
  take: 50,
  skip: page * 50,
  select: { id: true, email: true }, // Don't return passwords
});

Fix: Pagination, indexing, and field selection.

Performance Impact: Loading all records into memory causes:

1. Memory exhaustion at scale (OOM errors)
2. Slow response times proportional to table size
3. Database load from full table scans

Solution: Cursor-based pagination for large datasets, offset-based for smaller ones. Always use SELECT with explicit fields to avoid over-fetching.

Reference: Karwin, B. (2010). SQL Antipatterns: Avoiding the Pitfalls of Database Programming. Pragmatic Bookshelf. (Chapter on “Avoiding SELECT *“)

The Hardening Process

Step 1: Security Audit (1-2 days)

Run through OWASP Top 10:

1. Broken access control - Check authorization on every protected endpoint
2. Cryptographic failures - Verify encryption at rest and in transit
3. Injection - Parameterized queries, input validation
4. Insecure design - Threat modeling, security requirements
5. Security misconfiguration - Default credentials, unnecessary features enabled
6. Vulnerable components - Outdated dependencies with known CVEs
7. Authentication failures - Weak passwords, missing MFA, session fixation
8. Data integrity failures - Missing signature verification, insecure deserialization
9. Logging failures - No audit trail for security events
10. SSRF - Unvalidated URLs in backend requests

Reference: OWASP Foundation. (2021). OWASP Top 10 - 2021. https://owasp.org/www-project-top-ten/

Tools:

• npm audit (built-in Node.js vulnerability scanner)
• Snyk (commercial, free tier available) - https://snyk.io
• Semgrep (open-source static analysis) - https://semgrep.dev

Step 2: Type Safety (1 day)

• Enable TypeScript strict mode
• Add Zod schemas for all external inputs
• Remove any and @ts-ignore

Strict Mode Benefits: Microsoft Research found that static type checking can detect approximately 15% of bugs in JavaScript codebases (Gao et al., 2017). TypeScript’s strict mode provides enhanced safety through specific compiler flags:

• strictNullChecks: Prevents “Cannot read property of undefined” errors
• strictFunctionTypes: Catches function parameter mismatches
• noImplicitAny: Forces explicit type declarations

Reference: Gao, Z., Bird, C., & Barr, E. T. (2017). To Type or Not to Type: Quantifying Detectable Bugs in JavaScript. ICSE 2017. https://www.microsoft.com/en-us/research/publication/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/

Step 3: Observability (1 day)

• Replace console.log with structured logging
• Add error tracking (Sentry, LogRocket, etc.)
• Instrument critical operations

Structured Logging Format (JSON):

logger.info({
  message: "User login successful",
  userId: user.id,
  ipAddress: req.ip,
  timestamp: new Date().toISOString(),
  traceId: req.headers["x-trace-id"],
});

Why Structured Logs? Machine-parseable logs enable:

• Automated alerting on error patterns
• Log aggregation and search (ELK stack, Datadog)
• Distributed tracing across microservices

Reference: OpenTelemetry. (2026). Logging Specification. https://opentelemetry.io/docs/specs/otel/logs/

Step 4: Testing (2-3 days)

• Write tests for critical paths (auth, payments, data mutations)
• Add end-to-end tests for user flows
• Set up CI to run tests pre-merge

Testing Strategy:

1. Unit tests (70%): Business logic, pure functions, validation rules
2. Integration tests (20%): API endpoints, database interactions
3. E2E tests (10%): Critical user journeys (signup, checkout, core workflow)

Coverage Target: Aim for 80% code coverage on critical modules (auth, payments, data mutations). Don’t chase 100% coverage; focus on high-risk code.

Reference: Fowler, M. (2012). TestPyramid. https://martinfowler.com/bliki/TestPyramid.html

Step 5: Deployment (1 day)

• Document environment variables
• Set up staging environment
• Create rollback plan
• Write runbook for common incidents

Blue-Green Deployment Pattern: Run two identical production environments (“blue” and “green”). Deploy to idle environment, smoke test, then switch traffic. Instant rollback if issues detected.

Reference: Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional.

Estimated Effort

For a typical MVP (5-10 API endpoints, 3-5 pages):

• DIY: 1-2 weeks (if you know what you’re doing)
• Agent Xero Custom Build: 3-5 days (we do it for you)
• Agent Xero Session: 1-3 hours (we give you the checklist + guidance)

When to Hire Help

DIY if:

• You’re a senior engineer with production experience
• You have time to learn
• The risk is low (internal tool, no user data)

Hire if:

• You’re early-stage and need to ship fast
• You’re handling sensitive data (payments, PII, health data)
• You don’t have production experience

---

Ready to harden your prototype? Request a custom build →

---

References

1. Nygard, M. T. (2018). Release It! Design and Deploy Production-Ready Software (2nd ed.). Pragmatic Bookshelf.
2. OWASP Foundation. (2021). OWASP Top Ten Application Security Risks. https://owasp.org/Top10/2021
3. Karwin, B. (2010). SQL Antipatterns: Avoiding the Pitfalls of Database Programming. Pragmatic Bookshelf.
4. Gao, Z., Bird, C., & Barr, E. T. (2017). To Type or Not to Type: Quantifying Detectable Bugs in JavaScript. ICSE 2017. Microsoft Research.
5. OpenTelemetry. (2026). OpenTelemetry Logging Specification. https://opentelemetry.io/docs/specs/otel/logs/
6. Fowler, M. (2012). Test Pyramid. https://martinfowler.com/bliki/TestPyramid.html
7. Humble, J., & Farley, D. (2010). Continuous Delivery. Addison-Wesley Professional.

Last verified: February 2026