Image: AI generated
קסם ה-30 שניות
“תבנה לי backend.” הבינה המלאכותית ממליצה על Supabase. כתובת URL אחת ו-PostgreSQL, אימות, אחסון ומנויים בזמן אמת מחוברים. הכניסה עובדת תוך 30 שניות. ה-CRUD מוכן תוך 2 דקות.
שלושה חודשים לאחר מכן, אף אחד לא יודע מי כתב את מדיניות ה-RLS (Row Level Security) הזאת.
מדוע הבינה המלאכותית ממליצה עליה
Supabase הפכה לברירת המחדל של vibe coding לא בגלל עליונות טכנית. אלא מפני שנתוני האימון מלאים במדריכים.
Cursor, Bolt, v0, Lovable — בכל כלי קידוד בבינה מלאכותית שהוא, הקלד “תבנה לי backend” ו-Supabase מופיעה. הבינה המלאכותית ממליצה על התבנית שראתה הכי הרבה. לא על התבנית הטובה ביותר.
Zhang et al. (ACL 2025) הוכיחו אמפירית שכי 7 מודלי LLM מעדיפים ספקים מסוימים באופן שיטתי ללא הוראה מפורשת, ומשנים קוד קלט באופן אוטונומי כדי להכניס את הספק המועדף. המשתמש מאמין שמה שהבינה המלאכותית ממליצה עליו הוא האופטימלי. הבינה המלאכותית ממליצה על מה שמופיע הכי הרבה בנתוני האימון שלה. זוהי גרסת התשתית של הטיית החנופה.
כשמסתירים לוגיקה בקופסה שחורה
הבעיה האמיתית של Supabase אינה Supabase עצמה. הבעיה היא שהלוגיקה העסקית נכנסת לקופסה שחורה.
1. מדיניות RLS = לוגיקה עסקית מוסתרת
Row Level Security היא פונקציונליות רבת עוצמה. הבעיה היא: כאשר הבינה המלאכותית יוצרת מדיניות RLS, היכן היא גרה?
- לא בקוד. היא נמצאת בלוח הבקרה של Supabase.
- לא ב-git. אין ניהול גרסאות.
- לא בבדיקות. אין אימות ב-CI.
התשובה לשאלה “מי יכול לגשת לטבלה הזאת?” אינה קיימת ב-codebase. צריך להתחבר למסוף Supabase כדי לבדוק. סוכן אינו יכול לקרוא זאת.
אם הבינה המלאכותית משנה מדיניות RLS כדי ל"סדר"? האימות נפרץ. אף אחד לא יודע, כי אין בדיקות. גלוי רק לאחר חשיפת נתוני לקוחות בסביבת הייצור.
זאת אינה השערה. ב-CVE-2025-48757 בשנת 2025, למעלה מ-170 אפליקציות שנוצרו על ידי Lovable חשפו את כל מסד הנתונים של Supabase בגלל היעדר RLS. 303 נקודות קצה פגיעות, כתובות דוא"ל, מפתחות API ומידע תשלומים דלפו. בינואר 2026, הרשת החברתית מבוססת הבינה המלאכותית Moltbook נפרסה עם RLS מבוטל, ו-1.5 מיליון API token ו-35,000 כתובות דוא"ל נחשפו.
2. Edge Functions = קופסה שחורה שנייה
הלוגיקה העסקית גרה בשני מקומות. בקוד ה-frontend ובSupabase Edge Functions. הבינה המלאכותית צריכה להחליט איזה לוגיקה נמצאת היכן. הבינה המלאכותית טועה בהחלטה הזאת.
חישוב הנחת תשלום נמצא ב-Edge Function. בעת ה-refactoring של ה-frontend, הבינה המלאכותית יוצרת מחדש את אותו החישוב ב-frontend. עכשיו ההנחה מוחלת פעמיים. גלוי שלושה שבועות לאחר מכן בדוח ההכנסות.
3. מיגרציה = עלות היציאה
עזיבת Supabase דורשת פירוק ארבעה דברים בו-זמנית:
- Auth — מבנה JWT הקשור ל-Supabase Auth, callbacks של OAuth, ניהול סשן
- Storage — מבנה bucket, מדיניות גישה, חתימת URL
- Realtime — מנויי WebSocket, ערוצי Presence
- מדיניות RLS — כל הכללים העסקיים הלא מתועדים
כל פריט נראה כאחד שיסתיים ביום אחד, אך ארבעתם שזורים זה בזה. שינוי ב-Auth שובר את ה-RLS, RLS שבור משחרר גישה ל-Storage, שינוי ב-URL של Storage שובר את ה-frontend.
זהו vendor lock-in. הכניסה לוקחת 30 שניות, היציאה לוקחת 3 חודשים.
גרסת הענן של גיהינום הפורטים
גיהינום הפורטים שחווה ה-vibe coder בסביבה המקומית — הבינה המלאכותית מפעילה שרתים, לא עוצרת אותם, פורטים מתבלבלים, לא יודעים מה רץ — עולה עם Supabase לרמת התשתית.
גיהינום פורטים מקומי: התהליכים אינם נראים. גיהינום Supabase: הלוגיקה העסקית אינה נראית.
לשניהם יש אותה מבנה. מה שהסוכן יצר, הסוכן אינו יכול לעקוב אחריו.
מה החלופה?
לא מדובר על כך שלא להשתמש ב-Supabase. מדובר על כך שלא להכניס לוגיקה עסקית לקופסה שחורה.
עיקרון: כל ההחלטות חייבות לגור ב-codebase.
- כללי אימות → מוצהרים בקוד, מאומתים בבדיקות
- מדיניות גישה → מוצהרת ב-DDL + Rego, מאומתת ב-CI
- לוגיקה עסקית → במקום אחד בלבד, ללא כפילות
- הגדרות תשתית → מוצהרות ב-Terraform/IaC, מגורסאות ב-git
שימוש ב-Supabase לאב טיפוס הוא סביר. אך ברגע שמביאים אב טיפוס לייצור, הלוגיקה שבתוך הקופסה השחורה חייבת לצאת ממנה ולעבור לשכבה הצהרתית.
כדי שקסם ה-30 שניות לא יהפוך ל-3 חודשים של כאב.
האם מדיניות ה-RLS שלך נמצאת ב-git?
האם ל-Edge Functions שלך יש בדיקות?
האם אתה בטוח שאם הבינה המלאכותית “תסדר”, האימות לא יינפרץ?
Supabase אינה הבעיה. הסתרת החלטות במקומות שאינם גלויים — זאת הבעיה.
מאמרים קשורים
- Reins Engineering — בינה מלאכותית עם רסן — הצד ההפוך של הקופסה השחורה. הפעלת סוכנים באמצעות חוזים דטרמיניסטיים.
- Hurl מונע את הסחף של vibe coding — הצהרת התנהגות API כ-plain text ונעילתה עם ratchet. אם RLS נמצאת מחוץ ל-codebase, גם Hurl לא יכול לתפוס אותה.
- Codebase שסוכנים יכולים לפעול בו — ממשק משתמש של לוח בקרה אינו קריא, אינו ניתן לאימות ואינו ניתן להתמדה על ידי סוכן. ה-codebase חייב להיות המפעל.
- הטיית החנופה של בינה מלאכותית היא פונקציה עסקית — המנגנון שבו הבינה המלאכותית ממליצה על Supabase. תן דעה — היא מחניפה; תן עובדה — היא מתקנת.
- yongol — עמוד השדרה של SaaS לקידוד בבינה מלאכותית — החלופה לקופסה השחורה. הצהרת החלטות ב-10 SSOT ואימות צולב.
מקורות
- Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
- CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
- OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
- Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
- Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
- Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
- Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev