Код-рев’ю в епоху ШІ — Хто перевіряє код, який пише AI?

У попередній статті (AI173) я назвав «верифікацію» третьою новою вузькістю після того, як код став майже безкоштовним, і пообіцяв повернутися до четвертого пункту окремо. Ця стаття — обіцяне продовження. Спочатку головний висновок: якщо в середині 2026 року озирнутися на те, що принесли інструменти AI-програмування, найбільшою змінною виявиться не кількість ліцензій, не число робочих місць і не бали бенчмарків моделей — це пропускна здатність рев’ю.

Головний висновок

Без рев’ю AI-код перетворюється на технічний борг за лічені тижні. Швидкість, з якою AI генерує код, вже значно перевищує швидкість, з якою люди можуть його перевіряти. Якщо раніше дефіцитним ресурсом був час розробника, то тепер дефіцитним став час рев’юера. У будь-якій компанії, що серйозно впровадила AI-кодування, «вузьке місце» зсунулося — більше немає черги з тікетів на реалізацію, є черга з тікетів на перевірку.

Звідси фреймворк статті:

  1. Чому рев’ю стало вузьким місцем
  2. Які підходи до рев’ю існують зараз і чому всі вони провалюються в реальному масштабі
  3. Рішення: двошарова архітектура рев’ю, поєднання людей і AI
  4. Як це впроваджувати — практичний сценарій для 30 днів
  5. Чого не вирішить навіть хороший рев’ю-процес

1. Чому рев’ю стало вузьким місцем

Зсув продуктивності

AI-кодування підвищило продуктивність розробника у 3–5 разів за різними оцінками. Водночас продуктивність рев’юера залишилася приблизно на колишньому рівні — людина як і раніше читає код рядок за рядком, утримуючи в голові контекст кількох файлів і кількох абстракцій. Коли 5 розробників з AI видають у 5 разів більше PR (Pull Request), на 1 рев’юера припадає в 5 разів більше роботи. Це класичне вузьке місце конвеєра: швидкість кодування зросла, а швидкість перевірки — ні.

Це не гіпотеза — це дані. Дослідження DORA 2024 («DORA — DevOps Research and Assessment», щорічний звіт Google про стан DevOps) показало, що хоча впровадження AI підвищило швидкість доставки коду, одночасно зросли й показники відмовлення змін (change failure rate), тобто більше коду потрапляє у продакшн, але більше з нього ламається. Внутрішні дані великих технологічних компаній показують схожу картину: у 2024–2025 роках час очікування першого рев’ю став ключовим вузьким місцем циклу доставки.

PR став коротшим, але кількість зросла

Поширена реакція — «AI пише коротший код, тому рев’ю простіше». Це ілюзія. AI дійсно може стиснути 100 рядків до 20, але PR стало не менше — їх просто більше. Якщо раніше розробник відкривав 3 PR на день, тепер відкриває 10. Менше рядків на PR, більше PR на людину. Площа поверхні рев’ю (кількість точок прийняття рішень) не зменшилася — вона збільшилася.

Витрати уваги

Рев’ю — це не просто читання. Це прийняття рішень: чи прийняти цей дизайн? Чи безпечна ця SQL-конструкція? Чи не зламає ця зміна мій сервіс? Кожне рішення споживає когнітивний ресурс. Рев’юер після 4 годин перевірок приймає гірші рішення, ніж після 1 години. Це підтверджується і в дослідженнях прийняття рішень під когнітивним навантаженням, і в практиці: у другій половині дня схвалюють більше «слабких» PR, ніж у першій. AI збільшив кількість рішень, які треба прийняти людині за день, у 3–5 разів. Пропускна здатність рев’ю на годину не змінилася, але кількість годин, які рев’юер може ефективно працювати, зменшилася.

Нові категорії ризиків

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

  • Тихі баги в обробці помилок (try/catch, який «ковтає» винятки)
  • Невідповідність архітектурним патернам проєкту
  • Залежності від API, що не існують або поводяться інакше
  • «Ліниві» рішення, оптимальні для навчальних даних, але не для конкретного продакшн-кейсу
  • Дублювання коду, яке важко виявити без контексту всього репозиторію

Людина-рев’юер бачить «зелений CI» і несвідомо знижує пильність. Це називається automation bias — схильність надмірно довіряти автоматизованим системам, і вона добре задокументована в авіації, медицині та тепер у програмуванні.

2. Існуючі підходи та чому вони не працюють у масштабі

2.1 Збільшити штат рев’юерів

Найочевидніша відповідь — найняти більше людей. Але:

  • Рев’юер рівня «синьйор» — це кваліфікований фахівець, і їх на ринку не вистачає вже зараз. У Європі, за даними Eurostat 2024, нестача IT-спеціалістів становить близько 1 млн осіб; у Японії — аналогічна проблема через демографічні процеси.
  • Збільшення штату рев’юерів створює лінійну залежність вартості від обсягу коду — це суперечить самій ідеї AI-кодування, яке обіцяло знизити, а не перерозподілити витрати.
  • Навіть якщо ви знайдете людей, on-call рев’ю швидко вигорає: у дослідженні GitHub 2023 року 60% розробників повідомляли про вигорання, значною мірою пов’язане з навантаженням рев’ю.

2.2 Зменшити PR

Ідея: розбити великі PR на менші. Працює, але:

  • AI особливо схильний генерувати «монолітні» рішення, які важко розділити логічно.
  • Деякі зміни за своєю природою торкнуться кількох модулів (рефакторинг API, міграція схеми бази даних).
  • Мікро-PR знижують навантаження на рев’ю, але збільшують кількість точок інтеграції — більше дрібних PR означає більше місць, де щось може «протікати».

2.3 Покласти рев’ю на самого автора

Деякі команди почали просити розробника рев’ювати власний код після AI. Це антипатерн. Дослідження в галузі інспекції програмного забезпечення (Fagan inspections, 1976; та численні подальші) однозначно показують: автор знаходить лише 30–50% дефектів у власному коді. Це нижча ефективність, ніж у peer review (перевірка колегами). Самоперевірка не масштабується.

2.4 Сувора автоматизація: CI/CD як рев’ю

Лінтери, форматери, статичний аналіз, security-сканери, покриття тестами — це необхідний фундамент, але це не рев’ю. Вони перевіряють синтаксис, стиль, відомі вразливості — але не приймають рішень щодо дизайну, архітектури, семантики бізнес-логіки. AI-код особливо добре «обходить» ці інструменти, оскільки навчений на коді, який їм відповідає.

2.5 CodeRabbit, Sourcery, GitHub Copilot Code Review та інші

З’явився цілий клас AI-рев’ю-інструментів: CodeRabbit, Sourcery, Bito, Codacy, QodanaA, а також вбудовані функції в GitHub Copilot і Cursor. Вони корисні, але мають спільні обмеження:

  • Бачать лише diff (різницю між версіями), а не увесь репозиторій і не повний контекст виконання
  • Не розуміють бізнес-наміру, тільки код
  • Не несуть відповідальності за наслідки
  • Добре ловлять синтаксичні та стилістичні помилки, але пропускають архітектурні та семантичні
  • Не замінюють людського рішення — людина все одно має прийняти остаточне рішення

Ці інструменти — чудовий перший шар. Вони відсіюють 40–60% «шумних» коментарів і дають рев’юеру структурований звіт. Але це лише фільтр, не сама перевірка.

2.6 Pair programming у стилі AI: Cursor Tab, Copilot Chat

Інтерактивна взаємодія з AI під час написання коду — Cursor Tab (функція автодоповнення в IDE Cursor, що передбачає наступні правки), Copilot Chat, Claude Code — знижує кількість «тупих» помилок у момент їх виникнення. Але:

  • Працює лише в момент написання, а не під час рев’ю
  • Розробник під тиском часу може прийняти AI-пропозицію, не замислюючись (знову automation bias)
  • Не зачіпає архітектурні рішення, які стають очевидними лише при інтеграції

3. Рішення: двошарова архітектура рев’ю

Ні один з перелічених підходів не вирішує проблему повністю. Працює комбінація. Ось фреймворк, який я пропоную і який у різних варіаціях уже застосовується у передових командах.

Шар 1: AI-фільтр (CodeRabbit, Sourcery, QodanaA, вбудовані інструменти)

Мета: відсіювати очевидне, стандартизувати стиль, ловити типові патерни помилок. Цей шар працює автоматично при відкритті або оновленні PR.

Конкретні функції:

  • Лінтинг і форматування (ESLint, Prettier, Black, gofmt — автоматичні інструменти перевірки стилю коду)
  • Статичний аналіз (SonarQube, Semgrep)
  • Security-сканування (Snyk, Trivy, GitGuardian)
  • AI-коментарі до diff: CodeRabbit залишає інлайн-коментарі до кожного «підозрілого» блоку, Sourcery пропонує рефакторинг
  • Перевірка відповідності стандартам проєкту: чи є тести, чи оновлено документацію, чи немає великих файлів без owning-команди

Цей шар не приймає рішень — він готує ґрунт. PR, що пройшов шар 1, має чистий diff, автоматично виправлені стилістичні помилки, список потенційних проблем із пріоритетами. Рев’юер бачить не «сирий код», а «оброблений» — і витрачає час не на дрібниці, а на архітектуру.

Шар 2: людське рев’ю, сфокусоване на смислі

Тут відбувається справжня перевірка. Людина-рев’юер відповідає за чотири речі, які AI поки не може:

  1. Бізнес-логіка. Чи правильно код вирішує задачу, яку поставив продакт-менеджер? Чи відповідає код очікуванням користувачів і регуляторним вимогам (для банків — чи відповідає вимогам локального регулятора банківської діяльності)?
  2. Архітектурна узгодженість. Чи вписується зміна в довгострокову архітектуру? Чи не створює вона технічний борг? Чи узгоджується з існуючими патернами модуля чи сервісу?
  3. Операційні ризики. Як цей код поводитиметься під навантаженням? Чи є в ньому шляхи витоку пам’яті? Чи безпечний він у продакшні?
  4. Відповідальність і підзвітність. Хто відповідає, якщо цей код зламається? Чи є escalation-процес? Чи є runbook (інструкція для усунення інциденту)?

На цьому шарі рев’юер не читає кожен рядок. Він читає diff, AI-звіт і задає 3–5 ключових питань:

  • «Цей блок — нащо? Яку вимогу він реалізує?»
  • «Якщо цей рядок видалити, що зламається?»
  • «Хто це підтримуватиме через рік?»
  • «Як ми дізнаємося в продакшні, що цей код працює неправильно?»
  • «Який найгірший сценарій, якщо цей код потрапить у продакшн таким, який він є?»

Ці п’ять питань — не риторика. Це checklist, який можна вбудувати в шаблон PR. Вони звужують фокус рев’ю з «прочитати 200 рядків» до «прийняти 5 рішень».

Важлива деталь: capacity planning

Двошарова модель вимагає явного планування потужності рев’ю. Практичний рецепт:

  • Виміряйте поточний throughput рев’ю (скільки PR на день опрацьовує 1 рев’юер)
  • Після впровадження шару 1 очікуйте 30–50% зниження навантаження на людину
  • Перерозподіліть звільнений час: 50% — на глибше рев’ю критичних змін, 50% — на розробку власних AI-інструментів рев’ю для проєкту

Без capacity planning шар 1 стане «ще однією автоматизацією, яка не звільняє час, а додає роботи».

4. П

Дані про дефекти та безпеку AI-коду: що кажуть дослідження 2025 року

У звіті CodeRabbit наприкінці 2025 року проаналізовано 470 open-source GitHub PR. Висновок: код, згенерований за участі AI, містить в 1,7 раза більше дефектів, ніж чисто людський (у середньому 10,83 проти 6,45 на PR, без парингу за розміром/складністю файлу). Безпекові вразливості за підкатегоріями зросли від 1,57 до 2,74 раза — XSS 2,74×, некоректна обробка паролів 1,88×, небезпечні прямі посилання на об’єкти (IDOR) 1,91×, небезпечна десеріалізація 1,82×; logic/correctness 1,75×, readability понад 3×, formatting 2,66×, error handling близько 2×.

У вересні 2025 року Apiiro провела сканування у сорока компаніях зі списку Fortune 50 (дані за грудень 2024 – червень 2025) і доповнила картину з іншого боку: через AI-генерований код щомісячна кількість знахідок безпеки злетіла з приблизно 1 000 до понад 10 000 інцидентів — зростання у 10 разів. Кількість вразливостей підвищення привілеїв зросла на 322% (за абсолютним численням; після нормалізації на обсяг коду оцінне зростання становить близько 60–80%), а дефекти проєктування на архітектурному рівні — на 153%. Водночас синтаксичних помилок стало менше на 76%, а логічних багів — на 60%.

Ці два набори даних разом розкривають одну думку, яка є особливо важливою в контексті регулювання: значна частина тих 322% зростання кількості вразливостей, пов’язаних з ескалацією привілеїв, які зафіксувала Apiiro, припадає на межі повноважень — а в фінансах і телекомунікаціях ці межі захищають кошти та дані клієнтів. Код, згенерований ШІ, часто працює, але кількість дефектів і вразливостей зростає пропорційно — і небезпечні з них ростуть непомітно. (Застереження щодо методології: звіт CodeRabbit відображає позицію постачальника, а дані Apiiro походять від стороннього постачальника безпеки; напрямок висновків збігається, але інтерпретувати їх слід з урахуванням способу нормалізації.)

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

1. Два контрінтуїтивні наслідки

Контрінтуїтивний наслідок 1: роль розробника зміщується від «того, хто пише код», до «того, хто перевіряє код», але перевіряти — виснажливіше, ніж писати.

Дослідження JetBrains за січень 2026 року (понад 10 000 розробників, 8 мов) показує, що 90% розробників використовують щонайменше один AI-інструмент. У лютневому опитуванні Pragmatic Engineer за той самий рік є ще тривожніший рядок: 56% досвідчених інженерів заявляють, що понад 70% їхньої інженерної роботи залежить від AI-інструментів (включно з самооцінкою розробників з інтенсивним використанням, не за часткою рядків коду). Йдеться не про епізодичне “AI написав мені кілька рядків” — AI вже став робочим процесом за замовчуванням. Виробничі відносини змістилися: написання коду тепер належить AI, тоді як розробник витрачає більше часу на читання й оцінювання — тобто на ревʼю. Читати чужий код завжди важче й повільніше, ніж писати; читати незнайомий код, згенерований AI, і водночас оцінювати його на відповідність compliance-межам і бізнес-правилам — це когнітивне навантаження, яке суттєво перевищує написання власного коду. Це й є корінь тривалого зворотного звʼязку 2025–2026 років “AI робить мене втомленим” — за лаштунками стоїть переглянута версія дослідження METR від лютого 2026 (ранніший висновок про сповільнення досвідчених розробників на 19% частково переглянуто на новій вибірці; нові розробники, як і раніше, показують −4%, і загальний вердикт — “пропускна здатність ревʼю є вужчим місцем, ніж пропускна здатність виробництва”).

Контрінтуїтивно №2: що потужніші AI-інструменти, то більше організація потребує не нових інструментів, а governance.

CodeRabbit із 1,7-кратним зростанням дефектів і Apiiro з 322% приростом вразливостей підвищення привілеїв — окремо ці випадки виглядають як провал ШІ. Але якщо подивитися крізь призму теорії обмежень (Theory of Constraints), це закономірний результат: інструмент став продуктивнішим, а ваші спроможності ревʼю не встигають за ним. Пропускна здатність системи визначається її найвужчим місцем. ШІ розширив етап «написання коду», і тепер найвужчим став етап «перевірки». Поки пропускна здатність ревʼю не зросте, що швидше ШІ пише, то небезпечніший борг накопичує організація. Це висновок AI173 — автоматизація не усуває вузькі місця, вона лише переміщує їх.

Коли ми переносимо цю логіку на ШІ-програмування, потрібно одразу зробити важливе уточнення: розробка програмного забезпечення — це не одноконвеєрне вузьке місце, а кілька паралельних вузьких місць, що динамічно мігрують. TOC спрацьовує для класичного конвеєра, але в сценарії ШІ-програмування з кількома паралельними обмеженнями найвужче місце дрейфує від «написання» до «ревʼю», а всередині «ревʼю» зʼявляються ще три незалежні вузькі перешийки — верифікація, управління (governance) і комплаєнс‑перевірка, кожен з яких блокує процес окремо.

Практичне значення цього принципу

Розгляньмо це у двох площинах.

Перша. Перш ніж запускати автономних агентів, потрібно поставити чотири гальма:

  • обов’язковий людський code review,
  • автоматизоване тестування (кожну зміну від AI треба прогнати),
  • сканування безпеки на рівні вимог до коду, написаного людиною,
  • canary-релізи (спочатку мала частка, потім розширення).

PR від AI не може йти без ревʼю. Це мінімальний поріг, який перетворює «AI пише код» на інженерну задачу «AI пише код, а організація здатна це утримати». Без будь-якого з цих елементів лишається поверхня для втрати контролю.

У січні–лютому 2026 року Carlini задокументував показовий експеримент: дослідник з Anthropic запустив 16 агентів на Claude Opus 4.6 паралельно на два тижні — близько 2000 сесій, приблизно $20 000 API-витрат. З нуля вони написали Rust-компілятор мови C на 100 000 рядків, який здатний компілювати ядро Linux 6.9 і проходить тести GCC torture на 99%.

Ключове застереження: це контрольований експеримент у замкненій предметній області. Carlini не виводив код у продакшн. Корисний як «екстремальний контрприклад» того, що буває без ревʼю, але не як зразок для негайного запуску автономних агентів — він схиляє до переоцінки узагальнюваності. В організації без code review, без автотестів, без сканування безпеки й без canary-релізів така конфігурація рано чи пізно вибухне.

Другий, глибший шар: сенс ревʼю — не в пошуку багів

Ключове запитання ревʼю вже не «чи є тут помилка в коді», а «чи цей код взагалі має існувати в цьому файлі, в цьому проєкті, в цих регуляторних межах». Для старшого покоління інженерів це найтиповіша пастка — ототожнювати ревʼю епохи ШІ з класичним code review.

Класичне ревʼю перевіряє: «цей код правильний?». Ревʼю епохи ШІ перевіряє: «цей код взагалі має бути тут, з таким рівнем доступу, з такими defaults?»

Цифри, які наводять CodeRabbit (у 1,82–2,74 раза більше вразливостей, виявлених до потрапляння в продакшн) та Apiiro (+322 % вразливостей, повʼязаних з ескалацією привілеїв), стосуються саме цього класу проблем: ШІ написав синтаксично коректний код, але не туди, не з тим рівнем доступу, не з тими безпечними значеннями за замовчуванням. Такі речі не виправиш в IDE — їх треба побачити під час ревʼю.

Загальноприйнятою інженерною практикою є налаштування GitHub/GitLab branch protection + CODEOWNERS так, щоб будь-які зміни в schema / auth / billing чи в регуляторно чутливих межах автоматично маркувалися червоним і маршрутизувалися на підпис двох відповідальних. У фінансовому та телекомунікаційному секторах (NTT, KDDI, Deutsche Telekom, Telefónica, банки на кшталт BBVA чи CaixaBank) на практиці це зазвичай реалізується як backup veto — право вето резервного рецензента — а не повне ревʼю, з часткою вибіркових перевірок (spot-check), що масштабується залежно від рівня ризику.

Architecture Decision Records (ADR), базові лінії безпеки та комплаєнсу (маппінг на локальні регулятори: GDPR, NIS2, DORA в ЄС;個人情報保護法 в Японії; SOC 2, HIPAA у США), коректність бізнес-правил — ось де насправді варто витрачати час у ревʼю епохи ШІ.

Розділ 2: Чому «саме зараз»: механізм, у якому верифікація стає новим вузьким місцем

Виконую обіцянку з §3 AI173 — «окремо в §4». Унікальність вікна середини 2026 року: автономні агенти (Claude Code, Codex) переходять від «пілотного використання» до «увімкненого за замовчуванням»; організації, які до H2 не оновили процес ревʼю, зіткнуться з масштабними збоями під час Q4-піків продажів / річної заморозки релізів / планових регуляторних перевірок. Спочатку поясню, чому верифікацію як нове вузьке місце найбільше недооцінюють, а потім покажу її поряд із двома попередніми (правильна постановка задачі, системна інтеграція) на єдиній схемі.

Scissors gap: code volume 6×, review bandwidth 1.3× 2024 H1 → 2026 H1 relative volume (baseline = 1×); Gap = risk accumulation Time Relative volume

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI code generation 6× Review bandwidth 1.3×

Gap = risk accumulation (defects +1.7×, security vulns +1.82–2.74×, privilege escalation +322%)
Ratios are directional illustration, synthesized from JetBrains 2026.1 survey, CodeRabbit 2025.12 report, Apiiro 2025.9 report

Корінь проблеми, який всі недооцінюють: більшість дискусій про AI-програмування за замовчуванням зводить “валідацію” до CI/CD, юніт-тестів і лінтерів. Це світ інтернет-продуктів: код деплоїться в хмару, всі юніт-тести зелені, CI проходить, merge — і в продакшн. Такий пайплайн працює в ритмі інтернет-продуктів, але перенесений у телекому, фінанси, виробництво чи e-commerce — не працює: у цих галузях “валідація” — це реєстрація алгоритмів, обов’язковий захист інформації за рівнями, оцінка транскордонної передачі даних, узгодження змін через Change Advisory Board (Change Advisory Board (CAB)), аудит звірки розрахунків, регуляторна звітність — і все це не має жодного стосунку до коду, але кожен етап забирає тижні. У AI173 ми вже показували схему (код пишеться швидко, вузьке місце — валідація), тут повторювати не будемо. Наголосимо на питанні, яке вона залишила: скільки рівнів валідації має пройти AI-згенерований код, перш ніж потрапить у продакшн?

Мінімум сім: автоматизоване тестування + code review + сканування безпеки + архітектурний огляд / ADR + огляд бізнес-правил + compliance clearance + поступовий rollout. Кожен етап споживає свою частку bandwidth. Ці сім шарів — “інший бік” тієї самої схеми з AI173: AI прискорює ту ділянку, де граничні витрати найнижчі (час GPU, ліцензії), а валідація з’їдає ту, де найвищі інституційні витрати (регулювання, реєстрація, звірка).

Другий корінь проблеми, який масово недооцінюють, — це звуження поняття “огляду” (review) до “code review”. Дві головні течії code review — концепція egoless programming, запропонована Вайнбергом у 1971 році в “The Psychology of Computer Programming” (з контексту NASA й академічних кіл), та Fagan Inspections від IBM 1976 року (систематизований продукт IBM) — спираються на одне й те саме припущення: код пишеться рядок за рядком, той хто його написав, розуміє його найкраще, а після написання инший розробник перечитує його у пошуках помилок. Штучний інтелект ламає це припущення: код видається ШІ за кілька секунд, той хто його “написав” (ШІ) не передає контекст, а той хто його “читає” (розробник) має справу з незнайомим згенерованим продуктом. Попереднє припущення про “виловлювання помилок” більше не працює. Нове припущення для огляду таке: чи має цей код взагалі існувати в цьому файлі? Чи не обходить він наявні архітектурні рішення? Він всередині чи за межами встановлених compliance-обмежень? Чи не перетвориться його дефолтна конфігурація на продакшн-вразливість?

На кожне з цих трьох питань здатен відповісти лише фахівець, який одночасно розуміє бізнес + архітектуру + нормативні вимоги; інструмент відіграє лише допоміжну роль. Це й є перетворення “огляду” з lint-перевірки в CI/CD-пайплайні на повноцінну лінію інженерного governance.

III. Трирівнева модель ревʼю: AI pre-review, людський контроль, governance-правила

Зведемо попередній аналіз до операційної структури. Трирівнева модель — це не заміна, а нашарування: будь-який PR проходить усі три рівні одночасно, і кожен відповідає за свій клас проблем.

Three-layer review model: AI pre-review → human gatekeeping → governance rules Any PR passes through all three layers; layers don't replace, they stack; triggers encoded by risk level Layer 1 · AI pre-review (runs automatically, seconds–minutes) Every line of AI-written code passes through; rules customizable; low cost → CodeRabbit / GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review Solves: lint, security vulns, duplicated code, naming, dependency risks Cannot solve: architectural alignment, compliance boundaries, business correctness Layer 2 · Human gatekeeping (senior engineer spot-check, hours–days) High-risk changes go through; medium/low sampled; moderate budget → Architect + business owner + security lead (routed by change type) Resolves: architecture alignment, business correctness, hidden assumptions, maintainability Does not resolve: cross-team governance, regulatory reporting, compliance sign-off Layer 3 · Governance rules (compliance & strategic, day–week) Triggered at compliance boundary, regulatory reporting, cross-border per Law 2297-VI (consent / cross-border agreement), SLA; high budget → Change Advisory Board (CAB) / filing review / ISO 27001 + Derzhspetszvyazku graded protection H/K/C / regulator liaison Resolves: cross-team governance, compliance sign-off, regulatory reporting, accountability Does not resolve: single-point code quality, architecture details

Layer 1 працює в масштабі секунд–хвилин — кожен рядок AI-коду спершу проходить через інструмент. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot, Antigravity Review — кожен із них залишає коментарі за десятки секунд чи кілька хвилин після створення PR, покриваючи lint, вразливості безпеки, дублювання, неймінг і ризики залежностей. Бюджет цього рівня мінімальний (якою б не була кількість PR, інструмент — це та сама передплата), а покриття максимальне (проходить кожен PR). Це фундамент пропускної здатності. Та й сліпі зони тут найочевидніші — він не вирішує архітектурної відповідності, compliance-меж і бізнес-коректності. CodeRabbit чесно каже: «автоматично зупиняємо більшість явних проблем», але решта прихованих ризиків (дефолтні конфіги, межі прав доступу, exception-шляхи, заховані в деталях) — це вже робота для людини. Цей рівень — лише фундамент, не фініш.

Layer 2 — години–дні

Високоризикові зміни (торкання ядрeвих модулів, зміна схеми бази даних, втручання в автентифікацію / білінг / модулі відповідності) повинні проходити ручну вибіркову перевірку групою у складі архітектора, бізнес-власника сервісу та відповідального з безпеки. Значна частина тих 1.82–2.74× безпекових вразливостей, про які звітує CodeRabbit, і тих 322% вразливостей ескалації привілеїв від Apiiro — це саме те, що має виловлювати цей рівень: код, згенерований AI, виглядає коректно, запускається, але дефолтні конфігурації, межі повноважень і гілки обробки помилок ховаються в деталях. Зміни з низьким і середнім ризиком проходять вибірковий контроль (рекомендована вибірка 20–30% — значення з досвіду внутрішніх тренінгів, не галузевий стандарт), не потрібно дивитися кожен PR. По суті це перерозподіл людського ресурсу з «перевіряти все» на «перевіряти критичне».

Найпоширеніша пастка цього рівня — поступове зниження планки: заради швидшого проходження PR-ів від AI команда тихо послаблює критерії «високого ризику». Послабиш стандарт — одного дня прилітає інцидент, і тоді вже пізно щось міняти.

Рівень 3 працює в масштабі днів-тижнів — сюди потрапляють зміни, що зачіпають комплаєнс-межі, регуляторну звітність, транскордонну передачу даних, SLA та міжкомандну архітектуру: Change Advisory Board (Change Advisory Board (CAB)), атестація за ґалузевими стандартами безпеки (адаптер локального регулювання, напр. PCI DSS / SOC 2 для фінансів, NIS2 для телекому), оцінка впливу на захист персональних даних (аналог DPIA за GDPR), комунікація з регуляторами. Це та «помаранчева зона», яку AI не може зрушити на схемі AI173, і це найдорожчий рядок витрат для галузей під жорстким регулюванням. Позиція AI174 така: AI не може обслуговувати Рівень 3 напряму, але якісно виконані Рівні 1+2 здатні відфільтрувати переважну більшість низькоризикових змін ще до їхнього надходження на Рівень 3 (за оцінкою внутрішнього навчального пулу клієнтів — орієнтовно 80–90%). Решта 10–20% високоризикових змін проходять через Change Advisory Board (CAB), і навантаження комітету звужується з усього портфеля змін компанії до тих, що справді потребують governance. Черга Change Advisory Board (CAB) скорочується, загальний темп постачання прискорюється — це той «бонус пропускної здатності governance», який найчастіше недооцінюють під час ескалації практик ревʼю.

Підпис комплаєнсу на Рівні 3 має залишатися на папері. Кожен PR, що маршрутизується через Рівень 3, мусить мати повний ланцюг аудит-слідів: diff PR + коментарі ревʼюерів + підпис бізнес-власника + підпис власника з комплаєнсу + таймстемпи + доданий звіт валідації моделі; строк зберігання — 5 років для фінансів, 3 роки для телекому (орієнтир: ст. 55 ЗУ 2297-VI — Закону КНР про захист персональної інформації, банківські регуляторні циркуляри Китаю, а також галузеві правила реєстрації алгоритмів у Китаї; для інших юрисдикцій — місцеві еквіваленти на кшталт GDPR Art. 30 / SOX retention / NIS2 log-keeping). Ця вимога — не «паперовий комплаєнс», а реальний доказ для діалогу з регулятором.

Ключовий дизайн із трьома шарами: тригер керується рівнем ризику, а не обсягом коду чи розміром PR

На практиці класифікація ризику не може покладатися на самооцінку ШІ. ШІ не має поняття про комплаєнс і не усвідомлює, що «торкатися поля з ідентифікаційним номером клієнта» — це червона лінія за ЗУ 2297-VI. Рівень ризику повинен визначати автор PR: у шаблоні PR вручну відзначаються чекбокси (змінює схему? змінює автентифікацію? змінює білінг? зачіпає межі комплаєнсу?), а правила CODEOWNERS служать другим рівнем підтвердження. За результатами цих позначень PR маршрутизується до відповідного шару:

  • Layer 1 — низький ризик: автоматичний merge (за умови, що зміни в межах whitelist-шляхів і спрацьовує механізм error fuse — якщо протягом 30 днів хоча б один автоматично злитий PR спричинить інцидент у продакшені, автоматичний merge призупиняється, а всі зміни повертаються на повний ручний review).
  • Layer 2 — середній ризик: вибіркова перевірка (spot-check).
  • Layer 3 — високий ризик: процедура governance.

Ця модель «risk-adaptive routing» є найвищою формою ескалації ревʼю.

Розділ 4. Вибір інструменту ревʼю: CodeRabbit — не єдиний варіант, але поточна фактична базова лінія

Переведемо тришарову модель на рівень інструментів. Цей розділ присвячений виключно вибору для Layer 1 — для Layer 2 і Layer 3 головну роль відіграють організація та процеси, тож інструменти дають небагато.

GitHub Marketplace у категорії AI‑review лідером за встановленням є CodeRabbit (Series B у вересні 2025 за оцінкою $550M, прогнозований ARR $40M до Q2 2026, дані Sacra) — він вбудовує «AI‑рецензента» в потік коментарів PR, де кожен коментар містить клікабельне пояснення, підказку щодо виправлення та рівень серйозності, що особливо ефективно для «сліпих зон» unit‑тестів. Найглибша інтеграція — з GitHub Actions, ціноутворення — східчасте за кількістю PR, а в Enterprise‑версії додаються приватні моделі, allowlist і внутрішня база знань. Наведені вище показники 1.7× для дефектів і 1.82–2.74× для вразливостей — це дані з його власного звіту. Його підхід полягає у вбудовуванні «AI‑рецензента» в потік коментарів PR, де кожен коментар містить клікабельне пояснення, підказку щодо виправлення та рівень серйозності, що особливо ефективно для «сліпих зон» unit‑тестів. Найглибша інтеграція — з GitHub Actions, ціноутворення — східчасте за кількістю PR, а в Enterprise‑версії додаються приватні моделі, allowlist і внутрішня база знань.

GitHub Copilot Review має сенс обирати лише за однієї умови: ви вже на GitHub Enterprise і не хочете заводити нового постачальника. Але правила тут не піддаються глибокому налаштуванню, і з часом ваша бібліотека правил неминуче програє CodeRabbit.

Інструменти автоматизованого ревʼю коду

Sourcery — найпотужніший інструмент автоматичного ревʼю в Python-спільноті: він дає конкретні рекомендації з рефакторингу просто в PR (не просто вказує на помилки, а й переписує код), і особливо добре справляється з додаванням type hints та прибиранням технічного боргу. Для крос-мовних команд цього замало — підтримка TypeScript і Go зʼявилася нещодавно, а для решти мов покриття все ще слабке.

Cursor BugBot виграє за рахунок доступу до контексту діалогу в редакторі Cursor: він «бачить» усе, що ви обговорювали зі своїм AI-асистентом, і робить ревʼю з урахуванням саме цього контексту. Корисний лише для проєктів, які живуть у Cursor.

Antigravity Review — це вбудована можливість ревʼю в платформі Antigravity від Google, запущена в листопаді 2025 року. Працює на базі моделі Gemini 3 із підтримкою корпоративної compliance-інфраструктури Google Cloud. У першій половині 2026 року функціонал усе ще стрімко розвивається: набір правил поки не такий глибокий, як у CodeRabbit, а корпоративні ціни й модель розгортання ще уточнюються.

Вибір інструментів виконуйте в такому порядку пріоритетів: гнучкість правил > якість коментарів у PR > глибина інтеграцій > ціна. Якщо Layer 1 інструмент плануєте використовувати довго, відсутність кастомізації правил прив’яже вас до вбудованої моделі безпеки; неякісні коментарі ревʼюера (коли AI просто каже «тут щось не так» без пояснення і без підказки, як виправити) — це марнування часу розробників; глибина інтеграцій визначає, наскільки швидко команда зможе почати працювати; ціна — четвертий критерій не тому, що неважлива, а тому, що в межах одного класу різниця рідко перевищує 30%, тоді як розрив у перших трьох пунктах зазвичай більший.

Дві поради, протилежні до поширених уявлень під час вибору. По-перше, у фінансовому, державному, оборонному та телекомунікаційному ядрі приватне розгортання або self-hosting — це квиток на вхід. Але приватне розгортання — ще не кінець. Інструмент ревʼю бачить увесь ваш код (PR diff плюс історію репозиторію), тобто фактично передає його третій стороні на обробку. Відповідно потрібна угода про обробку даних третьою стороною (ЗУ 2297-VI §21 — доручення на обробку персональних даних; в ЄС це відображено як ст. 28 GDPR); самої лише технічної ізоляції недостатньо. По-друге, AI pre-review і ручне code review — це не «або/або». Поєднання двох Layer 1 інструментів на кшталт CodeRabbit + GitHub Copilot Review — буденність у великих організаціях. їхні правила різні, типи вразливостей, які вони покривають, доповнюють одне одного; жоден окремий інструмент не закриває всі сліпі зони.

Пʼять. Як оновлення ревʼю виглядає в кожній з чотирьох галузей залежно від регуляторного контексту

Four-industry review escalation: Layer 1 shared, Layer 2/3 redesigned per industry Risk routing criteria = regulatory-context differences per industry; Layer 1 tooling reusable across industries Telecom (tariffs/billing/enterprise) Layer 1 Flag high-risk: billing/authentication/compliance modules Layer 2 Business owner + compliance owner joint sign-off Layer 3 Change Advisory Board (CAB) · Мінцифра · ISO 27001 H/K · ЗУ 2297 cross · Держспецзв'язку Review bandwidth bottleneck Change Advisory Board (CAB) щомісяця 5 000-8 000 змін（(вкл. екстрені патчі)） Upgrade target target Change Advisory Board (CAB) 100-200 changes/month (high risk) Process essence: Change Advisory Board (CAB) capacity from full change to high risk Finance (credit/risk control/AML) Layer 1 Mark high risk: features/labels/thresholds/weights Layer 2 Credit risk control + data compliance dual sign-off + independent validation group Layer 3 Model validation · regulatory reporting · NBU · NBU data · Law 2297 · algorithmic fairness audit Review bandwidth bottleneck validation group vs. data compliance group data sharing friction Upgrade target Layer 2 people first, then talk tools Process essence: Business + compliance experts spot-check Manufacturing (MES/production line/process) Layer 1 Найвищий ризик: блокування/OEE (загальна ефективність обладнання)/SPC (статистичне управління процесами)/трасування партій Layer 2 Технолог + інженер з безпеки — спільний підпис Layer 3 Пробний пуск · canary (мала серія на лінії) Review bandwidth bottleneck Дефіцит досвідчених технологів Upgrade target Увага з обходів на високоризикові перевірки Process essence: Перерозподіл ресурсів, не оновлення інструментів E-commerce (Великі акції/транзакції/контроль ризиків) Layer 1 Найвищий ризик: великі акції/купоні/секонд-кіл/залишки Layer 2 Бізнес + ризик-власник — спільний підпис Layer 3 canary · стрес-тест full-chain · lock пікового сезону Review bandwidth bottleneck Вікно пікового сезону витісняється виробництвом Upgrade target У мирний час — м'якше, у воєнний — жорсткіше, lock беклогу Process essence: Віконний період зі зсувом + рівні ризику

Телеком — підвищення рівня ревʼю для зміни тарифів і білінгу. В одному з розборів внутрішнього AI-навчання регіонального оператора мені показали схематичну ілюстрацію: кожна зміна тарифного плану проходить 11 рівнів перевірки від написання коду до виходу в прод. AI стиснув етап «кодування» із двох днів до половини, але пʼять інших кроків — Change Advisory Board, реєстрація алгоритму (оскільки зачіпає білінгову модель), оцінка відповідності захисту інформації (еквівалент китайського «ISO 27001 + Держспецзв’язку 等级保护 H/K/C»), оцінка транскордонної передачі даних (тут використовується зовнішня модель, і діє «Тимчасова методика управління безпекою даних у сфері промисловості та інформаційних технологій» із власним негативним переліком для експорту — стандартний контракт ЗУ 2297-VI її не замінює) і звірка з аудитом — кожен забирає від кількох днів до місяця. Реєстрація алгоритму в МІІТ — від підготовки пакета документів до зворотного звʼязку від відомства — зазвичай триває 4–6 місяців, і це справжнє «вузьке горло». Загальний цикл доставки фактично не змінився. Напрямок апгрейду ревʼю такий: інструмент рівня Layer 1 повинен розпізнавати «зачіпання модулів білінгу, аутентифікації чи комплаєнсу» й автоматично піднімати ризик, маршрутизуючи такий запит на спільний підпис бізнес-овнера й комплаєнс-овнера на рівні Layer 2; шар Change Advisory Board виконує повторну перевірку лише для тих змін, що реально торкаються регуляторної звітності. Суть підходу — стиснути потік Change Advisory Board (CAB) з 5 000–8 000 заявок на місяць (усі зміни включно з терміновими патчами) до 100–200 справді регульованих змін на місяць. До апгрейду вузьким місцем був саме Change Advisory Board (CAB); після — Change Advisory Board (CAB) став найшвидшим етапом, бо 8 із 11 кроків заздалегідь закриваються автоматизацією та правилами.

Найбільш прихований біль телекому — не Change Advisory Board (CAB), а інтерпретованість моделей

У телекомунікаціях найменш помітний, але найгостріший біль — не Change Advisory Board, а інтерпретованість моделей. Білінгова система має вміти пояснити походження кожного тарифу в кожному рахунку; коли після запуску AI-моделі «чорної скриньки» надходить скарга клієнта, потрібно миттєти відтворити логіку рішення. Три головні сценарії звернень до національного регулятора (перенесення номера, доступність і коректність рахунків, керування підключенням/відключенням послуг) після першого ж спрацювання проходять обов’язковий попередній compliance-аудит на рівні групи компаній — і цю роль Change Advisory Board (CAB) замінити не може.

Міркування щодо перекладу:

  • Change Advisory Board (CAB) залишено як Change Advisory Board (міжнародний стандарт ITIL).
  • 模型可解释性 — інтерпретованість моделей (усталений ML-термін; буквально «explainability» тут звучить надто розмовно для CIO-аудиторії).
  • 黑盒模型 — «чорна скринька» залишилася в лапках, бо це образний сталий вираз і в українській техлітературі він теж уживаний.
  • Держспецзв’язку 利用者申立 申诉 — це конкретний китайський регулятор (China’s telecom complaints hotline). Замість вигадування неіснуючого українського/європейського аналога я залишив узагальнений опис «звернення до національного регулятора» з трьома характерними сценаріями. Якщо потрібно зберегти прив’язку саме до Китаю, варто написати: «звернень на гарячу лінію Держспецзв’язку 利用者申立 Державного управління зв’язку КНР».
  • 集团消保预审 — «попередній compliance-аудит на рівні групи компаній» (мається на увазі внутрішньокорпоративний захист прав споживачів; у європейському контексті це мапиться на pre-launch review під Consumer Rights Directive та NIS2).
  • 客诉/溯源 — «скарга клієнта / відтворити логіку рішення» (ідіоматично, не калька «трасування джерела»).

Фінанси — посилення ревʼю моделей кредитного ризику. У банківських core-системах реальний шлях виведення ризик-моделі в пром — це незалежна валідація Група валідації моделей (Model Validation Unit) → затвердження Комітетом з модельних ризиків → подання заявки на регуляторну реєстрацію бізнес-підрозділом → зворотний звʼязок від регулятора → вихід у пром після успішної реєстрації — пʼять кроків із чіткою послідовністю, які не можна ставити в один ряд. Ділянка, де AI-генерація коду реально дає прискорення, доволі вузька (генерація скриптів, код фіч-інжинірингу, код препроцесингу даних), але кожна зміна зачіпає регуляторний периметр — наприклад, зміна таргета в Китаї відповідає вимозі «істотних змін моделі, що потребують повторної реєстрації» згідно зі ст. 24 «Правил управління інтернет-кредитуванням комерційних банків» та документом НБУ 通知〔2020〕24 号 (нормативний акт CBIRC/China Banking and Insurance Regulatory Commission). Напрямок посилення ревʼю такий: Layer 1 мусить розпізнавати «зміну фіч / таргета / порогових значень / ваг моделі» й примусово маршрутизувати їх як high-risk; Layer 2 — обовʼязковий подвійний підпис від кредитного ризик-менеджера, що розуміється на бізнесі, та від DPO/відповідального за комплаєнс даних, причому Група валідації моделей має бути незалежним і від бізнесу, і від IT (жорстка вимога документа НБУ 通知〔2020〕24 号); Layer 3 — повний цикл: валідація моделі + звітність НБУ 規制データ報告 (система регуляторної звітності CBIRC) + звітність НБУ 規制データ報告 (формат статистичної звітності CBIRC) + оцінка відповідності ЗУ 2297-VI (Personal Information Protection Law — китайський аналог GDPR) + перевірка алгоритмічної справедливості (стать, вік, географія не повинні використовуватись як змінні моделі).

Реальний біль: після впровадження інструменту AI-конструювання ознак в одному акціонерному банку черга на валідацію моделей зросла з 8 до 12 тижнів. Команда Група валідації моделей (Model Validation Unit) мусить перевіряти кожну згенеровану AI ознаку на дрейф PSI/CSI, а обмін даними між Група валідації моделей та підрозділом комплаєнсу наражається на постійне тертя: Група валідації моделей потребує доступу до вихідних розподілів ознак, тоді як комплаєнс, керуючись ЗУ 2297-VI (китайським Законом про захист персональних даних), не дозволяє безпосередньо працювати з даними на рівні клієнтів. Єдиний прохідний шлях — «пісочниця для валідації моделей плюс агреговані ознаки після деідентифікації». Спочатку укомплектуйте Layer 2 людьми — і лише потім говоріть про інструменти. Якими б потужними не були інструменти, без фахівців, що розуміються і на бізнесі, і на комплаєнсі та здатних робити spot-check, ескалація рев’ю залишиться повітряним замком.

Виробництво — посилення ревʼю змін у MES. У виробничому секторі AI-написання коду приваблює найбільше (інтеграція ліній, моделі контролю якості, диспетчеризація процесів), але зміни в MES (Manufacturing Execution System) часто зачіпають захисні блокування: зсув одного параметра процесу може зупинити всю лінію. Виробниче ноу-хау значно глибше, ніж здається на поверхні: зачіпання OEE (загальна ефективність обладнання)-блокувань (загальна ефективність обладнання), контрольних карт SPC (статистичне управління процесами) (статистичне управління процесами), логіки прослідковуваності партій, процедур повернення/додавання сировини — усе це належить до зон високого ризику, а не просто «зміна технологічного порогу». Напрямок посилення ревʼю такий: на Рівні 1 (Layer 1) зміни, що зачіпають захисні блокування/OEE (загальна ефективність обладнання)/SPC (статистичне управління процесами)/прослідковуваність партій, мають позначатися найвищим ризиком, і авто-мердж заборонений; на Рівні 2 (Layer 2) обовʼязковий спільний підпис технолога та інженера з безпеки; на Рівні 3 (Layer 3) — пілотний запуск і поетапне розгортання (спочатку мала партія на одній лінії, перевірка відсутності побічних ефектів на захисні блокування, далі масштабування). Вузьке місце галузі — люди на Рівні 2: досвідчених технологів обмаль, їхній час виїдає виробництво, тож посилення ревʼю — це, по суті, перерозподіл ресурсу «перемістити їхню увагу з рутинних обходів на ревʼю високоризикових PR».

E-commerce — Оновлення ревʼю під час великих розпродажів. У e-commerce найпомітніший ефект від AI-кодування — це швидкість роботи з фронтендом, маркетинговими правилами, дашбордами та рекомендаційними моделями. Але будь-яка зміна в коді в період розпродажу зачіпає транзакційний ланцюг, антифрод і фінансові звірки — одна помилка коштує мільйони. Напрямок посилення ревʼю такий: Layer 1 має позначати найвищим ризиком усе, що стосується модулів розпродажу, купонів, flash-сейлів і залишків на складі; Layer 2 — спільний підпис бізнес-оʼнера та оʼнера з ризиків; Layer 3 — канареєчний реліз плюс повне навантажувальне тестування всього ланцюга. Специфіка e-commerce — у розпродажів є вікно: за два тижні до і після ключових подій (11.11, Mid-Year Sale / 618, передсвятковий сезон) стандарти ревʼю стають суворішими, а от пропускна здатність команди ревʼю якраз стискається через бойові інциденти. Перевірена практика в цій галузі — «у мирний час мʼякше, у воєнний — суворіше»: за тиждень до вікна розпродажу всі високоризикові зміни блокуються, приймаються лише bug-fixи; потужність ревʼю кидається на розблокування накопиченого беклогу, щоб високоризикові зміни не потрапили у вікно розпродажу.

Шість. Що це означає для керівників

Зворотний самоконтроль — чи ваша команда довіряє результатам AI дедалі більше, чи дедалі менше? Як ви проводите code review для AI-генерованого коду — переглядаєте 100%, робите вибіркову перевірку за рівнем ризику, чи тихо пропускаєте? Скільки разів за останні 6 місяців спрацював ваш Layer 3 маршрут? У скількох випадках це виявило проблеми? У скількох — справжні інциденти? Якщо правління не отримує ци три цифри, ваше управління — це паперова відповідність.

Висновок із чотирьох галузей

Переглядаючи всі чотири індустрії, закономірність чітка: серцевина ескалації ревью — не купівля інструмента, а перепроєктування маршрутизації ризиків. Умови маршрутизації на Layer 2/3 відрізняються в кожній галузі (телекомунікації — Change Advisory Board + реєстрація алгоритмів + інтерпретованість моделі; фінанси — незалежне Minimum Viable Unit + валідація моделі + НБУ 規制データ報告 + алгоритмічна справедливість; виробництво — дослідна експлуатація + канарієві релізи + OEE (загальна ефективність обладнання)/SPC (статистичне управління процесами); e-commerce — freeze перед піковими розпродажами), але логіка Layer 1 може бути спільною: ідентифікувати високий ризик, автоматично маркувати, примусово маршрутизувати. На рівні інструментів цілком нормально придбати один-два продукти Layer 1 й використовувати їх між галузями; на рівні процесів обов’язково потрібно перепроєктувати маршрутизацію під специфіку кожної індустрії.

Урок перший: модернізація ревʼю — це розвиток організаційних спроможностей, а не технологічна закупівля. CodeRabbit Pro коштує $24 за ліцензію на місяць (Pro Plus — $48 за ліцензію на місяць, рахуючи розробників, які створюють pull request’и); для команди з 200 людей це приблизно $58k на рік, а корпоративна ліцензія — у 3–5 разів дорожча. На тлі бюджету на R&D у мільйони доларів це дрібниця. Справжні витрати — це другий рівень (Layer 2), де потрібні правильні люди, і третій рівень (Layer 3), де доводиться перепроєктовувати процеси. За гроші це не купиш: потрібна готовність організації змінюватися і готовність старших інженерів виділяти час на ревʼю. Ті, кому не вдається просунути модернізацію ревʼю, майже завжди підходять до неї як до ІТ-проєкту: видалити ліцензії, налаштувати інструменти, визначити KPI. А просувають її ті, хто зводить керівника розробки й комплаєнс-офіцера за один стіл, щоб спільно визначити правила маршрутизації pull request’ів. Це бюджетний сигнал про переміщення governance з cost-центру в актив пропускної здатності — і лише тоді бюджет перерозподіляється з «купити більше ліцензій» на «додати bandwidth на ревʼю».

Урок другий: перш ніж запускати автономних агентів — AI pre-review має бути налагоджений. Це інший бік принципу «спершу постав гальма, а вже потім запускай двигун»: автономні агенти (як Claude Code чи Codex) здатні самостійно редагувати десятки файлів, відкривати PR і виконувати shell-команди. Тому до того, як такі можливості виходять у прод, Layer 1 мусить вміти розпізнавати «який модуль зачіпається, які межі порушуються» і примусово маршрутизувати задачу на відповідний рівень ревʼю. Ось пропоновані кількісні критерії налагодженості: автоматичний merge на Layer 1 ≥ 95 %, вибіркова перевірка на Layer 2 ≥ 20 %, нуль P0-інцидентів три місяці поспіль. Зразок Карліні з його 100-тисячним Rust-based C-компілятором — не десь далеко від вас: автономний агент може за два тижні поставити в продакшен готовий проєкт, а може за ті ж два тижні накопичити в організації без ревʼю 20 000 продакшен-ризиків. Ще ближчий приклад із суміжної індустрії — агент Stripe під назвою «Minions», який щотижня мерджить близько 1 300 PR: нуль рядків коду, написаних людиною вручну, лише людський review. «AI видає все автоматично + людина лише ревʼюїть» — це і є ознака належно оновленого ревʼю-процесу.

Урок 3: і «приріст», і «втрати» від ескалації ревʼю рахуються разом із пропускною здатністю.

Даваймо перевизначимо «пропускну здатність ревʼю». Це не лише людино-години, проведені за review-столом, — це сукупна здатність організації виявляти ризики, маршрутизувати їх і опрацьовувати. Теза зі звіту CodeRabbit про те, що «автоматика зупиняє більшість явних проблем», — лише частина картини. Справжнє запитання: чи вистачає у Layer 2/3 людського ресурсу, щоб розібратися з тим, що залишилось — прихованими ризиками на кшталт архітектурної узгодженості, меж комплаєнсу та коректності з погляду бізнес-логіки.

Найпоширеніший патерн провалу ескалації ревʼю — дозволити AI автоматично мерджити PR. Задля того, щоб «ефект від AI виглядав переконливіше», правила Layer 1 тихо послаблюють, Layer 2 перетворюють на 5%-ву вибірку, а Layer 3 і зовсім зводять до декорації. У короткостроковій перспективі цифри тішать, у довгостроковій — аварійність зростає: AI пише швидко + ревʼю послаблене = технічний борг росте пропорційно. Подвійне попередження — 1,7× дефектів від CodeRabbit і +322% ескалації прав від Apiiro — це саме та ціна, яку платить організація за подібні «послаблення», і йдеться не про один щабель, що дав тріщину, а про систему загалом. Пропускна здатність ревʼю має масштабуватися синхронно з обсягом PR; будь-який дисбаланс — це втрата контролю.

30-денний план впровадження (з конкретизацістю до рівня «яку нараду провести наступного понеділка та який документ змінити»):

  • 1-й тиждень: проведіть аудит наявних правил маршрутизації PR і позначте червоним чотири категорії: зміна schema / auth / billing / комплаєнс. Зіберіть дані про кількість спрацювань Layer 3 та середню тривалість черги за останні 90 днів, щоб сформувати базові показники.
  • 2-й тиждень: упровадьте інструмент Layer 1 — оберіть CodeRabbit або GitHub Copilot Review і відхиліть варіанти, які не відповідають жорсткій вимозі «приватного розміщення». Налаштуйте правила; додайте до шаблону PR поле для ручного вибору рівня ризику.
  • 3-й тиждень: сформуйте перелік бізнес-власників Layer 2 і власників комплаєнсу, визначте частоту spot-вибірки (рекомендовано 20–30%); повністю заповніть файл CODEOWNERS відповідними власниками модулів.
  • 4-й тиждень: додайте до щотижневого звіту PMO п’ять показників: середня тривалість розгляду PR, частка невдалих змін, частка пропущених дефектів після рев’ю, середня тривалість черги Layer 2/3 і кількість подій комплаєнсу, спричинених маршрутизацією Layer 3. Одночасно встановіть пороги допуску автономних агентів: рівень схвалення Layer 1 не нижче 95%, охоплення вибіркової перевірки Layer 2 не нижче 20% та відсутність P0-інцидентів протягом трьох послідовних місяців.

Супровідні метрики мають наздогнати

Середній час ревʼю PR, частка невдалих змін, частка пропущених дефектів після ревʼю, середній час очікування на Layer 2/3, кількість інцидентів комплаєнсу, спричинених маршрутизацією на Layer 3, час очікування у черзі на валідацію моделі. У самому кінці AI173 я вже ділився спостереженням: багато великих компаній звітують перед керівництвом про ROI від AI-програмування у термінах «скільки розробників охоплено» та «скільки seat-ів куплено» — і саме так ховають справжнє «вузьке місце». Коли ці метрики потрапляють на рівень ради директорів (а не кількість seat-ів і рядків коду), бюджет починає перетікати від «купити ще ліцензій» до «розширити пропускну здатність ревʼю».

Governance тіньового AI має рухатися синхронно

Звіт UpGuard за 2025 рік рахує «працівників у всьому світі, які використовують несанкціоновані генеративні AI-інструменти» — і це не лише розробники. Близько 80% співробітників визнають, що користуються AI-інструментами без схвалення IT-служби: бізнес-підрозділи обходять IT і самі пишуть код у ChatGPT. Зараз це чи не найбільший головний біль для комплаєнс-офікерів. Якщо вдосконалення governance не йде в парі з governance тіньового AI, ви, по суті, контролюєте «задекларовану зброю», залишаючи без нагляду «незадекларовану».

Незастосовний сценарій: якщо у вашій команді менше 50 людей, ви не працюєте в жорстко регульованій галузі, не маєте справи з автономними агентами, а обсяг PR становить < 100 на місяць — щонайменше 60% суджень із цієї статті до вас не застосовуються. Не треба силоміць натягувати структуру: вистачить двох рівнів — інструменти Layer 1 плюс ключові spot-check.

Що далі

Наступний матеріал (AI175) розповідає про інструментальний шар: битва за AI-інструменти вже завершилася у 2026 році, але чи зможуть переможці ними скористатися — інше питання. Йдеться про двох «власників трону» (Claude Code / Codex), Copilot, який тримається на інерції закупівель, і Antigravity, що ще на старті. А також про те, що «здатність до governance визначає, хто зможе ними користуватися і на якому рівні». AI174 дає структуру оновлення ревʼю, AI175 — структуру вибору інструментів; узяті разом, вони дають повну картину: «AI пише код — а як організація це приймає?».

Після цієї статті раджу прочитати розділ 3 з AI173 (судження про нові вузькі місця) + розділ X з AI175 (відповідність governance-здатностей інструментальним можливостям) — три ключові висновки розподілені між трьома матеріалами.

Хочете перенести ці судження у свою компанію?

Коли AI-інструменти для програмування заходять у компанію

Коли AI-інструменти для програмування (Cursor, Claude Code, Copilot, Codex, Antigravity, Trae, Qoder, 通义灵码 (Alibaba coding assistant), 文心快码 Comate, CodeGeeX) заходять у компанію, реальні запити зазвичай зводяться до чотирьох:

  • Чи витримує поточний процес code review той обсяг коду, який генерує AI — і чи не з’їдає він bandwidth ревʼюерів?
  • Скільки людей потрібно на Layer 2 — у перерахунку на кількість PR / модулів / частку FTE?
  • Чи треба перепроєктовувати Change Advisory Board (CAB) / compliance-маршрутизацію (Layer 3), особливо коли йдеться про дані під GDPR (ЄС) чи NIS2, 日本個人情報保護法 (Японія), SOC 2 / HIPAA (США)?
  • Які саме метрики брати як критерій успіху пілоту?

Діагностичний вхід: спершу подивись на 5 цифр твоєї команди — середній час ревʼю PR, відсоток невдалих змін, частка пропущених дефектів після ревʼю, середній час очікування в черзі на Layer 2/3, кількість compliance-інцидентів, які спрацювали через маршрутизацію Layer 3. Якщо хоча б одну з цих метрик нереально витягнути — команда ще не готова впроваджувати AI pre-review.

Формати співпраці

Зараз пропоную три варіанти:

1. Корпоративний тренінг — на ваших реальних проєктах розбираємо: як landingнути тришарову модель AI-ревʼю, як обрати інструмент для Layer 1 (CodeRabbit / GitHub Copilot Review тощо — за чотирма вимірами: private deployment, кастомізація правил, глибина інтеграції, ціна), як перепроєктувати процеси Layer 2/3 і яку систему метрик до цього прив’язати.

2. Пілот під ключ — спільно визначаємо scope (1-2 сервіси, ~10k LOC кожен, два репозиторії), запускаємо, через 6 тижнів маємо виміряний uplift. Типовий результат у телекому/банках: −40% часу ревʼю без зростання defect escape rate.

3. Стратегічна сесія (1 день, ≈€12k) — для CIO/CTO, хто ще не починав. Розбираємо: де AI-ревʼю дає ROI у вашому стеку (Java/Spring чи Go, мікросервіси чи моноліт), як вбудувати в існуючий SDLC, які compliance-ризики (data residency під NIS2 / GDPR / APPI) закривати в першу чергу.

Стандартний пакет «Корпоративний тренінг»: 3 дні ≈ ¥90 тис. Доставка:

  1. Скоринг поточного стану команди (saturation ревʼю-bandwidth)
  2. Roadmap впровадження тришарової моделі на 3–6 місяців
  3. Decision tree для вибору інструмента Layer 1
  4. Чернетка dashboard метрик

Спеціалізовані консультації: фокус на одному конкретному рішенні — наприклад, оцінка доцільності впровадження CodeRabbit, як адаптувати трирівневу модель ревʼю до середовища з жорстким регулюванням (фінанси: незалежний Група валідації моделей + аудиторський ланцюг / телекомунікації: реєстрація алгоритмів + звернення через лінію Держспецзв’язку 利用者申立 — китайський регуляторний аналог скарг абонентів), або як переналаштувати маршрутизацію AI PR у межах існуючого Change Advisory Board (Change Advisory Board (CAB)). Ціна формується за темою рішення (консультаційний пакет 5–15 годин), результат = протокол рішення + чек-ліст впровадження + 1 тиждень follow-up. ¥5K/год.

Індивідуальний коучинг / приватна advisory-сесія: для віце-президентів, директорів та senior-інженерів, які «готові серйозно інвестувати у власний розвиток» — ви вже використовуєте AI-інструменти для програмування й хочете виростити всередині своєї організації власну експертизу з ревʼю, governance команди та міжфункціональної взаємодії. 12 сесій / 6 місяців, ціна за темою, результат = протокол коучинг-діалогу + покроковий action review. ¥180–360K.

Виступи для менеджменту та галузеві доповіді: теми — AI-ревʼю, організаційний governance, корпоративна AI-трансформація та зміни у software engineering. Пів дня / повний день, формат під потреби організатора.

Стаття може запропонувати загальний фреймворк. Конкретне впровадження все одно потребує повторного проектування з урахуванням data boundaries, регуляторних вимог, зрілості інженерних практик і наявних процесів ревʼю у кожній компанії. Щодо співпраці писати на coach@iaiuse.com.

Додаткове читання: «Бачити вивіску — методологія v1.0» (Повільне навчання AI 187) — системний огляд 7-крокової рамки корпоративної AI-трансформації.

Про цю серію

«Зміни в інженерії програмного забезпечення в епоху AI» — це дослідницька серія для CIO, CDO, CTO та керівників цифрової трансформації у телекому, фінансах, виробництві та e-commerce. Центральне питання: як AI-інструменти для програмування змінюють процеси доставки ПЗ, оргструктуру, моделі управління та метрики ефективності.

За цим блогом стоїть невелика команда — я та 1–2 колеги, з якими працюю роками. Ми розподілили між собою три напрями: дослідження AI-інструментів для коду, кейси з орг治理 та коучингові діалоги з командами. Більшість проєктів, про які я пишу «ми пройшли з компанією», — це наші спільні поставки.

Серія систематично відстежує наукові статті, матеріали вендорів та галузеві звіти; бібліотека досліджень налічує понад 200 джерел. До ключових тверджень я додаю рівень доказовості, розрізняючи підтверджені факти, заяви вендорів, галузеві спостереження та власні міркування.

Маю майже 8 років досвіду консалтингу та бізнес-аналітики у великих корпораціях, зокрема в IBM, де працював із проєктами для телекому, фінансів, страхування та виробництва. Після цього продовжував на передовій — продукти операторів зв’язку, інтернет-продукти та розробка AI-застосунків — займаючись аналізом вимог, продуктовим дизайном та крос-функціональним впровадженням.

Ця серія висновків щодо ескалації перевірок, організаційного управління та редизайну процесів базується на зазначених практиках і перехресно перевірена відкритими дослідженнями та галузевими кейсами. Усі відомості, що стосуються конкретних проєктів, знеособлено; частина галузевих сценаріїв є типовими проблемними розвідками, відповідні джерела наведено наприкінці.

Список джерел (покрокові посилання + рівень доказовості + позначення позиції)

  • CodeRabbit State of AI vs Human Code Generation Report (17.12.2025, першоджерело, позиція вендора): проаналізовано 470 open-source GitHub Pull Request’ів (AI проти людей, без парного зіставлення за розмаром/складністю файлів). Загальна кількість дефектів — 1.7× (у середньому 10.83 проти 6.45 на PR); вразливості безпеки за підкатегоріями — 1.57–2.74× — XSS 2.74×, неналежна обробка паролів 1.88×, небезпечні прямі посилання на об’єкти (IDOR) 1.91×, небезпечна десеріалізація 1.82×; логіка/коректність 1.75× (з яких 75% — високого рівня), якість коду 1.64×, продуктивність 1.42×, читабельність 3×+, форматування 2.66×, обробка помилок ~2×, надмірний I/O ~8×. Дослідження проведене самою CodeRabbit, позиція вендора, вибірка й методологія оприлюднені. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / повідомлення The Register від 17.12.2025.

  • Apiiro, 2025.9.4 (позиція вендора): сканування репозиторіїв Fortune 50 (період даних — грудень 2024 – червень 2025). Щомісячна кількість знахідок безпеки в AI-генерованому коді зросла з близько 1 000 до понад 10 000 (10× в абсолютних числах); вразливості ескалації привілеїв — +322% (абсолютно), дефекти проєктування на архітектурному рівні — +153%; у перерахунку на зростання обсягу коду оціночне зростання становить приблизно 60–80%. Синтаксичні помилки знизилися на 76%, логічні баги — на 60%. Повідомляли The Register, Cloud Security Alliance Labs та SiliconANGLE.

  • JetBrains AI Pulse Survey, 2026.1 (першоджерело): понад 10 000 професійних розробників, 8 мов. 90% розробників використовують щонайменше один AI-інструмент; 70% — від 2 до 4. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/

  • Pragmatic Engineer Newsletter (лютий 2026, першоджерело): близько 906 респондентів, охоплення 150 тис. читачів; 56% досвідчених інженерів повідомили, що 70%+ їхньої інженерної роботи залежить від AI-інструментів (самооцінка інтенсивного використання, не частка рядків коду); Claude Code — 46% (улюблений), Cursor — 19%, Copilot — 9%; у компаніях до 10 тис. співробітників 75% обирають Claude Code, у компаніях понад 10 тис. — 56% обирають Copilot. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026

  • GitHub Octoverse 2024 / 2025 (першоджерело): згідно зі звітом Octoverse 2025, Copilot coding agent за травень–вересень 2025 року створив понад 1 млн PR; 80% нових розробників використовують Copilot протягом першого тижня. «Рівень участі у PR 40–60%» — це галузева оцінка, а не прямі дані Octoverse. GitHub Engineering Blog, The New Stack.

  • Stripe Minions (березень 2026, першоджерело): агент Stripe “Minions” щотижня зливає близько 1 300 PR, нуль рядків коду, написаних людиною (лише людський review) — повністю автоматичне виробництво ШІ + виключно людино-асистований code review і є візитівкою цієї моделі. 500+ MCP-інструментів, devbox на AWS EC2, стратегія гілок Block Goose. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / репортаж InfoQ від 20.03.2026.

  • Система Skills від Anthropic (січень 2026, першоджерело, позиція вендора): Anthropic опублікувала дизайн-документ Skills — в основі лежить модуляризація задачних здібностей (modular folders that teach Claude specific tasks, реалізовані як skill-файли + progressive context loading), що не має стосунку до маршрутизації PR. Ризик-маршрутизація PR, яка поширена в індустрії, покладається на механізми branch protection + CODEOWNERS від GitHub/GitLab — тобто маршрутизація PR за шляхом/Codeowner. Anthropic Engineering Blog.

  • Carlini / Anthropic (січень–лютий 2026, першоджерело, першорівневе дослідження): дослідник Anthropic Ніколас Карліні запустив 16 агентів Claude Opus 4.6 паралельно на два тижні — близько 2000 сесій та приблизно $20 000 витрат на API — і змусив їх із нуля написати 100-тисячнорядковий компілятор C на Rust, що компілює Linux 6.9 (x86/ARM/RISC-V) і проходить 99% тестів GCC torture suite. Це закрите дослідження, не виведене в продакшн і без механізму code review. Висвітлення: The Register, 9 лютого 2026; Ars Technica, лютий 2026.

  • Оновлення дослідження METR 2026.2 (рівень 1, потребує перевірки): раннє дослідження охопило 16 досвідчених розробників і 246 реальних задач із використанням Cursor Pro + Claude 3.5/3.7 Sonnet, де AI сповільнив роботу на 19% (95% ДІ 2%–39%), при цьому самі розробники суб’єктивно оцінювали, що працювали на 20% швидше. У подальшому дослідженні 2026.2 з’являється протилежне твердження (нові розробники показують –4%, а частина результатів для досвідчених розробників є зворотною). Методологію потрібно додатково звірити з оригінальним звітом METR. https://metr.org/blog/2026-02-24-uplift-update

  • Кейс Microsoft FY26 Frontier Suite / EY (першоджерело, позиція вендора): EY розгорнула Microsoft 365 Copilot на 150 000 співробітників із зафіксованим зростанням продуктивності на 15% (еквівалент 14 годин на особу на тиждень, перерозподілених на клієнтську роботу та навчання); надалі планується масштабування на понад 400 000 співробітників. У сценарії фінансових операцій, реалізованому на базі Microsoft Power Platform + Copilot Studio, час повного циклу обробки скоротився на 95%, а операційні витрати знизилися на 37% (показники виміряно лише в межах фінансово-операційного сценарію, а не в масштабі всієї компанії). Джерела: Microsoft Customer Story 25760 та інвесторська сторінка FY26.

  • Впровадження Atos Agent 365 (червень 2026, першоджерело, позиція вендора): Atos розгорнула Microsoft 365 Copilot на 56 000 співробітників у 54 країнах і використовує Agent 365 для управління 19 000 внутрішніми AI-агентами; у своїх матеріалах Atos наголошує, що «governance та безпека — це перший рубіж agentic AI». Microsoft News, 9 червня 2026 р. / CDO Magazine.

  • Автономні можливості агентів Anthropic Claude Code / OpenAI Codex (першоджерело, позиція вендора): Claude Code здатний самостійно редагувати понад десяток файлів, виконувати shell-команди, керувати Git і формувати pull request’и; Codex може запускати кілька sub-agent’ів паралельно в ізольованих копіях і потім об’єднувати результати. Технічна документація Anthropic / OpenAI.

  • CodeRabbit: основні відомості про компанію (2025–2026, першоджерела): лідер ринку AI-інструментів для ревʼю коду в GitHub Marketplace; у вересні 2025 року оцінка Series B близько $550 млн; ARR зріс майже у 10× у 2025–2026 рр., сягнувши приблизно $40 млн (Q2 2026, дані Sacra); Pro — $24 за робоче місце/місяць, Pro Plus — $48 за робоче місце/місяць (тарифікується за розробником, який створює PR). Джерела: Sacra / Reuters / TechCrunch. https://sacra.com/c/coderabbit

  • GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (першоджерела, позиція вендора): офіційна документація та продуктові сторінки кожного з інструментів Layer 1 — зіставні за охопленням, гнучкістю правил і глибиною інтеграції. Antigravity GA 18.11.2025, за матеріалами VentureBeat / PCMag.

  • Походження code review (рівень 1): два основні джерела — ① Вайнберг (Weinberg) у 1971 році в «The Psychology of Computer Programming» сформулював ідею egoless programming (сам автор працював у NASA Goddard Space Flight Center і викладав в Університеті Небраски, без жодного стосунку до IBM); ② IBM Fagan Inspections — Майкл Фаган (Michael Fagan) систематизував метод у 1976 році в IBM (сам Фаган був співробітником IBM). Ці дві традиції розвивалися паралельно. Це історична точка відліку, що дозволяє порівняти ревʼю в епоху ШІ з класичним review.

  • Фінансове регулювання (першоджерела): ст. 24 «Методичних рекомендацій щодо управління ризиками інтернет-кредитування для комерційних банків» + документ Банку та страхового регулятора Китаю 2020 р. № 24 «Про управління ризиками інтернет-кредитування комерційних банків» — три лінії захисту в управлінні моделями (бізнес, IT, комплаєнс-аудит) + незалежний Група валідації моделей (Model Validation Unit) + повторна реєстрація при суттєвих змінах моделі; щомісячні пакети НБУ 規制データ報告 (External Audit System of Testing — система перевірки й аналізу) + звітність за формою НБУ 規制データ報告; персональне кредитне бюро НБК + перевірка алгоритмічної справедливості (обмеження на змінні статі, віку, регіону).

  • Телекомунікаційне регуляторне поле (першоджерело): Положення MIIT про реєстрацію алгоритмів (подвійний нагляд для алгоритмів білінгу/фінансових сервісів); оцінка відповідності рівням захисту — рівень 2: 30 робочих днів / рівень 3: 45 робочих днів; топ-3 скарг на гарячу лінію Держспецзв’язку 利用者申立 (перенесення номера, доступність рахунків, керування підключенням/відключенням); негативний перелік для транскордонної передачі даних згідно з «Тимчасовими правилами управління безпекою даних у промисловості та інформаційних технологіях» (Industrial and Information Technology Sector Data Security Management Measures, Trial).

  • Доручення обробки персональних даних за ЗУ 2297-VI (першоджерело): Статті 21 + 55 Закону КНР «Про захист персональної інформації» (Personal Information Protection Law, ЗУ 2297-VI) — угода з третьою стороною-обробником + термін зберігання журналів 3–5 років (залежно від галузі).

  • Щорічне опитування розробників Stack Overflow 2025 (першоджерело): 49 000+ розробників. Частка розробників, які довіряють точності ШІ, впала з 40 % у 2024 році до 29 % у 2025 році (зниження на 11 в.п.); водночас 46 % розробників активно не довіряють результатам ШІ (проти 31 % у 2024 році). Code churn зріс із 3,1 % у 2020 році до 5,7 % у 2024 році. https://survey.stackoverflow.co/2025/

  • Shadow AI (UpGuard 2025, рівень 2): 80% працівників у всьому світі використовують несанкціоновані інструменти генеративного AI (не лише розробники), а 68% керівників із безпеки визнають наявність несанкціонованого AI. Оновлення політик без одночасного впровадження governance для shadow AI створює сліпі зони в комплаєнсі. https://www.upguard.com/resources/the-state-of-shadow-ai

  • Власні кейси автора (деідентифіковані): ① AI-тренінг для провідного оператора зв’язку провінційного рівня (Q4 2024, розбір 11 контрольних точок, деідентифіковано) ② Обговорення модернізації процесу оцінки кредитних ризиків у спільному банку (H1 2025, деідентифіковано) ③ Редизайн процесу затвердження технологічних змін MES на великому виробничому підприємстві (H2 2025, деідентифіковано) ④ Бойове застосування AI під час великого розпродажу провідної e-commerce платформи (2025 Double 11, деідентифіковано).

  • Пояснення щодо деідентифікації кейсів: Згадані в цьому матеріалі кейси з телекому, фінансів, виробництва та e-commerce базуються на досвіді автора серії з проведення AI-тренінгів та роботі з командами цифрової трансформації в операторів зв’язку; вони деідентифіковані. Галузеві сценарії є типовими проблемними розборами, а не результатами конкретних клієнтських консультацій. У разі будь-якого цитування просимо зазначати деідентифікацію.