יש סוג משימה שסוכן AI אוהב במיוחד: "תשפר את זה".
שלוש מילים. אינסוף אפשרויות.
מבחינת הסוכן זו הזמנה להיות יצירתי. מבחינת מוצר קיים זו יכולה להיות קטסטרופה קטנה.
ב-Studio Haim אנחנו משתמשים ב-Codex ובכלי פיתוח נוספים כחלק אמיתי מהעבודה. לא רק לכתוב snippet. PRs. בדיקות. reviews. structured data. פיצ'רים. תיקוני regression.
והדבר שחזר שוב ושוב הוא שסוכן טוב לא פותר את הצורך ב-scope. הוא מגדיל אותו.
ככל שהסוכן מסוגל לעשות יותר, הגבולות חשובים יותר
אם מפתח אנושי מקבל משימה עמומה, הוא עשוי לשאול שאלות. סוכן יכול פשוט להתחיל.
ולפעמים הוא ייתן תוצאה מרשימה מאוד. קבצים חדשים. tests. types. UI. documentation. והכול נראה מקצועי.
עד שמגלים שהוא פתר גם שלוש בעיות שלא ביקשנו לפתור. או גרוע יותר: שה-tests וה-UI מספרים סיפור שהמערכת עדיין לא באמת יודעת לבצע.
ראינו את זה בפועל בעבודת Instagram
באחת מעבודות האינטגרציה, review של Codex מצא מצב בעייתי במיוחד.
PR הפעיל בדיקות שקשורות ל-Instagram, אבל בפועל חלקים מהיכולת עצמה עדיין לא היו ממומשים. לא היו כל ה-targets הדרושים. לא כל קבצי ה-OAuth. לא כל מיפויי הפרסום.
המערכת נראתה כאילו היא מתקדמת לכיוון feature מלא. העובדות אמרו משהו אחר.
בשלב אחר Codex הצביע על בעיה נוספת: הצלחה ב-PATCH של receipt ביוטיוב לא בהכרח הוכיחה שה-mapping של הפוסט שפורסם נשמר אחר כך.
כלומר, אסור להגיד למשתמש "הכול נרשם" רק כי שלב אחד בשרשרת הצליח. צריך לבדוק את העובדה שהמערכת מבטיחה.
tests צריכים לבדוק עובדות, לא קופי
זה עיקרון שהתחיל להיכנס גם במקומות אחרים באתר.
כשעבדנו על structured data, למשל, ההנחיה לא הייתה לבדוק string מדויק של description. הבדיקות צריכות לוודא עובדות:
אותם entity IDs. שה-Person לא מוצג כאילו BY+ הוא הזהות הראשית שלו. שה-ProfessionalService באמת מזכיר אתרים, מערכות, וידאו AI ואוטומציות. ש-CreativeWork מצביע על creator/publisher מתאים. ש-Service משתמש ב-provider.
הסיבה פשוטה. קופי יכול להשתנות. העובדה שמתחתיו לא אמורה לזוז בטעות.
המשימה הכי טובה לסוכן היא לא "תעשה טוב"
היא משהו כמו: עדכן רק X. אל תיגע ב-Y. שמור על Z. אל תוסיף property שלא קיים. אל תשנה visible copy. תפעיל regression tests על העובדות האלה.
ה-spec אולי נשמע פחות סקסי. אבל הוא נותן לסוכן שטח פעולה ברור. וזה בדרך כלל המקום שבו הוא הכי חזק.
גם review צריך להיות ממוקד
PR רחב מדי מייצר גם review רחב מדי.
אם השתנו 40 דברים, קשה לדעת איזה שינוי באמת גרם ל-regression.
לכן אנחנו מעדיפים PRs קטנים ובינוניים עם מטרה ברורה.
זה לא אומר שכל commit חייב להיות זעיר. זה אומר שהשאלה "מה המשימה הזאת אמורה לשנות?" צריכה לקבל תשובה אחת ברורה.
לפעמים הפתרון הנכון הוא להציג שהפיצ'ר לא זמין
באינטגרציית Instagram הייתה גם החלטה חשובה אחרת.
אם upload path קיים עבור YouTube ו-TikTok, אבל Instagram עדיין לא באמת נתמך מקצה לקצה, לא נכון לקחת את המשתמש למסך generic שנראה כאילו הכול אמור לעבוד.
עדיף להגיד שהיכולת אינה זמינה עדיין. זה פחות מרשים. וזה יותר אמין.
AI מקל מאוד לבנות את החלק הקדמי של feature. כפתור. מסך. state. animation. אבל מערכת טובה נמדדת במה שקורה אחרי שלוחצים.
גם "הכול ירוק" לא תמיד מספיק
היו לנו PRs שבהם deployment או quality checks נכשלו. זה חלק מהעבודה.
הנקודה היא לא שסוכן AI טועה. גם מפתחים טועים.
הנקודה היא שהמהירות שבה AI מסוגל לייצר קוד הופכת verification לחלק גדול יותר מהמקצוע, לא קטן יותר.
ככל שאנחנו בונים מהר יותר, אנחנו צריכים להיות טובים יותר בלשאול: מה באמת הוכח?
איך אנחנו עובדים היום
אנחנו משתדלים להגדיר מראש: מה משתנה. מה אסור להשתנות. איזו עובדה תיחשב הצלחה. איזה test צריך להגן עליה. מה מחוץ ל-scope.
והמשפט האחרון חשוב מאוד. כי בלי "מה לא בונים", כמעט כל spec יכול להפוך לפרויקט חדש.
מה לקחנו מזה
היתרון של סוכן AI הוא מהירות.
אבל מהירות בלי גבולות היא לא leverage. היא פשוט דרך מהירה יותר להגדיל scope.