Орган із дизайну ШІ

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

Проблема не в генерувати коду. Це в валідація цього.

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

Рішення полягає не в більше людях. Рішення полягає у Авторитеті Дизайну ШІ.

Від ремісника до директора заводу

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

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

Але хто контролює, чи ці стіни рівні?

«Рукавиця»: Автоматизоване вогневе випробування

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

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

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

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

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

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

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

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

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

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

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

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

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