סוכני קוד מציפים את Git: מה OpenAI נאלצה לבנות בגללם

בקצרה: ב-OpenAI הסוכנים של Codex עבדו כל כך הרבה במקביל, שה-Git של החברה התחיל לקרוס, עם אמינות שירדה לפעמים מתחת ל-90%. הם בנו שרת Git חדש בשם Pando, שמוותר על שני דברים ש-Git רגיל מניח שהם חובה. לפי OpenAI, זמן ה-push ירד בכ-80% והשרת מגיש היום כמעט פטה-בייט של נתונים ביום. השיעור למי שעובד עם סוכנים: הם לא רק כותבים קוד, הם מעמיסים על כל מה שמסביב לקוד.

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

אני מפתח 17 שנה, ו-Git הוא הכלי שהכי פחות חשבתי עליו. הוא פשוט עובד. אז כשהחברה שמאחורי Codex כותבת שה-Git שלה לא החזיק, שווה לעצור ולקרוא.

מה בעצם קרה ב-OpenAI?

ב-OpenAI כל הקוד יושב בריפו אחד גדול (monorepo). לפי הפוסט, במהלך השנה האחרונה הריפו הזה גדל בקצב חד, בגלל כמות העבודה המקבילה ש-Codex מאפשר. מסוף השנה שעברה התחילו הבעיות: אחזורים ו-push איטיים, merges שנכשלו, ואמינות שירדה לפעמים מתחת ל-90%.

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

למה סוכנים מציפים את Git?

ההסבר בפוסט פשוט, ודווקא בגלל זה הוא מעניין. מהנדס אחד מחזיק היום כמה שינויים שמוכנים לבדיקות באותו זמן. כל push כזה מפעיל כמה משימות שמורידות את אותו commit: סביבות פיתוח, משימות מחקר ובדיקות אוטומטיות (CI).

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

ב-Hacker News, בדיון על הפוסט, היו מי שהציעו הסבר נוסף: סוכנים כותבים הרבה יותר קוד מאדם, ושומרים הרבה שלבי ביניים. מישהו אחד אפילו כתב שראה 600 commits ו-200 אלף שורות לתוכנה שהייתה צריכה 15 commits ו-10 אלף שורות. זו תגובה של אדם אחד ולא נתון, אבל השאלה שהיא מעלה במקום: חלק מהעומס הוא עבודה, וחלק הוא נפח.

מה OpenAI ויתרה עליו כדי שזה יעבוד?

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

ויתור ראשון: לא כל הריפו צריך להיות מסונכרן באותו רגע

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

ויתור שני: לא מכינים חבילה מיוחדת לכל לקוח

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

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

מה המספרים אומרים?

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

• זמן ה-push החציוני ירד בכמעט 80%, כלומר כמעט פי 5 מהר יותר.
• אמינות ה-merge השתפרה. אין מספר מדויק בפוסט.
• כמעט פטה-בייט של נתוני Git ביום, ובשעת שיא יותר מ-57 טרה-בייט בשעה אחת.
• הורדות שממצות קו של 10 Gbps, על שרתים רגילים בענן.

הסוכנים בנו את המערכת שמחזיקה אותם

הפרט שהכי תפס אותי לא קשור ל-Git בכלל. לפי הפוסט, Pando נבנה עם Codex, מהתחלה ועד ייצור, בעשרה שבועות. מהנדס אחד תכנן את הליבה, צוותי סוכנים מימשו אותה, וקומץ מהנדסים פרס אותה. הוא כתוב ב-Rust ומשרת תעבורה אמיתית מאפריל.

וזה לא נגמר בכתיבת קוד. סוכנים כתבו הוכחות פורמליות (בשפות Lean ו-TLA+) כדי למצוא באגים ולהוכיח שהמערכת מתנהגת נכון, וסשנים רצו מאות שעות ברצף. סוכנים אחרים תוקפים את Git ואת Pando מסביב לשעון, כדי למצוא חורים לפני שמישהו אחר ימצא. גם המעבר עצמו נעשה בלי השבתה: Pando התחיל כשכבה מעל המערכת הישנה, ו-Codex עזר למפתחים להעביר את הסביבות שלהם.

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

אפשר כבר להשתמש ב-Pando?

לא. גרג ברוקמן מ-OpenAI כתב ב-X שהם שוקלים לתת את Pando לאחרים, וביקש שמי שמעוניין יכתוב לו. זה לא מוצר זמין. מה שכן פתוח: חלק מהתיקונים ש-OpenAI עשתה ל-Git עצמו כבר נכנסו לגרסה הרשמית, ואחרים נמצאים בעותק הציבורי שלהם בגיטהאב.

מה אני הייתי עושה

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

1. סופרים כמה ענפים פתוחים יש. סוכנים פותחים ענפים בקלות ולא תמיד סוגרים. ענף שסיים את תפקידו נמחק.
2. בודקים מה כל push מפעיל. אם כל דחיפה של סוכן מריצה את כל הבדיקות, אתם משלמים על זה בזמן ובכסף. אפשר להריץ בדיקות מלאות רק כשהענף מוכן למיזוג.
3. מבקשים מהסוכן לאחד שלבים. לא כל שלב ביניים צריך להיות commit נפרד. הנחיה אחת בקובץ ההוראות של הפרויקט (למשל CLAUDE.md) חוסכת הרבה רעש בהיסטוריה.
4. מסתכלים על הזמנים. אם push או fetch התחילו להתארך, זה סימן מוקדם. עדיף לראות את זה בשבוע הראשון מאשר כשמשהו נכשל.

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

שאלות נפוצות

מה זה Pando?

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

אפשר להשתמש ב-Pando היום?

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

זה רלוונטי למי שמריץ סוכן אחד או שניים?

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

הנתונים של OpenAI נבדקו על ידי מישהו מבחוץ?

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

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

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

מקור: Scaling Git at OpenAI, הפוסט של OpenAI על Pando. ההסברים והמסקנות במילים שלי. עוד: OpenAIDevs ב-X · גרג ברוקמן ב-X · הדיון ב-Hacker News.