Цикл верифікації для ШІ вимірює, чи може ШІ-агент для кодування налаштувати проєкт, запустити його та верифікувати власну зміну без допомоги людини. Це серцевина автономної агентської роботи — агент, здатний перевіряти свою роботу, нарощує результат; нездатний — лише породжує правдоподібний текст — і саме тому ця метрика має найбільшу вагу в бейджі Готовність до ШІ.
- Категорія: Готовність до ШІ (40% у межах категорії)
- Вага в загальному індексі: 1.6%
- Ключ метрики:
ai_verify_loop
Як обчислюється значення
| Компонент | Вага | Підтвердження |
|---|---|---|
| Розгортання однією командою | 18 | Makefile, Taskfile, justfile, mise або noxfile дають повний бал; тулчейн, який сам визначає команду (Cargo.toml, go.mod, mix.exs, Maven, Gradle, .csproj), дає більшу її частину |
| Автоматизовані тести | 22 | набір тестів, який агент може запустити для самоперевірки (спільне з інженерними практиками) |
| Конфігурація лінтера / форматера | 11 | спільне з інженерним сигналом лінтера |
| Статична перевірка типів | 11 | статично типізована мова або конфігурація перевірки типів (mypy, pyright, tsconfig, py.typed) |
| Відтворюване середовище | 10 | devcontainer, Dockerfile, Nix або файл блокування залежностей |
| Підтверджена агентська практика | 10 | частка недавніх комітів, авторами або співавторами яких є агент для кодування; повний бал від 5% і вище |
| Автоматизований супровід | 8 | коміти бота оновлення залежностей, помічені у вибірці; конфігурація без жодного поміченого коміта дає часткові бали |
| OpenSSF Scorecard: Pinned-Dependencies | 10 | результат Scorecard 0–10, масштабований до 10 балів |
Pinned-Dependencies — це спільне підтвердження: воно додає до циклу верифікації агентів інформацію про відтворюваність ланцюга постачання, залишаючись повноцінним компонентом Безпеки. Компонент виключається, коли Scorecard недоступний або звітує n/a.
Свідчення, а не лише оснащення
Усі інші компоненти тут читають файли репозиторію: раннер задач існує, файл блокування існує. Кожен із них — це проксі для циклу, роботи якого ніхто не спостерігав.
Коміти, авторами яких є агент для кодування — або яким його зараховано в трейлері Co-authored-by, — це єдиний доступний запис про те, що цикл справді замкнувся. Зміну запропонували, верифікували та злили з агентом у циклі, і власна історія проєкту це засвідчує.
Pull request бота залежностей теж машинного авторства, і він мусить пройти ті самі перевірки: тести виконуються, перевірки минають, він зливається. Проєкт, який уже поглинає такий трафік, показав шлях, потрібний агентові, — і саме тому автоматизований супровід оцінюється поруч з агентською практикою, а не вкладається в неї: кожне з двох може бути присутнім без іншого.
Значення мають помічені коміти, а не конфігураційний файл. dependabot.yml може лежати в репозиторії з вимкненою інтеграцією, а Renovate часто налаштовують узагалі поза репозиторієм: два широко вживані проєкти проганяють його приблизно через третину своїх комітів, не маючи жодного розпізнаваного конфігураційного файлу. Зараховуються лише боти, які самі є авторами вмісту, — робот, що зливає чужу роботу, змін не пише.
Ті самі коміти рахуються проти репозиторію в активності розробки, де автоматика, яка витісняє людську роботу, є тривожним сигналом. Це навмисно. Дві метрики ставлять різні запитання: чи люди досі підтримують проєкт і чи можуть машини робити до нього внесок. Обидві відповіді можуть бути істинними водночас.
Це свідчить про впровадження, а не про автономність. Мейнтейнер, що працює з агентом інтерактивно, лишає той самий слід, що й запуск без нагляду, і публічні дані не дають їх розрізнити — тому компонент має помірну вагу і не стверджує нічого про те, яку частку роботи виконав агент. Виявлення до того ж розпізнає лише відомих йому агентів, тож проєкт із нерозпізнаним інструментом просто читається як такий, що не має свідчень, — ніколи як провальний.
Компонент виключається, а не оцінюється як нуль, коли вибірку комітів не було зібрано.
Чому тулчейн зараховується як розгортання
cargo test і go test ./... — це канонічні цикли верифікації своїх мов. Зараховувати лише раннери задач означало штрафувати ці екосистеми за кращі типові налаштування — добре ведені Rust-проєкти отримували нуль за цей компонент через відсутність Makefile. package.json і pyproject.toml навмисно не зараховуються: npm і Python не визначають універсальної команди тестування, а чи визначає її конкретний проєкт — це вміст файлів, якого ця метрика не читає.
Чому цей цикл вирішує корисність агента
Кожен компонент усуває один зі способів провалу автономної роботи:
- Розгортання — агент може перейти від клонування до запуску без археологічних розкопок.
- Тести — агент може довести, що зміна зробила саме те, що замислювалося.
- Лінтинг і типи — цілі класи помилок відловлюються механічно, ще до рецензування.
- Відтворюване середовище — «працює в пісочниці агента» означає, що працює й деінде.
Прикметно, що це та сама інфраструктура, яка слугує людям-контриб'юторам — метрика не винагороджує жодної агентської екзотики понад те, що дисциплінований проєкт уже має. Проєкт із сильною Інженерною якістю зазвичай і тут стартує сильно.
Як читати результат
- Сигнали підтверджують існування циклу, а не його швидкість чи покриття — правило чесності на основі наявності, чинне для всього бейджа.
- Високий цикл верифікації поруч із заготовкою контексту для агентів зазвичай означає добре зінженерений проєкт, який просто ще не написав настанов для агентів — найдешевше з можливих покращень.
Як покращити значення
- Додати Makefile (або justfile/Taskfile) з цілями
install,testтаlint. - Тримати автоматизований набір тестів, який запускається локально однією командою.
- Запровадити перевірку типів — зараховується навіть мінімальний mypy/tsconfig.
- Закомітити файл блокування, Dockerfile або devcontainer для відтворюваності середовища.
- Там, де агентів уже використовують, зберігати трейлер
Co-authored-by, який інструменти додають типово. Вирізаючи його, прибирають єдине публічне свідчення того, що цикл замикається на практиці.
Дивіться також: читабельність коду для ШІ · інженерні практики