תהליך הפיתוח משולב AI ב 37 Signals
בפרק האחרון של rework דייויד הנסן מדבר על פיתוח משולב AI ב 37 Signals.
https://37signals.com/podcast/ai-challenges-in-software/
אלה הדברים המרכזיים שאני לוקח מהפרק:
רוב הפיתוחים החדשים אצלם מתחילים בפרומפט. כך גם אני עובד ואני שומע את זה מיותר ויותר חברים בתעשייה. כשבאים לבנות פיצ'ר חדש נקודת ההתחלה היא לא עורך הטקסט אלא ממשק השיחה.
כח העל של AI עבורם היה בהקמת Preview Pipeline למעצבים - כלומר מעצבים היום כותבים פרומפטים, ה AI מעדכן את הקוד ל PR, המערכת מעלה אוטומטית גרסה של הקוד החדש על מכונת בדיקה ומחזירה למעצב לינק למכונת הבדיקה. זה Pipeline שמאוד קל להקים היום ויש לו המון כח, כי מעצבים יכולים לנסות כך המון רעיונות לפני שבכלל מגיעים לדבר עם המפתחים.
כשמגיעים כבר לדבר עם המפתחים הם מרגישים מאוד בנוח לזרוק את כל הקוד ש AI כתב. זו נקודה קריטית ב Pipeline שהרבה אנשים מפספסים. כשמעצב או מתכנת ג'וניור כותב פרומפטים התוצאה מבחינת הקוד היא די גרועה, גם אם על המסך המוצר נראה יפה. המפתחים הטובים שלהם קוראים קוד של AI בשביל לפסול אותו. הם לא עושים Code Review בשביל להבין מה AI עשה ובשביל לתקן דברים קטנים, אלא מזהים קודם כל אם הקוד בכלל מתחבר לעולם שלהם, קריא וקל להבנה. הם שמחים לזרוק קוד ש AI יצר ולממש את הפיצ'ר בדרך אחרת כשהקוד לא בדיוק מה שהם רצו.
אם תתנו ל AI לכתוב קוד ללא השגחה התוצאה תהיה בלאגן. או במילים של DHH:
The problem is if you just keep doing that, if you keep asking the monkeypaw for more wishes, you’re going to get a distorted code base.
יש בעיה אמיתית שסוכני קידוד לא אומרים "לא", אבל מוצאים דרכים עקומות לפתור בעיות. DHH נתן פה כדוגמה מישהו שמקבל שלוש משאלות ומבקש סכום כסף גדול ואז למחרת קרוב משפחה שאהב נפטר והוא נשאר עם הביטוח חיים ... זאת לא היתה הכוונה.
יותר פיצ'רים לא מביאים יותר מכירות. זאת נקודה שגם Dax מאופןקוד העלה. האתגר שלנו הוא לא לבנות כמה שיותר פיצ'רים אלא לבנות מוצר טוב ומלוטש. הרבה פעמים שני הדברים האלה לא הולכים יחד ואפילו סותרים. ככל שנשים יותר פיצ'רים רק נפגע בחווית המשתמשים.