ИИ в веб-разработке: правильный уровень решения важнее качества кода

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

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

Первый разобранный случай — импорт товаров из Excel для сайта кондиционеров. Файл поставщика содержал запутанные связи: какие блоки продаются отдельно, какие только комплектом, как от этого считается цена. Клиент сам не мог чётко объяснить структуру данных. Стандартный подход — попросить ИИ написать компонент импорта — давал черновик, который потом приходилось многократно уточнять. Команда изменила порядок: сначала провела встречу с клиентом, записала разговор и использовала ИИ для разбора этой записи вместе с таблицей. Инструмент помог вытащить требования, сопоставить их со структурой файла и собрать схему импорта. Только после этого был сгенерирован код компонента — и разработчик уже проверял его против понятного технического задания, а не против «мутного файла».

Второй случай — мобильное меню на MODX с библиотекой Mmenu Light. Несколько родительских пунктов должны были быть заголовками групп, а не ссылками. ИИ предложил два варианта: сделать пункты некликабельными через JavaScript или создать полноценные страницы-разделы вроде /catalog/ и /services/ с описаниями и дочерними ссылками. Второй вариант звучал убедительно с точки зрения SEO и UX. Но это было решение другой задачи. В pdoMenu правильная разметка формируется через шаблон вывода пункта меню — штатный механизм, без JavaScript и без новых страниц. Когда разработчик указал ИИ правильное направление, тот за несколько секунд нашёл нужную документацию и сделал корректную правку. Проблема была не в возможностях инструмента, а в том, что без знания экосистемы легко принять первый прилично выглядящий вариант.

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

Авторы материала формулируют это как смену приоритета: «работает ли этот код» перестало быть первым вопросом. Первый — «на том ли уровне решается задача». ИИ ускоряет получение первого варианта, черновика, гипотезы. Но дальше начинается обычная разработческая работа: понять, можно ли это оставлять в проекте, нужно ли переписать, встроить в существующую логику или просто выбросить. Квалификация разработчика в такой момент проявляется не в объёме написанного кода, а в умении сказать: «нет, это не берём, здесь уже есть нормальный механизм».