סוכני AI בפיתוח תוכנה: מה המהלך של טק מהינדרה מחייב לשנות

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

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

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

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

למה האוטומציה מתרחבת מעבר לכתיבת קוד?

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

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

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

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

מערכות ותיקות: קל יותר לייצר קוד מאשר להבין התחייבות עסקית

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

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

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

מודל יכול להציע כיצד לשנות מערכת. הארגון חייב להגדיר מה אסור לשנות במשמעות העסקית שלה.

מה צריך להשתנות בהתקשרות עם ספק הפיתוח?

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

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

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

אדם בלולאה, בלי להפוך אותו לצוואר הבקבוק

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

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

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

1. 01

   בוחרים תהליך מוגבל

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

2. 02

   מגדירים בסיס להשוואה

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

3. 03

   קובעים גבולות פעולה

   מגדירים הרשאות, סביבות עבודה ופעולות שמחייבות אישור אנושי.

4. 04

   בודקים תוצאה עצמאית

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

5. 05

   מרחיבים לפי ראיות

   מרחיבים את השימוש רק כאשר השיפור נשמר בלי פגיעה באיכות ובבקרה.

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

לקנות שירות, אבל לשמור יכולת פנימית

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

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

Grok Build, Claude Code וכלים אחרים צריכים להיבחן מול אותו תהליך ארגוני, לא רק מול הדגמה. יש לבדוק גם תנאי שימוש בנתונים, שמירת מידע, מיקום עיבוד, תמיכה בסביבת הפיתוח ותלות בספק.

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