Michael Johnsonהחל מ־5 בנובמבר, צוותים המשתמשים ב־GitHub Copilot Code Review יכולים לראות בדוחות ה־API אילו הערות הובילו מפתחים לפעולה. באותו יום הוסיפה GitHub שדות המסייעים למנהלים לזהות פערים בטלמטריה וגרסאות מיושנות של עורכי קוד. העדכונים האלה נותנים למנהלים ולבעלי ארגונים דרך ממוקדת יותר לבדוק כיצד סקירת קוד באמצעות AI פועלת ועד כמה נתוני השימוש ב־Copilot מלאים.
איך למדוד תגובה להערות AI
לאובייקט היומי `repos-1-day` בדוח לפי מאגר נוספה רשומת `copilot_code_review`. בין השדות שלה נמצאים `total_comments_evaluated`, מספר ההערות שנבדקו, ו־`total_comments_addressed`, מספר ההערות שהמפתח הגיב להן. כדי לחשב את שיעור ההערות שטופלו במאגר, יש לחלק את הערך השני בראשון. השדות החדשים מתוארים בעדכון של Copilot usage metrics API.
GitHub מחשיבה הערה כמטופלת אם המפתח החיל את התיקון המוצע, ביקש מ־Copilot לבצע אותו, ערך את הקוד בעצמו או השיב שהתיקון ייכלל בבקשת המשיכה הבאה. הדוח מפרט בנפרד הערות לפי חומרה, רמת סקירה, סוג ההערה והאם נכללו הוראות נוספות או כלים. כך הצוות יכול, למשל, לבדוק אם התגובות להערות אבטחה שונות מהתגובות להערות אחרות, או אילו קטגוריות דורשות יותר עבודה ידנית.
המדד מציג פעולה שתועדה, ולא איכות מאומתת של התיקון. לכן כדאי לעיין בו לצד בדיקת הקוד ומצב בקשת המשיכה: שיעור גבוה של הערות שטופלו מעיד שההערות זכו למענה, אך אינו מוכיח כשלעצמו שכל השינויים נכונים או נחוצים. נקודה חשובה נוספת: ההערות נספרות ביום שבו בקשת המשיכה מוזגה, ולא ביום שבו Copilot פרסמה אותן.
למה מדד הפעולות שונה ממדד קבלת ההצעות
השדות הקודמים ספרו הפעלות של Copilot Code Review ומקרים שבהם המשתמש לחץ על כפתור להחלת הצעה מוכנה. המדד החדש כולל דרכים נוספות להגיב: המפתח יכול לבצע את התיקון בעצמו, לבקש מ־Copilot לבצע אותו או לדחות את השינוי לבקשת המשיכה הבאה. לכן `total_comments_addressed` משיב על השאלה אילו פעולות ננקטו בעקבות ההערות, ואילו `total_copilot_applied_suggestions` מתייחס רק לקבלת הצעות שאפשר להחיל בפעולה אחת.
הדוח כולל גם את `total_merged_no_human_change_request_after_review`: מספר בקשות המשיכה שמוזגו ונבדקו בידי Copilot, ושלאחר הסקירה הראשונה שלהן אף אדם לא ביקש שינויים. המדדים האלה מתארים שלבים שונים בתהליך, ועדיף לקרוא אותם יחד: הראשון משקף את התגובה להערות, והשני את מהלך הסקירה עד למיזוג.
השדות החדשים מראים מדוע הדוחות אינם מלאים
עדכון נפרד מ־5 בנובמבר מוסיף מידע על טלמטריית לקוח ועל גרסאות הכלים. השדה `client_telemetry_present` מראה אם התקבלו אירועים מעורך הקוד של המשתמש ביום מסוים; `usage_metrics_requirements` מציין אם סביבת הפיתוח המשולבת (IDE) וההרחבות עומדות בגרסאות המינימום הנדרשות למדדים. מנהלים מקבלים גם נתונים יומיים על משתמשים שלא התקבלה מהם טלמטריה ועל משתמשים שיש להם לפחות רכיב אחד מיושן. הפרטים מפורטים בהודעה על פערים בנתוני Copilot.
המידע הזה מסייע להבחין בין פעילות המשתמש לבין שלמות הדיווח. GitHub מסבירה שמשתמש עשוי להיחשב פעיל גם אם לא התקבלו אירועים מעורך הקוד שלו — ואז חסרים בדוח פרטים, כגון פירוט השימוש לפי תכונה ומודל. הסיבות האפשריות כוללות גרסה ישנה של סביבת הפיתוח המשולבת או של הרחבה, טלמטריה של עורך הקוד שהושבתה, וכן שרת proxy או חומת אש שחוסמים אירועים.
אין לחבר את שני מוני הפערים כדי לחשב את מספר המשתמשים הייחודיים: אותו אדם עשוי להופיע בשתי הקבוצות. נוסף על כך, גרסה תקינה של עורך הקוד אינה מבטיחה שהטלמטריה תתקבל — למשל, מגבלות רשת עדיין עשויות למנוע זאת. אם ערך חסר או שווה ל־`null`, GitHub מציינת שמדובר בנתונים שאינם זמינים, ולא באפס או בהיעדר בעיה.
מה המשמעות עבור צוותים
העדכונים מאפשרים להחליף מדד כללי של פעילות Copilot בשתי בדיקות מעשיות יותר: מה קורה עם הערות Code Review, ועד כמה הנתונים שעליהם מבוסס הדוח הפנימי מהימנים. מנהלי צוותי הנדסה יכולים להשוות בין סוגי הערות ומאגרים, ואילו מנהלים יכולים לזהות משתמשים שצריכים לעדכן את סביבת הפיתוח המשולבת או את ההרחבה, או לבדוק את הגדרות הרשת.
הדוחות זמינים ברמת הארגון וברמת הארגון הארגוני למשתמשים בעלי הרשאות מתאימות לצפייה במדדי Copilot; יש להפעיל את מדיניות Copilot usage metrics. נתוני Code Review נמצאים ברשומות `repos-1-day`, ואילו שדות הטלמטריה והגרסאות מופיעים בדוחות משתמשים לתקופות של יום אחד ו־28 ימים. לכן העדכון החדש שימושי במיוחד לארגונים שכבר מנהלים את Copilot באופן מרכזי: כעת הם יכולים לבדוק לא רק את עצם השימוש בעוזר, אלא גם את התגובה לסקירות שלו ואת הסיבות למדידות חלקיות.
