Джерела даних у статті: CodeRabbit 2025.12 / New Relic 2026 report, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms announcement, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Кейси є узагальненням типових сценаріїв і не прив’язані до конкретних компаній.

Ваша найбільша помилка — не те, що ви не купили інструменти, а те, що ви не написали CLAUDE.md

Один ІТ-директор ПриватБанку поскаржився мені: інструменти зі штучним інтелектом купили, моделі розгорнули, людей навчили — а за перше півріччя 2026 року цикл поставки майже не зрушився з місця. Керівник команди, що відповідає за ядро системи, висловився ще прямолінійніше: «Код, який пише ШІ, можна використати, але щоразу доводиться переписувати його з нуля — він не розуміє наших банківських правил, не розуміє регуляторних вимог, не розуміє, як інтегруватися з тією 30-річною легасі-системою».

Проблема не в тому, що AI недостатньо потужний, — а в тому, що ви не записали правила. У грудні 2025 року CodeRabbit опублікував аналіз 470 відкритих pull request-ів, і ці цифри потім широко цитували: у PR, створених за участі AI, у середньому 10,83 проблеми, у суто ручних — 6,45. У 1,7 раза більше — тобто на 70% більше багів, ніж у ручній роботі. До 2026 року картина не змінилася: New Relic у своєму звіті 2026 State of AI Coding Report виявив, що 78% команд повідомляють про більше інцидентів після впровадження AI-коду, а 62% технічних лідерів визнають, що їхні команди «впевнено відправляють AI-код у прод без порядкового рев’ю» (офіційний звіт New Relic, 2026, оцінка 0,866, первинне джерело). Обидва набори даних говорять про одне й те саме: AI не бракує здібностей — йому бракує контексту.

Звернімося до реального болю того самого CIO. AI у трьох конкретних збоях фінансових ядр:

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

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

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

Повертаючись до інших цифр New Relic: 62% команд «впевнено публікують без рев’ю», а 78% повідомляють про більше інцидентів після випуску. Разом вони кажуть: проблема не в рівні дефектів AI-коду, а в тому, що ніхто не знає, які дефекти там є.

Типовий сценарій: один із банків впровадив AI-допомогу для розробки модуля контролю ризиків у ключовій системі. Протягом трьох місяців частка відхилень під час комплаєнс-перевірки помітно зросла. Основні проблеми — внутрішні правила щодо керування паролями, шифрування чутливих полів, логування для відповідності вимогам тощо. Ці правила були описані у внутрішній документації, але AI їх не бачив. Згодом команда записала ключові правила у файл CLAUDE.md — і частка відхилень суттєво знизилася.

Станом на серпень 2026 року будь-яку наративу про «прискорення AI-трансформації» варто розглядати крізь призму такого зіставлення:

| Табір | Прогрес (H1 2026) | Контрприклад (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot розгорнуто для 150 000 співробітників, економія 2,5 млн годин / 250 млн доларів; масштабування на 400 000 працівників по всьому світу | Водночас визнають, що прискорення на 95% і зниження операційних витрат у фінансах на 37% можливі лише за умови «спочатку стандартизація» |
| Atos | Розгортання в 54 країнах / для 56 000 співробітників; одночасно працюють 19 000 AI-агентів під єдиною площиною контролю для ідентичності, безпеки, комплаєнсу та керування | Жорстко дотримуються принципу «спочатку вивести на продакшн governance-можливості Agent 365, потім масштабуватися» |
| Сама Microsoft | Work Trend Index 2026: 82% керівників планують розширювати робочу силу за допомогою AI-агентів протягом 12–18 місяців | Водночас визнають, що «темпи організаційних змін відстають від індивідуального використання» — це ключове протиріччя в концепції Frontier Firm |

Джерело: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Ці два зіставлення показують одне: без стандартів масштабування означає помножити ризик на N. «Швидкість» EY/Atos/Microsoft — це не швидкість моделі, а те, що «організація спершу відповіла на питання, як використовувати AI». Саме це пояснює, чому Spec-Driven Development (SDD, розробка, керована специфікаціями) у першій половині 2026 року справді став мейнстримом — не тому, що інженери полюбляють документацію, а тому, що без написання специфікацій уже неможливо вижити в середовищі з 19 000 агентів.

Ця стаття пояснює три речі: 1) чому дефекти в AI-коді є щонайменше в 1,7 раза серйознішими, ніж у коді, написаному людиною; 2) як GitHub, AWS, OpenAI, Anthropic та Alibaba — п’ять платформ — у першій половині 2026 року прийшли до однієї парадигми: обмежувати поведінку AI за допомогою документації; 3) чому розробка, керована специфікаціями, — це організаційна спроможність, а не вибір інструменту, і які три етапи впровадження відбулися в першій половині 2026 року.

Довжина стовпчика = дефекти AI як кратність до людських; базова лінія 1.0× = рівень людини

Базова лінія 1.0×

Усього проблем

1.7×
AI 10.83 проти людина 6.45 / PR

Помилки логіки / коректності

1.75×

Якість коду / підтримуваність

1.64×

Знахідки безпеки (сумарно)

1.57×

Неправильна обробка паролів

1.88×

XSS-вразливості

2.74×
↑ Найвищий

AI-код без специфікаційних обмежень перевищує людський за кожним виміром
Фінанси/телекому = узгодження комплаєнсу, управління паролями, шифрування чутливих полів — AI пропускає все

I. Рівень дефектів AI — це не проблема моделі, а проблема контексту

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

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

Логіка/коректність +75%: помилки бізнес-логіки, помилки залежностей, помилки потоку керування, помилки конфігурації — такі проблеми не завжди спливають під час тестування, але призводять до інцидентів у продакшені.
Якість коду +64%: неузгодженість найменувань, нечітка структура, порушення патернів проєкту — це «категорія з найбільшою різницею». Досвідчений інженер бачить з першого погляду: «це не наш стиль написання».
Безпека +57% (XSS-клас найвищий — 2.74×): неналежна обробка паролів (1.88×), небезпечні посилання на об’єкти (1.91×), витік чутливої інформації, небезпечна десеріалізація (1.82×) — у фінансовій галузі це питання не «чи працює», а «чи можна це взагалі випускати».

Проблема не в тому, що AI недостатньо потужний. Проблема в тому, що він не бачить.

II. П’ять платформ у першій половині 2026 року: різні шляхи, спільний вектор — «керування через специфікації»

У липні 2025 року GitHub випустив Spec Kit. На початку 2026 року AWS Kiro, OpenAI Codex та Anthropic Claude Code — усі доповнили свої продукти відповідними функціями. У травні 2026 року Alibaba Qoder закріпив «Spec-Driven Workflow» у позиціонуванні продукту. До першої половини 2026 року всі п’ять платформ дійшли до спільної парадигми — використання документації для обмеження поведінки AI. Це не винахід однієї компанії, а колективна відповідь індустрії на «кризу якості AI-коду».

Розгляньмо найсвіжіші дії кожної платформи в першій половині 2026 року:

GitHub Spec Kit: еталонна реалізація з п’ятиетапним гейтом. Відкритий у вересні 2025 року, до першої половини 2026-го він став галузевим еталоном. 5 основних команд + 2 додаткові: /speckit.constitution (непорушні принципи), /speckit.specify (що робимо і чому), /speckit.plan (як змінюємо), /speckit.tasks (декомпозиція на задачі), /speckit.implement (виконання), плюс /clarify і /analyze. Ключова особливість — модельна незалежність: одні й ті ж файли spec/plan/tasks не прив’язані до конкретного виконавця, їх підхоплюють Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code. Це перетворює інструмент на «організаційний SDD-протокол», а не фірмовий продукт GitHub (оцінка vibecoding.app, червень 2026, 0.816 бала, вторинне джерело).

AWS Kiro: вбудовує специфікації прямо в IDE. Випущений у липні 2025 року, до першої половини 2026-го еволюціонував у повноцінну Agent IDE. Робочий процес складається з трьох етапів: вимоги → дизайн → завдання. Головна відмінність від Spec Kit — у «гачках»: spec-файли Kiro можуть запускати заздалегідь визначені дії агента, вбудовуючи кроки, що потребують зовнішніх систем (комплаєнс, аудит, деплой), прямо у робочий процес. Якщо хочете змусити команду писати специфікації — обирайте Kiro, бо без spec-файлу Kiro просто не запуститься (AWS Kiro official 2025.7; Kiro.dev docs 2026).

OpenAI Codex: AGENTS.md + компоновані Skills. У 2025–2026 роках AGENTS.md перетворився на центральний елемент екосистеми. Skills — ключове розширення першої половини 2026 року: рутинні операції на кшталт «прочитати Excel-файл», «згенерувати SQL» чи «провести міграцію даних» тепер збираються як конструктор Lego — готові блоки, які можна викликати за потреби. До червня 2026 року тижнева активність Codex перевищила 5 мільйонів користувачів, і 20% з них — не розробники. Цей сигнал часто ігнорують, а даремно: специфікації та інструкції для агентів більше не є справою лише інженерних команд. Їх пишуть усі — продакт-менеджери, операційники, фахівці з ризик-менеджменту (анонс OpenAI від 2 червня 2026 року; огляд thebcms.com, 2026, оцінка 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic називає проектні інструкційні документи CLAUDE.md (у лютому 2026 року вони вийшли на офіційний ринок), .claude/rules/ (правила, розподілені за каталогами) та Skills (спільні робочі процеси). Claude Code — інструмент із найвищим рівнем задоволеності розробників у першій половині 2026 року — згідно з опитуванням JetBrains 2026.1, показник CSAT становить 91%, NPS — 54, і це підтверджують два незалежні дослідження (Pragmatic Engineer, лютий 2026). Це найвищий бал у галузі AI-інструментів для програмування на сьогодні (uvik.net, травень 2026, оцінка 0,956, зведення первинних джерел). За 9 місяців Claude Code зріс із нуля до $2,5 млрд річного регулярного доходу (дані раунду G від Anthropic, лютий 2026), а на GitHub репозиторій Skills зібрав 112 тисяч зірок — розробники голосують своїми діями, і це свідчить про реальну цінність підходу, керованого правилами.

Alibaba Qoder: нормативний драйвер китайського ринку. Випущений у серпні 2025 року, 15 травня 2026 року оновлений до версії 1.0, офіційно перейшовши з «AI IDE» на «Autonomous Agent Development Workbench». Його Spec-Driven Workflow був представлений разом із Quest Mode (автономні багатофайлові завдання), Expert Mode (паралельна робота команди експертів) та RepoWiki (граф знань репозиторію). 28 травня 2026 року запущено Cloud Agents (повністю кероване середовище виконання агентів), 21 липня — Qoder Security (можливості комплаєнсу та безпеки), того ж місяця вийшла мобільна версія (Android/iOS/HarmonyOS). Станом на травень 2026 року кількість користувачів у світі перевищила 5 мільйонів, а інтеграція з Microsoft Teams CLI включила його до переліку підтримуваних середовищ виконання агентів (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Спільний підхід: прямо задокументувати “як ми співпрацюємо з AI”, покласти цей документ у репозиторій і змусити всіх людей та всі AI-агенти працювати за одним і тим же стандартом. Деталі реалізації в п’ятьох платформах різняться (назви файлів / кількість етапів / механізми хук-ів), але мета абсолютно однакова.

Чому це стало масовим явищем саме в першій половині 2026 року? Тому що поріг можливостей AI вже пройдено — автономні агенти Claude Code, багатоагентний паралелізм Codex, багатофайловий рефакторинг Cursor: AI більше не “інструмент автодоповнення”, а “колега”. Документація, яку ви даєте новому колезі, має бути доступна й для AI.

III. Специфікація як рушій — це організаційна спроможність, а не вибір інструменту

Це найважливіший пункт для осіб, що ухвалюють рішення. Специфікація як рушій — це не вибір інструменту, а визначення того, “як наша організація співпрацює з AI”. Чи оберете ви GitHub Spec Kit, чи Claude Code — неважливо. Важливо, чи задокументували ви специфікацію, поклали її в репозиторій і змусили всіх людей та AI працювати за нею.

Без цього навіть найкращий інструмент лише дозволить команді швидше накопичувати борг.

Розгляньмо це в контексті масштабного впровадження у першій половині 2026 року — докази тут набагато переконливіші. У своєму ретроспективному звіті за FY26 (липень 2026) Microsoft описує кейси EY та Atos як еталонний шаблон «Frontier Firm» — не тому, що моделі нові, а тому, що обидві компанії першими дали відповідь на питання «як саме використовувати AI»:

EY: спочатку стандарти, потім масштабування. Протягом 2024–2025 років EY розгорнула Microsoft 365 Copilot для 150 000 співробітників, заощадивши 2,5 мільйона годин і близько 250 мільйонів доларів. Ключова умова — спершу створили структуру AI-управління: EY побудувала єдиний технологічний стек на базі Power Platform, Copilot Studio, Azure, Foundry та Fabric, об’єднавши нормативні вимоги, комплаєнс і аудит в одному фундаменті. Саме це дало змогу досягти 95% прискорення процесів, 37% зниження операційних витрат у фінансах і скорочення до 90% ручної роботи. Віцепрезидент EY на AI Tour 2026 висловився прямо: «Ми не спочатку впроваджували AI, а потім наздоганяли управління — ми спочатку побудували управління, а вже потім масштабували AI».

Atos: єдина площина керування для 19 000 агентів. Atos — одна з перших організацій у світі, що розгорнула Microsoft 365 E7 (Frontier Suite), охопивши Copilot для 56 000 співробітників у 54 країнах. Водночас у них працює 19 000 AI-агентів — від внутрішнього ІТ і бізнес-підрозділів до клієнтських проєктів, усі створені на базі Foundry та Copilot Studio. Ключ до успіху Atos — «єдина площина керування»: Entra (ідентифікація) + Defender (безпека) + Intune (пристрої) + Purview (відповідність) + Agent 365 (керування агентами), усі п’ять компонентів пов’язані в одне ціле. Такий підхід у фінансовому секторі відповідає концепції «багаторівневого захисту + оцінки трансферу даних + реєстрації алгоритмів + аудиту + керування моделями» — це архітектура керування, а не просто набір AI-інструментів.

Парадокс організаційних змін у Microsoft. У звіті Work Trend Index 2026 сама Microsoft визнає: “організаційні зміни відстають від індивідуального впровадження”. Серед 20 000 опитаних користувачів AI 82% керівників планують протягом 12–18 місяців розширити робочу силу за допомогою AI-агентів, але лише 24% уже завершили впровадження на корпоративному рівні. 81% керівників очікують, що AI-агенти будуть помірно або значною мірою інтегровані в AI-стратегію — і знову ж таки, лише 24% цього досягли. Це означає, що більшість компаній перебувають на відстані 12–18 місяців між “підготовкою” і “результатом”. І саме нормативне регулювання стане ключовою опорою в тому, як подолати цей розрив.

Джерела: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 05.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, первинне джерело у PDF); аналіз Futurum Group, 26.01.2026 (вторинне джерело).

Висновок перший: інвестиції в специфікації — це найвищий ROI.

Дані CodeRabbit дають чітку основу для розрахунку ROI: AI-код має приблизно в 1,7 раза більше проблем і в 2,74 раза більше вразливостей безпеки. Це означає:

менше повернень на доопрацювання (у фінансовій сфері один цикл комплаєнс-повернення — це 2–4 тижні);
менше інцидентів безпеки (один витік даних тягне регуляторні штрафи та репутаційні втрати);
нижчі витрати на підтримку (скорочення технічного боргу на 40% — типове число).

Написати проєктну специфікацію CLAUDE.md/AGENTS.md — це інженерна дія з найвищим ROI в епоху AI. Кейс EY дає реальне переведення в гроші: 150 000 співробітників з Copilot, економія 250 млн доларів. Зверніть увагу: EY заощадила не тому, що «інструмент був потужний», а тому, що «специфікація дозволила розкрити цінність інструменту».

Висновок другий: закріпіть специфікації в організаційних процесах, а не в головах окремих людей.

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

документації репозиторію (AGENTS.md / CLAUDE.md / constitution.md);
CI-гейтах (автоматична перевірка дотримання специфікацій);
спільних конфігураціях команди (система Skills дозволяє використовувати їх усій команді).

Зробіть специфікації організаційним активом, а не особистою навичкою. Це особливо важливо у фінансовій сфері — ваші вимоги до комплаєнсу, правила безпеки та бізнес-процедури є активами рівня організації, а не «досвідом» окремого інженера. 19 000 агентів Atos працюють у 54 країнах саме тому, що управління тут — це не «хтось знає, як треба», а «система примушує».

Висновок третій: гейтинг важливіший за швидкість.

П’ятиетапний гейтинг GitHub Spec Kit (constitution → specify → plan → tasks → implement), правило Claude Code «не писати код, поки тести не падають», вимога Kiro «не можна стартувати без spec» — усе це робить одну й ту саму річ: додає «гальма» між AI та кінцевим результатом. Кожен крок має перевірний артефакт (spec.md, plan.md, tasks.md), який можна відхилити або змінити ще до генерації коду.

Що автономніший AI, то більше він потребує гейтингу. Change Advisory Board (CAB) у фінансовій галузі, процедури реєстрації алгоритмів, оцінка відповідності вимогам захисту інформації (аналог європейського NIS2) — усе це, по суті, гейтинг перед запуском у продакшн. Для AI-коду потрібен аналогічний гейтинг, просто в іншій формі. Ті 62% команд зі звіту New Relic 2026, які «впевнено публікують без рев’ю», зараз розплачуються за цю самовпевненість вищим рівнем інцидентів (78%).

Фаза 1 займає найбільше часу, але має найвищий ROI
Правила більшості фінансових організацій розкидані по документах/листах/головах; перше прибирання потребує 3–8 тижнів зусиль

IV. Реальне впровадження трьох етапів у першій половині 2026 року

На прикладі фінансової галузі — три етапи шляху; інші галузі з жорстким регулюванням можуть використовувати його як орієнтир. Кейси EY та Atos у першій половині 2026 року точно відповідають цим трьом етапам.

Перший етап: інвентаризація правил (2–4 тижні).

Це найбільш тривалий, але з найвищим ROI етап. Зібрати розкидані правила:

Комплаєнс-вимоги: для фінансової сфери мінімальний базис = ISO 27001 + Держспецзв’язку рівні H/K/C + оцінка транскордонної передачі даних + реєстрація алгоритму (якщо хоча б один з цих компонентів відсутній, краще не починати розгортати AI); крім того — правила подання звітності регулятору, захист клієнтських даних, обмеження транскордонної передачі, перелік даних, які можна показувати AI.
Правила безпеки: керування паролями, стандарти шифрування, обробка чутливих полів, вимоги до журналів.
Бізнес-правила: пороги ризик-менеджменту, умови врегулювання, торгові обмеження, логіка білінгу.
Технічні обмеження: інтерфейси старих систем, найменування баз даних, обмеження версій фреймворків.
Управління постачальниками: як вимагати від постачальників дотримання наших стандартів у контракті, як аудитувати їхнє використання AI.

Типовий сценарій: на етапі інвентаризації одна брокерська компанія виявила, що правила розкидані по численних Word-документах, вікі в JIRA, особистих листах і Excel-таблицях — лише після впорядкування вдалося отримати структурований перелік правил. Підхід Atos більш системний — вони одразу розділили правила на п’ять категорій: «комплаєнс, безпека, бізнес, технології, постачальники». Для кожної категорії створили окремий робочий процес управління, який підключили до єдиної площини керування Agent 365.

Це не технічне завдання, а організаційне — потрібно зібрати за одним столом комплаєнс, безпеку та бізнес-підрозділи й зафіксувати правила, з якими всі згодні. Перший раз це займає у фінансових організацій 3–8 тижнів — але результат стає постійним організаційним активом.

Другий етап: завантаження в репозиторій (1–2 тижні).

Правила, зібрані на першому етапі, оформлюються у вигляді документів і розміщуються в репозиторії. GitHub Spec Kit використовує constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, Alibaba Qoder — Spec Workflow. Назви файлів різні, але мета одна — щоб AI завантажував їх одразу під час відкриття репозиторію.

Рекомендована структура (актуальний формат першої половини 2026 року):

Опис проєкту: що це за система, для кого вона створена.
Непорушні принципи: межі безпеки, межі комплаєнсу, межі бізнесу.
Технічний стек і обмеження: які фреймворки, бази даних, інтерфейси використовуються, які обмеження існують.
Стандарти коду: угоди про найменування, структура каталогів, мінімальні вимоги до покриття тестами (не обов’язково TDD, але потрібно чітко зафіксувати мінімальний відсоток покриття, обов’язкові шляхи тестування та заборонені шляхи — TDD це опціональний організаційний ритм, а не жорстка вимога специфікаційно-керованого підходу).
Бізнес-правила: правила ризик-менеджменту, торгові правила, правила білінгу.
Регуляторні вимоги: вимоги до захисту даних (Держспецзв’язку), оцінка транскордонної передачі, подання звітності регулятору, реєстрація AI-алгоритмів.
Правила використання AI: у яких сценаріях можна використовувати AI, у яких потрібна перевірка людиною, правила транскордонної передачі даних.
Управління постачальниками: контракти, механізми аудиту, розподіл відповідальності.

Додаток: CLAUDE.md для банку (орієнтовно 200 рядків, можна відразу форкати й адаптувати)

Нижче наведено приклад CLAUDE.md для ПриватБанку, який вже організований за принципами “нерушимі принципи → державні вимоги → навігація AI → бізнес-регули → технічні обмеження”.

# CLAUDE.md — <назва системи> — регламент співпраці з AI

> Сфера застосування: <назва системи> v<версія>, всі AI-агенти (Claude Code / Cursor / Copilot / Codex),
> що працюють у цьому репозиторії, повинні дотримуватися цього регламенту. Документ підтримується <комітетом управління>,
> квартальний рев'ю.
> Останнє оновлення: <YYYY-MM-DD>

## 1. Огляд проєкту
- **Бізнес-призначення**: назва ядра системи / обслуговувані сегменти клієнтів / основні типи транзакцій
- **Ключовий ланцюг**: транзакція → ризик-менеджмент → кліринг → звірка → подання звітності
- **Вікно недоступності**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (будь-які зміни заборонені)
- **Основні залежності**: верхній рівень <система>, нижній рівень <система>, платформа подання звітності регулятору

## 2. Принципи, що не підлягають обговоренню (червоні лінії, порушення = відмова у злитті)

### 2.1 Червоні лінії безпеки
- Паролі, ключі, токени — обов'язково через KMS (Key Management Service), **заборонено хардкодити**, **заборонено друкувати в логах**
- Чутливі поля клієнтів (ідентифікаційний номер / номер картки / CVV / номер телефону) **повинні бути зашифровані при зберіганні**, відкритий текст у базі заборонено
- У логах заборонено: повний ідентифікаційний номер, повний номер картки, пароль у відкритому тексті, комбінація ім'я + телефон клієнта
- Зовнішні виклики API повинні проходити через API-шлюз, прямі з'єднання заборонені

### 2.2 Червоні лінії відповідності
- Якщо AI-генерований код передбачає доступ до даних клієнтів, у описі PR необхідно зазначити "доступ до даних: <поле>"
- Транскордонна передача даних заборонена, **будь-який вивіз даних потребує проходження оцінки транскордонної передачі даних** (звертатися до комплаєнс-відділу)
- Алгоритмічні рішення (кредитування / страхове ціноутворення / протидія шахрайству) повинні зберігати можливість людської перевірки
- Зміна моделі потребує реєстрації алгоритмів, номер реєстрації має бути вказаний в описі PR

### 2.3 Червоні лінії бізнесу
- Зміна порогів ризик-менеджменту потребує двох підписів: керівника ризиків і керівника бізнесу
- Операції з коштами клієнтів повинні мати ідемпотентність + відкат у разі збою
- Зміна лімітів транзакцій, тарифів і параметрів продукту здійснюється через платформу управління параметрами, хардкодження в коді заборонено

## 3. Технологічний стек та обмеження
- **Мови**: Java 17 (ядро) / Kotlin (нові модулі) / SQL (база даних)
- **Фреймворк**: Spring Boot 3.x + Spring Cloud Alibaba
- **База даних**: OceanBase 4.x (режим сумісності з MySQL), **використання зовнішніх ключів заборонено**
- **Стандарти інтерфейсів**: внутрішні — gRPC; зовнішні — OpenAPI 3.0; RESTful лише для адміністративних інтерфейсів
- **Угоди найменування**: класи Java — PascalCase, методи — camelCase, константи — UPPER_SNAKE; назви таблиць `t_<бізнес-домен>_<сутність>`; індекси `idx_<таблиця>_<поле>_<порядок>`
- **Структура пакетів**: `com.<компанія>.<бізнес-домен>.<піддомен>.<рівень>` (наприклад, `com.bank.pay.tx.core.service`)

## 4. Стандарти коду
- **Мінімальне покриття тестами**: ключовий ланцюг ≥ 80%, утиліти ≥ 60%, новий код у PR має супроводжуватися тестами
- **Обов'язкові шляхи тестування**: всі controller повинні мати інтеграційні тести (включаючи шляхи відмови); всі гілки enum повинні мати юніт-тести
- **Заборонені шляхи**: заборонено модифікувати каталог `<модулі історичної спадщини>` — спочатку створіть адаптаційний шар
- **Керування залежностями**: нові сторонні залежності потребують SCA-сканування + погодження безпеки

## 5. Бізнес-правила (за доменами)
### 5.1 Транзакції
- Ліміт однієї операції: <сума>; добовий ліміт: <сума>; перевищення — ручне затвердження
- Вікно транзакцій: <HH:MM> ~ <HH:MM>
- Визначення дублікату транзакції: у межах <часового вікна> однакове <поле> = дублікат

### 5.2 Ризик-менеджмент
- Пріоритет чорного списку: внутрішній чорний список → регуляторний спадний список → судове замороження
- Поріг виходу моделі протидії шахрайству: <оцінка>; перевищення — обов'язкова друга ручна перевірка

### 5.3 Білінг
- Зміна тарифу повинна мати номер версії + дату набрання чинності
- Історичні замовлення розраховуються за тарифом, що діяв на дату набрання чинності, без ретроактивного перерахунку

## 6. Вимоги відповідності
- MLPS рівень 3: <орган оцінки>, <дата наступної оцінки>
- Оцінка транскордонної передачі даних: сфера застосування (лише модулі транскордонної діяльності)
- Реєстрація алгоритмів: сфера застосування (кредитування / страхове ціноутворення тощо), номер реєстрації <номер реєстрації>
- Регуляторна звітність: таблиця відповідності полів <регулятор (CBIRC / Народний банк Китаю)> знаходиться у <шлях>

## 7. Стандарти використання ШІ
- **Сценарії, де ШІ дозволено**: CRUD-шаблони, генерація юніт-тестів, чернетки документації, рекомендації з оптимізації SQL
- **Сценарії, що потребують обов'язкової ручної перевірки**: логіка ризик-менеджменту, правила білінгу, контроль доступу, шифрування/дешифрування, транскордонні дані
- **Сценарії, де ШІ заборонено діяти самостійно**: матеріали для затвердження CAB (Change Advisory Board), виконання змін у прод, аварійне реагування
- **Правила вивезення даних**: навчальні дані / промпти / логи виводу — вивезення заборонено; перевага надається локалізованим версіям розгортання (<постачальник>)
- **Вимоги до аудиту**: весь AI-генерований код має бути позначений в описі PR як "AI-допомога: <назва інструменту>"

## 8. Управління постачальниками
- **Допуск постачальників**: вимагати звіти SOC 2 / ISO 27001; AI-моделі повинні супроводжуватися model card
- **Контрактні умови**: право власності на дані, пояснюваність моделі, умови виходу, право аудиту
- **Механізм аудиту**: квартальний аудит використання AI постачальниками; для високоризикових постачальників — щомісячний аудит

## 9. Управління та оновлення
- **Власник**: <комітет управління> (комплаєнс + безпека + архітектура + бізнес)
- **Частота оновлень**: квартальний рев'ю; екстрені зміни — через швидкий канал (дві підписи + 24h публікація)
- **Журнал змін**: див. `CLAUDE_CHANGELOG.md`
- **Обробка порушень**: перше порушення = попередження + примусове навчання; друге = призупинення використання AI-інструментів; третє = скасування прав

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

Наприклад, у деяких банках вже існує спеціальний документ CLAUDE.md, де визначені правила обробки паролів. Коли AI-генерований код стосується паролів, він повинен викликати внутрішній API керування паролями, а не використовувати закодовані дані. Такі правила часто стають причиною відмови в перевірці відповідності вимогам.

У першому півріччі 2026 року новим важливим полем стає Навички/Визначення робочого процесу. Це не лише документація, а й інструментальна ланцюжок, який можна викликати AI. Система Skills від Claude Code (яка вже була представлена в офіційному магазині Anthropic у лютому 2026 року та має понад 112 тисяч зірок на GitHub) перетворює такі завдання, як “читання таблиць Excel”, “генерування SQL” або “робота з міграцією даних” на спільні робочі процеси. Цей розвиток є ключовим кроком у розвитку 2026 року: Норми не лише обмежують, а й виконуються як робочі процеси.

Третій етап: інституціалізація (постійність)

Установлення правил не закінчуєся цим. Ви повинні зробити їх частиною організаційних процесів:

CI-governance: автоматично перевірте, чи дотримуються коду правила (наприклад, перевірте, чи немає зашифрованих паролів чи відкритих даних).
загальна конфігурація команди: використовуйте систему Skills, щоб усі члени команди могли працювати з однією і тією ж конфігурацією правил.
система періодичної оновлення: якщо правила змінилися, конфігурація правил повинна змінитися разом з ними (квартальні огляди).
визначення та відгук: слідкувати за кількістю помилок в коді AI, кількістю успішних перевірок відповідності, кількістю повторної роботи.
Управління агентами: розширити управління людьми на управління AI-агентами — Atos реалізував це на Agent 365, зробивши це «системним» рівнем, а не особистим.

EY та Atos у першому півріччі 2026 року перетворили третій етап на «організаційну спроможність». 2,5 мільйона годин економії EY — це результат правильно реалізованих першого та третього етапів; другий етап був лише перекладом правил на мову, яку може прочитати AI.

V. Варіанти для жорстко регульованих галузей: три інженерні підходи до інтеграції комплаєнсу

Фінансові, телекомунікаційні та медичні галузі зі строгими регулюваннями мають додаткову стадію — відповідність не є зовнішнім додатком процесу, а є інтегрованим у код. Нижче наведені три методи інтеграції відповідності, які були перевірені у першому півріччі 2026 року, і керівники IT/директори цифрового розвитку можуть використовувати їх у своїй організації.

5.1 Впровадження співробітників з питань дотримання в потоці розробки: зробити дотримання присутнім, а не затвердженим

Традиційний підхід: бізнесові команди пишуть код, а команди з питань дотримання перевіряють його пізніше. Коли проблеми виявляються, код вже був випущений протягом півмісяця, а вартість повернення до розробки становить 2-4 тижні. Питання полягає в тому, що дотримання знаходиться в кінці процесу.

Новий підхід: в кожній команді розробників потоку (stream-aligned team) розміщувати співробітника з питань дотримання. Форма цього співробітника є “прямою лінією в відділі дотримання, а лінією зірок в бізнес-команді”. Конкретні вимоги:

Персональний склад: співробітника з питань дотримання розміщувати кожні 6-8 команд розробників, підпорядковувати відділу дотримання, фізично розміщувати в бізнес-команді - не на дистанційній основі.
Віртуальні КПІ: співробітника з питань дотримання оцінювати з вагою 50% щодо бізнес-команди за “рівнем дотримання” та “рівнем затвердження в першому проході”, а не лише за рівнем затвердження відділу дотримання.
Передчасовий втручання: співробітника з питань дотримання залучати до щоденних засідань команди розробників (щотижня достатньо), перевірки Pull Request, а також перевірки коду, згенерованого AI, перед його злиттям - а не після.
Навчальні засоби: співробітника з питань дотримання використовувати інструменти перевірки дотримання, такі як Skills, а не здійснювати перевірку вручну.

Типовий сценарій: один із національних акціонерних банків у першому півріччі 2026 року запустив пілот із трьома потоковими командами, до яких було вбудовано комплаєнс-представників. У результаті частка відхилених AI-кодів у межах комплаєнс-перевірки знизилася з 35% до 8% — і ключ тут не в тому, що комплаєнс став «суворішим», а в тому, що він став «ранішим». Головна умова такого підходу — щоб непряма мотивація комплаєнс-представників була узгоджена з бізнес-цілями — якщо KPI комплаєнс-представника досі визначаються лише завданнями від комплаєнс-департаменту, таке вбудовування приречене на провал.

5.2 Комплаєнс як enabling team: перетворити обмеження на можливості

Традиційний підхід: комплаєнс-команда виконує роль «вартового», а бізнес-команди сприймають комплаєнс як «джерело проблем». У результаті — гра з нульовою сумою.

Новий підхід: комплаєнс-команда перебудовується за моделлю enabling team з Team Topologies — вона не пише код напряму, не рев’ює pull request-и, але надає три речі, які дозволяють бізнес-командам «проходити комплаєнс самостійно»:

Перевірки комплаєнсу в CI-конвеєрі: перетворити типові комплаєнс-точки (зашифровані паролі, відкриті чутливі поля, транскордонна передача даних, точки алгоритмічних рішень) на примусові гейти через GitHub Actions / GitLab CI. PR бізнес-команд запускає автоматичну перевірку, невідповідність одразу fail — без потреби в ручному прогоні комплаєнс-представника.
Регуляторні вимоги як affordance (середовище реагує): наприклад, під час розробки функцій, що працюють із клієнтськими даними, плагін IDE виводить підказку «для цього поля рекомендовано викликати KMS»; під час написання логів автоматично виявляється наявність чутливої інформації та спрацьовує попередження. Регуляторні вимоги стають «природною дією під час розробки», а не «повідомленням про порушення перед релізом».
Спільна бібліотека Skills + навчання комплаєнсу: комплаєнс-команда підтримує набір «комплаєнс-Skills», до яких звертаються під час онбордингу нових співробітників або переходу між командами — комплаєнс-знання перетворюються з «документа» на «інструмент, який можна виконати».

Типовий сценарій: один міський банк у першій половині 2026 року запустив CI-гейти для комплаєнсу + IDE-підказки щодо комплаєнсу, скоротивши середній час комплаєнс-перевірки AI-коду з 45 хвилин на справу до 8 хвилин на справу, ключ не в тому, що комплаєнс «перевіряє швидше», а в тому, що AI одразу «не помиляється» під час генерації.

5.3 Двошвидкісний комплаєнс: шарове узгодження з бізнес-ритмом

Остання деталь: комплаєнс не має бути «一刀切». Правила слід розділити на два рівні за ризиком:

Високоризикові правила (стосуються коштів клієнтів / алгоритмічних рішень / транскордонних даних / червоних ліній захисту рівня) ідуть через суворий гейт: обов’язковий ручний рев’ю + повторне підтвердження AI + реєстрація в CAB
Низькоризикові правила (CRUD-шаблони / утилітний код / генерація документації) ідуть через самообслуговуючий гейт: достатньо автоматичної CI-перевірки, ручне рев’ю не потрібне

Контрольна площина Agent 365 від Atos по суті реалізує саме це шарування — різні рівні агентів прив’язані до різних вимог управління. Коли правила комплаєнсу розділені за ризиком, бізнес-команди відчувають, що «комплаєнс не блокує мене на кожному кроці».

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

VI. Запитання, які ви могли б поставити

“Ми вже маємо кодові стандарти, а що відрізняє цей підхід?”

Кодові стандарти регулюють “Як писати код”, а нормативно-орієнтований підхід регулює “Як співпрацювати з AI”. Кодові стандарти не містять: бізнес-регламентів, вимог щодо дотримання законодавства, стратегії використання AI. Нормативно-орієнтований підхід робить “Всю діяльність людини і AI явною”, а не є керівництвом щодо стилю коду.

“Чи сповільнить написання специфікацій розробку?”

У короткостроковій перспективі — так, у довгостроковій — ні. Дані CodeRabbit дають чітку відповідь: код, згенерований AI без жодних обмежень, має приблизно в 1,7 раза вищий ризик дефектів і в 2,74 раза вищий ризик уразливостей безпеки. У фінансовому секторі один цикл доопрацювання через комплаєнс-перевірку коштує 2–4 тижні — і одного уникненого циклу достатньо, щоб окупити місяць роботи над специфікаціями. Економія $250 млн, яку зафіксувала EY, — це реальний доказ того, що такий підхід можна перетворити на організаційну спроможність.

“А якщо в нашій команді ніхто не вміє писати специфікації?”

Починати з нуля не доведеться. У GitHub Spec Kit, Claude Code Superpowers та AWS Kiro вже є готові шаблони. Вам лишається лише додати правила, специфічні для вашої організації — здебільшого це комплаєнс- і безпекові вимоги, які ваші відповідні відділи вже давно сформулювали. Просто вони досі не були в місці, доступному для AI.

“Інструментів на базі AI багато — який обрати?”

Неважливо. Беріть те, що вже використовуєте. Підхід на основі правил не прив’язаний до інструменту — CLAUDE.md працює і в Claude Code, і в Cursor, і в Codex; AGENTS.md запускається в екосистемі OpenAI; constitution.md взагалі не залежить від моделі. Головне — писати правила, а не міняти інструменти. EY розгортає це в екосистемі Microsoft, Atos — теж в екосистемі Microsoft. Різниця у виборі інструментів — лише зовнішня; уніфікована структура governance — ось що справді має значення.

«У серпні 2026 року EU AI Act набуває повної чинності. Чи вплине це на нас?»

Так. EU AI Act набуває повної чинності 2 серпня 2026 року і встановлює обов’язкові вимоги для високоризикових систем ШІ — включно з кредитуванням, страховим ціноутворенням, відбором кандидатів на роботу та критичною інфраструктурою. Йдеться про управління ризиками (ст. 9), якість даних (ст. 10), прозорість документації (ст. 11–13), людський нагляд (ст. 14) та точність/надійність (ст. 15). Штрафи сягають 35 млн євро або 7% глобального обороту. Для китайських компаній, що виходять на ринок ЄС, це обов’язкова тема. А для внутрішнього ринку — EU AI Act фактично став найбільш референтним стандартом у світі: навіть якщо ви не підпадаєте під нього напряму, його вплив через постачальників, партнерів і транскордонні операції обійти практично неможливо (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

«А що в нас? Китайський підхід: не сам ШІ, а його використання»

У Китаї регулювання генеративного ШІ будується на трьох опорах: реєстрація алгоритмів, перевірка навчальних даних і оцінка безпеки. Ключовий документ — «Тимчасові заходи щодо управління послугами генеративного штучного інтелекту», що діють із серпня 2023 року. В Україні регуляторне поле формується «Мінцифра AI регуляторним проєктом» (2024) на основі ЗУ № 2297-VI (2010, з новим проєктом 12277/2024, що гармонізується з GDPR). Головна відмінність від європейського підходу не в деталізації норм, а в самій філософії законодавства:

Що відрізняє законодавство щодо штучного інтелекту в ЄС та Китаї?

Параметр	ЄС (Акт про штучний інтелект)	Китай (Порядок управління послугами штучного інтелекту)
Положення законодавства	Хоризонтальне регулювання (застосовується до всіх систем штучного інтелекту)	Вертикальні правила (зосереджені на послугах штучного інтелекту)
Рівні ризику	4 рівні (невідповідність / високий / обмежений / дуже малий)	2 рівні (відносно безпеки громадськості / загальне використання)
Точка регулювання	Передбачена (розробка передбачає реєстрацію)	Після виходу на лід (послуга реєструється після виходу на лід + реєстрація алгоритму)
Прозорість	Висока (обов’язково публікувати підсумковий виклад джерел навчання, модельні карти)	Середня (обов’язково дотримуватися вимог щодо матеріалів навчання, але не обов’язково публікувати джерела)
Порогові штрафи	7% світових продажів або 35 мільйонів євро	Відключення послуги / штраф (зазвичай в кілька разів більший за отриманий прибуток)
Діапазон застосування	Всі підприємства, які перевищують світові пороги продажів	Всі суб’єкти, які здійснюють послуги в Китаї

На практиці внутрішні фінансові системи в Китаї одночасно підпадають під дію трьох регуляторних шарів: «Правила управління генеративним AI» (базовий рівень) + «Правила управління інтернет-кредитами для комерційних банків» (бізнес-рівень) + вимоги захисту інформації та реєстрації алгоритмів (рівень комплаєнсу). Це означає, що в Китаї специфікаційно-керований підхід не може бути реалізовано простим копіюванням європейської рамки EU AI Act. Натомість у проєктну специфікацію необхідно включити всі три рівні регулювання: «цілісність даних + реєстрація алгоритмів + подання звітності регулятору».

Для українських експортерів на ринок ЄС: європейський підхід EU AI Act уже сьогодні є орієнтиром, який Україна імплементує через проєкт Мінцифри. Якщо ви зараз пишете специфікацію, сумісну з EU AI Act, протягом найближчих 3 років вона з високою ймовірністю лишатиметься сумісною і з українськими регуляторними оновленнями, включно з гармонізацією проєкту 12277/2024 до GDPR (реєстраційні повідомлення Мінцифри та повідомлення про реєстрацію китайських регуляторів за 2025–2026 роки; EU AI Act compliance 2026.6).

VII. Висновки для осіб, що ухвалюють рішення

Висновок 1: написати проєктну специфікацію CLAUDE.md/AGENTS.md — це інженерна дія з найвищим ROI в епоху AI.

Його вкладення — це 3–8 тижнів інвентаризації + 1–2 тижні оформлення документа. Його віддача: верхня межа ризику дефектів — близько 1,7 раза, скорочення вразливостей безпеки — у 2,74 раза, падіння частки повернень на доопрацювання — на 40%+. У фінансовій сфері економія на одному комплаєнс-поверненні (2–4 тижні) покриває цю вартість. EY розгорнула Copilot для 150 000 співробітників і заощадила 250 млн доларів — але спершу маючи специфікацію.

Висновок 2: нормативна база — це організаційна спроможність, а не вибір інструменту.

Неважливо, оберете ви GitHub Spec Kit чи Claude Code. Важливо, чи визначили ви, «як наша організація співпрацює з AI». Без цього навіть найкращий інструмент лише дозволить команді швидше накопичувати борг.

Висновок 3: фіксуйте нормативи в організаційних процесах, а не покладайтеся на окремих людей.

Якщо нормативи існують лише в голові досвідченого інженера, вони зникнуть разом із плинністю кадрів. Їх необхідно закріпити в документації репозиторію, CI-гейтах, спільних конфігураціях команди та платформах керування агентами. Нормативи мають стати організаційним активом, а не особистою навичкою. 19 000 агентів Atos працюють у 54 країнах саме тому, що управління — це не «хтось розуміє», а «система зобов’язує».

Висновок 4: гейти важливіші за швидкість.

П’ятиетапний гейтинг GitHub Spec Kit, правило Superpowers «не писати код, поки тести не падають», вимога Kiro «не можна стартувати без spec» — усе це додає «гальма» між AI та кінцевим результатом. Що потужніший AI, то більше управління має випереджати його. Ті 78% рівня інцидентів зі звіту New Relic 2026 — це ціна, яку сплачують 62% команд, що «публікують без рев’ю». CIO у фінансовій сфері знають це краще за всіх: їхні Change Advisory Board (CAB), процедури реєстрації алгоритмів та оцінка відповідності вимогам Держспецзв’язку — усе це гейтинг перед випуском у продакшн. AI-код потребує аналогічного гейтингу, причому ще більш випереджаючого.

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

Три коучингові запитання для осіб, що ухвалюють рішення

На завершення — три запитання, не чек-ліст, а інструмент для обговорення з вашою командою:

“Якщо завтра всі AI-інструменти зникнуть, наскільки впаде якість коду вашої команди?” — Це питання розкриває справжню цінність специфікацій: якщо відповідь “суттєво впаде” — ваші специфікації ще не усталені; якщо “майже не зміниться” — специфікації вже працюють на вас.
“У вашому проєкті зі специфікаціями комплаєнс-відділ — це ‘брама’ чи ‘енabler’?” — Якщо “брама”, ваша швидкість впровадження впертиметься в бюрократичні затори; якщо “енabler” — ви вже на правильному шляху, описаному в розділі 5.2.
“Через 12–18 місяців як зміниться розмір вашої команди?” — За даними Microsoft WTI 2026, 82% керівників планують “розширювати” робочу силу за допомогою AI-агентів. Якщо ваша відповідь “не зміниться”, або ваш бізнес не зростає, або ваша організаційна структура не встигає за перевагами специфікацій.

На ці три питання немає єдиної правильної відповіді. Але напрямок відповіді важливіший за саму відповідь.

Що далі

Це шостий матеріал із серії “Трансформація розробки ПЗ в епоху AI”. Ми пройшли шлях від Конвея (організація визначає архітектуру) через Team Topologies (як проєктувати організацію) до зміщення вузького місця (воно тепер у валідації, а не в написанні коду). Сьогодні ми говоримо про специфікації (використання документації для обмеження поведінки AI).

У наступній (сьомій) частині ми розглянемо базову інфраструктуру, на якій усе це тримається — протокол MCP (Model Context Protocol): чому відкритий протокол від Anthropic називають «USB-C для ШІ», чому OpenAI, Google і Microsoft усі приєдналися до нього, і як він уможливлює взаємодію між багатьма інструментами та агентами.

Хочете впровадити цей підхід у своїй компанії?

Коли нормативно-орієнтований підхід потрапляє в реальну організацію, на практиці зазвичай постають кілька конкретних питань: як закріпити ключові правила у файлах CLAUDE.md / AGENTS.md, як привести наявний код до стандартів, як вбудувати комплаєнс і за якими метриками оцінювати пілотний проєкт.

Наразі пропонуємо три формати співпраці:

Корпоративне навчання: на основі реальних проєктів вашої компанії — розробка нормативних документів, проєктування CI-гейтів, шляхів упровадження комплаєнсу та побудова механізмів управління.
Цільовий консалтинг: фокус на одному чіткому рішенні, наприклад, «чи варто нам спочатку писати CLAUDE.md / AGENTS.md» або визначення пріоритетів приведення наявного коду до вимог.
Виступи для керівництва та галузеві доповіді: теми ШІ-інструментів для програмування, нормативно-орієнтованого підходу, організаційного управління та Frontier Firms.

Стаття пропонує загальну рамку, але практичне впровадження потребує переосмислення з урахуванням комплаєнс-вимог компанії, регуляторних меж, інженерної зрілості та наявних процесів доставки. Для співпраці звертайтеся: coach@iaiuse.com.

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

Про цю серію

«Трансформація інженерії програмного забезпечення в епоху ШІ» — це дослідницька серія для CIO, CDO, CTO та керівників цифрової трансформації в телекомунікаціях, фінансах, виробництві та електронній комерції. Серія налічує 18 статей і зосереджена на тому, як AI-інструменти для програмування, нормативно-орієнтований підхід та організаційне управління впливають на процеси доставки програмного забезпечення, організаційну структуру та інженерну зрілість.

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

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

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

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

Джерела (усі перевірено, для кожного позичення зазначено рівень доказовості)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Проблем в AI-коді в 1,7 раза більше, ніж у коді, написаному людиною (10,83 проти 6,45 проблеми на PR), логіка/коректність — у 1,75 раза, якість коду — у 1,64 раза, безпека — у 1,57 раза, обробка паролів — у 1,88 раза, XSS — у 2,74 раза. Рівень доказовості: перший. Джерело: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). Висвітлення повного звіту CodeRabbit: аналіз 470 відкритих PR-запитів, PR з AI-співавторством містять 10,83 проблеми проти 6,45 у суто ручних. Рівень доказовості: другий. Джерело: та сама URL-адреса
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 рік стає переломним моментом переходу від «швидкості генерації коду» до «якості коду та керування ним». Рівень доказовості: другий. Джерело: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. 78% команд повідомляють про більше інцидентів після впровадження AI-коду; 62% технічних лідерів визнають, що їхні команди «впевнено публікують код без перевірки»; 96% вважають спостережуваність обов’язковою. Рівень доказовості: перший (звіт вендора). Джерело: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Опитування 20 000 працівників, які використовують AI, у 10 країнах; 82% керівників планують протягом 12–18 місяців розширити робочу силу за допомогою AI-агентів; 81% очікують помірної або значної інтеграції AI-агентів; 24% уже впровадили їх на корпоративному рівні; 49% діалогів у Copilot підтримують когнітивну роботу; 58% користувачів AI кажуть, що роблять речі, які були неможливі рік тому, а серед Frontier Professionals цей показник сягає 80%. Рівень доказовості: перший. Джерело: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26 Підсумки: від AI-експериментів до трансформації на рівні фронтиру (28.07.2026). EY розгорнула Microsoft 365 Copilot для 150 000 співробітників, заощадивши 2,5 мільйона годин і близько 250 мільйонів доларів; масштабування на 400 000 працівників по всьому світу дало прискорення роботи на 95%, зниження фінансових операційних витрат на 37% і скорочення до 90% ручних робочих процесів. Atos розгорнула Copilot для 56 000 співробітників у 56 країнах, а також 19 000 AI-агентів, з уніфікованою площиною керування для ідентичності, безпеки, комплаєнсу та governance. Рівень доказовості: перший (офіційний огляд Microsoft). Джерело: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Стратегічна співпраця Atos Group і Microsoft (2026.6.9). Atos впроваджує Microsoft 365 E7 (Frontier Suite) для 56 000 співробітників у 56 країнах + 19 000 AI-агентів; уніфікована площина керування Entra/Defender/Intune/Purview/Agent 365. Рівень доказовості: перший (спільний пресреліз обох компаній). Джерело: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (відкрито у вересні 2025, розвиток у 1H 2026). 5-етапний процес з воротами /speckit.constitution → /specify → /plan → /tasks → /implement, плюс /clarify /analyze; не залежить від моделі (працює з Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Рівень доказовості: перший. Джерело: https://github.com/github/spec-kit
AWS Kiro (випущено у липні 2025, розвиток у 1H 2026). Триетапний робочий процес: вимоги → дизайн → завдання; spec тригеріть попередньо визначені дії агента; без написання spec робота не запускається. Рівень доказовості: перший. Джерело: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 — понад 5 млн щотижневих активних користувачів, 20% з них — не розробники; AGENTS.md + Skills як комбінований набір інструкцій. Рівень доказовості: перший (офіційні оголошення OpenAI). Джерело: https://developers.openai.com/codex/skills
Claude Code (Anthropic, перша половина 2026). Система CLAUDE.md + .claude/rules/ + Skills; у лютому 2026 потрапив в офіційний маркетплейс Anthropic; репозиторій Skills на GitHub — 112 тисяч зірок; у лютому 2026 під час раунду G розкрито річний дохід у 2,5 млрд доларів. Рівень доказовості: перший. Джерело: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Опитування понад 10 000 професійних розробників у всьому світі, локалізоване 8 мовами; CSAT для Claude Code — 91%, NPS — 54 (найвищий показник у галузі); рівень впровадження Claude Code на робочих місцях — 18% (зріс у 6 разів із 3% за 9 місяців), у Північній Америці — 24%; Copilot — 29% впровадження на робочих місцях, але зростання зупинилося; Cursor — 18%. Рівень доказовості: перший. Джерело: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Опитування 15 000 розробників; 46% обрали Claude Code як «найулюбленіший інструмент», Cursor — 19%, Copilot — 9%. Рівень доказовості: перший. Джерело: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). У серпні 2025 року Alibaba випустила Qoder; 15 травня 2026 року Qoder 1.0 оновлено до Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 травня 2026 року — Cloud Agents (кероване середовище виконання агентів); 21 липня 2026 року — Qoder Security; у травні 2026 року — понад 5 мільйонів користувачів у світі; інтеграція з Microsoft Teams CLI; 20 травня 2026 року Tongyi Lima перейменовано на Qoder CN. Рівень доказовості: перший. Джерела: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (перша половина 2026). Команди п’яти етапів Spec Kit, порівняльний огляд інструментів SDD, нотація EARS. Рівень доказовості: другий (сторонні огляди). Джерела: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (повне застосування з 2 серпня 2026). Для високоризикових AI-систем дедлайн відповідності — 2 серпня 2026; для наявних GPAI-моделей — до 2 серпня 2027; штрафи — до 35 млн євро або 7% глобального обороту; Art. 9–15: управління ризиками, керування даними, прозорість документації, людський нагляд, точність і надійність. Рівень доказовості: перший (регламент + вторинний комплаєнс-аналіз). Джерела: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). 44% проблем у коді спричинені браком контексту. Рівень доказовості: другий (звіт вендора). Джерело: https://www.qodo.ai/reports/state-of-ai-code-quality/