אוטומציה של תיקון באגים: הטמעת SWE-Agent

הטמעת SWE-Agent: היכן נשבר תיקון באגים אוטומטי

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

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

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

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

מה משתנה לאחר הפעלת סוכן אוטונומי בפיתוח

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

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

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

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

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

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

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

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

שלבי הטמעה: מניתוח המאגר ועד העברה לצוות

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

1. אודיט של בסיס הקוד והבדיקות. מנתחים את מבנה המאגר, הבנייה, בידוד המודולים, שיעור הבדיקות העוברות וכיסוי נתיבים קריטיים. בסיום מתעדים אילו אזורים הסוכן מתקן באוטונומיה ואילו סגורים לשינויים.
2. סכמת מתחם בדיקות. מגדירים מה רץ על כל תיקון: בדיקות יחידה ואינטגרציה, לינטרים, ניתוח סטטי. כלל מרכזי — תיקון בלי הרצה ירוקה לא נכנס לענף.
3. הגדרת סביבה וכללים. בונים קונטיינר מבודד עם השירותים ונתוני הבדיקה הנדרשים, מתארים בהוראות לסוכן את קונבנציות הפרויקט, גבולות השינויים ופורמט הקומיט.
4. הרצת פיילוט. נותנים 10-15 משימות אמת מהתור — מפגמים קטנים ועד תיקונים בכמה קבצים. מחשבים את שיעור ההחלטות שהסוקר קיבל בלי השלמות, ומנתחים את סיבות הדחיות.
5. בדיקת איכות התיקונים. בנפרד בוחנים החלטות שנדחו: היכן הסוכן עקף בדיקות, תיקן בשכבה הלא נכונה, שבר תאימות לאחור. לכל סוג שגיאה מוסיפים בדיקה או מדייקים כלל.
6. העברת הפתרון לצוות. מוסרים קונפיגורציה, סכמת מתחם, הוראות לסוכן, יומן הרצות ונוהל לניתוח תיקונים שנויים במחלוקת. לאחר הדרכה המהנדסים מריצים משימות ומשנים כללים בעצמם.

מה נשאר לצוות: קונפיגורציות, נהלים, תיעוד

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

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

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

מקרה בוחן: איך צמצמנו את זרם הפגמים הקטנים בצוות מוצר

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

מדדים לפני הטמעה

בשבוע הצטברו 45-60 תיקונים קטנים, ובזמן נסגרו כשליש. זמן חציוני עד תיקון — 6 ימי עבודה, הפגמים הישנים ביותר היו תלויים שלושה שבועות. על ניתוח פניות זהות הושקעו עד 20% מהספרינט, וחלק מהפגמים אבדו בהעברה בין המשתתפים.

מה שינינו ומה קיבלנו

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

כעבור חודש זרם הפגמים הקטנים הפסיק לגדול, הזמן החציוני עד תיקון הצטמצם ל-1-2 ימים, ושיעור התיקונים שנדחו של הסוכן התייצב על 22% — אותם או מחזירים להשלמה או סוגרים ידנית. המהנדסים הפסיקו להיות צוואר בקבוק במשימות זהות וחזרו לפיתוח המוצר.

מה לעשות אם הטמעת הסוכן כבר החלה בכוחות עצמכם

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

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

שגיאות הגדרה טיפוסיות נראות כמעט מיד: תחום הרשאות רחב מדי, שבגללו הסוכן פוגע במודולים סמוכים; היעדר מגבלת ניסיונות, שבגללו לולאת התיקונים לא מתכנסת; בדיקות שהסוכן כתב לתיקון שלו עצמו — הן ירוקות, אבל אינן תופסות רגרסיה. וכמעט תמיד אין סט משימות ייחוס, ולכן «נהיה טוב יותר» אינו נתמך בדבר.

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

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

ספקות טכניים: גישות, אבטחה, איכות התיקונים

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

איך להגביל גישה למאגר?

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

מה קורה כשהתיקון שגוי?

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

איך נבדק כיסוי הבדיקות?

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

נדון במשימה: איך להריץ סוכן במתחם שלכם

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

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

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