Орган з архітектури ШІ

Ми перебуваємо на переломному етапі розвитку програмного забезпечення. Дискусія часто точиться навколо того, який чи пише ШІ найкращий код (Claude чи ChatGPT), чи де де саме має працювати ШІ (в IDE чи CLI). Але це неправильна постановка питання.

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

Рішення полягає не в тому, щоб більше замінити людей. Рішення — створити орган управління дизайном ШІ.

Від ремісника до директора фабрики

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

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

Але хто перевіряє, чи рівно стоять ці стіни?

«Гонтлет»: автоматизоване випробування вогнем

AI Design Authority — це не людина, а конвеєр. «Гладіаторська арена», крізь яку кожен рядок згенерованого коду має пройти, щоб потрапити у промислову експлуатацію. Цей процес не замінює перевірку коду людиною на ніщо, а на щось краще.

Він працює у три етапи:

1. Виконавча влада (генерація)
Ми просимо не один ШІ запропонувати рішення, а одразу три. Ми змушуємо Gemini 3, GPT-5 і модель із відкритим кодом (наприклад, Llama) паралельно працювати над однією й тією самою проблемою. Це запобігає обмеженості мислення та долає «лінощі», від яких іноді потерпають великі мовні моделі. Цей підхід також науково досліджений і демонструє, що можна запобігати галюцинаціям ШІ та будувати дуже довгі ланцюжки без помилок

2. Жорсткий фільтр (закон)
Тут не може бути жодних дискусій. Код має компілюватися. Лінтери не повинні знаходити помилок. І що особливо важливо: Тести методом чорної скриньки мають пройти перевірку. Ми не тестуємо, чи працює функція всередині (ШІ може це підробити), а перевіряємо, чи робить система зовні саме те, що має робити. Тест не пройдено? Одразу до смітника.

3. М’який фільтр (журі зі штучного інтелекту)
Це справжня інновація. Рішення, що залишилися, передаються спеціалізованому «ШІ для голосування». Цей агент не пише код, а читає коду. Його навчено відповідно до наших архітектурних принципів, вимог безпеки (OWASP, ISO) та правил відповідності нормативам (Закон ЄС про штучний інтелект).
Він оцінює: «Рішення A швидше, але рішення B безпечніше й краще відповідає нашій мікросервісній архітектурі».

Переможець переходить у промислову експлуатацію.

Поділ влади у світі програмного забезпечення

Ця модель забезпечує розподіл повноважень, якого бракує багатьом командам.

• Законодавча влада (архітектор): Архітектор пише «Конституцію». Промпти, архітектурні документи (project-description.md, rules.md, skills.md en principles.md), жорсткі вимоги. Архітектор визначає що що ми будуємо, хто це будує, як і чому.
• Виконавча влада (агенти кодування): Вони виконують завдання. Швидко, дешево й під наглядом людей-розробників.
• Судова влада (орган з архітектури): Незалежний рівень ШІ, який перевіряє відповідність закону.

Висновок: нова роль архітектора

Вона звільняє нас від тиранії синтаксичних помилок і дає змогу зосередитися на тому, що ми вміємо найкраще: системному мисленні, пошуку істини, структуруванні та ухваленні рішень.

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

дай мені знати