Как я работал с AI над своим сайтом: от контекста до доработок

Вступление

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

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

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

Почему я вообще решил работать с ИИ над своим сайтом

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

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

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

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

Почему просто давать задачи ИИ оказалось недостаточно

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

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

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

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

Почему я решил сначала собрать для ИИ рабочую среду внутри проекта

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

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

Для этого я собрал несколько опорных слоев внутри проекта. В AGENTS.md были описаны правила поведения самого ИИ-агента: как он должен себя вести перед началом работы, что ему нельзя делать без необходимости, как не ломать архитектуру и как двигаться по задаче аккуратно. В DEVELOPMENT_RULES.md я зафиксировал инженерные стандарты, чтобы у агента была не только задача, но и понятный уровень требований к исполнению. Отдельно в папке docs были собраны видение проекта, архитектура и дорожная карта, чтобы у него была не только тактическая, но и общая картина.

Фрагмент AI-framework внутри проекта: правила, роли и структура работы агента

Кроме этого, я добавил протокол выполнения задач: от чтения задачи до проверки результата и предложения следующего шага. Появились шаблоны задач и архитектурных решений, а также режимы работы — design, engineer, architect, seo, debug. Для каждого режима была своя зона ответственности, чтобы ИИ не пытался одинаково смотреть на все задачи сразу. И только после этого взаимодействие с агентом стало выглядеть не как хаотичный диалог, а как более управляемая работа внутри понятной рамки.

Какие ограничения я задал ИИ и почему это не мешало, а помогало

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

Например, агенту нельзя было просто так менять существующий код проекта. Разрешалось только создавать заранее определенные файлы и заполнять их содержимым. Это сразу сужало пространство для случайных действий и уменьшало риск, что под видом полезной доработки он начнет переписывать то, что уже работает. Для меня это было принципиально: в реальном проекте любое лишнее изменение — это не творчество, а потенциальный источник новых проблем.

Кроме этого, были и другие рамки: не трогать секреты, не устанавливать пакеты без разрешения, не затрагивать лишние файлы, сохранять текущее поведение проекта, двигаться маленькими шагами. Отдельно был зафиксирован приоритет performance и SEO, чтобы агент не предлагал решения, которые выглядят рабочими только на первый взгляд, но потом бьют по качеству сайта в целом.

Именно здесь я сильнее всего почувствовал, что ограничения не мешают ИИ, а делают его полезнее. Без них он мог бы, например, в рамках одного аудита полезть не только в анализ, но и в переписывание логики, структуры или кода — просто потому, что ему так показалось уместным. С ограничениями работа становилась заметно спокойнее: агент не пытался “спасти” проект целиком, а работал в пределах той зоны, которую ему действительно задали.

Как выглядел реальный цикл работы с ИИ

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

Обычно все начиналось с того, что я формулировал задачу в ChatGPT. Не всегда это получалось сразу. Часто первая версия запроса была слишком общей, и нормальный промпт для работы удавалось собрать со второй, третьей или даже четвертой попытки. Уже на этом этапе стало понятно, что хороший результат редко начинается с первого запроса: постановка задачи сама по себе стала частью работы.

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

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

Схема рабочего цикла: от постановки задачи до проверки и выкладки изменений

И только после такой проверки изменения шли дальше по обычной цепочке работы над проектом: через локальный коммит, push в GitHub, доставку на VPS и обновление продакшна. Для меня это тоже было важной частью процесса. Я не хотел, чтобы работа с ИИ существовала отдельно от проекта как что-то полуэкспериментальное. Мне было важно встроить ее в нормальную цепочку разработки, где результат не только генерируется, но и проходит проверку, фиксацию и аккуратную доставку в продакшн.

Где ИИ действительно ускорял работу

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

Хорошо ИИ помогал в аудитах сайта — и в технических, и в SEO-задачах. Когда после серии доработок нужно было посмотреть на проект более широко, проверить, не осталось ли неиспользуемого кода, не накопились ли слабые места в структуре, не появились ли вещи, которые со временем начинают мешать, здесь ИИ был полезен. Он помогал быстрее увидеть, где накопились слабые места и что стоит проверить вручную уже более внимательно.

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

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

Где ИИ давал слабый или сырой результат

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

Лучше всего это было видно на задачах, где не хватало деталей. Если промпт был обобщенным, без конкретики, без скринов и точного описания поведения интерфейса, агент давал сырой вариант. Он мог сделать что-то внешне похожее на ожидаемый результат, но в таких случаях быстро становилось заметно, что решение не держится на нюансах. А именно нюансы в интерфейсе и визуале часто решают, выглядит страница собранной или нет.

Хороший пример здесь — работа над страницей блога. На первый взгляд задача была описана подробно: были заданы расположения элементов, общая структура, основные блоки. Но этого оказалось недостаточно. Слабым местом стал визуал. Выяснилось, что для таких задач мало описать, что где должно находиться. Нужно идти гораздо глубже: задавать расстояния между элементами, описывать поведение на планшетах и мобильных разрешениях, продумывать динамику отступов, изменение размеров текста и заголовков на каждом устройстве. Без этого ИИ заполняет пробелы слишком усредненно, и результат получается технически собранным, но визуально слабым.

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

Почему для ИИ важны не только промпты, но и разделение контекстов

В какой-то момент я понял, что проблема не только в качестве формулировки, но и в том, в каком контексте решается задача. Даже хороший промпт начинает работать хуже, если внутри одного и того же диалога смешиваются разные направления: дизайн, SEO, архитектура, отладка, интерфейсные правки. Для человека это еще может выглядеть как единый поток работы, но для ИИ такая смесь часто размывает фокус.

На практике это ощущалось довольно просто: когда в одном чате начинали наслаиваться задачи из разных областей, агент хуже держал приоритеты. Он мог отвечать вроде бы по теме, но уже не так точно попадал в нужный тип мышления. Где-то начинал слишком инженерно смотреть на визуальную задачу, где-то, наоборот, давал слишком общие рекомендации там, где нужен был технический разбор. В итоге результат получался менее собранным, даже если сама задача по отдельности была понятной.

Именно поэтому режимы вроде design, engineer, architect, seo и debug для меня были не декоративной надстройкой. Они помогали разделять контексты и заранее задавать, в какой роли агент должен смотреть на конкретную задачу. Это снижало шум, делало решения более точными и уменьшало количество ситуаций, когда ИИ пытается одновременно быть всем сразу.

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

Что в этой работе все равно оставалось на мне

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

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

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

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

Что я в итоге понял про работу с ИИ над сайтом

Главный вывод для меня оказался довольно простым, но важным: ИИ начинает быть полезным не тогда, когда от него ждут магии, а тогда, когда его встраивают в нормальный рабочий процесс. Сам по себе он не дает качества. Качество появляется там, где есть контекст, ограничения, понятная постановка задач, проверка результата и готовность несколько раз возвращаться к доработке, если это нужно.

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

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

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