איך לייצא פרויקט מ-Lovable ולבנות אותו מחדש עם קלוד קוד — המדריך המלא בעברית 2026

כדי לייצא פרויקט מלאבבל (Lovable) ולהמשיך לפתח אותו עם קלוד קוד (Claude Code), מחברים את הפרויקט ל-GitHub (סנכרון דו-כיווני מובנה וחינמי), משכפלים את הריפוזיטורי למחשב, ופותחים אותו בקלוד קוד — שממפה את הפרויקט, מחבר מחדש את Supabase ופורס ל-Vercel. הקוד שנוצר בלאבבל הוא React + Vite + TypeScript סטנדרטי לחלוטין, כך שהמעבר לא דורש "המרה" — רק חיבור מחדש של החלקים המנוהלים: סודות, פונקציות צד-שרת ודומיין. מעבר טיפוסי לוקח 2–4 שעות, ובסופו אתם הבעלים המלאים של 100% מהקוד.

זה המדריך המלא, צעד אחר צעד, כולל פרומפטים מוכנים להעתקה — נכון ליולי 2026.

מה זה בעצם "ייצוא מ-Lovable לקלוד קוד"?

הגדרה: ייצוא מלאבבל (Lovable) לקלוד קוד (Claude Code) הוא תהליך שבו לוקחים פרויקט שנבנה בצ'אט של לאבבל, מוציאים את קוד המקור שלו לריפוזיטורי GitHub בבעלותכם, ומעבירים את המשך הפיתוח לסוכן קוד שרץ מקומית בטרמינל — עם שליטה מלאה בקוד, ב-Git, בסביבת ההרצה ובפריסה.

חשוב לדייק את המילה "ייצוא": זה לא ייצוא במובן של קובץ ZIP חד-פעמי. לאבבל מציעה סנכרון דו-כיווני חי עם GitHub — כל שינוי שנשמר בלאבבל נדחף אוטומטית לריפוזיטורי, וכל commit שנדחף ל-GitHub מופיע בלאבבל תוך שניות. המשמעות: המעבר לקלוד קוד יכול להיות חד (עוזבים את לאבבל לגמרי) או הדרגתי (עובדים בשני הכלים במקביל על אותו קוד). את המודל ההיברידי פירטנו בהרחבה במדריך Workflow משולב של לאבבל, קלוד קוד ו-GitHub — וכאן נתמקד בתרחיש המלא: יציאה מסודרת ובנייה מחדש של סביבת פיתוח עצמאית.

ומה זה קלוד קוד? בקצרה: סוכן קוד של Anthropic שרץ בטרמינל, קורא ועורך קבצים במחשב שלכם, מריץ פקודות, עושה commit-ים ופורס לפרודקשן — הכול בשיחה בשפה חופשית, כולל עברית. יש לנו עמוד מלא על קלוד קוד למי שפוגש אותו פעם ראשונה, והמדריך הזה מניח היכרות בסיסית בלבד.

למה אנשים "גדלים מעבר" ללאבבל — ולמה זה בסדר גמור

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

1. עלות הקרדיטים בקנה מידה

לאבבל מתמחרת לפי קרדיטים, וכל הודעה בצ'אט עולה מספר קרדיטים משתנה לפי מורכבות הבקשה — תיקון סטייל קטן עולה חלקיק קרדיט, ופיצ'ר שלם עם לוגיקה יכול לעלות פי כמה. במסלול ה-Pro הבסיסי מקבלים כ-100 קרדיטים חודשיים (נכון ליולי 2026), וסולם הקרדיטים מטפס במחיר ככל שצריך יותר. בפרוטוטייפ זה זול להפליא. אבל כשמתחזקים מוצר אמיתי — תיקוני באגים, שיפורים שוטפים, ניסויים — הקרדיטים נשרפים על עבודה שוטפת, ומעל זה מצטרף חיוב שימוש נפרד על תשתית Lovable Cloud שהאפליקציה צורכת בזמן ריצה. התוצאה: החשבון החודשי האמיתי גבוה משמעותית ממחיר המנוי המוצהר.

2. לולאת העריכה בשינויים מורכבים

זו התלונה הנפוצה ביותר: מבקשים שינוי, לאבבל מבצעת, אבל שוברת משהו אחר. מבקשים תיקון — והתיקון שובר את השינוי הראשון. כל סיבוב בלולאה הזאת עולה קרדיטים, וככל שהפרויקט גדול ומסובך יותר, הלולאה מתארכת. זו לא רשלנות של לאבבל — זו מגבלה מובנית של עריכה דרך צ'אט בדפדפן, בלי יכולת אמיתית לחקור את הקוד, להריץ בדיקות מקומית ולעבוד בצעדים קטנים עם ביקורת. סוכן טרמינל כמו קלוד קוד בנוי בדיוק לתרחיש הזה: הוא קורא את כל הקבצים הרלוונטיים לפני שינוי, מריץ את הפרויקט, בודק שלא נשבר כלום, ומתקן את עצמו באותה שיחה.

3. חשש מנעילה לספק (Vendor Lock-in)

עסק שבנה מוצר אמיתי שואל בצדק: מה קורה אם המחירים יעלו? אם השירות ישתנה? אם נרצה מפתח אנושי שיצטרף? החדשות הטובות — ובזה לאבבל דווקא ראויה למחמאה — היא שהנעילה קטנה בהרבה ממה שמקובל לחשוב. הקוד ניתן לייצוא מלא, ומאז יולי 2026 גם ל-Lovable Cloud (הבקאנד המנוהל) יש כפתור ייצוא רשמי. אבל "אפשר לצאת" ו"יצאנו בפועל" הם שני דברים שונים — והמדריך הזה סוגר את הפער.

4. הצורך בשליטה מלאה

בשלב מסוים רוצים דברים שבונה חזותי לא נותן: בדיקות אוטומטיות, CI/CD, סביבות staging, אינטגרציות מותאמות, אוטומציות תזמון, גישה ישירה לדאטהבייס. אלה בדיוק החוזקות של עבודה מקומית עם קלוד קוד.

💡 מהשטח: אני מלווה מעל 100 ארגונים בהטמעת AI, והדפוס חוזר על עצמו: הלקוחות הכי מרוצים הם דווקא אלה שהתחילו בלאבבל. הם הגיעו עם מוצר עובד, משתמשים אמיתיים והבנה מדויקת של מה חסר — במקום עם רעיון על נייר. המעבר לקלוד קוד אצלם הוא לא "תיקון טעות", הוא שלב התבגרות טבעי. מי שמתבייש שהתחיל בכלי No-Code פשוט לא מבין כמה זמן וכסף הוא חסך.

מה זה פרויקט לאבבל מתחת למכסה — ולמה זה חדשות מצוינות

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

רכיב	טכנולוגיה	מה זה אומר בפועל
שפה	TypeScript	סטנדרט התעשייה, כל מפתח וכל כלי AI מכירים
ספריית UI	React	הספרייה הפופולרית בעולם לממשקים
כלי בנייה	Vite	מהיר, סטנדרטי, נתמך בכל פלטפורמת פריסה
עיצוב	Tailwind CSS + shadcn/ui	קלאסים בקוד + קומפוננטות מוכנות שיושבות אצלכם בפרויקט
בקאנד	Supabase (או Lovable Cloud, שבנוי על Supabase)	דאטהבייס PostgreSQL, אימות, אחסון ופונקציות ענן

שימו לב מה אין בטבלה: פורמט קנייני. אין "קובץ לאבבל" מיוחד, אין שכבת תרגום, אין ריצה על שרת סודי של לאבבל. מה שנוצר בצ'אט הוא פרויקט ווב סטנדרטי לגמרי שכל מפתח — אנושי או AI — יכול להרים תוך דקות. זה ההבדל העצום בין לאבבל לבין דור קודם של בוני אתרים, שבהם "הייצוא" היה בדיה שיווקית.

ויותר מזה: המחסנית הזאת היא בדיוק אזור הנוחות של קלוד קוד. React, Vite, Tailwind, shadcn ו-Supabase הם מהטכנולוגיות המתועדות והנפוצות ביותר בעולם, וסוכני קוד עובדים איתן מצוין. גם העובדה שהבקאנד הוא Supabase משחקת לטובתכם — יש לנו מדריך שלם על קלוד קוד עם Supabase, והצמד הזה הוא אחד השילובים החזקים שקיימים לפיתוח מהיר.

שני קבצים ספציפיים ללאבבל כן תמצאו בפרויקט, ושניהם לא מזיקים: תלות פיתוח בשם lovable-tagger (מסמנת קומפוננטות כדי שהעורך החזותי של לאבבל ידע על מה לחצתם) ואזכור שלה ב-vite.config.ts. נטפל בהם בהמשך — זה ניקוי של שתי דקות.

שלב הייצוא: חיבור GitHub — הדרך המרכזית החוצה

GitHub הוא צינור הייצוא הרשמי, החינמי והדו-כיווני של לאבבל. כך מחברים:

חיבור הפרויקט לריפוזיטורי

1. פתחו את הפרויקט בלאבבל ולחצו על GitHub בסרגל העליון (או דרך הגדרות הפרויקט, תלוי בגרסת הממשק).
2. אשרו את ההרשאות — לאבבל תבקש גישה לחשבון ה-GitHub שלכם (או לארגון). מומלץ לאשר גישה ברמת הריפוזיטורי הספציפי בלבד.
3. לאבבל יוצרת ריפוזיטורי חדש ודוחפת אליו את כל קוד הפרויקט כ-commit ראשון. מרגע זה הסנכרון דו-כיווני: כל שמירה בלאבבל נדחפת ל-GitHub אוטומטית, וכל push ל-branch הראשי (main) מופיע בלאבבל תוך שניות.

שלושה כללים שחוסכים כאב לב

• הסנכרון עובד רק על main. עבודה על branches אחרים אפשרית ב-GitHub, אבל לאבבל רואה ומסנכרנת רק את ברירת המחדל.
• לעולם אל תשנו שם, תעבירו או תמחקו את הריפוזיטורי המחובר. זה שובר את הסנכרון באופן בלתי הפיך. אם אתם מתכננים ניתוק מלא מלאבבל — קודם משלימים את המעבר, ורק אז נוגעים בריפו.
• היזהרו מקונפליקטים. אם עורכים בו-זמנית בלאבבל ובמקומי, שני הצדדים דוחפים ל-main ויכולים להתנגש. בתקופת המעבר קבעו כלל פשוט: עורכים רק בצד אחד בכל רגע נתון.

מה בדיוק בבעלותכם אחרי החיבור

הכול. 100% מקוד המקור — כל קומפוננטה, כל עמוד, כל hook, כל קובץ קונפיגורציה — יושב בריפוזיטורי בחשבון ה-GitHub שלכם, תחת הבעלות המשפטית והטכנית שלכם. אפשר לשכפל, לערוך בכל כלי (קלוד קוד, קרסר (Cursor), VS Code — מה שתרצו), לפרוס בכל מקום, ואפילו למכור. לאבבל לא מחזיקה שום דבר מהקוד כבן ערובה — וזה, שוב, לזכותה.

💡 מהשטח: בסדנאות שלי אני מבקש מכל משתתף שבנה משהו בלאבבל לחבר GitHub באותו רגע — עוד לפני שיש תוכנית לעזוב. למה? כי זה גיבוי חינם, היסטוריית גרסאות חינם, ופוליסת ביטוח חינם. ראיתי אנשים שגילו את חשיבות העניין רק אחרי שפרומפט אחד לא מוצלח דרס להם עמוד שלם. תחברו GitHub היום, גם אם אתם נשארים בלאבבל לנצח.

מה לא עובר נקי בייצוא — והפתרון לכל פריט

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

מה לא עובר	למה	הפתרון
דאטה ומשתמשים ב-Lovable Cloud	הבקאנד המנוהל יושב בחשבון Supabase של לאבבל, לא שלכם	כפתור הייצוא הרשמי (מיולי 2026) או כלי ייצוא ייעודיים → פרויקט Supabase משלכם
סודות (env secrets)	מפתחות API מאוחסנים בכספת של לאבבל ולא נכתבים לקוד (ובצדק!)	יצירת קובץ .env מקומי והזנת המפתחות מחדש
פריסת Edge Functions	קוד המקור מיוצא, אבל הפונקציות רצות בפרויקט ה-Supabase הישן	פריסה מחדש עם Supabase CLI + הגדרת ה-secrets שלהן
דומיין מותאם	ה-DNS מצביע על שרתי לאבבל	עדכון רשומות DNS לפלטפורמה החדשה (Vercel)

נעבור אחד-אחד:

Lovable Cloud — הדאטה שלכם בחשבון של מישהו אחר

אם הפרויקט שלכם משתמש ב-Lovable Cloud (ברירת המחדל בפרויקטים חדשים), הדאטהבייס, המשתמשים והקבצים יושבים פיזית בפרויקט Supabase שמנוהל בחשבון של לאבבל. במשך תקופה ארוכה לא הייתה דרך רשמית לצאת משם — וזו הייתה הביקורת המוצדקת ביותר על הפלטפורמה. ביולי 2026 לאבבל שחררה כפתורי Export / Pause / Remove רשמיים (בטאב Cloud ← Overview ← Advanced settings), ותהליך הייצוא הרשמי מכסה סכמה, דאטה, משתמשי אימות כולל סיסמאות, קבצי אחסון ומשימות cron. קיימים גם כלי קהילה חינמיים בקוד פתוח שמעבירים טבלאות, חשבונות משתמשים וקבצים לפרויקט Supabase משלכם.

הצעד המעשי: פתחו חשבון Supabase (יש שכבת חינם נדיבה), צרו פרויקט חדש, והריצו את הייצוא לתוכו. אם הפרויקט שלכם חובר מלכתחילה ל-Supabase חיצוני משלכם (האופציה השנייה שלאבבל מציעה) — מזל טוב, הסעיף הזה כבר פתור מעצמו: הדאטה כבר אצלכם.

סודות — ולמה טוב שהם לא מיוצאים

מפתחות API (Stripe, OpenAI, Resend וכדומה) שהזנתם בלאבבל שמורים בכספת ולא מוטמעים בקוד. זה בדיוק מה שאמור לקרות מבחינת אבטחה — סוד שנכתב בקוד הוא סוד שדלף. המשמעות למעבר: תצטרכו רשימת מלאי. עברו על הפרויקט (או תנו לקלוד קוד לעשות את זה — פרומפט מוכן בהמשך), זהו כל משתנה סביבה שהקוד מצפה לו, והשיגו כל מפתח מחדש מהשירות המקורי. את הרשימה שומרים בקובץ .env מקומי שלעולם לא נכנס ל-Git.

Edge Functions — הקוד אצלכם, ההרצה לא

פונקציות צד-שרת שלאבבל כתבה עבורכם (שליחת מיילים, חיוב, ולידציות) מיוצאות כקוד מקור בתיקיית supabase/functions בריפוזיטורי. אבל הן רצות בפרויקט ה-Supabase הישן. אחרי שהקמתם פרויקט Supabase משלכם, פורסים אותן מחדש בפקודה אחת לכל פונקציה (supabase functions deploy) ומגדירים מחדש את הסודות שלהן. קלוד קוד עושה את כל זה בשבילכם — כולל התקנת ה-CLI אם צריך.

דומיין מותאם — הצעד האחרון, לא הראשון

אם חיברתם דומיין (tzedek-style: app.yourbusiness.co.il) לפרויקט הלאבבל, הוא ימשיך להצביע על הפריסה של לאבבל עד שתעדכנו DNS. חשוב: את הדומיין מעבירים אחרונים, רק אחרי שהגרסה החדשה רצה ונבדקה על כתובת ה-Vercel הזמנית. ככה אין רגע שבו המשתמשים רואים אתר שבור.

הבנייה מחדש עם קלוד קוד — צעד אחר צעד

עכשיו החלק המהנה. הנחת עבודה: יש לכם מחשב עם Node.js, חשבון GitHub עם הריפוזיטורי המיוצא, ומנוי Claude (רמת Pro ומעלה מספיקה להתחלה). אם קלוד קוד עדיין לא מותקן — ההתקנה היא פקודה אחת, ופירטנו הכול בעמוד קלוד קוד שלנו.

צעד 1: שכפול הריפוזיטורי

git clone https://github.com/USERNAME/PROJECT.git
cd PROJECT
npm install

שלוש פקודות, ויש לכם עותק מקומי מלא של הפרויקט עם כל התלויות.

צעד 2: פתיחת קלוד קוד ומיפוי הפרויקט

מריצים claude בתיקיית הפרויקט. הפעולה הראשונה — לפני כל שינוי! — היא לתת לקלוד קוד למפות את הפרויקט ולכתוב קובץ CLAUDE.md: קובץ הזיכרון שקלוד קוד קורא בתחילת כל שיחה, ובו המחסנית, מבנה התיקיות, המוסכמות והמשימות הפתוחות. זה הרגע שבו הפרויקט הופך מ"קוד שמישהו אחר כתב" ל"פרויקט שהסוכן שלכם מכיר". הפרומפט המדויק — בפרק הפרומפטים למטה.

צעד 3: ניקוי שאריות לאבבל

מסירים את lovable-tagger ואת האזכור שלה ב-vite.config.ts, ובודקים אם יש הפניות לכתובות פריסה של לאבבל. זה ניקוי קוסמטי ברובו — הפרויקט ירוץ גם בלעדיו — אבל הוא מסמן בעלות: מהרגע הזה זה הפרויקט שלכם.

צעד 4: חיבור Supabase וסביבת ההרצה

יוצרים קובץ .env (או .env.local) עם כתובת פרויקט ה-Supabase החדש והמפתח הציבורי שלו — בפרויקטי Vite המשתנים מתחילים ב-VITE_. מוודאים ש-.env נמצא ב-.gitignore. אם הדאטה עוד ב-Lovable Cloud, זה השלב להריץ את הייצוא שתיארנו למעלה. ואם אתם רוצים לתת לקלוד קוד שליטה עמוקה בדאטהבייס (הרצת מיגרציות, בדיקת טבלאות, פריסת פונקציות) — מחברים את ה-MCP הרשמי של Supabase, כמו שהסברנו במדריך קלוד קוד + Supabase. זה אחד היתרונות הגדולים של המעבר: בלאבבל הבקאנד היה קופסה סגורה; בקלוד קוד הוא שקוף לגמרי.

צעד 5: הרצה מקומית ובדיקה

npm run dev

הפרויקט עולה על localhost ואפשר לראות אותו בדפדפן. עברו על התהליכים הקריטיים: הרשמה, התחברות, הפעולה המרכזית של האפליקציה. כל מה שנשבר (בדרך כלל: משהו שקשור לסוד חסר או לפונקציה שלא נפרסה) — מתארים לקלוד קוד והוא מאתר ומתקן. היכולת הזאת, לראות שגיאה ולתת לסוכן לחקור אותה עד הפתרון באותה שיחה, היא בדיוק מה שחסר בלולאת העריכה של לאבבל.

צעד 6: פריסה ל-Vercel

Vercel מזהה פרויקטי Vite אוטומטית. שתי דרכים: לייבא את הריפוזיטורי מ-GitHub בממשק של Vercel (ואז כל push פורס אוטומטית — התנהגות זהה ללאבבל), או דרך ה-CLI. לא לשכוח להזין את משתני הסביבה בהגדרות הפרויקט ב-Vercel — ה-.env המקומי לא עולה לענן, וזו הסיבה מספר אחת ל"עובד אצלי אבל שבור בפרודקשן".

צעד 7: העברת הדומיין

הגרסה החדשה רצה על כתובת vercel.app זמנית? נבדקה? מעולה. עכשיו — ורק עכשיו — מוסיפים את הדומיין בהגדרות Vercel, מעדכנים את רשומות ה-DNS אצל רשם הדומיין, ומחכים להתפשטות (בדרך כלל דקות, לעיתים שעות). מרגע שהדומיין מצביע על Vercel, המעבר הושלם.

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

פרומפטים מוכנים להעתקה לקלוד קוד

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

פרומפט 1: מיפוי הפרויקט וכתיבת CLAUDE.md

זהו פרויקט שיוצא מ-Lovable דרך GitHub sync. עבור על כל מבנה הפרויקט —
package.json, vite.config.ts, תיקיות src ו-supabase — וכתוב קובץ CLAUDE.md
תמציתי שכולל: המחסנית המדויקת וגרסאות עיקריות, מבנה התיקיות והתפקיד של כל
אחת, רשימת העמודים והקומפוננטות המרכזיות, כל טבלאות ה-Supabase וה-Edge
Functions שהקוד מצפה להן, וכל משתני הסביבה שהפרויקט דורש (חפש שימושים
ב-import.meta.env). בסוף, כתוב סעיף "ידוע/פתוח" עם כל דבר חשוד או לא גמור
שמצאת. אל תשנה שום קוד בשלב הזה.

פרומפט 2: ניקוי תלויות ספציפיות ללאבבל

הסר את התלות lovable-tagger מ-package.json ואת השימוש בה מ-vite.config.ts,
כולל ה-import וה-componentTagger מרשימת הפלאגינים. חפש בכל הפרויקט אזכורים
נוספים ל-lovable (כתובות lovableproject.com, הערות, מטא-תגים ב-index.html)
ורשום לי מה מצאת לפני שאתה מסיר. בסוף הרץ npm install ו-npm run build
כדי לוודא שהפרויקט עדיין נבנה נקי.

פרומפט 3: הקמת סביבה וחיבור Supabase

אני מעביר את הפרויקט לפרויקט Supabase חדש בבעלותי.
כתובת הפרויקט: [SUPABASE_URL], מפתח anon/publishable: [KEY].
1. צור קובץ .env.local עם המשתנים הנכונים לפי מה שהקוד מצפה לו, וודא
   שהוא ב-.gitignore.
2. עדכן את קובץ ה-client של Supabase אם יש בו ערכים קשיחים (hardcoded).
3. עבור על תיקיית supabase/functions ותן לי רשימה של כל הפונקציות,
   מה כל אחת עושה, ואילו secrets כל אחת צריכה.
4. הכן את פקודות ה-CLI לפריסת כל הפונקציות לפרויקט החדש — אל תריץ עדיין,
   רק הצג לי אותן לאישור.

פרומפט 4: פריסה ל-Vercel

פרוס את הפרויקט ל-Vercel:
1. ודא שהפרויקט נבנה נקי מקומית (npm run build).
2. אם Vercel CLI לא מותקן, התקן והתחבר.
3. פרוס עם vercel --prod וקשר את הפרויקט לריפוזיטורי GitHub כדי שכל
   push יפרוס אוטומטית.
4. הזכר לי אילו משתני סביבה אני חייב להגדיר בהגדרות הפרויקט ב-Vercel
   לפני שהאתר יעבוד, ובדוק אחרי הפריסה שהעמוד הראשי עולה בלי שגיאות
   קונסול.

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

איך משתנה העבודה היומיומית אחרי המעבר

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

מה מקבלים

• סוכן במקום צ'אט-עריכה. קלוד קוד לא רק עורך קבצים — הוא מריץ בדיקות, קורא לוגים, חוקר באגים, מתקין חבילות ומתקן את עצמו. משימה כמו "החיפוש איטי, תמצא למה ותתקן" היא שיחה אחת, לא עשרה סיבובי קרדיטים.
• Git אמיתי. כל שינוי הוא commit עם הודעה ברורה. אפשר לחזור לכל נקודה בהיסטוריה, לעבוד על branches, ולראות בדיוק מה השתנה ומתי. בלאבבל יש היסטוריית גרסאות, אבל Git נותן שליטה ברזולוציה אחרת לגמרי.
• Skills ואוטומציות. לקלוד קוד יש מערכת Skills — "מתכונים" שמלמדים אותו יכולות שלמות (מערכת ניוזלטר, חנות, מערכת תיאום פגישות) שהוא מבצע מקצה לקצה. אפשר גם לתזמן משימות אוטומטיות, לחבר טלגרם ו-WhatsApp, ולבנות סוכנים שרצים לבד.
• חיבור לכל דבר דרך MCP. פרוטוקול MCP מחבר את קלוד קוד ל-Supabase, ל-Vercel, לדפדפן, למערכות פרסום — האקוסיסטם שאנחנו מלמדים בכל הקורסים שלנו.

מה מאבדים

• התצוגה החיה המיידית. בלאבבל רואים כל שינוי ברגע שהוא קורה, בדפדפן, בלי כלום. בעבודה מקומית יש npm run dev ורענון — קרוב, אבל פחות "קסום". מי שמתגעגע לעריכה ויזואלית — זה בדיוק המקום למודל ההיברידי (בהמשך).
• האפס-התקנה. לאבבל רצה בדפדפן מכל מחשב. קלוד קוד דורש סביבה מקומית מסודרת: Node, Git, טרמינל. ההקמה חד-פעמית, אבל היא קיימת.
• הפשטות של מוצר אחד. בלאבבל הכול במקום אחד — קוד, בקאנד, פריסה, דומיין. אחרי המעבר אתם מנהלים GitHub + Supabase + Vercel. שלושתם חינמיים או זולים ברמות הכניסה, אבל זה שלושה חשבונות במקום אחד.

השוואת עלויות — בכנות

היבט	לאבבל (Lovable)	קלוד קוד (Claude Code)
מודל תמחור	מנוי + קרדיטים משתנים לכל בקשה	מנוי Claude חודשי קבוע (Pro ומעלה)
עלות בקשה שולית	קרדיטים — נגמרים ומשדרגים	כלולה במנוי עד מגבלות השימוש
עלות תשתית (בקאנד, אחסון)	חיוב שימוש של Lovable Cloud מעל המנוי	Supabase + Vercel — שכבות חינם נדיבות, תשלום לפי גדילה
פרויקט קטן וחד-פעמי	זול מאוד, לרוב זול יותר	פחות משתלם אם זה השימוש היחיד במנוי
מוצר חי עם תחזוקה שוטפת	מתייקר עם היקף העבודה	עלות קבועה וצפויה

נכון ליולי 2026, הכלל המעשי: אם אתם עובדים על הפרויקט כמה שעות בחודש — לאבבל כנראה זולה יותר. אם אתם עובדים עליו כל יום, או מנהלים כמה פרויקטים — מנוי Claude אחד מכסה הכול, וההפרש גדל ככל שהעבודה גדלה. ובל נשכח שמנוי Claude נותן גם את כל השאר: קלוד לכתיבה, לניתוח, לאוטומציות — לא רק לקוד.

מתי דווקא להישאר בלאבבל — פרק הכנות

לא כל פרויקט צריך לעבור, ומי שאומר לכם אחרת מוכר משהו. הישארו בלאבבל אם:

• הפרויקט בשלב רעיון או ולידציה. כשהשאלה היא "האם מישהו בכלל רוצה את זה?", מהירות האיטרציה של לאבבל שווה יותר מכל שליטה טכנית. אל תבזבזו יומיים על תשתית למוצר שאולי תזרקו בשבוע הבא.
• אין לכם (עדיין) נוחות עם טרמינל. קלוד קוד סלחני ומלמד, אבל עבודה מקומית דורשת מינימום ביטחון עם שורת פקודה. אם המילה "טרמינל" מלחיצה — התחילו עם הקורסים החינמיים באקדמיה לפני המעבר, לא במהלכו.
• האפליקציה קטנה ויציבה. דף נחיתה עם טופס, כלי פנימי פשוט, אתר תדמית — אם זה עובד ונוגעים בו פעם בחודש, המעבר הוא פתרון שמחפש בעיה.
• הצוות כולו לא-טכני. היתרון הגדול של לאבבל בארגונים הוא שכל אחד יכול לתקן טקסט או להזיז כפתור. מעבר לקלוד קוד מרכז את היכולת הזאת אצל מי שמכיר את הכלי.

האופציה השלישית: המודל ההיברידי

וזו אולי הנקודה החשובה בפרק: המעבר הוא לא בינארי. בזכות הסנכרון הדו-כיווני של GitHub, אפשר — ולדעתנו לרוב כדאי — לעבוד בשני הכלים על אותו ריפוזיטורי: לאבבל לאיטרציות UI מהירות ולעריכה ויזואלית, קלוד קוד ללוגיקה, ריפקטורים, אינטגרציות ותשתית. כל כלי עושה את מה שהוא הכי טוב בו, והקרדיטים בלאבבל נשמרים לעבודה הוויזואלית שבה הם באמת שווים את הכסף. בנינו על זה מדריך שלם — ה-Workflow המשולב של לאבבל, קלוד קוד ו-GitHub — והוא ההשלמה הטבעית של המדריך הזה למי שלא רוצה לנתק את לאבבל.

אגב, אותו היגיון בדיוק תקף גם לכלים מקבילים: מי שבנה ב-v0 של Vercel או בכלי Vibe Coding אחר ייצא דרך GitHub באותה דרך כמעט אחד-לאחד, כי כולם מייצרים React סטנדרטי.

טעויות נפוצות במעבר — למדו מהכוויות של אחרים

1. להעביר את הדומיין לפני שהכול נבדק. התוצאה: משתמשים על אתר שבור. הדומיין תמיד אחרון.
2. לשכוח את משתני הסביבה ב-Vercel. הפרויקט עובד מקומית ונשבר בפרודקשן. תמיד להשוות את רשימת המשתנים ב-.env המקומי מול הגדרות Vercel.
3. למחוק את פרויקט הלאבבל מוקדם מדי. גם אחרי מעבר מוצלח, השאירו את המקור שבועיים. אחסון זול; שחזור דאטה אבוד — לא.
4. לדלג על כתיבת CLAUDE.md. בלי הקובץ הזה, כל שיחה עם קלוד קוד מתחילה מאפס והוא מבזבז זמן על גילוי מחדש של הפרויקט. חמש דקות שחוסכות שעות.
5. לערוך במקביל בלאבבל ובמקומי בלי תיאום. קונפליקטים ב-main הם הדרך המהירה ביותר לאבד עבודה. צד אחד בכל רגע.
6. להזין secrets לתוך הקוד. אם קלוד קוד מציע פתרון עם מפתח API כתוב בקובץ — עצרו אותו ובקשו משתנה סביבה. תמיד.
7. לא לבדוק את משתמשי האימות אחרי ייצוא Cloud. ודאו שהתחברות עם משתמש קיים עובדת בפרויקט החדש לפני ההעברה — אימות הוא החלק הרגיש ביותר במיגרציה.

צ'קליסט מעבר מרוכז — להדפסה

לפני שסוגרים את המדריך, הנה כל התהליך בעמוד אחד. סמנו וי על כל שורה, בסדר הזה:

1. ☐ חיברתם את פרויקט הלאבבל ל-GitHub וראיתם את הקוד בריפוזיטורי שלכם
2. ☐ פתחתם פרויקט Supabase חדש בחשבון שלכם (אם הייתם על Lovable Cloud)
3. ☐ הרצתם את ייצוא ה-Cloud הרשמי: סכמה, דאטה, משתמשים, קבצים
4. ☐ שכפלתם את הריפו מקומית והרצתם npm install בהצלחה
5. ☐ קלוד קוד מיפה את הפרויקט וכתב CLAUDE.md (פרומפט 1)
6. ☐ ניקיתם את שאריות הלאבבל והפרויקט נבנה נקי (פרומפט 2)
7. ☐ קובץ .env מקומי מוכן עם כל הסודות, ונמצא ב-.gitignore (פרומפט 3)
8. ☐ ה-Edge Functions נפרסו לפרויקט החדש כולל הסודות שלהן
9. ☐ הרשמה, התחברות והפעולה המרכזית עובדות ב-localhost
10. ☐ הפריסה ל-Vercel עלתה, כולל משתני סביבה בהגדרות (פרומפט 4)
11. ☐ בדקתם את האתר החי על כתובת ה-vercel.app הזמנית — הכול תקין
12. ☐ העברתם את הדומיין, ורק עכשיו
13. ☐ הגרסה הישנה בלאבבל נשארת חיה עוד שבועיים כגיבוי

שלוש עשרה שורות. אם כולן מסומנות — סיימתם מעבר מלא, מסודר, בלי הפתעות.

שאלות נפוצות

כמה זמן לוקח המעבר המלא מ-Lovable לקלוד קוד?

לפרויקט טיפוסי (אפליקציה עם אימות, דאטהבייס וכמה עמודים): 2–4 שעות עבודה נטו. חיבור GitHub ושכפול — דקות. עיקר הזמן הולך על ייצוא הדאטה מ-Lovable Cloud, השגת ה-secrets מחדש ובדיקות. פרויקט בלי Cloud (עם Supabase חיצוני מההתחלה) יכול לעבור תוך שעה.

האם הקוד שלאבבל כותבת בכלל טוב מספיק להמשך פיתוח?

ברוב המקרים כן, עם הסתייגות. הקוד קריא, משתמש בספריות סטנדרטיות ומאורגן סביר. בפרויקטים שגדלו דרך הרבה איטרציות צ'אט מצטברים כפילויות וקומפוננטות מנופחות — אבל זה בדיוק סוג העבודה שקלוד קוד מצטיין בה: בקשו ממנו סקירת קוד וריפקטור מדורג אחרי המיפוי הראשוני.

מה קורה לסנכרון עם לאבבל אחרי המעבר?

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

יש לי פרויקט על Lovable Cloud עם משתמשים אמיתיים. המעבר מסוכן?

הוא דורש זהירות, לא גבורה. תהליך הייצוא הרשמי (יולי 2026) מעביר גם משתמשי אימות כולל סיסמאות, כך שהמשתמשים לא יצטרכו להירשם מחדש. הכלל: מריצים את הייצוא, בודקים התחברות ופעולות קריטיות בסביבה החדשה על כתובת זמנית, ורק אז מעבירים דומיין. ולמקרה קצה — המקור נשאר חי עוד שבועיים.

אפשר לעבור לקרסר (Cursor) במקום לקלוד קוד?

אפשר — הייצוא דרך GitHub זהה, והקוד סטנדרטי לכל כלי. קרסר הוא IDE עם AI מוטמע ומתאים למי שרוצה לראות ולערוך קוד בעצמו; קלוד קוד הוא סוכן אוטונומי שמתאים יותר למי שמגיע מעולם הצ'אט של לאבבל ורוצה להמשיך לעבוד בהנחיות בשפה חופשית. לא מעט מפתחים משתמשים בשניהם.

האם קלוד קוד עובד טוב בעברית?

כן, מצוין — גם ההנחיות וגם התוכן. אפשר לנהל את כל המעבר בעברית, כמו בפרומפטים שבמדריך. ממשקי האפליקציה שתבנו (RTL, גופנים עבריים) הם עניין של הקוד עצמו, וקלוד קוד מטפל בהם היטב כשמבקשים.

האם המעבר משפיע על ה-SEO של האתר?

אם עושים אותו נכון — לא. הדומיין נשאר זהה, וכתובות העמודים (routes) נשמרות כי הקוד זהה. שני דברים כן שווים בדיקה אחרי המעבר: שקובצי ה-sitemap וה-robots עברו כמו שהם, ושמהירות הטעינה לא נפגעה — בפועל היא לרוב דווקא משתפרת על Vercel. אם שיניתם מבנה כתובות במהלך המעבר, בקשו מקלוד קוד להגדיר הפניות 301 מהכתובות הישנות.

מה עושים אם משהו נשבר באמצע ואני תקוע?

ראשית — Git הוא רשת הביטחון: git status ו-git checkout מחזירים כל קובץ למצב האחרון שעבד, וקלוד קוד עצמו יודע לעשות את זה בשבילכם אם מבקשים. שנית, אפשר תמיד להדביק את הודעת השגיאה המלאה לקלוד קוד ולבקש חקירה. ואם אתם רוצים ליווי אנושי צמוד — ראו את השורה התחתונה למטה.

שורה תחתונה

לאבבל (Lovable) היא נקודת פתיחה מצוינת, והעובדה שקל לצאת ממנה היא חלק ממה שעושה אותה מצוינת. הקוד שהיא מייצרת הוא React + Vite + TypeScript סטנדרטי, הייצוא דרך GitHub חינמי ודו-כיווני, ומאז יולי 2026 גם הדאטה ב-Lovable Cloud ניתן לייצוא רשמי. המעבר לקלוד קוד (Claude Code) הוא ברובו לא "המרה" אלא חיבור מחדש של ארבעה דברים: דאטה, סודות, פונקציות ודומיין — ועם הפרומפטים שבמדריך, קלוד קוד עושה את רוב העבודה הכבדה בעצמו.

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

רוצים להעמיק לפני הקפיצה? הקורסים החינמיים באקדמיה מכסים את קלוד קוד מאפס, כולל עבודה עם Git ו-Supabase. ואם יש לכם פרויקט לאבבל אמיתי שאתם רוצים להעביר בליווי צמוד — אפשר לקבוע שיעור פרטי אחד-על-אחד, לעבור את המיגרציה יחד מקצה לקצה, ולצאת עם פרויקט רץ וסביבת עבודה שאתם שולטים בה. הקוד שלכם. הכלים שלכם. קדימה לעבודה.