Почему код, написанный ИИ, всё ещё нуждается в проверке

Идея простая: отдать ИИ рутинную часть работы и получить готовый код быстрее. Google попыталась воплотить её в жизнь с помощью Modern Web Guidance — набора рекомендаций, который должен был научить модели создавать доступные, быстрые и безопасные веб-приложения.

Получилось не совсем то, что планировали.

Доступность нельзя добавить потом

Если проект не учитывает доступность с самого начала, он не готов к запуску. Это не финальная шлифовка — это основа архитектуры.

В одном из примеров Google попросила создать аккордеон со статистикой и плавной анимацией. Задача выглядела элементарной, но сгенерированный код не работал в Firefox и не соответствовал стандартам WCAG AA. При этом MWG прямо обещала учитывать «прогрессивное улучшение» и поддержку базовых браузеров. Модель просто проигнорировала собственные инструкции.

Это не случайная ошибка. Так устроены большие языковые модели.

Модели не обязаны следовать правилам

В документации MWG прямо указано: даже если все инструкции прописаны идеально, нет никакой гарантии, что модель их применит. LLMs работают недетерминировано — они не обязаны использовать предоставленные рекомендации.

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

Разрозненные паттерны усложняют задачу

MWG запустили с неполным набором компонентов. Например, для всплывающих уведомлений не было отдельной инструкции — хотя Google сама раньше сталкивалась с проблемами доступности в таких элементах. Когда разработчик просит создать toast, модель вынуждена собирать общие рекомендации по кусочкам.

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

Сейчас такого единства нет.

Что это значит для ваших проектов

Если вы используете ИИ для генерации production-кода, важно понимать:

• Модель — это помощник, а не QA-инженер. Каждый сгенерированный участок требует проверки.
• Доступность (WCAG AA) критична для большинства коммерческих проектов.
• Кроссбраузерность нужно тестировать вручную — обещания «базовой поддержки» не заменяют реальные проверки.
• Безопасность и производительность тоже остаются зоной ответственности разработчика.

Как двигаться дальше

Это не значит, что ИИ бесполезен. Просто нужно изменить подход:

1. Проверять сгенерированный код так же тщательно, как код коллеги.
2. Фиксировать ошибки доступности и возвращать их в модель для дообучения.
3. Требовать от инструментов честных предупреждений о недетерминированности.
4. Встраивать автоматические тесты доступности (axe, WAVE, Lighthouse) в CI/CD.

В NameOcean мы активно используем ИИ для ускорения разработки — для черновиков, boilerplate и поиска идей. Но финальное решение и ответственность за код остаются за человеком.

В эпоху ИИ-генерации главное умение — не писать код, а проверять его, исправлять и гарантировать качество. Это по-прежнему требует человеческого участия. Modern Web Guidance — полезная инициатива, но инструкции без механизма принуждения остаются просто советами. А модели пока плохо их слушают.

Поэтому относитесь к коду от ИИ как к первой версии. Финальная — всё ещё за вами.