תשובה קצרה: כש-Lovable שוברת דברים שעבדו, הבעיה היא בדרך כלל לא ההודעה האחרונה אלא השיטה: אין גרסה מסומנת לחזור אליה, ה-AI לא יודע מה אסור לשבור, ושינויים גדולים נבנים בלי תכנון. ששת הצעדים למטה סוגרים את זה, ובכל אחד יש רעיון ראשון שלוקח כמה דקות ואפשר לעשות היום. המטרה: לשנות דבר אחד בלי לפחד ששניים אחרים יישברו.
למה זה קורה
כל הודעה ב-Build mode משנה קוד. כשהבקשה רחבה, כמו "תסדר את הדשבורד", השינוי נוגע בהרבה קבצים, וחלק מהם משרתים דברים שעבדו. ה-AI עובד על מה שביקשתם. הוא לא יודע מה עוד חשוב לכם אם לא אמרתם לו.
ואז מגיע התיקון של התיקון. לפי התיעוד של Lovable, קרדיטים משלמים על העבודה שבוצעה, ולכן גם הודעות שמבטלים אחר כך נספרות. כל סבב של "זה עדיין לא עובד" עולה, גם כשהוא לא מקדם.
צעד 1: גרסה מסומנת לפני כל שינוי
Lovable שומרת כל שינוי כגרסה, אוטומטית. בחלון History אפשר לפתוח גרסה ישנה, לראות אילו קבצים ושורות היא שינתה, ולחזור אליה. אפשר גם לסמן גרסה בסימנייה (Bookmark), כדי שהגרסה הטובה האחרונה תהיה במרחק לחיצה ולא קבורה בהיסטוריה. התיעוד ממליץ בדיוק על זה לפני שינוי גדול.
הרעיון הראשון להיום: פתחו את History, מצאו את הגרסה האחרונה שבה הכל עבד, וסמנו אותה. מעכשיו, סימנייה לפני כל שינוי שנוגע בהתחברות, בתשלום או במבנה הנתונים.
צעד 2: רשימה של מה שאסור שיישבר
ל-Lovable יש הוראות פרויקט (Project instructions, שנקראו בעבר Knowledge). לפי התיעוד, זה טקסט קבוע שנכלל בהקשר של כל הודעה, כך שלא צריך לחזור עליו בכל שיחה.
הרעיון הראשון להיום: כתבו בהוראות הפרויקט חמש שורות, אחת לכל זרימה שאסור שתישבר. למשל: "משתמש חדש נרשם, מאשר את המייל ומגיע לדשבורד", או "לקוח משלם ומקבל גישה". הוסיפו שורה אחת בסוף: "לפני כל שינוי, ציין באילו מהזרימות האלה הוא עלול לגעת."
צעד 3: לתכנן לפני שבונים
לצ'אט של Lovable יש שלושה מצבים. Build משנה את האפליקציה. Chat מדבר על האפליקציה בלי לשנות קוד, ולפי התיעוד הודעה בו עולה בדרך כלל חלק מקרדיט, ומכסה יומית מכסה אותה קודם. Plan חוקר את הפרויקט וכותב תוכנית שאתם עורכים ומאשרים לפני שנכתבת שורת קוד, ולפי התיעוד כל הודעה בו עולה קרדיט אחד, ועוד המחקר שהוא מריץ.
הרעיון הראשון להיום: את השינוי הבא שנוגע במשהו שעובד, התחילו ב-Plan. בקשו שהתוכנית תפרט אילו קבצים וטבלאות היא משנה, ובאילו מחמש הזרימות שלכם היא עלולה לגעת. אם התשובה מפתיעה, עצרתם שבירה לפני שקרתה.
צעד 4: שינוי אחד בכל הודעה
בקשה אחת עם שלושה דברים מייצרת שינוי אחד גדול. כשמשהו נשבר אחריו, אי אפשר לדעת איזה משלושת הדברים שבר, ואי אפשר לבטל רק אותו: לפי התיעוד, חזרה לגרסה היא הכל או כלום.
הרעיון הראשון להיום: קחו את הבקשה הבאה שלכם ופצלו אותה. הודעה אחת, שינוי אחד, בדיקה, ורק אז הבא. אם התוצאה לא טובה, Undo latest edit מבטל את השינוי האחרון בלבד.
צעד 5: לבדוק בעצמכם, לא לסמוך על "תוקן"
לפי התיעוד של Lovable, כשמוסיפים או משנים כלל באפליקציה, כמו מחיר, מגבלה או הרשאה, Lovable כותבת לו בדיקה קטנה, ולפני שהיא מדווחת שסיימה היא מריצה את הבדיקות שמכסות את השינוי. לטקסט ולעיצוב היא לא כותבת בדיקות, ולפונקציות שרצות בשרת (Edge Functions) היא כותבת בדיקות רק כשמבקשים. כלומר "סיימתי" אומר שהבדיקות שקיימות עברו. הוא לא אומר שחמש הזרימות שלכם עובדות.
הרעיון הראשון להיום: אחרי כל שינוי, עברו בעצמכם על חמש הזרימות בתצוגה המקדימה. זה לוקח כמה דקות, ותופס שבירה לפני שמשתמש תופס אותה. לזרימה שקשורה לכסף, בקשו גם בדיקה לפונקציה שרצה בשרת.
צעד 6: כשמשהו נשבר, לחזור ולא לתקן על תיקון
כשתיקון לא עובד, הנטייה היא לשלוח עוד הודעה. כל הודעה כזו בונה שינוי חדש על בסיס שכבר שבור. כשיש סימנייה, יש דרך קצרה יותר: חוזרים לגרסה המסומנת ושולחים את הבקשה מחדש, מפוצלת ומדויקת יותר. אפשר גם לערוך הודעה ישנה שלכם ולבחור Revert and resend.
שני דברים לדעת לפני שחוזרים. הראשון: לפי התיעוד, חזרה לגרסה מחזירה את הקוד בלבד ולא את הנתונים, כך ששינוי שכבר רץ על מסד הנתונים לא יתבטל. השני: לפי התיעוד של הצ'אט, לכפתור Try to fix יש 10 תיקונים חינמיים לחשבון, וכל אחד מהם חוזר 24 שעות אחרי שהשתמשתם בו. אחרי זה הוא נספר כעבודה רגילה וצורך קרדיטים.
הרעיון הראשון להיום: קבעו לעצמכם כלל: תיקון שלא הצליח בפעם השנייה, חוזרים לסימנייה במקום לשלוח הודעה שלישית.
מתי זה כבר לא עניין של שיטה
ששת הצעדים עוצרים שבירות שנוצרות מהדרך שבה עובדים. הם לא מתקנים מבנה שכבר נשבר. שלושה סימנים שהבעיה עמוקה יותר: אותו באג חוזר אחרי שכבר תוקן, יש אזורים באפליקציה שאתם מעדיפים לא לבקש בהם כלום, או שהשינוי הבא נוגע במבנה הנתונים כשכבר יש משתמשים אמיתיים. כאן צריך מישהו שיקרא את הקוד, ימפה מה תלוי במה, ויבנה רשת בדיקות סביב האזורים המסוכנים לפני שנוגעים בהם. זה מה שעושים בטיפול בחוב טכנולוגי, ולפני השקה, בבדיקה לפני השקה.
הרעיון הראשון להיום: שלחו לנו בוואטסאפ את חמש הזרימות מצעד 2 ואת מה שנשבר לאחרונה. בשיחה של 20 דקות נגיד לכם אם השיטה תספיק, או שצריך לפתוח את הקוד.
ששת הצעדים בטבלה אחת
| צעד | מה עושים | הרעיון הראשון להיום |
|---|---|---|
| 1 | גרסה מסומנת | לסמן את הגרסה האחרונה שעבדה |
| 2 | מה אסור שיישבר | חמש זרימות בהוראות הפרויקט |
| 3 | לתכנן לפני שבונים | השינוי הבא מתחיל ב-Plan |
| 4 | שינוי אחד בהודעה | לפצל את הבקשה הבאה |
| 5 | לבדוק בעצמכם | לעבור על חמש הזרימות אחרי כל שינוי |
| 6 | לחזור ולא לתקן על תיקון | אחרי שני ניסיונות, חוזרים לסימנייה |
מקורות
- Lovable Documentation - Version history: גרסאות, סימניות, מה חזרה לגרסה מחזירה, וקרדיטים
- Lovable Documentation - Instructions: הוראות פרויקט שנכללות בכל הודעה
- Lovable Documentation - Chat mode ו-Plan mode: מה כל מצב עושה ואיך הוא מתומחר
- Lovable Documentation - Test and verify your app: אילו בדיקות Lovable כותבת לבד
- Lovable Documentation - Project chat: Undo latest edit ו-Try to fix
כל תיקון שובר משהו אחר, והאפליקציה כבר עם משתמשים? בעמוד טיפול בחוב טכנולוגי אפשר לקבוע שיחת וואטסאפ חינמית של 20 דקות. מספרים מה בניתם ומה נשבר, ונגיד לכם מה הצעד הבא.
