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

הניסוי שהפך לפרודקשן

ב-2 בספטמבר ביקש טקניום (Teknium) מהרמס אייג'נט, סוכן הקוד הפתוח שהצוות מפתח, לבצע ניקוי יסודי במאגר שצבר יותר ממיליון שורות פייתון שאינן טסטים. הקובץ gateway/run.py לבדו הכיל 34,847 שורות. 19 שעות פעילות ו-1,393 סב-אייג'נטים מאוחר יותר (בשיא רצו 218 במקביל), המאגר הצטמצם ב-34.4% וה-PR מוזג ב-4 בספטמבר אחרי הפעלה מחדש, סשן המשך ושני סבבי ריוויו קהילתיים. עלות הטוקנים עמדה על כ-19,300 דולר (כ-71 אלף שקל) לריצה הראשית, כ-25 אלף דולר (כ-92 אלף שקל) כולל ההמשכים, לא כולל זמן ריוויו אנושי.

מה בדיוק התבקש האייג'נט לעשות

ההנחיה שניתנה דרך פקודת /goal, שנותנת לסוכן יעד מתמשך ומקפיצה אותו כשהוא נעצר, הייתה מפורטת ותובענית: צמצום דרמטי של שורות קוד, מינימום 30% בסך הכול, פירוק "קבצי אלוהים" (god files), איחוד הלפרים ומתודות לשימוש חוזר, הסרת ניתובי if-else מקוננים, שיפור קריאות ואינטרפרטביליות, וסילוק נפח מיותר בלי להמתין להחלטות אנושיות. התוצאה: היעד הושג במלואו, והקוד הפך קטן וברור יותר בלי לשבור פונקציונליות.

המספרים שמסבירים למה זה לא בוצע קודם

הצוות העריך שעבודה ידנית על אותו היקף הייתה עולה 150 אלף עד 1.8 מיליון דולר (כ-550 אלף עד 6.7 מיליון שקל) לצוות קטן לאורך חודשיים עד שנתיים, טווח שמשקף אי-ודאות לגבי מורכבות הריפקטורינג. מול זה, עלות המודל הייתה שבריר: פחות מ-2% מהקצה התחתון של ההערכה הידנית. הפער הזה מסביר מדוע הניקוי נדחה חודשים ארוכים לטובת פיצ'רים ובאגים דחופים; פתאום הוא הפך לכדאי כלכלית בלי להסיט כוח אדם.

מנגנון השיפור העצמי שמאפשר את זה

מה שאיפשר את הביצוע אינו רק מודל גדול אלא מערכת סקילים (skills) שהרמס בונה לעצמו תוך כדי עבודה יומיומית. כשמהנדס מתקן טעות או שהאייג'נט מוצא נתיב נכון, הלקח נשמר כמסמך מארקדאון קריא עם קבצי עזר וסקריפטים, סקיל שנטען אוטומטית במשימות עתידיות. הסקיל hermes-agent-dev, למשל, מכיל הוראה להריץ טסט כושל על origin/main HEAD בסביבה נקייה כדי לבדוק אם הכישלון קדם לשינוי; אותה לוגיקה שימשה בריפקטורינג להשוואה מול בסיס קפוא בכל אינטגרציה של שינויים מהסב-אייג'נטים.

סקילים עוברים בין מהנדסים, לא רק בין ריצות

הסקילים אינם נשארים אצל מפתח יחיד. טקניום מעביר את hermes-agent-dev לשאר המהנדסים בצוות, והם מתקינים אותו בסביבות ההרמס שלהם, כך שכל אייג'נט נהנה מהניסיון המצטבר של האחרים. זו דוגמה חיה ל"דוגפודינג" (dogfooding) קיצוני: הרמס מפתח את הרמס, לומד מהתהליך, ומייצא את הידע הלאה. התוצאה אינה רק קוד קטן יותר, אלא תשתית שהופכת כל משימת ריפקטורינג עתידית לזולה ומהירה יותר.