c-CRAB, מדד סוכני ביקורת הקוד: מה הוא מודד, מה הוא מצא, ומה 41.5% באמת אומר

סוכן ביקורת קוד ומבקר אנושי בחנו את אותה בקשת pull request והעלו את אותה דאגה. הטיפול בהערת הסוכן מתקן את הבאג; הבדיקה עוברת. וכל מדד דמיון טקסטואלי שחישבו המחברים דירג את הביקורת של הסוכן כלא קשורה למעשה לזו של המבקר: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, דמיון embedding 54.59. אותה דאגה, מילים שונות, והדרך הסטנדרטית לניקוד ביקורת לא יכלה לראות שהם הסכימו. הדוגמה הזו היא הטיעון מאחורי c-CRAB (מבוטא "see-crab"), מדד סוכני ביקורת הקוד, שפורסם בתור arXiv:2603.23448.

c-CRAB בוחן סוכני ביקורת קוד, לא סוכני כתיבת קוד. בהינתן בקשת משיכה (pull request) — שיכולה להגיע מאדם או מסוכן כתיבת קוד — סוכן ביקורת מייצר ביקורת, ו-c-CRAB נותן ציון לביקורת לפי האם יישומה מוביל לתיקון נכון מבחינה התנהגותית. המדד נבנה על ידי חוקרי הנדסת תוכנה: Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen ו-Abhik Roychoudhury, והוא בוחן ארבעה כלים: PR-Agent, Devin, Claude Code ו-Codex. אחד המחברים קשור ל-SonarSource, והמאמר מבהיר במפורש, במילותיו שלו, מה זה אומר ומה זה לא אומר: "הדעות והמסקנות המובעות במאמר זה הן של המחברים בלבד ואינן מייצגות את המדיניות הרשמית או התמיכות של SonarSource. יתרה מזאת, הממצאים המוצגים כאן הם עצמאיים ואין לפרשם כהערכה של איכות המוצרים של SonarSource."

שתי הערות לפני הפירוט. חלק מהכתבות של צד שלישי מכנות את אותה עבודה בשם “CR-bench”; זהו אותו benchmark, ודף זה משתמש ב-c-CRAB לכל אורכו. כל איור להלן הוא תוצאה שדווחה על ידי המאמר עצמו, שנקראה היום מתוך המאמר וחבילת השכפול — לא הורצה מחדש באופן עצמאי — והפרשנות היא שלנו, בתוספת הדיון המעשי שהמאמר כבר משך. שום דבר מזה אינו הנחיה מהספקים שהכלים שלהם נבדקו. ואם אתה עדיין מתלבט אם להפעיל סוכן ביקורת קוד בכלל, המדריך לקונה שלנו על סוכני ביקורת קוד הוא נקודת התחלה טובה יותר; דף זה עוסק כיצד סוכנים אלה נמדדים.

מדוע c-CRAB מדרג ביקורות באמצעות בדיקות, ולא באמצעות שופט LLM

הדרך הרגילה לניקוד סוכן ביקורת קוד היא להשוות את הביקורת שלו לזו של אדם, באמצעות LLM-as-judge או מדד דמיון טקסטואלי. מחברי c-CRAB דוחים את שתי השיטות. הם טוענים ש-LLM-as-judge סובל מהטיה, מחוסר יציבות ומרגישות להנחיה, מה שמקשה על ניקוד שניתן לשחזור ועקבי. ומקרה הבוחן שלמעלה מראה מה מדדי מחרוזות מודדים בפועל: ניסוח, לא אפקטיביות. לגבי בקשת המשיכה ההיא של python-telegram-bot, ביקורת Codex אמרה את אותו דבר כמו האדם, ו-BLEU-4 ו-ROUGE-L לא הצליחו לזהות זאת.

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

המאמר מגדיר שני סוגי מבחנים, בלשונו: "מבחנים התנהגותיים מייבאים ומריצים את הקוד הנבדק בזמן ריצה. הם קוראים לפונקציות הנבדקות עם קלטים ספציפיים, ובודקים פלטים או מאמתים חריגות. לעומת זאת, מבחנים מבניים בוחנים את טקסט קוד המקור, תואמים תבניות, ובודקים את משטחי ה-API כדי לקבוע האם בוצעו שינויי הקוד הרצויים." החלוקה הסופית היא 42 מבחנים התנהגותיים (17.9%) ו-192 מבחנים מבניים (82.1%). ראוי לומר בכנות: רוב האורקל הוא התאמת תבניות על טקסט המקור, לא הרצת הקוד. ההטיה הזו היא מגבלה אמיתית שכדאי לזכור.

איך נבנה המדד, וכמה עלה המשפך

c-CRAB בנוי על גבי מערך הנתונים הקיים inclusionAI/SWE-CARE, המספק מופעי pull-request עם מטא-נתונים של commit; התרומה של c-CRAB עצמו היא האורקל, לא קורפוס ה-PR. צינור האצירה מפעיל ארבעה מסננים, וכל אחד מהם גובה מופעים. המאמר מדווח על המשפך כך:

• מערך נתונים ראשוני — 671 PRs, 1,313 תגובות.

• סינון ביקורות — 410 בקשות משיכה (PRs), 595 תגובות. מסווג LLM, מכויל לפי סט זהב של 100 תגובות שסומנו ידנית, שומר רק בעיות הניתנות לאימות אובייקטיבי ומשמיט משוב שיחתי או סובייקטיבי.

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

• המרת הערות בשפה טבעית לבדיקות — 339 PRs, 481 הערות. הבדיקות נוצרות עם GPT-5.2 בלולאת חידוד מונחית-ביצוע של עד שלושה ניסיונות; בדיקה נשמרת רק אם היא נכשלת על הקוד המקורי ועוברת לאחר התיקון.

• אימות עם סוכן קידוד — 184 PRs, 234 תגובות. Claude Code על בק-אנד Sonnet-4.6 מנסה לתקן את הקוד בהתבסס על הערת הביקורת האנושית בלבד; מקרים שבהם אינו מצליח לגרום לבדיקה לעבור נמחקים. זוהי הקבוצה הסופית.

כ-27% מבקשות המשיכה הראשוניות שורדות. זהו המחיר הכנה של אורקל מבוסס-בדיקות, וזו גם הסיבה שהבנצ'מרק קטן ולא רחב-ידיים. הסט השורד: 184 מופעי PR, 234 הערות ביקורת מאומתות, 1.27 בדיקות למופע, 418.1 שורות ששונו בממוצע לכל PR, ו-31.8 שורות לכל בדיקה. שני מעריכים שפטו באופן בלתי תלוי אם בדיקה שנוצרה תפסה בנאמנות את חששו של מבקר-האדם, על 50 מופעים מדגמיים, והסכימו ב-84% מהמקרים.

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

התוצאות, ואיך לקרוא אותן

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

• Claude Code — 1,336 תגובות, 7.3 לכל PR — התנהגותי 38.1%, מבני 30.7%, כולל 32.1%

• Devin — 1,344 תגובות, 7.3 לכל PR — התנהגותי 31.0%, מבני 23.4%, כולל 24.8%

• PR-Agent — 524 תגובות, 2.8 לכל PR — התנהגותי 38.1%, מבני 19.8%, כולל 23.1%

• Codex — 324 תגובות, 1.8 ל-PR — התנהגותי 38.1%, מבני 16.1%, כולל 20.1%

• אנושי — 234 תגובות, 1.3 לכל PR — 100% מעצם הבנייה. בני האדם כתבו את ה-oracle, ולכן שורה זו היא סמן קנה מידה, לא מתחרה.

קרא את השורות הללו בעיון לפני שתצטט כל אחת מהן. ה"רק כ-40%" מהתקציר הוא איחוד: 41.5% מתוך 234 הבדיקות עברו על ידי לפחות אחד מארבעת הכלים. זה אינו הציון של סוכן יחיד — הציון הטוב ביותר של סוכן יחיד הוא 32.1% של Claude Code — וזה לא אומר שארבעת הכלים יחד תפסו 40% מהליקויים האמיתיים. הסעיף שלהלן מסביר מדוע.

המספר המעניין ביותר אינו זה שזכה. Claude Code ו-Devin פרסמו כל אחד יותר מ-1,300 תגובות — כ-7.3 לכל PR — כדי להגיע ל-32.1% ו-24.8%. Codex פרסם 324, כ-1.8 לכל PR, כדי להגיע ל-20.1%. קו הבסיס האנושי הוא 1.3 תגובות לכל PR. עשו את החשבון: נפח תגובות גדול פי ארבעה בערך משיג הרבה פחות מכפליים משיעור המעבר. נפח אינו כיסוי. מבקר פטפטן אינו אותו דבר כמו מבקר מועיל, ו-c-CRAB הוא המדד הראשון שהוקם כדי להראות זאת.

התועלת פועלת בכיוון ההפוך

שיעורי המעבר הנמוכים נראים כגינוי, עד שמסתכלים על מה עוד מדדו הכותבים. הם בדקו ידנית 92 תגובות על פני 6 PRs, ושפטו 84% מהן כמועילות (77 מתוך 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. אז רוב התגובות שנכשלות במבחן c-CRAB אינן רעש; הן עוסקות במשהו שהמבקר האנושי לא העלה. המדגם קטן — 92 תגובות, 6 PRs — והמאמר אומר זאת, וכך גם אנחנו צריכים.

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

מה ש-c-CRAB לא יכול לראות

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

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

להריץ את זה בעצמך

אם אתה רוצה לשחזר את המספרים או להוסיף מבקר משלך, חבילת השכפול זמינה לציבור ב־c-CRAB-Benchmark/dataset. ה-README הוא התיעוד בפועל, והוא כן לגבי צורתו של הדבר. ההתקנה היא code>uv sync/code>; אתה צריך Docker ו־code>OPENAI_API_KEY/code> או code>ANTHROPIC_API_KEY/code>, ו-Claude Code גם קורא אישורים מ־code>~/.claude/.credentials.json/code>. הארגון גם מפרסם תמונות Docker מובנות מראש עבור הסביבות.

המבנה: code>pipeline//code> מכיל את לוגיקת הפייפליין ואת הפרומפטים, code>execution//code> את בוני תמונות Docker וכלי העזר לזמן הריצה, code>results_preprocessed//code> את תת־קבוצת ה־benchmark ששוחררה (410 מופעים מעובדים מראש), code>results_pipeline_funnel//code> את קבצי ה־JSONL של stage0–stage4 ואת סיכום המשפך, ו־code>raw_results_compressed//code> את פלטי הניסויים הגולמיים.

שחזור הריצה המלאה כולל חמישה שלבים: לבנות את סביבות Docker (code>execution.build_swe_care/code>), ליצור את הבדיקות (code>run_testgen_full.sh/code>), לאסוף סקירות בסיס (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), להריץ פתרון סוכן (code>run_batch_agent_resolution.py/code>), ואז להעריך (code>run_batch_tool_eval.py --tool <name>/code>). אם אתה רוצה להוסיף סוקר חמישי, שים לב שנקודת ההרחבה אינה ממשק תוסף: פרומפטים של סקירת הבסיס עבור כל כלי נמצאים ב-code>run_batch_baselines.py/code>, והקובץ README אינו מתאר דרך נקייה יותר — אתה עורך את הסקריפט הזה.

שתי עובדות נוספות לפני שאתה משכפל אותו. המאמר ברישיון CC BY 4.0; דף המאגר אינו מציין רישיון עבור הקוד, אז אל תניח שקיים רישיון. המאמר גם אינו מפרסם נתוני עלות או צריכת טוקנים להרצת ה-benchmark — זה לא פורסם, ולכן לא נמציא זאת. מה שהצינור מרמז עליו: תמונת Docker אחת לכל PR על פני 184 מופעים, ובנוסף מעבר פתרון על ידי סוכן, זה לא עניין של אחר צהריים על מחשב נייד.

מה זה אומר עבור כל מי שמשחרר צינור ביקורות

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

זוהי בדיוק התקלה שמתכון הניתוב שמאחורי הבודק שאנו שולחים מגן מפניה — והיא מקבילה עיצובית לביקורת של c-CRAB, לא תוצאת benchmark. הרתמה מריצה בכל זאת שופט LLM, כמעבר שני שמקבץ ממצאים, נותן לכל מקבץ ציון 0–1 האם מדובר בתקלה קונקרטית בשינוי הזה, ומשליך כל דבר מתחת לסף. המתכון שמנחה אותו, code>recipes/orcacode-review.dsl.yaml/code>, הוא קובץ ציבורי. ה-Action אף פעם לא מציין שם של מודל: הוא קורא לאליאס ניתוב, והמתכון מחליט. כפי שהוגדר, המתכון הוא בן ארבע שורות — ברירת המחדל של הבודק היא code>deepseek/deepseek-v4-flash-0731/code>, וכלל שתואם לכותרת code>x-cr-lens: judge/code> שולח את מעבר השיפוט אל code>z-ai/glm-5.3/code>, ספק שונה. דברי המתכון עצמו דורשים שהשופט “לא ינקוב בשמו של מודל ברירת המחדל”, משום שעל המודל של הבודק עצמו הוא “מסכים עם עצמו, ולכן המעבר הופך לרדום בעודו מדווח על הצלחה”.

שופט מספק אחר מפחית הסכמה-עצמית; הוא אינו הופך שופט LLM למבחן. c-CRAB לא בדק את המבקר שלנו, ואנחנו לא נרמוז אחרת. OrcaCode Review מריץ מעבר סקירה בתוספת שופט אימות בלתי תלוי, לפי טוקן ולא לפי מושב, וכל הנחיה בו היא ציבורית — כך שתוכלו לכוון אותו אל מדד כמו זה ולקבל מספר משלכם במקום שלנו.

השורה התחתונה

c-CRAB הוא benchmark לסקירת קוד שהניקוד שלו אפשר ברובו לסמוך שהוא אומר את מה שהוא אומר: סקירה עוברת רק אם יישומה מתקן את הקוד. המספרים הבולטים נמוכים באמת — הכלי הבודד הטוב ביותר 32.1%, האיחוד 41.5% — אבל הם מודדים חפיפה עם חששות שהעלו בני אדם, לא את איכות הסקירות, ונתוני השימושיות מראים שרוב ההערות הן אות אמיתי. המסקנות המתמשכות הן אלה שהמאמר עצמו טוען להן: נפח אינו כיסוי, סוכנים ובני אדם מסתכלים על דברים שונים, והפריסה הנכונה היא שיתוף פעולה בין אדם לסוכן. וה-benchmark פתוח, כך שהצעד הכנה הבא הוא להריץ עליו את המבקר שלך ולקבל מספר משלך.