מבחן הביצועים v1 של CodeVetter מריץ 27 מקרים סינתטיים דרך צינור (pipeline) של סקירת קוד מבוססת AI ומתעד האם הכלי מזהה את הבאגים שהושתלו. לאחר מכן הוא סופר הצלחה או כישלון עבור כל מקרה.
למה מבחן הביצועים הזה חשוב
הבדיקה שואלת שאלה צרה: האם סוקר נתון יכול לזהות את הפגמים המדויקים שמעצבי המבחן הטמיעו בסט הקבוע הזה של קטעי קוד (snippets)? מפתחים יכולים להשתמש בתוצאה כבדיקה מהירה של כיסוי הבעיות. מכיוון שהמאגר (repository) כולל את חבילות המשימות ואת סקריפט הניקוד, כל אחד יכול להריץ את הבדיקה מחדש ולקבל את אותם המספרים.
מה המבחן לא מוכיח
סדרת מקרים סינתטית של 27 מקרים אינה מהווה תחליף לאלפי ה-pull requests שצוות מטפל בהם מדי יום. המבחן אינו אומר דבר לגבי:
- גיוון בעולם האמיתי – הוא מכסה רק מספר מצומצם של שפות וטווח מוגבל של קטגוריות באגים.
- ביצועים – הוא אינו מספק מדידות של זמן או עלויות מחשוב.
- אמינות על פני בסיסי קוד שונים – ללא בדיקות על מאגרים חיים (live-repo), איננו יכולים לדעת אם הכלי יפספס פגמים עדינים או ייצר התראות שווא (false positives) בסביבת הייצור (production).
שילוב התוצאות המפורסמות עם קבצי התשתית וההבטחות ל"נתונים רחבים וריאליסטיים" בעתיד יוצר נרטיב שיווקי לפיו הציון הבודד מייצג יכולת מוכנה לייצור, דבר שהנתונים אינם תומכים בו.
איך המבחן הזה משתלב באקו-סיסטם הבדיקות הרחב יותר
מבחני ביצועים מסוג זיהוי (recognition-style), כמו אלו של CodeVetter, ממפים את שטח הפנים שבו כלי יכול לפעול. הם משלימים מבחנים פונקציונליים כגון SWE-bench, שבודקים האם תיקון (patch) שנוצר על ידי AI אכן פותר בעיה אמיתית בבסיס קוד קיים. יחד הם נותנים תמונה מלאה יותר: כיסוי לעומת אפקטיביות.
מבחן ביצועים טוב לסוכן (agent) צריך לחשוף את כל ה-stack:
- מערך הנתונים (dataset) – קלטים גולמיים ופלטים צפויים.
- תיעוד לכל מקרה – דף לכל בדיקה המציג את הבאג, התיקון הנכון ותגובת הכלי.
- פלטי הסוקר – ההערות או ההצעות המדויקות שה-AI הפיק.
- מתודולוגיית ניקוד – כיצד נשפטים התאמות, כולל סובלנות לניקוד חלקי.
- הוראות לשחזור (reproducibility) – קיבוע גרסאות (version pins), פרטי חומרה וסקריפטים להרצת הבדיקה מחדש.
רק כאשר כל החלקים הללו שקופים, נוכל לסמוך על ציון מצטבר בודד.
מגבלות שהמבחן עצמו מציין
- מקרים סינתטיים, שאינם נלקחים ממאגרים חיים.
- בחירה מצומצמת של שפות וסוגי באגים.
- אין נתוני זמן או עלות, ולכן היעילות אינה ידועה.
- מגבלות דיוק שעלולות להסתיר כישלונות גבוליים.
מה לעקוב אחריו בהמשך
הצעד הבא עבור CodeVetter — ועבור כל מי שמשתמש בסוקרי AI — הוא הוכחות חוזרות ונשנות על קורפוסים (corpora) גדולים ומגוונים יותר. המשמעות היא פרסום תוצאות על זרמי pull-requests אמיתיים, דיווח על שיהוי (latency) וצריכת מחשוב, ופירוט של מצבי כישלון לפי קטגוריות. עד שנתונים כאלה יופיעו, התייחסו לציון של 27 המקרים כאינדיקטור מוקדם, ולא כהבטחה למוכנות.
שורה תחתונה: מבחן ביצועים שאומר לך רק אם כלי יכול לזהות קומץ באגים שנכתבו מראש הוא שימושי לבדיקת תקינות (sanity-check), אך הוא אינו מאשר שהכלי ישרד את המציאות המבולגנת והרגישה לעלויות של סקירת קוד בסביבת ייצור.