Кандидат, який щойно відправив задачу, має право знати, хто саме зараз читає його код. Ми пишемо це без маркетингового спіну — бо нам ця прозорість важлива більше, ніж вигляд.
Коротка відповідь
Вашу роботу оцінюють два агенти:
- Staff-інженер компанії-замовника. Він задав рубрику і формат задачі. Саму ж постановку ТЗ генерує і вичитує наш 4-агентний Bedrock-пайплайн (Scout → Composer → Calibrator → Verifier, усі ключові — на Claude Opus 4.7, найновішій моделі Bedrock-серії Opus) — перш ніж вона взагалі доходить до вас. Деталі — у статті "Як ми генеруємо задачі".
- LLM-суддя на базі Claude від Anthropic (теж Opus 4.7 на AWS Bedrock). Це AI-модель, яка читає ваш код і проставляє оцінки по кожному критерію рубрики.
У borderline-випадках до петлі підключається живий інженер merged (staff-рівень, з релевантним стеком), який робить second opinion.
Тобто Bedrock Claude Opus 4.7 у нас працює по обидва боки: один пайплайн перевіряє постановку задачі перед тим, як відправити її вам (там новий агент Verifier), інший — перевіряє виконання після того, як ви відкрили PR.
Що робить LLM-суддя
LLM-суддя — не одна магічна "оцінка від AI". Це pipeline з трьох етапів, який працює на Claude Opus 4.7 (найновіша модель Bedrock-серії Opus):
1. Нормалізація. Ваш diff (набір змін) приводиться до канонічної форми: однаковий вигляд імпортів, прибрані випадкові пробіли, зібрані метадані про коміти. Це прибирає варіативність, яка не повинна впливати на оцінку.
2. Паралельні per-criterion оцінки. Для кожного критерію рубрики (їх зазвичай 8–12) запускається окремий виклик моделі. Кожен виклик бачить тільки релевантну частину: оцінка тестів бачить тести і код, який вони покривають; оцінка комітів бачить git log, але не бачить коду; оцінка відповідей на ревʼю бачить тільки переписку.
Це зроблено, щоб одна сильна або слабка сторона не "заражала" іншу. Гарні коміти не перетягують слабкі тести, і навпаки.
3. Агрегація. Окремий виклик збирає всі per-criterion оцінки і не має права їх міняти — тільки підсумувати по вагах. Це архітектурне обмеження, а не прохання.
Які критерії дивляться
Повний список залежить від задачі. Але ось базове ядро, яке є майже завжди:
| Критерій | Що дивиться модель |
|---|---|
| Correctness | Чи проходять тести, чи вирішена заявлена задача |
| Test coverage | Чи додано тести, чи перевіряють поведінку, а не реалізацію |
| Diff focus | Чи сфокусовані зміни, чи не зачеплено зайвого |
| Commit quality | Атомарність, читабельність commit-повідомлень |
| Review response | Змістовність відповідей на автоматичні коментарі |
| Code idiomaticity | Чи пишете ви у стилі, типовому для цього стека |
| Invariants | Чи не порушено невидимих інваріантів у коді |
У кожному критерії модель зобовʼязана вказати не тільки оцінку, а й contrary evidence — аргументи проти її ж оцінки. Це технічне рішення, і воно важливе: ми встановили, що без цієї вимоги модель на 14 процентних пунктів частіше галюцинує впевнені, але неточні оцінки.
Чому можна довіряти LLM-судді
Ми запитуємо себе це самі. Відповідь — у вимірах, а не в обіцянках.
На калібрувальному сеті з 420 PR-ів, розмічених двома незалежними staff-інженерами, наш LLM-суддя дає 87% узгодженості з людським ревʼюером. Це не означає "87% правильності" — це означає, що в 87% випадків суддя ставить ту саму оцінку в межах тієї ж категорії (pass/borderline/fail), що і досвідчений інженер.
Для порівняння: узгодженість двох інженерів між собою на тому ж сеті — 91%. Тобто LLM-суддя відстає від людського консенсусу на ~4 процентні пункти.
Це не ідеально. Це достатньо, щоб ми використовували суддю як фільтр першого рівня, але недостатньо, щоб повністю викинути людину з петлі.
Де LLM-суддя помиляється
Ми відкриті про відомі регресії:
- Culture-bias. Модель трохи вище оцінює функціональний стиль (TypeScript з lodash) і трохи нижче — імперативний з явними for-циклами (часто в Go або системних мовах). Ми це калібруємо, але ефект залишковий.
- Verbose bias у commit-повідомленнях. Короткі точні повідомлення як
fix: handle UA VAT exemptчасом отримують нижчу оцінку, ніж багатослівні маркетингові абзаци. Ми це компенсуємо в вагах, але 100% не вилічили. - Refactor-blindness. Чисто рефакторингові PR-и (переіменування, витягання функцій) можуть отримати нижчу "diff focus" оцінку, бо змін багато за обʼємом. Для refactor-задач ми використовуємо окрему гілку рубрики.
Якщо ви відчуваєте, що один з цих biases вплинув на ваш результат — це прямий аргумент для апеляції.
Ваше право на апеляцію
Якщо ви отримали fail і вважаєте, що це некоректно, у вас є право на перегляд живою людиною. Це не формальна опція "пиши на info@" — це кнопка в тій же системі, де ви отримали результат.
Що відбувається:
- Ви описуєте своє незгоду (1–2 абзаци).
- Живий staff-інженер merged (не той, хто робив задачу, не LLM-суддя) протягом 5 робочих днів передивляється ваш PR.
- Ви отримуєте його письмовий висновок: підтверджено fail, переведено в borderline або перевизнано pass.
- Якщо змінено — компанії-замовнику автоматично йде оновлений статус.
Ми не колекціонуємо статистику, скільки апеляцій успішні. Бо не хочемо, щоб це перетворилось на KPI — ми хочемо, щоб кожна апеляція справді передивлялась чесно.
Що ми не оцінюємо
Також важливо, чого в рубриці немає:
- Часу виконання. Нам не важливо, 40 хвилин ви витратили чи 4 години.
- Кількості AI-асистента в дифі. Ми не намагаємось "ловити AI fingerprint". Ми оцінюємо результат.
- Вашого імені, статі, віку, місця проживання. Ми навіть не передаємо моделі ваше імʼя — PR-и нормалізуються до анонімної форми перед оцінкою.
- Ваших попередніх робіт або профілів. LLM-суддя не має доступу до GitHub, LinkedIn чи інших ваших артефактів. Тільки те, що ви здали.
Прозорість як принцип
Ми не створювали merged, щоб замінити людей на AI. Ми створювали, щоб зняти з інженерів монотонну роботу, за якою вони не бачать кандидата, і звільнити кандидата від 4-годинних марафонів live-coding, де ви не на пікові форми.
Ви маєте право знати, як це працює. Ми маємо обовʼязок це пояснити. Якщо у вас є питання, на які ця стаття не відповіла — [email protected]. Пишіть.