Вайбкодинг сайта: от макета до блога «Как подобает»

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

Формулировка получилась вполне в духе нашего эксперимента:

«сделай главную страницу сайта личного блога по этому макету, на будущее имей в виду, что будем делать цмс под него»

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

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

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

«так, и уже есть админка?»

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

Меня такой вариант не устраивал. Какой смысл менять WordPress на новую конструкцию, если потом любое движение придется согласовывать с нейронкой? Я как раз хотел обратного: чтобы содержание сайта было полностью в моих руках, а искусственный интеллект приходилось звать только тогда, когда захочется добавить новую функцию или что-то существенно переделать. Поэтому я попросил перестать изображать CMS и сделать ее рабочей.

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

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

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

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

«логтип превратился в какой-то цветочек»

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

Особенно жалко было осьминога. У персонажа очень выразительная физиономия, и когда система самовольно обрезает ему глаза, весь смысл иллюстрации несколько теряется. Вот это я и пытался исправить, а не просто «добавить функцию кропа» ради очередной галочки.

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

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

«все равно кропается некорректно»

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

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

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

Когда локальная версия уже стала похожа на полноценный блог, пришло время самого неприятного для меня этапа — поставить ее на основной домен вместо старого WordPress. Здесь мои знания довольно резко заканчивались. С WordPress все было элементарно: зашел в Beget, выбрал установку из панели, поставил тему и наполнил сайт. А с собственным проектом непонятных вопросов оказалось гораздо больше. Где он должен лежать? Что делать с базой? Как не потерять старые статьи? Куда, черт возьми, нажимать, чтобы ничего не снести?

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

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

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

«так ты забыл что я чайник, какой павер шелл, какой терминал, как туда попасть че писать»

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

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

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

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

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

«мда, а админка-то не работает. Новые секции не сохраняются. Изменения в текстах не сохраняются.»

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

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

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

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

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

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

После запуска я, конечно, не перестал менять сайт. В какой-то момент заметил, что пункты «Статьи» и «Кейсы» не очень удачно описывают содержимое. Решил оставить более понятные «Блог» и «Статьи», а вместе с названиями обновить и адреса разделов. Правда, по дороге сам допустил опечатку в английском слове articles, и пришлось просить чат исправить ее за мной. Вообще, занятное наблюдение: нейросеть иногда настолько исполнительна, что может очень старательно реализовать даже глупость, которую ты ей продиктовал. Поэтому контроль качества нужен не только за кодом, но и за собственными желаниями.

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

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

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

Знаю, это может звучать как бесконечная история про то, что все сломано. На самом деле наоборот: возможность быстро поправить то, что раздражает, и есть для меня одно из главных достоинств вайбкодинга. Раньше я бы, скорее всего, смирился с неудобным поведением готовой темы. Теперь могу объяснить, чего хочу, получить новую версию и проверить ее. Другое дело, что «получить новую версию» и «получить исправленную проблему», как мы уже выяснили на судьбе осьминожьих глаз, не всегда одно и то же.

Если сравнить стартовую точку и то, к чему я пришел, разница довольно забавная. Я начинал с картинки главной страницы и мысли «интересно, сможет ли нейронка сделать мне что-то подобное?». В итоге у меня появился сайт на собственном домене, куда можно зайти в качестве редактора, создать статью, подобрать рубрику, добавить изображения, изменить меню и выпустить материал так, чтобы его увидели другие люди. Старый WordPress я перед этим сохранил, а по дороге узнал много нового о резервных копиях, доменах, авторизации и том, как обманчиво выглядит зеленая надпись «Сохранено».

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

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

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