# ReviewBench: AI code review нарешті міряють як code review, а не як чат > GitHub випустив ReviewBench – відкритий бенчмарк для AI-рев’юерів на 219 реальних pull requests зі 187 репозиторіїв. Які метрики справді важливі команді і як провести власний eval свого AI-рев’юера. - Автор: Юра Скиба (https://cookiesoftware.io) - Опубліковано: 2026-10-15 - Категорія: AI в роботі розробника - Canonical: https://cookiesoftware.io/blog/reviewbench-ai-code-review --- GitHub 5 жовтня випустив ReviewBench – відкритий бенчмарк для AI code review на 219 реальних pull requests зі 187 open-source репозиторіїв у 19 мовах, із golden set-ом, зібраним із кількох незалежних джерел, і валідацією рубрики senior-інженерами (96.6% згоди). Сам факт появи такого бенчмарка важливіший за будь-якого конкретного переможця: категорію, яка досі продавалась через «вау, він знайшов баг», нарешті міряють precision-ом, recall-ом і ціною false positives. А головне – методику можна вкрасти для власного eval. ## Чому code review так важко оцінювати Якщо агент написав функцію, її можна прогнати тестом. Бінарно: працює або ні. А як оцінити review-коментар? Він може бути technically correct, але irrelevant. Важливий, але сформульований так, що автор PR його не зрозуміє. Може бути false positive, який з'їдає десять хвилин на «ні, це не баг». Може бути дублікатом того, що вже сказав інший рев'юер. Або style nit, замаскований під знахідку. Тому «кількість коментарів» – чи не найгірша метрика з можливих. AI-рев'юер, який лишає 25 коментарів, із яких 20 – шум, не економить час команди. Він створює нову категорію роботи: рев'ю рев'ю. ## Що саме зробив GitHub ReviewBench цікавий не цифрами лідерборда, а конструкцією: - **Дані**: 219 реальних PR зі 187 репозиторіїв, 19 мов програмування. Відбір калібрований на розподілах 103.9 мільйона реальних pull requests – корпус свідомо зважений у бік «reviewable middle and tail», а не крихітних однофайлових змін, на яких усі бенчмарки виглядають красиво. - **Golden set із кількох джерел**: коментарі реальних людських рев'юерів, проблеми, які автор сам виправив у наступних комітах після мержу (найчесніше джерело «пропущених» дефектів), детерміновані аналізатори і кілька frontier-моделей з різних сімейств. Далі – семантична дедуплікація і валідація за спільною рубрикою. - **Перевірка людьми**: senior-інженери незалежно розмітили golden true-positives до релізу – їхні судження зійшлися з бенчмарком у 96.6% випадків. - **Метрики, а не одне число**: precision/recall/F1 окремо для grounded-знахідок (проти фіксованого golden set) і augmented (нові знахідки, оцінені незалежно), плюс конфігурований Fβ – бо команди по-різному важать «пропустили критичний баг» проти «засипали шумом». Знахідки мають severity (Critical/Medium/Low) і категорії: Correctness, Security, Reliability, Maintainability, Testing. Усе це публічне: датасет, рубрика, judge-модель і self-serve runner для власних агентів живуть на review-bench.ai. За оглядами запуску, стартовий публічний лідерборд очолив Copilot code review у режимі Balanced із grounded F1 близько 40% – і одночасно незалежні лідерборди на тих самих даних уже показують інше ранжування. Це не суперечність, а нагадування: ранжування залежить від методики агрегації, тож дивись на методику, а не на перший рядок таблиці. ## Які метрики потрібні саме команді Якби я впроваджував AI-рев'юера в команді, дивився б у такому порядку: 1. **Recall критичних дефектів** – скільки справжніх Critical-проблем він ловить. Це причина, чому інструмент узагалі існує. 2. **False positives на PR** – скільки шуму доведеться розгрібати людям. Це причина, чому інструменти вимикають. 3. **Дублікати** – чи не повторює він те, що вже сказали люди або лінтер. 4. **Actionability** – чи можна за коментарем щось зробити, чи це «подумайте про перформанс». 5. **Збережений час рев'юерів** – фінальна метрика, заради якої все затівалось. Якщо вона не росте, решта не важить. Зверни увагу: це рівно та сама логіка, що й у [статті про evals AI-агентів](/blog/ai-agent-evals) – міряти треба task success у твоєму контексті, а не інтелект у вакуумі. ReviewBench фактично застосував цю методику до однієї вузької задачі й показав, як це робиться у виробничій якості. ## Як провести власний eval Чужий бенчмарк – стартова точка, не вирок. Твій стек, конвенції і больові точки відрізняються від медіани 187 репозиторіїв. План на пів дня: 1. Візьми 50 merged PR зі своєї історії за останні пів року. 2. Збери ground truth із трьох джерел: що реально знайшли людські рев'юери; баги, які проявились уже після мержу (git blame + баг-трекер); security/performance знахідки з пізніших аудитів. 3. Прожени AI-рев'юера на цих PR наосліп – без доступу до справжніх рев'ю. 4. Порівняй: скільки справжніх проблем знайшов (recall), скільки з його коментарів виявились шумом (precision), скільки з них ти як senior позначив би «варто виправити зараз». П'ятдесят PR – не 219, і твої цифри не будуть науковою публікацією. Але вони будуть про *твій* код, а це значно цінніше, ніж питати модель «чи добре ти рев'юїш?» – відповідь на це питання завжди «так». ## Де команди хиблять з AI-рев’ю - **Міряти задоволеність замість якості.** «Команді подобається» – важливо, але команда може любити рев'юера, який хвалить код і мовчить про проблеми. - **Один прогін – один висновок.** AI-рев'юери нестабільні між прогонами; міряй на кількох і дивись на розкид. - **Ігнорувати вартість false positive.** Один зайвий цикл «це не баг» на PR × 40 PR на тиждень = тихо з'їдений день команди. - **Вимкнути людське рев'ю після хороших цифр.** AI-рев'юер – це додатковий фільтр, а не заміна; [рев'ю з ментором чи колегою](/blog/code-review-z-mentorom) ловить класи проблем, яких у golden set-ах просто немає – бо вони про контекст, а не про код. ## Прожени власний міні-ReviewBench Міні-версія eval-у на один вечір: візьми 10 своїх старих PR, у яких точно були знайдені людьми проблеми. Прожени через будь-якого доступного AI-рев'юера. Порахуй дві цифри: скільки з відомих проблем він знайшов і скільки нових коментарів виявились шумом. Ці дві цифри скажуть про користь інструмента для тебе більше, ніж усі лідерборди разом. І ширша думка на завершення: поява ReviewBench – ще один крок дорослішання категорії, як [Decisions API після Jev](/blog/jev-ai-typesafe). Спочатку з'являється вражаюча демка, потім – бенчмарк, який чесно показує, де вона працює, а де ні. Другий етап завжди нудніший і завжди важливіший.