לנקות אחרי מפתחי ה"רוק סטאר" של הבינה המלאכותית

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

דפוס ה“רוק סטאר”

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

צבא של “רוק סטארים”

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

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

מה כן כדאי לעשות

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

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