שיעור 11. איך מצילים קוד vibe coding שהתרסק

טיפים מעשיים — זה כל מה שצריך

האפליקציה התרסקה. הכניסה שעבדה אתמול לא עובדת. התשלום נגבה פעמיים. ככל שנוגעים בקוד, כך נשבר עוד. לבקש מה-AI “תתקן” רק מחריף את המצב.

לא לבנות מחדש. לבנות מחדש — עוד 3 חודשים זה יתרסק באותו מקום. קודם כל לנעול את המצב הנוכחי.

יש שלושה כלי מבנה:

• codistill — אבחון. מחלץ אוטומטית endpoints של API, סכמת DB ותהליכי אימות מהקוד הקיים.
• huma — נעילה. מציב בדיקות רגרסיה על כל endpoint כדי להגן על ההתנהגות הנוכחית.
• yongol — מעבר. מייצר backend חדש מה-SSOT ומוכיח התנהגות זהה עם הבדיקות הקיימות.

מתקדמים משמאל לימין. לאבחן עם codistill, לנעול עם huma, לעבור עם yongol כשמוכנים.

לסוכן: “הרץ codist scan כדי לחלץ את רשימת ה-endpoints, סכמת ה-DB ותהליכי האימות של הפרויקט.”

המצב הנוכחי מופיע. רואים כמה מתוך 25 endpoints חיים וכמה מתים.

לסוכן: “הרץ huma verify כדי לבדוק את המצב של כל ה-endpoints, ולכל endpoint חי כתוב בדיקת Hurl.”

זה בדיקת הרגרסיה. נועלים מה שעובד עכשיו. כל עוד הבדיקות עוברות, הסוכן יכול לשנות קוד מבלי לשבור את ההתנהגות הקיימת.

לסוכן: “עכשיו תתקן את באג הכניסה. אבל כל בדיקות ה-Hurl חייבות לעבור.”

מתקנים את הבאג מבלי לשבור דבר אחר. מתקנים עם ה-ratchet נעול.

חוויה מהירה

גם בלי אפליקציה שבורה אפשר לחוות. לעבור את התהליך “לבנות → לשבור → להציל” תוך 3 דקות.

שלב 1 — בונים את האפליקציה

ב-Claude Code:

“צור API פשוט לרשימת משימות. 5 endpoints: רשימת משימות, הוספת משימה, עריכת משימה, מחיקת משימה, סימון משימה כהושלמה. הפעל את השרת.”

שלב 2 — מאבחנים עם codist

“הרץ codist scan כדי לחלץ את רשימת ה-endpoints של הפרויקט.”

codist מחלץ אוטומטית את הנתיב, המתודה והפרמטרים של 5 ה-endpoints. זו המפה הנוכחית.

שלב 3 — נועלים עם huma

“הרץ huma verify וכתוב בדיקות Hurl לכל ה-endpoints.”

נוצר קובץ Hurl לכל אחד מ-5 ה-endpoints. ההתנהגות הנוכחית נעולה.

שלב 4 — שוברים בכוונה

“שנה את פורמט התגובה של endpoint עריכת המשימה. שנה את שם השדה title ל-name.”

אחרי השינוי:

“הרץ את בדיקות ה-Hurl.”

הבדיקות נכשלות. “ציפה ל-title אבל קיבל name.” ה-drift נתפס. ה-ratchet עובד.

שלב 5 — מתקנים עם ה-ratchet נעול

“תתקן כך שכל בדיקות ה-Hurl יעברו. אבל גם הפונקציה החדשה שמשתמשת בשדה name חייבת להישמר.”

הסוכן שומר על תאימות לאחור בתיקון. אם Hurl עובר, ההתנהגות הקיימת נשמרת.

זו גרסה מוקטנת של codistill → huma → תיקון. באפליקציה שבורה אמיתית, התהליך הזה מתרחב ל-25, 50, 200 endpoints — העיקרון זהה.

למה לפקד כך

מבוא: הסיבה האמיתית שהאפליקציה שלך התרסקה

ב-2025, מסד הנתונים של 170 אפליקציות שנוצרו עם Lovable נחשף באינטרנט במלואו. מיילים, מפתחות API, פרטי תשלום. הסיבה לא הייתה באג בקוד. ה-AI יצר אפליקציות ללא מדיניות אבטחה, ואף אחד לא בדק.

בינואר 2026, 1.5 מיליון API token דלפו מ-Moltbook, הרשת החברתית ה-AI. אותה סיבה. ה-AI בנה, בני אדם לא בדקו.

זו לא סיפור של מישהו אחר. מי שבנה אפליקציה עם vibe coding יושב על אותו מבנה.

“צור כניסה” — 30 שניות. “הוסף תשלום” — 2 דקות. “הוסף לוח בקרה לניהול” — 5 דקות. שלושה חודשים אחר כך ה-AI “מנקה” את לוגיקת התשלום ומשנה את חישוב ההנחות, פיצ’ר חדש שובר את האימות, ודף שעבד אתמול מחזיר שגיאת 500 היום.

עומדים בפני שתי אפשרויות:

1. לבנות מחדש
2. להציל

לבנות מחדש יכולנו לפני 3 חודשים. הבעיה: לבנות מחדש חוזר על אותם תבניות. drift הוא לא בעיה של קוד — זו בעיה של מבנה.

צריך ללמוד להציל.

חילוץ עצמי של ניצול — 5 שלבים

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

שלב 1. אבחון — מה עדיין חי?

הדבר הראשון לעשות הוא לא לתקן קוד. זה להעריך את המצב הנוכחי.

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

אם 18 מתוך 25 endpoints מחזירים 200, 4 מחזירים 401, ו-3 מחזירים 500 — זו המפה הנוכחית. להתחיל תיקונים בלי מפה פירושו לשבור דברים אחרים בזמן תיקון.

codist scan של codistill מאוטמט עבודה זו. מחלץ endpoints, מודלי נתונים ותהליכי אימות מהקוד הקיים.

שלב 2. נעילה — קודם להגן על מה שחי

אחרי האבחון, לנעול את ה-endpoints החיים.

לסוכן: "כתוב בדיקות Hurl לכל אחד
מ-18 ה-endpoints שמחזירים 200.
קח את התגובה הנוכחית כערך צפוי.
לאלה שדורשים אימות, הרץ קודם
את רצף הכניסה כדי לקבל token."

18 קבצי Hurl אלה הם רשת הביטחון. לא משנה איזה שינוי ייעשה — אם הבדיקות עוברות, ההתנהגות הקיימת נשמרת.

huma verify של huma מארגן תהליך זה. עוקב אחר המצב לכל endpoint וקובע PASS/IMPROVE/FAIL.

חשוב: נעילה חלקית לא מספיקה. אם נועלים רק 10 מתוך 18 endpoints, ה-8 האחרים עלולים להישבר בזמן תיקון מבלי שנדע. נעילה מלאה היא העיקרון.

שלב 3. תיקון — לתקן עם ה-ratchet נעול

עם רשת הביטחון ניתן עכשיו לתקן באגים.

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

זהו היישום המעשי של Ratchet Pattern שנלמד בשיעור 6. לתקן מבלי לשבור. להריץ Hurl אחרי כל תיקון. אם עבר, לעבור לבאג הבא. אם נכשל, לחזור אחורה.

3 ה-endpoints שמחזירים שגיאת 500 מתוקנים באותה דרך. אחרי התיקון מוסיפים בדיקות Hurl חדשות. ה-ratchet נועל עוד שן.

שלב 4. חילוץ — להוציא לוגיקה מהקופסה השחורה

כאן נמצא הגרעין. הסיבה השורשית לקריסת אפליקציה נמצאת בדרך כלל כאן.

אם משתמשים ב-Supabase:

• מדיניות RLS נמצאת רק בלוח הבקרה, לא בקוד
• לוגיקה עסקית מוסתרת ב-Edge Functions
• לוגיקת האימות קשורה ל-Supabase Auth

אם משתמשים ב-Firebase:

• Security Rules נמצאות רק בקונסול
• הלוגיקה מפוזרת ב-Cloud Functions

לא משנה איזה BaaS משתמשים, המבנה זהה. הלוגיקה העסקית נמצאת מחוץ לבסיס הקוד.

לסוכן: "חלץ את כל מדיניות ה-RLS מלוח הבקרה של Supabase.
שמור את מדיניות SELECT, INSERT, UPDATE, DELETE
של כל טבלה בקבצי SQL. תעשה commit ל-git."

לסוכן: "נתח את הלוגיקה העסקית של ה-Edge Functions.
תעד איזו פונקציה מממשת איזו כלל עסקי."

מדובר בהוצאת הלוגיקה מהקופסה השחורה אל בסיס הקוד. אחרי שמוציאים, הסוכן יכול לקרוא, לבדוק ולנעול עם ה-ratchet.

codist ddl של codistill מחלץ DDL מה-DB הקיים. codist scan מחלץ SSOT מהקוד. זה הכלי למעבר מקופסה שחורה לשכבה הצהרתית.

שלב 5. מעבר — רק כשמוכנים

אחרי שלבים 1 עד 4, האפליקציה במצב הזה:

• לכל endpoint יש בדיקות רגרסיה של Hurl
• באגים תוקנו
• הלוגיקה של הקופסה השחורה מתועדת בבסיס הקוד
• ה-ratchet נעול: שינויים חדשים לא שוברים את ההתנהגות הקיימת

במצב הזה מחליטים על המעבר. מ-Supabase ל-backend עצמאי, מ-Deno ל-Go, לא משנה מה.

רשת הביטחון של המעבר היא בדיקות ה-Hurl שנכתבו בשלב 2. מריצים את אותן Hurl על השרת החדש — אם כולן עוברות, מוכח שההתנהגות זהה ללגאסי.

לסוכן: "יצור backend של Go+Gin עם yongol generate.
כל בדיקות ה-Hurl הקיימות חייבות לעבור."

המעבר הוא שלב 5, לא שלב 1. לנסות מעבר בשלב 1 מוביל לכישלון. לקח שאושר ב-onboardings לאחר אירועים.

איך לצאת מ-Supabase

המקרה השכיח ביותר בשיעור 11 הוא Supabase. מתחילים עם vibe coding, שמים הכל על Supabase, וזה מתרסק אחרי 3 חודשים.

סדר היציאה:

1. לשמור את ה-DB ורק לנעול

ה-PostgreSQL של Supabase נשאר כמו שהוא. להחליף את ה-DB זה לאחרון.

codist ddl → חילוץ DDL מהטבלאות הקיימות
huma verify → הערכת מצב ה-endpoints
hurl → נעילה מלאה של כל ה-APIs החיים

2. להעביר לוגיקה לקוד

מדיניות RLS → קבצי Rego. Edge Functions → אנוטציות SSaC. מלוח הבקרה לבסיס הקוד.

3. להפריד אימות

Supabase Auth הוא האחרון שמנתקים. מכיוון שלא ניתן לחלץ hash סיסמאות מ-auth.users, אם בשלב ראשוני (ללא לקוחות) עוברים מיד; אם יש לקוחות, מפעילים תקופת אימות כפול.

4. להעלות שרת חדש ולאמת עם Hurl

yongol generate → יצירת backend של Go+Gin
הרצת כל ה-Hurl → הוכחת התנהגות זהה ללגאסי

אם כל ה-Hurl עוברים, מעבירים את התנועה.

למה לא לבנות מחדש

“אי אפשר פשוט לבנות מחדש?”

לא. שלושה סיבות:

1. אותה תבנית חוזרת

drift הוא בעיית מבנה, לא בעיית קוד. לבנות מחדש ללא ratchet — עוד 3 חודשים זה יתרסק באותו מקום.

2. ידע קבור בלגאסי

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

3. אולי כבר יש לקוחות

יש רגע שבו הפרוטוטייפ הופך לפרודקשן. אם אפילו משתמש אחד קיים, “לבנות מחדש” מלווה במיגרציית נתונים, החלפת אימות, ועצירת שירות.

ללמוד להציל שווה יותר מללמוד לבנות מחדש. כי לגאסי תמיד קיים, וקוד חדש הופך ללגאסי תוך 6 חודשים.

הקשר בין שיעורים 1 עד 10 ושיעור 11

אותם כלים, כיוון הפוך. אם שיעורים 1 עד 10 היו “מלמעלה למטה” (הצהרה → יצירה), שיעור 11 הוא “מלמטה למעלה” (קוד קיים → חילוץ → הצהרה).

codistill הוא הכלי שמאוטמט את “מלמטה למעלה” הזה. מחלץ SSOT מקוד קיים.

מניצול למציל

אחרי תהליך זה יש לך שתי יכולות:

1. לבנות מההתחלה (שיעורים 1 עד 10) — להצהיר, לאמת, לנעול, להנציח
2. להציל את מה שנשבר (שיעור 11) — לאבחן, לנעול, לתקן, לחלץ, לעבור

רוב הקוד בעולם הוא לגאסי. פרויקטים שנבנים מאפס הם נדירים. יכולת ההצלה נדרשת לעתים קרובות יותר.

vibe coding לא נגמר. למדנו לאחוז ברסן.

מאמרים קשורים

• Supabase היא מלכודת של vibe coding — רקע תיאורטי לשיעור 11. למה BaaS מתרסק.
• Hurl מונע drift של vibe coding — פרטים על שלב 2: נעילה.
• codistill — חילוץ SSOT מקוד קיים — הכלי לשלבים 1 ו-4.
• huma — ה-ratchet שלא מפספס אף endpoint — הכלי לשלב 2: נעילה.
• yongol — קיל ה-SaaS של קידוד AI — הכלי לשלב 5: מעבר. יצירת fullstack מ-SSOT.
• בסיס קוד שסוכנים יכולים לעבוד איתו — העיקרון להפיכת קופסה שחורה למפעל.
• tsma — קו ההגנה מרגרסיה של קוד לגאסי — תיקון עם ratchet נעול.
• בניית מערכות שסוכנים יכולים להפעיל — הנגשת לגאסי לסוכנים.

קורס Reins Engineering המלא

מקורות

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• 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 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.