למה אני מוציא ריליסים קטנים מאז שהסוכן כותב את הקוד

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

צוואר הבקבוק זז למקום שסוכן לא יכול לשבת בו

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

ב-Brainers Club, The Next Level, Luma.ai, Tadam ובערבויות ישיר אני התורן היחיד. אין מפתח שני שיתפוס מיגרציה רעה בשתיים בלילה. האילוץ הזה, לא מתודולוגיה שקראתי עליה, הוא מה שעיצב את התהליך שלמטה.

איך נראה ריליס אחד אצלי

1. 01תוצאה אחת לריליס. אם אני צריך את המילה וגם כדי לתאר מה הוא עושה, אלה שני ריליסים.
2. 02כותב את הגייט לפני הפיצ'ר: הבדיקה שנופלת אם ההתנהגות נשברת, ועוד בדיקה אחת שארוץ בפרודקשן אחרי שזה באוויר.
3. 03נותן לסוכן לממש מול הגייט הזה, ואחר כך קורא את כל הדיף כמבקר, לא כמי שביקש את הפיצ'ר.
4. 04קודם staging, מול דאטה אמיתי בצורה שלו, לא רק פיקסצ'רים. סוויטה ירוקה על פיקסצ'רים מעולם לא הוכיחה לי ששינוי דאטה נכון.
5. 05מכיר את ה-rollback לפני הדיפלוי. קומיט חזרה מוכן, מיגרציה אדיטיבית או הפיכה, התנהגות חדשה מאחורי פלאג שכבוי כברירת מחדל.
6. 06מדפלוי, ואז מאמת ביד את המצב החי: הקומיט שרץ על השרת, המסך שהמשתמש עובר, ושאילתה אחת שמראה שהדאטה זז.

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

ריליס קטן זה לא סגנון, זה תוכנית חזרה

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

ממה הפסקתי מאז שהסוכן כותב את רוב הקוד

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

במה התלמידים טועים ראשון

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

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