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

Мы используем ИИ в веб‑разработке как рабочий инструмент и заметили повторяющуюся проблему: он не всегда ошибается в коде. Чаще ошибка появляется раньше, в выборе места, где вообще надо решать задачу.

На трех примерах из практики, импорт товаров из Excel, мобильное меню на MODX и компонент для Schema.org‑разметки, я показываю, почему рабочий ответ ИИ еще не значит, что его стоит брать в проект.

Ускорение есть. С этим спорить странно. Но чем дольше мы с ним работаем, тем чаще упираемся в одну и ту же вещь. Код может быть аккуратным, рабочим, даже вполне логичным. Проблема бывает раньше, в выборе места, где вообще надо решать задачу.

Проблему шаблона он может пытаться решить через JavaScript. Проблему структуры данных — локальной правкой в компоненте. Проблему плохо описанных требований решить сразу генерацией кода. Формально может заработать. Но в проекте появляется лишний слой, скрытая зависимость или решение, которое держится только на одном конкретном сценарии.

Поэтому вопрос «работает ли этот код» для нас теперь не первый. Сначала приходится спрашивать другое, где должна решаться задача? В требованиях, в структуре данных, в настройке компонента, в шаблоне, на бэкенде, на фронтенде или вообще не в коде?

Первый вариант — это не решение

ИИ чаще всего ускоряет не готовое решение, а первый вариант. Черновик, заготовку, гипотезу. Что‑то, что выглядит рабочим и иногда действительно работает. А дальше начинается обычная разработческая работа. Понять, можно ли это оставлять в проекте, нужно ли переписать, сократить, встроить в существующую логику или просто выбросить.

Сайт это не набор отдельных фрагментов. У него есть CMS, структура данных, шаблоны, старые доработки, связи между разделами, странные решения прошлых лет, ограничения клиента и логика, которую не всегда видно снаружи. ИИ может быстро предложить код, но он не знает, почему конкретный сайт устроен именно так.

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

Когда ИИ оказался на своем месте

Была задача загрузить товары на сайт из Excel‑файла поставщика. На словах все просто: есть файл, есть товары, надо сделать импорт. Обычная история.

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

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

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

ИИ помог вытащить из разговора требования, сопоставить их со структурой Excel‑файла и собрать более‑менее понятную схему импорта. После этого он сгенерировал код компонента. Не магически сделал все за нас, а дал рабочую основу. Разработчик потом проверил логику, прогнал импорт на реальных данных, сверил товары, комплекты, фотографии и связи, исправил ошибки и только после этого пустил компонент в продакшн.

Тут ИИ был на своем месте. Сначала он помог подняться с уровня «непонятная таблица и Незнаю‑Что‑Хочу клиент» до уровня техзадания, а уже потом дал код. Не утверждаю, что это универсальный рецепт для любого импорта. Где‑то таблица простая, где‑то клиент сразу знает структуру, где‑то проще написать руками. Но в этом случае ИИ сработал хорошо именно потому, что мы не начали с кода. Сначала разобрались, что вообще надо сделать.

Когда ИИ чинит не там

Другой пример, с мобильным меню. На проекте использовался MODX, меню собиралось через pdoMenu, для мобильной версии стояла библиотека Mmenu Light. Несколько родительских пунктов должны были быть просто заголовком группы вложенных пунктов. Не ссылкой. Они вообще не должны были никуда вести.

ИИ увидел проблему и предложил варианты. Один был близко к смыслу, сделать такие пункты некликабельными, чтобы они оставались только раскрывающимися разделами. Второй выглядел солиднее, создать полноценные страницы‑разделы вроде /ratings/, /catalog/, /events/, /services/, дать им описания и ссылки на дочерние страницы. С точки зрения пользователя и SEO звучит аккуратно. Не 404, не пустой переход, нормальная страница раздела.

Только это было решение другой задачи. Нам не нужны были новые страницы. Не нужно было менять структуру сайта. Нужно было правильно вывести родительский пункт в меню. В pdoMenu такая история решается штатно, через шаблон вывода пункта меню. Не надо городить JavaScript поверх готового HTML, не надо создавать служебные страницы, не надо менять информационную архитектуру. Нужно сразу сформировать правильную разметку: родительский пункт вывести как некликабельный элемент с нужным классом.

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

Здесь важна не сама CMS и не конкретно pdoMenu. В другом инструменте названия будут другие, но ситуация та же, ИИ уходит чинить результат после рендера или предлагает менять структуру сайта, а правильнее просто сформировать нужный результат сразу. Квалификация разработчика в такой момент проявляется не в том, чтобы написать больше кода руками, а в том, чтобы сказать: «нет, это не берем, здесь уже есть нормальный механизм».

Работает — не значит годится

У ИИ есть неприятное свойство, он почти всегда что‑то предлагает. Это удобно, но из‑за этого легко обмануться. Раньше, если ответа нет, приходится остановиться и подумать. Теперь ответ появляется сразу, он аккуратный, уверенный, с комментариями, иногда даже с правильным кодом. И кажется, ну все, задача закрыта.

Но в разработке «работает» — это низкая планка. Работает где? На каких данных? В какой CMS? В каком шаблоне? До первой доработки? До переноса на другой сайт? До момента, когда другой разработчик откроет этот код и попробует понять, что здесь происходит?

ИИ хорошо отвечает на вопрос «как можно сделать». Но этого мало. Нам все равно нужно ответить на другой вопрос: «где это должно быть сделано». В настройке? В шаблоне? В структуре данных? В бизнес‑логике? В интерфейсе? Иногда правильный ответ вообще не в коде, а в том, что надо вернуться к требованиям.

Если этот вопрос пропустить, можно получить рабочий код, который решает не ту задачу. Или ту, но слишком дорогим способом.

Контекст не живет сам по себе

ИИ хорошо помогает в локальных задачах. Но сайт почти никогда не локальная задача. У него есть история, структура данных, старые компоненты, нестандартные поля, решения, которые выглядят странно, но держатся на конкретном бизнес‑процессе клиента. Есть имена классов, шаблоны, договоренности и ограничения, которые нельзя просто взять и заменить.

ИИ этого не знает, если ему это не дать. А если дать, он все равно может потерять часть контекста в длинной переписке или при переходе между чатами. У нас были ситуации, когда задача расползалась по нескольким обсуждениям, и в какой‑то момент ИИ начинал вести себя так, будто впервые видит проект. Предлагал другие имена классов, забывал уже принятые решения, менял подход там, где менять его нельзя. Формально он продолжал помогать. По факту проектная память разваливалась. В такие моменты лучше не мучить промпт до бесконечности, а заново собрать контекст…

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

Компонент, который оказался одноразовым

Еще один случай хорошо показывает разницу между «заработало» и «можно сопровождать». Коллега писал компонент для вывода Schema.org‑разметки на страницах сайта. Проект тоже был на MODX. На первом сайте все выглядело нормально. Данные выводились, разметка формировалась, задача считалась закрытой. По внешним признакам все было хорошо.

Проблема началась позже, когда компонент попытались перенести на другой сайт. Оказалось, что он слишком привязан к исходному проекту. Внутри были зашиты ID шаблонов, ID страниц, названия TV‑полей и логика, которая работала только при такой структуре. На втором сайте шаблоны другие, страницы другие, поля названы иначе.

Это была не ошибка на полчаса. Компонент оказался решением для одного конкретного сайта. Его нельзя было нормально адаптировать. От него пришлось отказаться и делать новое решение по другим принципам.

Здесь опять вопрос не только в качестве кода. ИИ помог получить рабочий результат в одном контексте, но решение было принято на слишком низком уровне обобщения. Получился компонент для одного сайта, хотя дальше от него фактически ждали большего. Он не спросил, а нужен ли этот компонент только здесь или потом его будут использовать еще где‑то? Какие зависимости нельзя зашивать внутрь? Что надо вынести в настройки? Где граница между разовой доработкой и нормальным компонентом?

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

Как мы теперь проверяем ответы ИИ

Мы не относимся к коду от ИИ как к готовому решению, которое можно просто скопировать. Но и не относимся к нему как к мусору, который надо сразу переписать. Это черновик от очень быстрого помощника. Иногда хороший черновик. Иногда странный. Иногда такой, который лучше выбросить сразу. После таких случаев у нас появился простой фильтр. Сначала спрашиваем «не работает?», а «это ли вообще там решается». Не правильно ли написан код, не красивый ли он, не сколько он сэкономил времени. Сначала «он в нужном месте написан»?

Если проблема в настройке компонента, не должен появляться JavaScript‑костыль. Если проблема в требованиях, не надо сразу генерировать код. Если компонент потенциально должен переноситься, нельзя зашивать внутрь структуру одного сайта.

Начинать полезно именно с уровня решения, потому что ошибка на этом этапе потом маскируется рабочим кодом. Мы сами не сразу стали так проверять AI‑код. Сначала тоже больше смотрели на результат. Вывелось, загрузилось, не упало. Но после нескольких таких случаев стало понятно, что этого мало. Рабочий ответ ИИ иногда надо останавливать не потому, что он не работает, а потому что он работает не там.

ИИ не снижает требования к разработчику

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

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

Вместо вывода

ИИ уже изменил веб‑разработку. Не потому, что заменил разработчика, а потому, что резко удешевил первый технический вариант. Теперь можно быстрее получить код, структуру, гипотезу, разбор данных или черновик компонента. Это полезно. Мы этим пользуемся. Но главная работа никуда не делась. Понять, что именно мы получили и можно ли это оставлять в проекте. И еще точнее, понять, на каком уровне вообще должна решаться задача.

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

Черновик стал дешевле. Понимание уровня решения — дороже.