ה-AI מאיצה את העבודה, אבל הארגונים רצים מהר מדי

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

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

לאמץ AI זו לא אסטרטגיה

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

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

דספינס הציגה בהקשר זה את דו"ח GenAI Divide של פרויקט NANDA ב-MIT, שבחן יותר מ-300 יוזמות AI ציבוריות לצד ראיונות וסקרים בארגונים. הדו"ח מצא שרק חלק קטן מהיוזמות הגיע להשפעה כספית מדידה, והצביע דווקא על פעילות תפעולית ובק-אופיס כאחד המקומות שבהם ארגונים מצליחים להפיק ערך ממשי יותר מהטכנולוגיה.

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

הקוד נכתב בשלוש שעות, הביקורת אורכת שלושה ימים

ֿ

גלעד שוהם, סמנכ"ל המו"פ ב-Bit צילום: ניב קנטור

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

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

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

במקום לבדוק כל שורה, לבדוק את המפה

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

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

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

פחות התלהבות מהכלי, יותר שיקול דעת

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

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