Архитектурный комитет по ИИ

Мы стоим на переломном этапе развития программного обеспечения. Дискуссия часто сводится к вопросу о том, какой пишет ли ИИ лучший код (Claude или ChatGPT) или где где должен находиться ИИ (в IDE или CLI). Но это неправильная постановка вопроса.

Если мы примем ИИ в качестве «вайб-кодеров» — будем обозначать намерение, а ИИ будет заниматься реализацией, — мы создадим огромный поток нового программного обеспечения. Рой ИИ-агентов за одну минуту может сгенерировать больше кода, чем старший разработчик способен проверить за неделю. Человек стал узким местом.

Решение — не больше люди. Решение — это центр архитектурного контроля ИИ.

От ремесленника к директору фабрики

Традиционно «архитектурный комитет» — это группа архитекторов, которая собирается раз в неделю или месяц, чтобы одобрить или отклонить проект. В мире высокоскоростной разработки с использованием ИИ эта модель безнадёжно устарела. Она слишком медленная и реактивная.

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

Но кто проверяет, ровно ли стоят эти стены?

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

Орган по проектированию ИИ — это не человек, а конвейер. «Перчатка», через которую должна пройти каждая строка сгенерированного кода, чтобы попасть в продакшен. Этот процесс не заменяет человеческую проверку кода с ничем, а чем-то лучшим.

Он работает в три слоя:

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

2. Жёсткий фильтр (закон)
Здесь не может быть никаких дискуссий. Код должен компилироваться. Линтеры не должны выдавать предупреждений. И что особенно важно: тесты чёрного ящика должны пройти проверку. Мы проверяем не то, работает ли функция внутри (этим ИИ может манипулировать), а то, делает ли система извне именно то, что должна. Тест не пройден? Немедленно в корзину.

3. Мягкий фильтр (жюри ИИ)
Это настоящая инновация. Оставшиеся решения передаются специализированному «голосующему ИИ». Этот агент не пишет код, а читает проверяет код. Он обучен нашим архитектурным принципам, требованиям безопасности (OWASP, ISO) и правилам соответствия нормативным требованиям (Закон ЕС об ИИ).
Он голосует: «Решение A работает быстрее, но решение B безопаснее и лучше соответствует нашей микросервисной архитектуре».

Победитель отправляется в продакшен.

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

Эта модель обеспечивает разделение полномочий, которого не хватает многим командам.

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

Заключение: новая роль архитектора

Она освобождает нас от тирании синтаксических ошибок и позволяет сосредоточиться на том, что мы умеем лучше всего: системном мышлении, поиске истины, структурировании и принятии решений.

Вопрос не в том, способен ли ИИ писать наш код. Этот вопрос уже закрыт. Код в значительной степени становится одноразовым продуктом.
Вопрос в другом: осмелишься ли ты отпустить контроль над кодом чтобы тем самым вновь обрести контроль над качеством вернуть?

дай мне знать