Орган з питань дизайну ШІ

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

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

Рішення полягає не в більше людях. Рішення — це Орган з питань проектування ШІ.

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

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

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

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

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

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

Він працює на трьох рівнях:

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

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

3. М'який фільтр (AI-журі)
Це справжня інновація. Рішення, що залишилися, передаються спеціалізованому «ШІ-судді» (Voting AI). Цей агент не пише код, а читати код. Він навчений на наших архітектурних принципах, вимогах безпеки (OWASP, ISO) та правилах відповідності (EU AI Act).
Він голосує: «Рішення А швидше, але Рішення Б безпечніше і краще відповідає нашій архітектурі мікросервісів».

Переможець іде у виробництво.

Тріас Політика програмного забезпечення

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

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

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

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

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

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