כשסוכן אחד הופך למנהל של כמה סוכנים, מישהו צריך לשלם גם על התיאום — ולא תמיד מקבלים בתמורה תוכנה טובה יותר.
סוכן אחד כותב את הממשק, אחר מטפל במסד הנתונים, שלישי בודק את הקוד, ומעל כולם סוכן מנהל שמחבר את החלקים. על הנייר, זו דרך מפתה להפוך בקשת פיתוח אחת לצוות תוכנה שלם. בפועל, מתברר שגם לעובדים הדיגיטליים יש הוצאות תיאום. בדיקה חדשה של חברת הערכת המודלים Vals AI, שעליה דיווח The Decoder, מצאה שצוותי סוכנים עלו משמעותית יותר מסוכן יחיד, בלי להציג ברוב ההשוואות יתרון איכות שאפשר לקבוע בביטחון סטטיסטי. זה ממצא שמצנן הבטחה מרכזית בתחום: אם אפשר להפעיל כמה מערכות במקביל, לכאורה אפשר גם לקבל יותר יכולת. אלא שהיכולת לחלק עבודה והיכולת להפיק ממנה תוצאה טובה יותר הן שתי שאלות שונות. החשבון, לעומת זאת, יודע להתחבר מצוין.
לפי הבדיקה המקורית של Vals AI, הניסוי כלל 50 אפליקציות ווב שנבנו ממפרטי מוצר באמצעות GPT-6 Sol ו-Claude Opus 5.5. כל מודל נבדק לבד ובצוות, ברמת מאמץ חשיבה בינונית ומרבית. הציון התבסס על שיעור בדיקות הממשק שעברו, ולא על התרשמות מהקוד. הצוותים עלו פי 1.8 עד 5.1, ורק אחת מארבע ההשוואות הציגה שיפור מובהק סטטיסטית: Sol במאמץ בינוני, שהשתפר ב-7.3 נקודות אחוז. במקרה הקיצוני, צוות Opus במאמץ מרבי עלה בממוצע 122 דולר לאפליקציה, לעומת 23.77 דולר לסוכן יחיד באותה רמת מאמץ. גם יתרון בזמן לא היה מובטח: צוות Sol במאמץ מרבי קיצר את זמן העבודה החציוני מכ-38 לכ-28 דקות, בעוד צוותי Opus ארכו יותר זמן. חלק גדול מההוצאה הנוספת הגיע מקריאת קלט שנשמר במטמון: לכל סוכן הקשר משלו, שמועבר שוב בקריאות למודל.
התמונה הזאת משתלבת גם בנתונים של Anthropic, שאותם מביא The Decoder מתוך מסמך המערכת של Opus 5.5. בשתי משימות, בניית בסיס ידע והוכחת משפטים ב-Lean, המעבר מסוכן אחד לעשרה העלה את הציונים באופן ניכר. אבל המעבר מעשרה למאה סוכנים הוסיף מעט בלבד לאחר 24 שעות: בבסיס הידע הציון עלה מ-0.70 ל-0.74, ובהוכחת המשפטים מ-0.66 ל-0.68. כלומר, התועלת לא נעלמה לחלוטין, אבל התוספת הלכה והצטמצמה. אלו ניסויים אחרים, ולכן אין לחבר את הציונים שלהם ישירות לתוצאות בניית האפליקציות. הם כן מדגישים שאלה משותפת: באיזה שלב תוספת כוח העבודה מפסיקה להצדיק את המשאבים שהיא צורכת? מערכת שמגיעה מהר יותר לרמה מסוימת יכולה להיות שימושית מאוד, גם אם התוצאה הסופית שלה כמעט לא משתפרת. צריך פשוט לדעת איזה יתרון קונים.
כדאי גם להיזהר מהכותרת הנוחה שלפיה צוותי סוכנים הם בזבוז מוחלט. Vals מדגישה שמדובר במדד אחד לבניית אפליקציות, ושכל תצורת ניסוי הורצה פעם אחת על קבוצת המשימות. היעדר מובהקות בשלוש השוואות אינו הוכחה לכך שאין שום תועלת; הוא אומר שהבדיקה הזאת לא סיפקה ראיות מספיק חזקות ליתרון. מעבר לכך, ציון בבדיקות ממשק אינו מכסה לבדו אבטחה, תחזוקה או איכות לאורך זמן. מבחינה כלכלית, זו הבחנה חשובה: צוות יכול להיות יקר יותר ועדיין להשתלם אם הוא מקצר המתנה קריטית, או מטפל בעבודה שאפשר לפצל באמת. מצד שני, עצם העובדה שסוכנים עסוקים, בודקים ומחליפים ביניהם הודעות אינה מדד לתפוקה. גם במשרד רגיל, הרבה פעילות ביומן לא מבטיחה שהמוצר מתקדם.
הניתוח שלנו: עבור סטארטאפ ישראלי או בית תוכנה שמנסה לתמחר שירות מבוסס AI, הנתון החשוב הוא העלות לתוצאה שעומדת בדרישות. מחיר של הרצה בודדת יכול להיראות זניח בזמן הדגמה, אך הוא הופך לרכיב עסקי כשאותו תהליך מופעל שוב ושוב עבור לקוחות. אם צוות מייקר את העבודה בלי לצמצם תיקונים, בלי לשפר הצלחה ובלי לחסוך זמן בעל ערך, התוספת אוכלת את הרווח. ואם הוא כן מקצר משמעותית את הדרך לתוצר שימושי, ייתכן שהפרמיה מוצדקת. לכן ניסוי מקומי צריך להשוות על משימות אמיתיות גם איכות, גם זמן עד למסירה וגם את עבודת הבדיקה האנושית שנשארה בסוף. זו מסקנה עסקית מהנתונים, לא ממצא על חברות בישראל: דמו מרשים של חמישה סוכנים אינו עדיין הוכחה לחיסכון.
יש כאן גם לקח לאופן שבו קונים ומציגים כלי AI. מספר הסוכנים הוא מאפיין של המערכת, לא תוצאה שהלקוח מקבל. לפני שבוחרים ארכיטקטורה מורכבת, אפשר להגדיר רף הצלחה ברור לסוכן יחיד, ואז לבדוק אם חלוקת העבודה משפרת אותו במחיר סביר. חשוב במיוחד לבדוק את נקודות החיבור: האם החלקים שבנו הסוכנים עובדים יחד, והאם התוצר השלם עומד בבקשה המקורית? שאלת ההמשך למחקר היא אילו משימות נהנות באופן עקבי מצוותים, ובאילו תנאים התיאום משתלם. עד שתהיה תשובה רחבה יותר, כדאי לבקש מספקי המערכות להראות שיפור מדיד מול חלופה פשוטה יותר. צוות דיגיטלי יכול להיות השקעה טובה; מספר המשתתפים לבדו עדיין לא משלם את החשבון.
