צ׳ק-ליסט: איך לוקחים vibe coding לפרודקשן בלי אסונות

למי זה מתאים: למי שבנה אפליקציה או אתר עם Claude Code, Cursor, Lovable, Bolt או v0, קיבל תוצאה שעובדת על המחשב שלו, ועכשיו צריך להעלות את זה לאנשים אמיתיים בלי שהמסד נתונים יידלף או שהשרת יקרוס ביום שני בבוקר.

מעבר בין "זה עובד אצלי" ל-vibe coding לפרודקשן הוא הפער הכי יקר בתעשייה כרגע. הכלים בנו לך אפליקציה שלמה תוך שעות, אבל אף כלי לא בונה לך אוטומטית מדיניות סודות, rate limiting או error handling הגיוני. זה נשאר עליך, ורוב מי שנכווה - נכווה כי דילג בדיוק על השלב הזה. הצ׳ק-ליסט הזה מסודר לפי סדר עדיפויות אמיתי: מה שיכול להפיל לך את העסק קודם, מה שיכול לעלות לך כסף אחר כך.

למה vibe coding לפרודקשן דורש שכבת בדיקה נפרדת

מודל שפה שכותב קוד אופטימלי למשימה המיידית שהצגת לו - "תבנה לי טופס הרשמה" - לא יודע להניח הנחות שאתה לא ביקשת. הוא לא ידע שאתה צריך rate limiting אלא אם ביקשת את זה במפורש, לא ידע שהמפתח API שהוא שם ב-.env בדוגמה שלו לא אמור להגיע ל-git, ולא ידע שהטבלה ב-Supabase שהוא יצר עם RLS כבוי היא דלת פתוחה לכל מי שיודע להריץ curl.

המחקר של Snyk על vibe coding ומחקרים דומים של Veracode מצביעים על אותו דפוס: קוד שנוצר על ידי LLM עובר יותר בעיות אבטחה בסיסיות (SQL injection, secrets בקוד, חסר input validation) מקוד שנכתב ידנית על ידי מפתח מנוסה - לא כי המודל "טיפש", אלא כי הוא ממטב לתוצאה שעובדת, לא לתוצאה שעמידה. זה בדיוק התפקיד של הצ׳ק-ליסט: לסגור את הפער בין "רץ" ל"בטוח שירוץ בלי להזיק".

אם עוד לא ברור לך מתי vibe coding בכלל מתאים לפרויקט שלך, שווה לקרוא קודם את המדריך מתי כדאי להשתמש בvibe coding ומתי לא - זה חוסך הרבה מהצ׳ק-ליסט הזה מראש.

שלב 1: סודות ו-Environment Variables

זו הבעיה הכי נפוצה וגם הכי קלה לתקן. אם מפתח API, סיסמת מסד נתונים או webhook secret נמצאים בקוד עצמו (hardcoded), הם ב-git history לתמיד גם אם תמחק אותם מהקובץ הבא.

מה לבדוק

• הרץ חיפוש גלובלי אחר sk-, AIza, pk_live, Bearer בכל הריפו - אלה prefixes נפוצים למפתחות אמיתיים.
• ודא שכל secret עובר דרך .env והקובץ .env נמצא ב-.gitignore - לא רק "מהיום", אלא שגם לא נדחף בהיסטוריה.
• אם דלף secret פעם אחת - הוא נחשב "שרוף". מחליפים אותו (rotate), לא רק מוחקים מהקוד.

# בדיקה מהירה לפני push - לא סוף פסוק אבל תופס הרבה
git log -p | grep -E "sk-[a-zA-Z0-9]{20,}|AIzaSy[a-zA-Z0-9_-]{33}"

טיפ: כלים כמו gitleaks או GitHub Secret Scanning (מופעל אוטומטית בריפו ציבורי) תופסים את זה לפני שזה מגיע ל-production. תריץ פעם אחת לפני כל דיפלוי ראשון.

טבלת דירוג סיכונים לפי מקום דליפה נפוץ:

שלב 2: Input Validation ו-Error Handling

כל endpoint שמקבל קלט מהמשתמש - טופס, API route, webhook - צריך לאמת את הקלט לפני שהוא נוגע במסד הנתונים או בלוגיקה עסקית. זה נכון גם אם "רק אני משתמש בזה בינתיים".

דפוס מומלץ: Zod או schema validation בכניסה לכל route

import { z } from "zod";

const leadSchema = z.object({
  name: z.string().min(2).max(80),
  phone: z.string().regex(/^0\d{8,9}$/),
  email: z.string().email().optional(),
});

export async function POST(req: Request) {
  const body = await req.json();
  const parsed = leadSchema.safeParse(body);
  if (!parsed.success) {
    return Response.json({ error: "invalid_input" }, { status: 400 });
  }
  // ...
}

כללי ברזל ל-error handling

• אין להחזיר ללקוח stack trace, שם טבלה במסד נתונים, או הודעת שגיאה גולמית מה-ORM. זה מידע שמסייע לתוקף.
• כל שגיאה פנימית נרשמת בלוג (Sentry, LogRocket, או פשוט console.error עם מזהה ייחודי) ומוחזר ללקוח מזהה קצר במקום הפרטים המלאים.
• לכל endpoint ציבורי - גם טופס יצירת קשר קטן - יש rate limiting. שירותים כמו Upstash Ratelimit או Vercel WAF נותנים את זה כמעט חינם.

אזהרה: טופס ליד פשוט בלי rate limiting הוא הדבר הראשון שבוטים סורקים אחריו. ראינו טפסים שקיבלו 4,000 שליחות ספאם ביום אחד כי לא הייתה שום הגנה. אם אתה בונה טופס לידים, המדריך טפסי יצירת קשר עם EmailJS ו-Resend מסביר גם איך למנוע את זה, ומדריך זיהוי בוטים 2026 מרחיב על השכבה הזו.

שלב 3: Authentication ו-Authorization

זו הנקודה שבה הכי הרבה אפליקציות vibe-coded נכשלות בשקט - האפליקציה "עובדת", אבל כל משתמש מחובר יכול לראות את הנתונים של כל משתמש אחר.

הבדל קריטי: Authentication מול Authorization

Authentication עונה על "מי אתה" - התחברות תקינה. Authorization עונה על "מה מותר לך" - וזה מה שבדרך כלל חסר. Row Level Security (RLS) ב-Supabase או Firestore Security Rules ב-Firebase הם המנגנון שאוכף את זה ברמת מסד הנתונים, לא רק ברמת הקוד.

// דוגמת Firestore rule - משתמש רואה רק את המסמכים שלו
match /leads/{leadId} {
  allow read: if request.auth != null && resource.data.ownerId == request.auth.uid;
  allow write: if request.auth != null && request.resource.data.ownerId == request.auth.uid;
}

רשימת בדיקה מהירה

• נסה לגשת ל-API עם token של משתמש A ולבקש נתונים של משתמש B - זה צריך להיכשל.
• ודא שכל route בפאנל ניהול (admin) בודק role, לא רק "האם מחובר".
• אם עברת מ-Base44 או פלטפורמת no-code אחרת, בדוק את כללי הגישה מחדש - הם לא תמיד עוברים נכון בהעברה. המדריך מעבר מ-Base44 ל-Firebase נותן צ׳ק-ליסט ייעודי למעבר הזה.

שלב 4: ביצועים ו-Core Web Vitals

אפליקציית vibe coding לרוב "עובדת מהר" בסביבת פיתוח כי יש 3 רשומות בטבלה. בפרודקשן עם 50,000 רשומות ותמונות לא ממוטבות, זה משהו אחר לגמרי.

מדד את זה עם Lighthouse ו-PageSpeed Insights לפני עלייה לאוויר, לא אחרי. המדריך Core Web Vitals 2026 מפרט את הספים המדויקים ואיך לשפר כל metric בנפרד.

שלב 5: בדיקות (Testing) - כמה זה מספיק

אין צורך ב-100% coverage לפני production. יש צורך בכיסוי של הנתיבים הקריטיים: תשלום, הרשמה, שליחת ליד, ומחיקת נתונים.

מינימום סביר לפני עלייה לאוויר

• בדיקת E2E אחת לפחות על ה-happy path המרכזי (Playwright או Cypress) - המשתמש נכנס, ממלא טופס, מקבל אישור.
• בדיקת unit לכל פונקציית validation ולוגיקה עסקית קריטית (חישוב מחיר, הרשאות).
• בדיקה ידנית של מצבי קצה: מה קורה כשה-API חיצוני (תשלומים, WhatsApp, מייל) נופל? האם המשתמש מקבל הודעת שגיאה ברורה או מסך לבן?
• אם משתמשים ב-AI agents בתוך המוצר עצמו, שווה להכיר eval-driven development - גישה שמתאימה יותר מטסטים קלאסיים כשיש רכיב לא-דטרמיניסטי.

טיפ: תן ל-Claude Code לכתוב את הבדיקות אחרי שהפיצ׳ר מוכן, לא לפני - ותמיד תקרא אותן. מודל שמייצר גם קוד וגם טסט לאותו קוד נוטה "לאשר את עצמו" בלי לתפוס את הבאג האמיתי.

שלב 6: ניטור ואיתות תקלות אחרי שהאתר באוויר

Production בלי ניטור זה כמו לנהוג עם עיניים עצומות. חובה שני דברים ביום הראשון:

1. Error tracking - Sentry (חינם עד 5,000 events בחודש) שיתפוס כל exception לא מטופל ויתריע אליך.
2. Uptime monitoring - UptimeRobot או Better Stack שיבדקו כל 5 דקות שהאתר בכלל עונה, ויתריעו ב-WhatsApp/מייל אם נפל.

זה ההבדל בין "לגלות מלקוח כועס אחרי 3 ימים" ל"לתקן תוך 10 דקות לפני שמישהו שם לב".

שלב 7: גיבויים ו-Rollback

לפני כל דיפלוי גדול תשאל: אם זה ישבור משהו, איך אני חוזר אחורה תוך 5 דקות?

• מסד נתונים: גיבוי אוטומטי יומי לפחות (Supabase ו-Firebase נותנים את זה, אבל צריך להפעיל במפורש).
• קוד: לפרוס דרך Git tags/releases כדי שיהיה לך commit ברור לחזור אליו, לא "הדחיפה האחרונה".
• Hosting: Vercel ו-Firebase Hosting שומרים deployments קודמים - תדע מראש איך עושים rollback בממשק לפני שאתה צריך את זה בלחץ. השוואה מלאה בין הפלטפורמות ב-Vercel מול Firebase Hosting.

שלב 8: סקירת קוד לפני שילוב (Code Review)

גם אם אתה לבד, שכבת סקירה שנייה - בין אם זו סוכן AI ייעודי ובין אם עצירה של 20 דקות למחרת בבוקר לפני שדוחפים - תופסת טעויות שקל לפספס תוך כדי בנייה מהירה. כלים כמו סקירת קוד עם AI יכולים לרוץ אוטומטית על כל Pull Request ולסמן דפוסי סיכון נפוצים (secrets, SQL injection, חסר error handling) לפני שהקוד בכלל מגיע אליך לעיון.

שאלות נפוצות

כמה זמן לוקח להעביר פרויקט vibe-coded ל-production מוכן?

תלוי בהיקף, אבל לפרויקט בגודל בינוני (טופס לידים, פאנל ניהול קטן, 10-20 מסכים) מדובר בדרך כלל ב-3-6 ימי עבודה נוספים מעבר לבנייה עצמה - רובם בשלבי אבטחה, טיפול בשגיאות ובדיקות. אם דילגת על validation ו-RLS לגמרי בבנייה הראשונית, זה יכול לקחת יותר כי צריך לשכתב לוגיקה קיימת.

האם חובה להשתמש ב-TypeScript כדי לעלות לפרודקשן בבטחה?

לא חובה, אבל זה מפחית משמעותית שגיאות runtime שנובעות מטעויות טיפוסים - בדיוק סוג הבאג שקל לפספס בקוד שנוצר מהר על ידי AI. אם הפרויקט כבר ב-JavaScript, לפחות תוסיף JSDoc types ו-schema validation (Zod) בגבולות המערכת - קלט מהמשתמש, תשובות API חיצוני.

מה ההבדל בין בדיקת אבטחה ידנית לסריקה אוטומטית?

סריקה אוטומטית (Snyk, gitleaks, npm audit) תופסת פגיעויות ידועות בספריות וסודות שדלפו - זה מהיר וזול וכדאי להריץ בכל דיפלוי. בדיקה ידנית או pentest תופסת בעיות לוגיות כמו authorization שבור, שסורק אוטומטי לא מבין כי הוא לא יודע מה "אמור" לקרות בעסק שלך. שתי השכבות משלימות, לא מחליפות זו את זו.

האם צריך rate limiting גם באתר קטן עם מעט תנועה?

כן, וזה בדיוק ההפך ממה שנראה הגיוני. אתרים קטנים הם המטרה הכי קלה לבוטים כי אין להם שום הגנה, בעוד שאתרים גדולים כבר מוגנים. עלות הטמעה של rate limiting בסיסי (Upstash, Cloudflare Rate Limiting) היא כמה שורות קוד ולרוב חינמית בהיקפים קטנים.

מה קורה אם כבר עליתי לפרודקשן בלי לעבור על הצ׳ק-ליסט הזה?

תתחיל מהסודות - זה הכי דחוף ולוקח הכי פחות זמן לתקן. אחר כך RLS/Authorization כי זו הפרצה הכי יקרה אם מנוצלת. Performance ו-monitoring אפשר להוסיף בהדרגה בלי לעצור את המוצר, אבל אבטחה לא מחכה לספרינט הבא.

סיכום ואיפה להתחיל

אם יש לך רק שעה אחת לפני שהאתר עולה לאוויר: תבדוק סודות, תפעיל RLS/Authorization, ותוסיף rate limiting לכל טופס ציבורי. שאר הרשימה חשובה, אבל השלושה האלה הם ההבדל בין "יש באג" ל"דלף מסד הנתונים של הלקוחות".

רוצים שמישהו שעשה את זה עשרות פעמים יעבור איתכם על הפרויקט הספציפי שלכם? קבעו שיחת ייעוץ קצרה של 30 דקות, ללא עלות, דרך טופס יצירת קשר או ישירות בוואטסאפ ל-wa.me/972585802298.

מקורות

• OWASP Top 10 - רשימת הסיכונים המרכזית לאבטחת אפליקציות ווב
• Supabase Row Level Security Docs
• Firebase Security Rules Docs
• web.dev Core Web Vitals
• Sentry Documentation
• gitleaks - Secret Scanning