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

https://open.spotify.com/episode/7wTqD5zwl8ZitUeplapvBG?si=f87b7e5cd4c14ff3

אלה הנקודות המרכזיות שלקחתי מהשיחה:

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

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

3. עדיין יש משימות פיתוח קשות ומהשיחה נשמע שגם באנטרופיק מאמינים שיהיו דברים קשים בעתיד הנראה לעין. יש משימות שלוקחות להם חודשים (בעיקר בצד ה Backend). יש תיעדוף מאוד קשוח איזה פיצ'רים ייבנו ואיך. יש הבנה שיש פיצ'רים שאפשר לרוץ איתם מהר ואפילו לתת ל AI לבנות מאפס, ויש שינויי תשתית מסובכים שדורשים הרבה מחשבה אנושית. 100% קוד מג'ונרט על ידי AI לא שווה 100% קוד שנכתב בלי בני אדם שמכתיבים מה ייכתב ומוודאים שדברים נכתבים נכון.

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

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

6. באותו נושא היא מאוד המליצה לכתוב Eval-ים כדי לתאם ציפיות בין מנהלי פרויקט וצוותי הפיתוח.

7. מודלים חדשים יכולים לייתר יכולות, ולפתוח פיצ'רים חדשים - כשהמודלים לא הצליחו לעשות משימות מורכבות הם הוסיפו מנגנון של Todo List בתוך קלוד קוד. המודל ממלא את רשימת ה Todo והרתמה רצה בלולאה עד שכל הסעיפים בוצעו. ככל שהמודל השתפר לכיוון אופוס או סונט 4.6 הם ראו שאפשר להעביר את כל פיצ'ר ה Todo להיות Tool והמודל מצליח להשתמש בו כדי לייצר לעצמו את הרשימות, ואופוס החדש אפילו לא צריך את זה ועובד טוב גם בלי רשימת Todo. פיצ'ר נוסף שעלה היה פיצ'ר ה Code Review, שהיה מוכן כבר תקופה אבל אף מודל לא הצליח לתת להם תוצאות טובות עד שהגיע אופוס 4.7 ולכן הם חיכו עם שילוב הפיצ'ר עד שהמודל ישתפר. הם מתמודדים עם זה באמצעות פיתוח פיצ'רים גם אם התוצאה עדיין לא מושלמת מתוך הנחה שעוד כמה חודשים תצא גרסה חדשה של המודל שכן תתמודד עם האתגר, ובמקביל כל גרסה חדשה של מודל חוזרים לבדוק אם יש פיצ'רים בסוכן שאפשר להוריד כי המודל כבר מצליח לעבוד טוב יותר בלעדיהם.

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