‏Vibe Coding עם Claude: איך זה באמת מתנהל, ומתי לעצור

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

איך הלולאה באמת נראית

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

1. לתאר משהו קטן.
2. להפעיל ולראות.
3. לתאר מה לא בסדר.
4. לחזור.

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

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

שני כללים שמצילים פרויקטים

1. להתחיל ממשהו שרץ

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

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

2. לשמור עותק עובד לפני כל שינוי

זה הכלל היחיד שאם תיקח רק אחד, קח אותו.

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

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

מה באמת שווה לבנות ככה

הקריטריון אינו מורכבות אלא עלות טעות:

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

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

ארבעת קווי העצירה

אלה לא המלצות. אלה קווים.

1. נתוני לקוחות אמיתיים

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

2. כסף

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

3. התחברות והרשאות

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

4. מישהו אחר נשען על זה

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

ושאלת ההמשך - האם מה שנבנה ככה יכול לצאת לאוויר - נענית בנפרד ובכנות.

שלוש התופעות שיפתיעו אותך

1. תיקון אחד שובר משהו אחר

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

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

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

2. "נראה שעובד" אינו "עובד"

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

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

3. ביטחון אינו נכונות

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

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

עברית

אם הכלי בעברית, שלוש נקודות שנשברות בשקט:

• כיווניות - לבקש עברית במפורש, ואז לפתוח ולהסתכל.
• תאריכים - יום/חודש ולא חודש/יום. זו שגיאה שנראית תקינה בכל יום מה-1 עד ה-12, ולכן היא נמצאת מאוחר מדי.
• טקסט שמגיע ממקום אחר - שמות עם רווחים כפולים או תווים בלתי נראים שוברים השוואות.

ההחלטה בסוף

אחרי שיש לך משהו שעובד, יש שלוש דרכים:

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

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