2,000 אייג'נטים בפרודקשן: כך הפכנו את ה-AI לחלק אמיתי מהצוות בלי לאבד שליטה

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

איך אפשר לסמוך על הסוכנים באמת? (צילום מסך: מאנדיי)

מאת תומר ברוק, Senior Engineering Manager במאנדיי

אטלס, הוא כבר חלק בלתי נפרד מהצוות שלי. הוא היה למעשה האייג'נט הראשון שחבר לצוות. הוא בוחר משימות מאותו בקלוג כמו שאר חברי הצוות, פותח Pull Requests ומבצע Code Reviews לחברי הצוות. אטלס הוא הראשון מתוך כ-2,000 אייג'נטים שרצים כיום בפרודקשן במאנדיי. אנחנו מתייחסים אליהם כאל חברי צוות דיגיטליים: הם עובדים על אותו קוד, באותם תהליכים ובאותם כלים כמו המפתחים האנושיים.

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

אבל קודם היינו חייבים לענות על השאלה: איך אפשר לסמוך על אייג'נטים מספיק כדי להפוך אותם לחברי צוות – בתוך מערכת בת יותר מעשר שנים, עם יותר מ-750 שירותים ומעל 700 מפתחים?

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

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

אתגר ראשון: איך נדע שה-PRs באמת טובים?

הפתרון שלנו לווידוא איכות ה-PRs היה Verification Loops ו-Evals. כל הרצה של האייג'נט מתועדת במערכת traces, והמודל מעריך אותה: האם האייג'נט הבין את הכוונה? האם הוא ביצע את המשימה נכון? והאם הוא פעל במסגרת ההרשאות והגבולות שהוגדרו לו?

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

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

אתגר שני: כל שיחה התחילה מאפס

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

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

---
name: keep-it-brief
description: User prefers short, direct responses
  type: feedback
---
Default to the shortest useful answer. Skip preamblesWhy: the user said long responses are unhelpful

אתגר שלישי: ה-PRs נפתחו, אבל לא עבדו כמצופה

קוד שנכתב, מוצלח ככל שיהיה, לא בהכרח עבד בסביבת בדיקות אמיתית. כדי לסגור את הפער, בנינו Feedback Loop מלא: שינויי Backend נפרסים אוטומטית לסביבות בדיקה מול נתוני Staging אמיתיים. במקביל, האייג'נטים מפעילים דפדפנים באמצעות Playwright כדי לוודא שה-Frontend עובד כמצופה.

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

אתגר רביעי: ה-Code Review הפך לצוואר בקבוק

אחד האתגרים הגדולים בעבודה עם אייג'נטים הוא שעומס העבודה נודד הרבה פעמים ממוקד אחד לאחר – ולכן הם לא באמת חוסכים זמן. במקרה שלנו, צוואר הבקבוק עבר ל-Code Review. אבל במקום להוסיף עוד Reviewers, הזזנו את כל תהליך הבקרה שמאלה. כלומר, עשינו Shift Left: כל Pull Request נבדק מול יותר מ-100 סטנדרטים הנדסיים, כאשר רבים מהם מוגדרים כחוסמים.

הבדיקות מתבצעות בשלוש נקודות:

• בזמן כתיבת ה-Specification
• בזמן כתיבת הקוד
• לפני פתיחת ה-PR

המטרה אינה לייצר קוד "יפה יותר", אלא למנוע תקלות בפרודקשן.

ה-Guardrails מחוברים ל-MCP הפנימי של מאנדיי, שמספק לאייג'נטים מידע עדכני על סביבת פרודקשן – Feature Flags, קונפיגורציות והתנהגות בזמן אמת.

הנה דוגמה שממחישה כיצד זה עובד: באחד המקרים, אייג'נט ניסה להסיר Feature Flag שנראה לא בשימוש. ה-MCP זיהה שהדגל עדיין מסומן כ-Not Ready for Cleanup, משום שעדיין היו עליו חוקים פעילים בפרודקשן. ה-PR נחסם אוטומטית, ונמנעה תקלה שמנתח קוד סטטי לעולם לא היה מגלה.

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

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

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

כך ניתן להרכיב אוספים שונים של Skills וליצור Personas שונים, מבלי לשנות את תשתית האייג'נט עצמה.

הרגע שבו אטלס באמת הפך לחבר צוות

כדי שיהפוך לחבר צוות אמיתי, היינו צריכים לתת לאטלס לעבוד בדיוק באותם מקומות שבהם עובדים כולם. monday boards מהווים את הבסיס לניהול העבודה: בני אדם ואייג'נטים עובדים על אותו Board, מושכים את אותם סוגי משימות ומקשרים Pull Requests לאותם פריטים. כלומר, אין אצלנו "תור AI" – משימת ארכיטקטורה של מפתח יושבת ליד משימת מיגרציה של אטלס. גם ב-Slack אין אצלנו הפרדה, והאייג'נטים נמצאים באותם ערוצים כמו שאר הצוות.

כאשר מתרחשת תקלה, Uzile – אייג'נט ה-On Call שלנו שפועל 24/7, מנתח את הבעיה ופועל. לדוגמה: באחד המקרים מפתח דיווח שנשברה מגבלת הרשאות. Uzile זיהה שהבעיה היא בערך MAX_USER_TEAM_SIZE, שעמד על 25, עדכן אותו, פתח Pull Request ושלח אותו בתוך דקות.

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

גם מבנה הארגון השתנה בהתאם. האייג'נטים לקחו על עצמם את 80 האחוזים של העבודה הרפטטיבית – Tickets, Bugs, Incidents ומשימות שוחקות – בעוד שהמפתחים עברו להתמקד בארכיטקטורה, תכנון ופתרון הבעיות המורכבות באמת.

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

היום 35% מה-Pull Requests במאנדיי נעשים על ידי אייג'נטים, עם שיעור Revert של כ-1% בלבד.

לעבוד עם חבר צוות שלעולם לא ישן

האייג'נטים שלנו לא אוטומציות ולא workflows. הם ישויות אוטונומיות שלוקחות משימה מקצה לקצה. כל שכבה שבנינו – Evals, זיכרון, feedback loops, Guardrails, Skills מודולריים ומנגנוני Governance – קיימים כדי להפוך אייג'נט לאמין מספיק כדי שאפשר יהיה לתת לו עבודה אמיתית ולהמשיך הלאה.

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

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

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