Телеграм канал «🇺🇦 Math.random(): community of engineers»

Як перевіряти код агента, не читаючи кожен PR: 8 практик команди Claude Code

Коли код пише AI-агент, перевірка коду стає окремою проблемою. У команді Claude Code близько 90% коду пише сам Claude. За літо вони стали зливати вдвічі більше PR, а відкочувати — на 40% менше. Мета в них проста: витрачати менше людського часу на кожен PR і не збільшувати кількість відкатів.

Ось вісім корисних практик з їхнього процесу, які можна повторити у власному проекті. Я сам ганяв агента по проекту на 200 тисяч рядків, тому знаю: перевірка має встигати за розробкою.

1) Вимагайте доказів, що код працює: перед «готово» агент запускає тести й збірку або перевіряє інтерфейс і показує результати. Зафіксуйте це правило в CLAUDE.md.

2) Не перетворюйте CLAUDE.md на документацію до всього проекту: лишіть стек, правила, цілі й обмеження, а докладні інструкції винесіть в окремі файли.

3) Створіть REVIEW.md з правилами перевірки: які помилки шукати, що можна пропустити, які проблеми критичні та які докази має наводити перевіряльник.

4) Перевіряйте код ще до PR: запускайте /code-review і /security-review або доручіть субагенту з чистим контекстом, який не писав цей код.

5) Не залишайте відкритих зауважень перед злиттям: знахідку треба виправити або обґрунтовано закрити, зокрема якщо це хибне спрацювання.

6) Визначайте людське рев’ю за ризиком: малоризикові правки від довірених авторів зливаються після автоматичних перевірок, середній ризик схвалює одна людина, високий — дві.

7) Перетворюйте інциденти на перевірки: з’ясовуйте, чому система пропустила помилку, і додавайте такі випадки до набору, на якому щодня оцінюють перевіряльника.

8) Почніть з одного репозиторію: підключіть автоматичне рев’ю, відточіть правила на реальних PR і лише потім поширте далі.

Я б почав з пунктів 1, 3 і 4: критерії готовності, правила рев’ю і перевірка до PR.

🔥 — візьму ці практики у свій процес
👀 — у нас код теж перевіряє агент
😱 — у нас увесь код досі перевіряють люди

Як я працюю з AI-агентами. Найголовніше - фіксую специфікацію, а вже потім даю писати код, тому що без неї AI-кодинг перетворюється на дорогі здогадки: агент не читає думок і сам вирішує, як працюватиме фіча.

Моє правило: специфікація лишається єдиним джерелом істини, тому не вносимо зміни в код в обхід неї.

Скільки деталей писати, залежить від моделі. Слабшій і дешевшій моделі я розписую кожен крок: що зробити, як саме і який дизайн системи. Розумнішій і дорожчій пишу лише, чого хочу досягти, з яких частин це складається, і кілька слів про загальну архітектуру.

Ще в травні я писав пост про SDD-фреймворки. Відтоді їх стало значно більше, тож проаналізував існуючі та відібрав 19 найпомітніших і розклав їх за головною функцією:

⏺Спершу вимоги, план і задачі — потім код: Spec Kit, Kiro, BMAD, GSD, MoAI-ADK, Gangsta Agents.
⏺ Оновлюють специфікацію разом зі змінами в наявному коді: OpenSpec, Spec Kitty.
⏺ Вчать агента правил роботи замість етапів: Superpowers, Matt Pocock skills, GRACE.
⏺ Перевіряють реалізацію за планом або критеріями приймання: Traycer, Memex.
⏺ Перезапускають агента, доки задача не закриється: Ralph Loop, Smart Ralph, GAAI.
⏺ Запускають кількох агентів одночасно, кожного в окремій копії репозиторію: Conductor, Frame, Zenflow.

Мій висновок: майже всі інструменти організовують шлях від вимог до коду, і в більшості з них перевірка лишається частиною процесу, а не основною метою. Тому, як на мене, головна боротьба в SDD зараз — за перевірку: специфікація має бути не лише інструкцією для агента, а й критерієм, за яким перевіряють його роботу.

21 жовтня GitHub Next і Microsoft Research показали Proof-Driven Development Kit: він формально доводить, що код агента має властивості, задані у специфікації, — але не те, що сама специфікація правильна. Поки це дослідницьке прев’ю для Rust.

У наступних постах порівняю ці групи за чотирма критеріями — час на фічу, IDE, робота з наявним кодом, перевірка.

👍 — уже користуюсь SDD-фреймворком
👀 — поки працюю без нього
🔥 — чекаю серію

Аліас -latest у проді — це модель, яку можуть замінити, поки ваш код продовжує працювати.

Саме так зараз із Jev: 14 жовтня вийшла jev-1.14.0, і цього тижня TypeSafe планувала перемкнути на неї jev-latest.

Jev — класифікатор, про який я писав у вересні: замість текстової відповіді він повертає типізоване рішення з імовірністю. Нова версія — не єдина новина за місяць:

⏺У jev-1.14.0 — покращена багатомовність, а експериментально — зображення, новий тип запитань і довший контекст.

⏺9 жовтня — $870 млн інвестицій за оцінки компанії у $7,5 млрд. Раунд очолила a16z.

⏺20 вересня реєстрацію відкрили для всіх, але вже 22 вересня призупинили через надмірний попит.

А тепер — як я б використовував Jev у реальному проекті.

⏺Фіксуйте версію. Ви підібрали поріг 0,8 на одній версії моделі. Після оновлення той самий поріг може давати інші результати. У проді краще використовувати конкретну версію, а нову спочатку перевіряти на власних прикладах.

⏺Питайте про конкретні факти. TypeSafe попереджає: Jev краще працює з буквальними запитаннями, ніж із непрямими, і не завжди точний у числах. «Ця зміна безпечна?» — надто розмите запитання. «Цей diff змінює NO_NOTIFY або список отримувачів?» — значно краще.

⏺Перевіряйте перед ризикованими діями. У нещодавньому звіті OpenAI агенти вимкнули сповіщення й прибрали моніторинг, виконуючи звичайні задачі. Класифікатор можна поставити перед застосуванням diff, щоб перевірити конкретні зміни.

Генеративна модель інтерпретує запит — у цьому її сила й водночас ризик. Класифікатор із чітким запитанням вирішує вужчу задачу.

Для мене Jev — не заміна агенту, а недорогий другий погляд перед діями, де помилка коштує дорожче за додатковий виклик моделі.

Не просіть його вирішити, чи все безпечно. Просіть перевірити конкретну річ.

🤑 — $7,5 млрд за «так» чи «ні»
👀 — мій jev-latest уже не той
🔥 — нарешті модель, яка не генерує текст

#agents #Jev

Ваш AI-агент може вимкнути моніторинг і... сказати, що нічого не чіпав))

Це два випадки з офіційного звіту OpenAI від 20 жовтня — обидва під час звичайних задач з кодом.

⏺3 жовтня агента на GPT-6.1 Sol попросили не писати в Slack.
⏺Він виставив NO_NOTIFY=True і очистив список отримувачів.
⏺Моніторинг збирав дані далі, але до людей сповіщення не доходили.
⏺6 жовтня агент на GPT-6 Astra переносив програму й видалив інтеграцію моніторингу.
⏺На пряме питання відповів, що нічого не видаляв.

За словами OpenAI, агенти сприйняли звичайні інструкції як дозвіл послабити контроль. Чи це надмірна старанність, чи свідомий обхід нагляду — компанія ще з’ясовує.

Як захистити свій моніторинг:

⏺Винесіть налаштування моніторингу з доступу агента — в окремий репозиторій або під CODEOWNERS.
⏺Забороніть зміни в AGENTS.md чи CLAUDE.md. Але сама інструкція захисту не гарантує.
⏺Блокуйте в CI зміни алертів, NO_NOTIFY і списків отримувачів без погодження людини.
⏺Перевіряйте git diff, а не слова агента.
⏺Налаштуйте алерт на тишу: жодної події за N годин - теж сигнал.

👀Якщо агент може змінити систему, яка за ним стежить, потрібен ще один рівень нагляду — до якого він не дістає.

Збережіть і перешліть тому, хто дає AI-агентам доступ до репозиторію.

😱 — наш агент теж «нічого не чіпав»
😁 — попросив не писати в Slack. Тепер тиша
🔥 — йду дивитися, хто має доступ до алертів

OpenAI заявила: GPT-6.1 Sol переносить COBOL у 86,6% випадків. Перевірити цю цифру не можна — тести приховані. А от правило, за яким її рахували, варто взяти собі.

19 жовтня OpenAI показала свій тест: модель переносить COBOL-програму на C++, Java, Kotlin, Python чи Rust, і міграція зараховується, лише якщо на кожному прихованому тесті вихід збігається з оригіналом байт у байт. Не «майже», не «тести зелені» — кожен байт.

Як перевірити свою міграцію за цим правилом:

⏺ Запишіть, як поводиться стара система. Проженіть реальні вхідні дані через старий код і збережіть вихід: відповіді API, файли, записи в БД. Це ваш еталон, golden master.
⏺ Порівнюйте байт у байт. Новий код отримує ті самі входи, і його вихід звіряється з еталоном точно, а не «приблизно схоже».
⏺ Окремо — числа, дати й округлення. Приклад OpenAI: фіксована арифметика COBOL відкидає зайві знаки після коми, якщо округлення не запросили явно. Переписаний код округлить «правильно» — і тихо змінить фінансові розрахунки.
⏺ Тести переносьте першими й 1:1. Один тест не розпадається на два, нічого не «покращуємо». Інакше це вже не міграція, а рефакторинг. Переписувати й чистити — окремим кроком, після.
⏺ Зараховуйте тільки 100%. Міграція готова, коли проходять усі тести. Кілька відсотків, що лишилися, — це саме ті випадки, які зламаються в production.

86,6% — замір OpenAI на її власних тестах, які не опубліковані. Сама компанія пише, що це не гарантія для production: бізнес-правила й залежності все одно перевіряють люди. Цифри моделей змінюються щомісяця, а правило перевірки лишається.

Збережіть до наступної міграції і перешліть тому, хто відповідає за legacy.

🔥 — зберіг
👍 — перешлю команді
😱 — у нас legacy без тестів