Мы находимся на переломном этапе в разработке программного обеспечения. Часто обсуждается, какой какой ИИ пишет лучший код (Claude против ChatGPT) или где где должен находиться ИИ (IDE или CLI). Но это не тот вопрос, который следует задавать.
Проблема не в генерировать кода. Проблема в проверка этом.
Если мы примем ИИ как «Кодеров Настроения» (Vibe Coders) — где мы задаем намерение, а ИИ выполняет работу — мы создадим огромный поток нового программного обеспечения. Рой ИИ-агентов может сгенерировать за минуту больше кода, чем старший разработчик сможет просмотреть за неделю. Человек стал узким местом.
Решение не в больше людях. Решение в Авторитете Проектирования ИИ.
Традиционно «Орган по утверждению проектов» (Design Authority) — это небольшая группа архитекторов, которая собирается раз в неделю или месяц, чтобы одобрить или отклонить проект. В мире высокоскоростной разработки ИИ эта модель безнадежно устарела. Она слишком медленная и слишком реактивная.
Если мы перейдем на «одноразовый код» (Disposable Code) — программное обеспечение, которое мы не будем бесконечно рефакторить, а будем выбрасывать и генерировать заново при изменении требований, — то наша роль кардинально изменится. Мы больше не каменщики, укладывающие камень за камнем. Мы — архитекторы фабрики, которая печатает стены.
Но кто проконтролирует, ровные ли эти стены?
AI Design Authority — это не человек, а конвейер. «Полоса препятствий», через которую должен пробиться каждый сгенерированный фрагмент кода, чтобы попасть в продакшн. Этот процесс заменяет человеческий код-ревью не ничем, а чем-то лучшим.
Он работает в три слоя:
1. Исполнительная власть (Генерация)
Мы просим не одну ИИ для решения, а три. Мы заставляем Gemini 3, GPT-5 и модель с открытым исходным кодом (например, Llama) параллельно работать над одной и той же проблемой. Это предотвращает туннельное зрение и преодолевает «лень», от которой иногда страдают большие языковые модели (LLM). Такой подход также научно исследован и доказывает, что вы можете предотвратить галлюцинации ИИ и строить очень длинные цепочки без ошибок
2. Жесткий фильтр (Закон)
Здесь не может быть никаких споров. Код должен компилироваться. Линтеры не должны жаловаться. И самое главное: Тестирование черного ящика тесты должны пройти. Мы не проверяем, работает ли функция внутри (это может привести к манипуляциям с ИИ), мы проверяем, делает ли система снаружи то, что должна делать. Тест провален? Сразу в корзину.
3. Мягкий фильтр (Жюри ИИ)
Это настоящая инновация. Оставшиеся решения представляются специализированному «Голосующему ИИ». Этот агент не пишет код, но читает код. Он обучен на наших архитектурных принципах, требованиях безопасности (OWASP, ISO) и нормах соответствия (Закон ЕС об ИИ).
Он говорит: «Решение А быстрее, но Решение Б безопаснее и лучше соответствует нашей микросервисной архитектуре».
Победитель переходит в стадию производства.
Эта модель обеспечивает разделение властей, которого не хватает во многих командах.
project-description.md, rules.md, skills.md en principles.md), жесткие требования. Архитектор определяет что что мы строим, кто это строит, как и почему.
Это освобождает нас от тирании синтаксических ошибок и позволяет сосредоточиться на том, в чем мы хороши: системное мышление. Поиск истины. Структура и принятие решений.
Вопрос не в том, может ли ИИ писать наш код. Этот вопрос уже закрыт. Код в значительной степени становится одноразовым продуктом.
Вопрос в том: осмелитесь ли вы взять под контроль код отпустить, чтобы таким образом получить контроль над качество вернуть?
дайте мне знать