צוותי סוכני AI מייקרים את הפיתוח בלי לשפר תוצאה

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

במחקר שפורסם ב-The Decoder, חברת ההערכה Vals AI בחנה ביצועים של מודלים בפיתוח 50 אפליקציות ווב מלאות. הם השוו בין סוכן בודד לצוות סוכנים, בשתי רמות מאמץ הסקה שונות. הממצאים ברורים: צוותי סוכנים צורכים פי 1.8 עד פי 5.1 יותר משאבים בהשוואה למודל יחיד שעובד לבד. התמורה בקוד עובד שואפת לאפס.

מס התיאום אוכל את התקציב

הבנצ׳מרק של Vals AI, שנקרא Vibe Code Bench, דרש לבנות אפליקציות מלאות עם בסיס נתונים וממשק משתמש. מתוך ארבע השוואות ישירות בין עבודה יחידנית לצוותית, רק במקרה בודד נרשם שיפור מובהק סטטיסטית: GPT-6 Sol ברמת הסקה בינונית, שבה הצוות רשם יתרון של 7.3 נקודות. בשאר המקרים, ההבדלים נעו בין מינוס 0.3 לפלוס 3.4 נקודות, טווח שאינו מובהק סטטיסטית. הוספת סוכני משנה שרפה תקציב בלי לספק שום שיפור אמיתי באיכות הקוד.

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

צוותי סוכנים מספקים כמעט אפס תוצאות טובות יותר לעומת סוכנים בודדים.The Decoder

הסקה עמוקה מנצחת נחיל

במקום לפזר את העבודה על פני חמישה סוכנים מקבילים, מתברר שעדיף לתת למודל בודד לחשוב יותר זמן. בבדיקות של GPT-6 Sol, העלאת רמת ההסקה של סוכן בודד הזניקה את הציון ב-11.4 נקודות, מ-77.6% ל-89%. זה שיפור גבוה בהרבה מזה שהשיג צוות סוכנים ברמת מאמץ בינונית (84.9%). הסוכן הבודד עם חשיבה עמוקה אמנם עלה 4.82 דולר לאפליקציה לעומת 3.07 דולר לצוות הבינוני, אבל הוא סיפק קוד איכותי בהרבה בלי להסתבך בתקשורת של בוטים.

התמונה מקצינה כשבוחנים את Opus 5.5 מבית Anthropic. סוכן בודד ברמת מאמץ בינונית השיג ציון של 91.5% בעלות של 4.08 דולר לאפליקציה. צוות סוכנים מקביל של אותו מודל ברמת הסקה מקסימלית השיג 93.2%, פער זניח ברמת המובהקות, אך גבה עלות ממוצעת של 121.95 דולר לאפליקציה. לפי ממצאי Vals AI, צוותי סוכנים עולים פי 1.8 עד 5.1 יותר מסוכן יחיד בלי להביא יתרון של ממש באיכות ברמות הסקה גבוהות. מי שבוחר בארכיטקטורת נחיל רק כדי לשפר את הדיוק, פשוט שורף מזומנים.

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

ההבדל בין מהירות לאיכות

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

בבנצ׳מרק של Vals AI, הפיצול עבד עבור GPT-6 Sol, שקיצר את זמן הריצה החציוני מ-38 דקות ל-28 דקות במאמץ מקסימלי. אבל אצל Claude Opus 5.5 קרתה תופעה הפוכה. הסוכן המוביל של Claude ייצר חוזה עבודה משותף ומפורט, ושלח גלי סוכנים סדרתיים של בונים ובודקים שחיכו זה לזה. זמן הריצה של צוות Opus במאמץ מקסימלי זינק לכמעט שלוש שעות לאפליקציה, פי 2.3 יותר מסוכן יחיד. במקום מקביליות זריזה, המערכת נתקעה בפקק בירוקרטי של בדיקות חוזרות.

גם נתוני ה-System Card הרשמיים של Claude Opus 5.5 מחזקים את המגמה. במשימות מאגרי ידע, מעבר מסוכן יחיד לעשרה סוכנים העלה את הציון מ-0.53 ל-0.70, אך קפיצה נוספת ל-100 סוכנים הזיזה את המחט בקושי ל-0.74, תוך שריפת ענק של טוקנים. במשימות מסוימות במודלים מקבילים נרשמה ירידה בביצועים כשהעלו את מספר הסוכנים מ-30 ל-100. תוספת ידיים עובדות יוצרת חיכוך שמבטל את התועלת.

החשבון תופח בעברית

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

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

מתי לעצור את המקביליות

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

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

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