מצב Chat ב-Lovable: לחשוב בקול בלי לשרוף קרדיטים

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס וייב קודינג אקספרס Vibe Coding Express

לפרטים נוספים לחצו כאן >>

שלושה מצבים, שלושה תפקידים

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

1) מצב Build: במצב הזה Lovable בונה בפועל, כלומר כותב קוד ומשנה את האפליקציה. זהו מצב ברירת המחדל, והתמחור בו מבוסס על היקף השימוש.

2) מצב Chat:מרחב שנועד לשיחה בלבד. שואלים, מתייעצים, בוחנים רעיונות ומקבלים תשובה מקצועית, בלי שנכתבת אף שורת קוד ובלי לגעת בקרדיטים של הבנייה.

3) מצב Plan:במצב הזה Lovable בוחן את הפרויקט ומנסח תוכנית עבודה מובנית לפיצ'ר או לרכיב, מעין מסמך תכנון מפורט (Detailed Design). הוא אינו נוגע בקוד. אפשר לערוך את התוכנית כטקסט בפורמט Markdown, וברגע שמאשרים אותה, הכלי עובר אוטומטית למצב Build ומתחיל לממש אותה. התוכנית המאושרת נשמרת כקובץ בתוך הפרויקט, וכל הודעה במצב הזה עולה קרדיט אחד

ניתן לעבור בין המצבים בכל רגע, דרך הבורר שליד תיבת הטקסט או בקיצור המקלדת Option+P במק ו-Alt+P בווינדוס. השיחה נשמרת לאורך כל המעברים, כך שכל מה שדיברתם עליו ב-Chat ילווה גם את שלבי התכנון והבנייה.

מעבר בין מצבים

מה אפשר לשאול, ומה לא יקרה

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

Chat שפועל בתוך פרויקט קיים

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

כשתבקשו שינוי של ממש, יופיע כרטיס בשם Start building. לחיצה על Build מעבירה את השיחה למצב בנייה ומחויבת בקרדיטים רגילים, ולחיצה על Skip משאירה אתכם במצב השיחה.

קרדיטים נפרדים שמתאפסים כל יום

כאן טמון ההיגיון הכלכלי. הודעה במצב Chat מתומחרת לפי היקף העבודה שנדרש כדי לענות עליה, ובדרך כלל מדובר בחלק קטן מקרדיט. זאת ועוד, סביבות עבודה בתוכניות Free, Pro ו-Business מקבלות מכסה יומית חינמית להודעות צ'אט. המכסה משותפת לכל חברי הצוות, מתאפסת מדי יום בחצות לפי שעון UTC ואינה מצטברת. רק לאחר שהיא מנוצלת, ההודעות מחויבות מקרדיטי הבנייה היומיים, ולאחר מכן מהקרדיטים הכלליים.

יש שתי הסתייגויות: בתוכנית Enterprise אין מכסה יומית, והחברה מגדירה את מודל התמחור הנוכחי כהצעה זמנית, שבתוקף עד 31 באוקטובר 2026.

שיחות גם מחוץ לפרויקט

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

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

רעיון מוכר מעולם הקוד

מי שעובד עם קרסר (Cursor) יזהה את הרעיון מיד. מצב Ask של קרסר עושה בדיוק את זה: הוא מגביל את הסוכן לכלי קריאה בלבד, כדי שאפשר יהיה לדון בקוד בלי שישתנה תוך כדי השיחה. גם החלוקה המשולשת של Lovable, בין שיחה, תכנון וביצוע, מזכירה את האופן שבו כלים כמו קלוד קוד (Claude Code) וקודקס (Codex) מפרידים בין חשיבה לעשייה.

מצב Ask בקרסר

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

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