Я много лет занимаюсь клиентской веб-разработкой: создаю сайты с нуля, дорабатываю существующие, занимаюсь рефакторингом и технической поддержкой. Сейчас подавляющее большинство проектов разрабатываю на двух платформах — WordPress (+ WooCommerce) и Laravel (+ Filament). Они закрывают почти все задачи малого и среднего бизнеса — моей основной аудитории.
В работе активно использую ChatGPT и Codex. За это время я заметила повторяющиеся ошибки моделей и выработала способы их обходить.
Общие наблюдения
ChatGPT хорошо ориентируется в платформах и особенно полезен при исследовании чужого или давно забытого собственного кода. Локальные задачи — написать обработчик, добавить поле, изменить запрос — часто решает очень быстро.
При этом модель может нарушать подробно изложенные правила, плодить лишний код, придумывать незапрошенную функциональность и строить неправдоподобные гипотезы при диагностике. Важнее другое: она способна самостоятельно и достаточно успешно обнаруживать и исправлять собственные ошибки. На этом построена большая часть моей методики.
Я работаю и в обычном диалоге, и в агентном режиме Codex. В диалоге удобнее обсуждать решения и проверять каждый шаг. Codex самостоятельно исследует кодовую базу и меняет файлы — это полезно для задач, затрагивающих много компонентов. Однако агент чаще проявляет ненужную инициативу: правит соседний код и делает то, чего не просили. Когда изменения уже внесены в файлы, контролировать такую самодеятельность особенно важно.
Проблема № 1. Шаблонный контент
Первая генерация текстов в ChatGPT меня обычно не устраивает. При массовой подготовке товарных страниц повторяются конструкции и композиции, появляется канцелярит, нейрослоп, общие слова вместо конкретики. Даже подробные стилистические инструкции не спасают: модель соглашается с запретами и тут же их нарушает.
Моё решение — постоянная редакционная инструкция и несколько проходов. Инструкция включает два набора требований: как писать (язык, стиль, тон, структура, глубина, SEO) и как писать нельзя (запрещённые конструкции, повторы, канцелярит, выдуманные факты, шаблонные приёмы). Она должна сохраняться между итерациями.
Рабочая методика:
ChatGPT подготавливает промпт, факты и SEO-ключи.
DeepSeek пишет первую версию (он пишет живее).
Grok проводит независимый аудит.
ChatGPT исправляет текст по аудиту и исходной инструкции.
Следующий аудит вычищает оставшийся нейрослоп, канцелярит и повторы. При необходимости цикл повторяется.
Разные модели необязательны — ChatGPT способен проверить и собственный текст. Но независимая критика помогает. Разумеется, аудит ИИ не заменяет проверки фактов по источникам и не гарантирует уникальности.
Проблема № 2. Вёрстка не по макету и засорённый HTML/CSS
Здесь два вида проблем. Во-первых, модель интерпретирует макет вместо точного воспроизведения. Даже имея точные данные из Figma или макет в Photoshop, она обязательно искажает какие-то элементы, игнорируя прочитанные стили. Во-вторых, генерирует лишние div, одноразовые классы и повторяющиеся стили. Вместо gap у Grid или Flex может расставить отступы на дочерних элементах. Вместо существующего общего класса — придумать ещё один.
На аудите ChatGPT сам объясняет, почему всё это избыточно, и успешно чистит код.
Моё решение — не смешивать визуальный и технический аудит. Сначала даю макет и постоянные правила вёрстки: семантический HTML, минимум обёрток, переиспользование классов, отсутствие дублирующих CSS-правил. Затем:
Получаю первоначальную вёрстку.
Проверяю соответствие макету и исправляю расхождения (иногда несколькими проходами).
Только после этого проверяю качество HTML/CSS по инструкции и провожу рефакторинг.
Снова сверяю результат с макетом — чистка кода может испортить внешний вид.
Так проще контролировать результат: сначала добиваемся правильного внешнего вида, потом оптимизируем реализацию.
Проблема № 3. Нерациональная архитектура
Лучше всего ChatGPT работает именно с платформами. Но хорошее знание их API не гарантирует хорошего архитектурного выбора. Модель нередко идёт по знакомому паттерну, а не ищет необходимое и достаточное решение.
В WordPress это проявляется особенно наглядно: целые деревья templates и template-parts ради нескольких простых компонентов, лишние варианты шаблонов, fallback «на всякий случай». Иногда при отсутствии данных ИИ предлагает вывести демонстрационный контент — и этим маскирует реальную проблему настройки. Другая привычка — хардкодинг: зашитые ID, slug, значения полей и пути, которые должны приходить из настроек или данных WordPress. Всё работает до первой смены конфигурации.
На Laravel + Filament встречаются свои варианты избыточности: дополнительные классы и уровни абстракции, неоправданное усложнение связей. В проекте с несколькими сущностями важно не позволять модели создавать новые сервисы и связи просто потому, что так выглядит «солиднее».
Моё решение — архитектурный контроль до, в процессе и после реализации. Перед сложной задачей задаю ограничения: какие сущности нужны, где хранятся данные, какие файлы и механизмы платформы использовать. При необходимости сначала прошу план, без изменения кода.
По ходу разработки регулярно запускаю отдельный аудит по заданным правилам. Сначала получаю список замечаний и зависимостей, затем разрешаю рефакторинг и проверяю работоспособность. Иногда нужны повторные проходы.
Идеальной первой генерации ждать бессмысленно. Но периодическая очистка не даёт техническому мусору накопиться. Ошибку в модели данных лучше обнаруживать заранее: её исправление бывает значительно дороже удаления лишнего шаблона.
Проблема № 4. Самодеятельность
Это не то же самое, что избыточная архитектура. Иногда ИИ делает заказанную функциональность правильно — и одновременно добавляет то, чего никто не просил.
В Codex, по моим наблюдениям, такое встречается чаще. Агент может попутно отрефакторить соседний компонент, поменять работающий механизм или добавить обработчик, который кажется ему полезным. При этом незаметно оставить мусор от собственной гипотезы.
Моё решение — запрет на самостоятельное расширение задачи, подробный отчёт о произведённых изменениях и аудит результата. ИИ может предлагать улучшения, но не реализовывать их без согласования. Попутный рефакторинг без команды — под запретом.
Проблема № 5. Завиральные гипотезы при диагностике
Есть заметная разница между запросами «найди код, отвечающий за это поведение» и «почему всё сломалось?». Первый модель обычно выполняет хорошо. На второй иногда отвечает цепочкой убедительных, но неподтверждённых догадок. Агент на проверке этих гипотез способен уничтожить недельный лимит.
Моё решение — давать свои технические гипотезы прямо в запросе. Описываю, где ошибка проявляется, где нет, что менялось, какие причины считаю наиболее вероятными. Прошу исследовать код и проверить версии, а не сразу предлагать исправление.
Если моя гипотеза неверна, её нужно отклонить, а не натягивать факты на готовое объяснение. Когда своих версий нет, сначала прошу построить карту кода и зависимостей и лишь потом переходить к поиску причины.
Проблема № 6. «Готово» не значит «работает»
Модель может объявить задачу завершённой, потому что написала код или собрала архив. Но синтаксически правильный PHP ещё может вызвать критическую ошибку.
В одном Laravel-проекте модель сгенерировала слишком длинное имя индекса для MySQL — и миграция не выполнилась. В другом случае ошибка в Blade привела к сбою при открытии страницы.
Поэтому я различаю три состояния: код написан → прошёл доступные технические проверки → проверен в целевом окружении. Это не одно и то же.
Синтаксические проверки, анализ зависимостей, маршрутов, миграций, структуры ZIP и diff полезны, но не заменяют проверки реального поведения. После исправлений также нужен контроль регрессий. Даже если Codex сообщил об успешных тестах, важно понимать, какие проверки он действительно выполнил.
Проблема № 7. ИИ плохо придумывает оригинальный дизайн
Это единственная проблема из перечисленных, для которой я пока не нашла удовлетворительного технического решения.
По подробному описанию ChatGPT может помочь создать хорошее изображение: если задать композицию, ракурс, свет, окружение, стиль и расположение объектов. Правда, иногда он зачем-то дорисовывает лишнее. А вот самостоятельные визуальные концепции сайта в моей практике чаще всего вторичны: знакомые сетки, стандартные карточки, предсказуемые композиции.
Поэтому художественную концепцию я разрабатываю сама, а ИИ использую для реализации и проработки деталей.
Зато ChatGPT полезен как критик готового дизайна. Он замечает проблемы визуальной иерархии, ритма, пропорций и акцентов, которые я могу упустить. Не все замечания стоит принимать: иногда модель пытается «исправить» сознательное решение и сделать композицию банальнее. Я выбираю полезные рекомендации, вношу точечные правки и при необходимости повторяю проверку.
Вместо заключения
Постоянные инструкции с правилами и запретами сами по себе не гарантируют нужную генерацию. Но отдельные аудиты по разным критериям, последовательные исправления и жёсткий контроль того, что ИИ вообще имел право менять, позволяют получать приемлемый результат. Можно запрограммировать процедуру и ценой большего количества токенов получать результат, соответствующий критериям качества.
Это не отменяет человеческих решений. Архитектуру, художественную концепцию, границы задания и приёмку результата контролирует разработчик. Зато значительную часть создания, исследования и даже проверки кода можно передать ИИ.
Они снимают огромный объём ручной работы и позволяют решать задачи, которые раньше просто не хотелось делать из-за объёма. При этом часть времени теперь уходит на формулирование требований, аудит, исправления и проверку регрессий.
Главный навык теперь не умение написать «волшебный» промпт, а способность организовать разработку так, чтобы сильные стороны ИИ работали на результат, а типичные ошибки вовремя обнаруживались и исправлялись.