Не проверять AI-сгенерированный код, а генерировать его меньше: модель AI assembly

По данным отчета Sonar State of Code Developer Survey за 2026 год, основанного на опросе более 1100 разработчиков, 42% кода, попадающего в репозиторий, уже создается с помощью AI, а примерно 29% этого кода сливается без ручного ревью. Не «легкого» ревью. Вообще без проверки.

Ответ отрасли предсказуем: больше guardrails. Static analysis, token linting, visual regression testing, accessibility audits, security scans. Каждый из этих инструментов оправдан, но вместе они описывают систему, которая постоянно компенсирует собственную ненадежность. AI генерирует. Инструменты проверяют. Разработчики принимают решение. И вся эта схема масштабируется линейно вместе с объемом кода.

Это неправильная кривая масштабирования для любого enterprise, который планирует строить больше нескольких приложений.

Обычная постановка вопроса — «как сделать guardrails для AI-сгенерированного кода лучше?» — не неверна, а просто неполна. Более продуктивный вопрос звучит иначе: «как уменьшить объем кода, который вообще нуждается в guardrails?»

Этот вопрос ведет к принципиально другой архитектуре, которая осознанно применяет AI по нарастающей — от нулевой генерации к частичной, а затем к полной. Автор называет ее моделью AI assembly.

Сначала стоит глубже взглянуть на то, как все работает сегодня.

Беговая дорожка «сгенерировать — проверить»

Когда инструмент generative AI создает UI-компонент с нуля — таблицу данных, форму, панель навигации, — результат носит вероятностный характер. Он может оказаться правильным. А может содержать пропущенную проверку аутентификации, жестко заданное значение цвета, нарушающее design system, сломанную разметку accessibility или подход к управлению состоянием, который развалится при параллельной нагрузке. Вы не узнаете этого, пока не проверите код. А проверка на уровне enterprise стоит дорого.

Поэтому отрасль добавляет post-generation validation. Static analyzer находит потенциальные векторы injection. Linter отмечает дрейф design token. Visual regression suite сравнивает отрисованный компонент с базовой версией. Accessibility scanner проверяет роли ARIA и контрастность. DAST-инструмент тестирует запущенное приложение на уязвимости OWASP Top 10. Каждый из этих инструментов закрывает реальный риск. Ни один из них не предотвращает риск заранее. Они обнаруживают его постфактум.

Это реактивная модель, и у нее есть структурная проблема стоимости. Каждое новое приложение, построенное по схеме generate-first, требует заново запускать полный набор проверок. Каждый компонент, созданный по prompt, — это новая поверхность для всех категорий дефектов. Удваиваете число приложений — удваиваете нагрузку на аудит. Утроили — утроили. Композитного преимущества нет. Каждая генерация начинается с нуля.

Для команды, которая выпускает один экспериментальный chatbot, такая цена приемлема. Для enterprise-программы, строящей десятки внутренних приложений в регулируемых бизнес-направлениях, она становится главной статьей расходов в жизненном цикле разработки — не в compute, а в часах разработчиков, потраченных на разбор неверного вывода, в QA-циклах, ловящих регрессии, и в инцидентах в продакшене, когда дефекты все же проходят.

Что если большая часть кода вообще не будет генерироваться?

Модель AI assembly исходит из другого предположения. Самый надежный код — это код, который вообще не генерировался по запросу.

Вместо того чтобы каждый раз просить large language model (LLM) написать компонент с нуля, assembly model сопоставляет намерение разработчика — выраженное через текстовый prompt, взаимодействие с visual canvas или импорт из Figma — с заранее созданным, протестированным и сертифицированным компонентом из enterprise library. Задача AI — не писать компонент. Задача AI — выбрать нужный компонент и сконфигурировать его.

Это важное архитектурное различие, а не маркетинговый ход. Модель assembly работает на трех уровнях генерации, у каждого из которых свой профиль риска.

1. Нулевая генерация: сопоставление компонента. Намерение разработчика сопоставляется с компонентной библиотекой. Если в библиотеке есть сертифицированный компонент, который решает задачу, он выбирается напрямую. Генерация кода вообще не запускается. Компонент уже поставляется с проверенными security posture, соблюдением accessibility, визуальной консистентностью и кроссплатформенной точностью. Использующее приложение наследует все это.
2. Минимальная генерация: конфигурация и связывание. AI настраивает выбранный компонент: задает свойства, подключает data connectors, привязывает пути навигации, добавляет authentication context. Это работа в пределах schema. Пространство конфигурации можно перечислить и проверить. Если AI неверно настраивает свойство относительно typed schema, это обнаруживаемая и исправимая ошибка — принципиально иная, чем выдуманная с нуля неверная реализация.
3. Точечная генерация: заполнение реальных пробелов. Собственная бизнес-логика, новые интеграции, компоненты, для которых в библиотеке нет аналога, — все это генерируется. Именно здесь AI code generation действительно полезна, и именно здесь нужны полные guardrails. Ключевое различие — в масштабе. Вместо того чтобы проверять все, вы проверяете только то, что реально было сгенерировано.

В этой модели guardrail — это не проверка, которая срабатывает после генерации. Это правило маршрутизации, которое отправляет намерение разработчика к готовому артефакту вместо generative model. Если в библиотеке есть ответ, генерация вообще не начинается. Если начинается, то только в рамках того пробела, который ее вызвал.

Что именно гарантируют заранее подготовленные компоненты

Модель assembly работает только в том случае, если компоненты в библиотеке — это действительно сертифицированные артефакты, а не просто переиспользуемые фрагменты. Качество должно быть свойством самого компонента, а не тем, что должен дополнительно проверять потребляющий его продукт. Значит, каждый компонент в enterprise library должен нести обязательные гарантии по нескольким направлениям.

• Визуальная консистентность. Design tokens, поведение в dark mode, responsive breakpoints и соответствие бренду проверяются на этапе сборки компонента. Любое приложение, собираемое из этих компонентов, наследует визуальную точность без отдельного visual regression для собранной части. Token drift — медленное расхождение с design system — для всего, что берется из библиотеки, устраняется.
• Безопасность. Каркас аутентификации, защита CSRF и соответствие OWASP являются структурными свойствами компонента. Нельзя собрать небезопасную версию безопасного компонента. Это более сильная гарантия, чем post-generation scanning, который может лишь сказать, внесла ли конкретная генерация уязвимость. Он не может предотвратить ее появление.
• Доступность. Соответствие WCAG AA проверяется один раз на этапе сборки компонента: контрастность, роли ARIA, управление фокусом, навигация с клавиатуры, совместимость со screen reader и поведение интерактивных элементов. Каждое приложение, использующее компонент, наследует результат. Это особенно важно, потому что дефекты accessibility в AI-сгенерированном коде чаще всего пропускаются при post-generation review и особенно дорого исправляются после релиза.
• Кроссплатформенная точность. Одна декларация компонента создает и протестированный web-артефакт, и протестированный mobile-артефакт. Платформенный паритет — это свойство компонента, а не повторяющаяся для каждого приложения нагрузка на тестирование. Для enterprise, который поддерживает параллельные web- и mobile-портфели, это само по себе может убрать заметную часть QA-цикла.

Back-end services: где architectural guardrails важнее всего

История с front-end компонентами убедительна, но более трудная и более рискованная проблема находится в back-end services. Слои persistence, API endpoints, security filters, service integrations — именно здесь в типичном enterprise-приложении генерируется больше всего кода, и именно здесь архитектурные ошибки наиболее опасны.

Модель AI assembly решает это, встраивая architectural guardrails в структурные свойства каждого сгенерированного сервиса — не как опциональные практики, которые разработчик должен помнить и соблюдать, а как invariants, которые принудительно обеспечивает платформа. Разница принципиальна. Паттерн, который разработчик может забыть применить, — это паттерн, который будут забывать, особенно под давлением скорости, которое создает AI-assisted development.

Шесть back-end guardrails особенно четко определяют разницу между кодом, который просто компилируется, и кодом, который может безопасно работать в регулируемом бизнесе.

1. Stateless, horizontally scalable services. Никакого session state на уровне приложения. Любой экземпляр может обслужить любой запрос. Масштабирование становится инфраструктурным решением — добавить экземпляры за load balancer, а не менять архитектуру приложения. Та же архитектура сервиса, которая обслуживает пилот на 50 пользователей, выдерживает production rollout на миллионы. Это следует принципу stateless processes из twelve-factor app methodology и означает, что разрыв между «прототипом» и «production» не требует архитектурной переписи.
2. Безопасный, кэшируемый и аудируемый доступ к данным. Вся работа с базой данных идет через сгенерированный persistence layer. В выводе платформы нет паттерна, который создает незащищенный, собранный вручную SQL-вызов — именно такие вызовы приводят к injection vulnerabilities, которые уже более десяти лет входят в OWASP Top 10. Часто используемые данные кэшируются единообразно между сервисами. Каждая операция записи автоматически получает audit trail: кто изменил что и когда. Для регулируемых отраслей это не удобство, а обязательное требование compliance, которое архитектура выполняет по умолчанию.
3. Secrets изолированы от кода. В сгенерированном коде сервиса нет учетных данных. API keys, пароли баз данных и encryption keys внедряются на этапе deployment из secure secrets vault и никогда не попадают в source control. Поворот ключа не требует изменения кода и повторного разворачивания бизнес-логики. Это принцип twelve-factor externalized config, сделанный структурным: не рекомендация из style guide, а свойство самой pipeline генерации кода.
4. Role-based access control на всем пути. Большинство платформ определяют правила доступа на уровне UI и оставляют back-end enforcement разработчикам. Модель assembly генерирует RBAC как единое непрерывное ограничение, проходящее через все слои. Пользователь видит в интерфейсе только то, что разрешает его роль. Его API calls проверяются по тому же определению роли до запуска бизнес-логики. Его запросы к данным фильтруются на уровне базы данных. Одно определение — везде. Без разрывов. Без расхождения между тем, какой доступ кажется у пользователя есть, и тем, какой доступ у него есть на самом деле.
5. API-bounded service contracts. Каждый сервис публикует typed, versioned API contract. Сервисы общаются через эти контракты, а не через общие хранилища данных или прямую связанность. Каждый сервис можно менять и разворачивать независимо, без скоординированных релизов по всему стеку. Именно так microservice architecture действительно работает на практике, а не превращается в distributed monolith, который многие команды случайно строят, когда границы сервисов не enforced платформой.
6. Безопасность, подтвержденная отраслевыми стандартами. Сгенерированные приложения тестируются на соответствие OWASP Top 10 и проверяются через dynamic application security testing в реальных условиях. Команды compliance получают независимо проверяемые доказательства security posture на каждом релизе — не утверждение разработчика, что best practices соблюдены, а проверяемые результаты тестов по известному стандарту.

По отдельности все это не ново. Twelve-factor apps, соответствие OWASP, externalized secrets, end-to-end RBAC — хорошо известные инженерные принципы. Новизна в том, чтобы сделать их структурными свойствами архитектуры генерации кода, а не пунктами в checklist. Когда guardrails становятся architectural invariants, они не зависят от дисциплины разработчика. Они не размываются под дедлайнами. Они не различаются от команды к команде.

О цене — честно

У модели AI assembly есть и компромиссы. У нее выше context overhead, чем у чисто generative подхода. Обучение системы схеме component library, привязкам design tokens и архитектурным ограничениям потребляет tokens еще до того, как появится первая полезная строка. Наивное сравнение стоимости одной сессии будет в пользу generate-first модели.

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

В generate-first модели каждый компонент полностью создается заново каждый раз. Каждая генерация тратит tokens на implementation code, который уже существует в тестированном виде где-то в библиотеке компонентов организации, если бы модель знала, что его нужно использовать. Циклы self-correction происходят часто, потому что вероятностный вывод регулярно промахивается с первого раза. И каждый сгенерированный компонент проходит полный audit cycle: security, accessibility, visual regression, functional testing.

В модели assembly код компонента уже существует. AI конфигурирует, а не конструирует. Это доля tokens. Это доля циклов self-correction. Это доля вывода, который нуждается в проверке. Контекстные затраты оплачиваются один раз за сессию. Экономия на генерации накапливается на каждом собранном компоненте. А затем еще раз — с каждым дополнительным приложением, построенным на той же библиотеке.

Но главное преимущество не в token economics. Оно в стоимости дефектов. Меньше часов разработчиков уходит на разбор неправильного AI-вывода. Меньше QA-циклов тратится на регрессии, которые generate-first модель производит стохастически. Меньше production incidents возникает, когда дефекты вообще проходят мимо guardrail-стека. Заранее подготовленный сертифицированный компонент поглощает эти затраты один раз — на этапе сборки. Каждое приложение, которое его использует, наследует выигрыш. Это накапливающаяся отдача от инвестиций в качество — противоположность линейному росту стоимости, характерному для схемы generate-then-check.

Сертифицировано конструкцией против проверено тестированием

Для компаний из регулируемых отраслей — финансовых услуг, здравоохранения, государственного сектора и страхования — последствия модели assembly для compliance заслуживают отдельного внимания.

Generate-first модель дает артефакт compliance, который по сути говорит: «Мы сгенерировали этот код, затем протестировали его, и тесты прошли». Это допустимая позиция. Но она хрупкая. Она зависит от полноты тестового набора, строгости процесса review и от предположения, что каждая генерация будет проверяться одинаково тщательно. Учитывая, что 29% AI-assisted кода уже сливается без проверки, это предположение заметно трещит.

Модель assembly дает другой артефакт: «Это приложение собрано из компонентов, которые были сертифицированы на этапе сборки по этим конкретным стандартам. Только сгенерированные custom-части потребовали runtime validation». Подход certified-by-construction сокращает compliance surface до действительно нового кода — бизнес-логики и интеграций, которые ни один компонент из библиотеки не может закрыть. Все остальное несет доказательства соответствия с собой, встроенные в историю сертификации компонента.

Это не теоретическая разница. Она меняет разговор с аудиторами, регуляторами и внутренним risk committee. Она переводит compliance из упражнения по тестированию каждого релиза в структурное свойство development platform. И она масштабируется: сотое приложение, построенное на сертифицированной библиотеке, несет ту же нагрузку compliance, что и первое, а не в сто раз большую.

Неприятный вывод

Дискуссия о генерации кода с помощью AI, как она сейчас сформулирована, задает неверный вопрос. «Как добавить лучшие guardrails к AI-сгенерированному коду?» — это вопрос, который принимает предпосылку «сначала сгенерируй все, потом проверь все». Он ведет к гонке вооружений между объемом генерации и validation tooling — гонке, в которой объем уже растет на 42% от всего кода и продолжает расти, а инструменты проверки постоянно отстают на одну категорию дефектов.

Модель AI assembly переформулирует вопрос. Не «как проверять эффективнее?», а «как генерировать меньше изначально?» Не «как ловить дефекты downstream?», а «как сделать дефекты структурно невозможными для собранной части приложения?»

Guardrails необходимы. Они останутся необходимыми для каждой строки кода, которую AI действительно генерирует. Речь не против guardrails. Речь против модели, в которой guardrails — это главный механизм качества для всего приложения, включая 70% или 80% его части, которые можно было бы собрать из сертифицированных элементов.

Команды, которые первыми это поймут, будут не просто быстрее выпускать продукты. Они будут выпускать их с профилем качества, который команды generate-first не смогут повторить без пропорционального наращивания инфраструктуры проверки — то есть без возврата большей части того прироста скорости, который AI-assisted development должен был дать.

—

New Tech Forum — это площадка, где технологические лидеры, включая вендоров и других внешних авторов, могут подробно обсуждать новые enterprise-технологии. Отбор материалов субъективен и основан на выборе тем, которые редакция считает важными и наиболее интересными для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь присланный контент. Все запросы направляйте на doug_dineley@foundryco.com.

Материал — перевод статьи с английского.

Оригинал: Stop checking AI-generated code. Start generating less of it