ה-SDLC שלי בנוי משלושה שלבים, לא משישה

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

רוב השלבים בתהליך הם העברת מקל בתחפושת

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

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

שלב ראשון: להחליט בכתב לפני שיש שורת קוד

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

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

שלב שני: לופ בנייה אחד במקום ארבע פאזות

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

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

שלב שלישי: הוכחה, וזה החלק שעולה הכי ביוקר

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

איפה שלושה שלבים מפסיקים לעבוד

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