Авторитет в области проектирования ИИ

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

Настоящая проблема не в поколение кода. Настоящая проблема в валидации его.

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

Решение не в больше людях. Решение в Авторитете по дизайну ИИ.

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

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

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

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

«Перчатка»: Автоматизированное боевое крещение

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

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

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

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

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

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

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

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

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

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

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

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