Всем привет, меня зовут Паша и я Head of QA. Ну… был им до недавнего времени. Мы оказались в банальной ситуации: проект пришлось приостановить по независящим от нас причинам — и я снова оказался «в поиске интересных возможностей».
И опять упёрся в саму парадигму найма. Бесконечная война соискателей и рекрутеров: одни не могут нормально рассказать, что умеют, вторые не знают, кого искать. В итоге ищут не человека, а функцию — и важно не то, как ты думаешь, а какие теги у тебя есть, чтобы пройти фильтры ATS. Эта парадигма ломает саму суть задачи найма.
Я решил, что мне не нужно резюме, заточенное под роботов. Мне нужна визитка, которая честно отвечает на вопрос: кто я и чем реально могу быть полезен компании.
Так появилась идея сделать собственный сайт. Не классическое резюме и не список технологий, а персональную визитку, более ориентированную на техлидов и C-level, чем на эйчаров и автоматические фильтры. Сам сайт я хотел сделать нескучным и изначально видел в голове в стилистике окна персонажа из Fallout 2 — с атрибутами, самооценкой скиллов, перками, и ироничным описанием.
И я осознаю: сам, без ИИ, я бы за это никогда не взялся. У меня поверхностное знание фронтенда, я не дизайнер и не веб-разработчик. Но у меня есть опыт производства IT-продуктов в целом — и мне стало интересно проверить вайбкодинг на практике.
Этот сайт бы не существовал без ИИ. И при этом почти на каждом этапе ИИ мешал мне сделать его так, как я хотел.
Если хотите — вот сайт: pavel.rocks (для полного погружения лучше смотреть с десктопа, под мобилу я постарался адаптировать на современный лад).
А под катом — подробный рассказ о процессе: как я к этому подошёл, на какие грабли наступал, почему мобильный адаптив оказался сложнее, чем весь остальной сайт, и при чём здесь дихотомИИя. Ну или просто заходите, если вы любите Fallout 2 так же как я.

Загрузка квеста…
«Мир за пределами убежища оказался не таким, каким вы его представляли»
В этой статье я расскажу о процессе создания сайта-визитки с нуля — с учётом моего бэкграунда в QA и всего лишь поверхностного знания фронтенда. Это не история успеха и не туториал «как сделать красиво». Скорее рассказ о том, как я лез туда, где раньше был только со стороны качества, и регулярно наступал на грабли, о существовании которых даже не задумывался (но о которых стопудово знает любой фронтенд разработчик).
Процесс оказался далеко не линейным. Было несколько этапов, и каждый из них по-своему вызвал у меня разные эмоции:
от генерации и подготовки визуала в стиле Fallout 2,
к первым попыткам собрать всё это в коде,
к болезненному переосмыслению архитектуры,
к мобильному адаптиву, который внезапно занял больше времени, чем весь остальной сайт,
и к финальным приключениям с доменами, хостингом и реальными девайсами.
По ходу этого пути я много раз ловил себя на противоречивых чувствах. С одной стороны — без ИИ этого сайта бы просто не было. С другой — почти на каждом этапе ИИ приходилось останавливать, переделывать за ним и принимать решения самому. Где-то он ускорял, где-то мешал, а где-то создавал иллюзию, что всё уже почти готово, хотя на самом деле нет.
Это статья про вайбкодинг на практике, а не в презентациях. Про то, где он реально помогает, где ломается, и почему пока ещё роботы не заменяет человека, особенно если у этого человека есть профдеформация на тему качества. И да — в конце будут выводы, но я к ним приду не из теории, а из собственного опыта.
Выход из убежища
«Они спросили меня, насколько хорошо я разбираюсь в теоретической физике. Я сказал, что у меня теоретическая степень по физике. Они сказали: “Добро пожаловать на борт!”»
Я начал с самого очевидного — с визуала. Мне было важно понять, жизнеспособна ли эта идея у меня в голове, или это очередная фантазия, которая развалится при первом столкновении с реальностью. Поэтому я сделал максимально простой шаг: попросил ChatGPT нарисовать первичный набросок того, как может выглядеть частичка сайта в стилистике Fallout 2.

Результат оказался неожиданно хорошим. Настолько, что я почти сразу купил подписку и стартанул уже на серьезных щщах. Я запустил самый длинный тред в своей жизни, в котором мы начали постепенно допиливать детали. Панель с именем, окно атрибутов, стилистика интерфейса, общая атмосфера — всё это начало складываться в цельную картину, и в какой-то момент я уже видел сайт почти целиком.
Именно на этом этапе появилась та самая эйфория: ощущение, что «да тут всё понятно», «ещё немного — и готово», «ну сейчас-то точно ИИ всё вытянет». Спойлер — нет.
В процессе я довольно быстро понял, что генерировать «весь сайт сразу» — плохая идея. Чем выше уровень абстракции картинки, тем хуже ИИ понимает, что именно ты хочешь куда подвинуть и как это должно работать вместе. Для него это просто красивая картинка, а не набор будущих компонентов.
В итоге я пришёл к более приземлённому подходу: перестал пытаться собрать целиковый драфт и сразу начал думать в сторону витрины компонентов. Отдельные подложки, панели, кнопки, иконки, декоративные элементы — всё по частям. Да, это уже не выглядело как «вау, готовый сайт», но зато начинало хоть как-то ложиться в реальность.
Помните я говорил про «самый длинный тред в жизни»? Так вот во время подготовки статьи случился очередной неприятный сюрприз. Я уже предвкушал как поделюсь с вами теми самыми первыми наработками дизайна, но в какой-то момент весь тред с генерациями просто исчез. Полностью. Без предупреждений, без возможности восстановления. Как оказалось позже — это плохо задокументированная особенность: при достижении лимита сообщений тред просто удаляется, даже в платной версии. В результате от всех первичных набросков не осталось почти ничего — только итоговый результат и воспоминания и только та самая первая картинка, которой я поделился с друзьями в чате.
С одной стороны, было обидно. С другой — это оказалось довольно символично: всё, что «просто красиво» и не зафиксировано в проекте, исчезает без следа. Ну а дальше по созданию сайта это стала уже не игра в картинки, а полноценный проект со всеми вытекающими — решениями, компромиссами и ошибками.

Случайная встреча в Пустоши: генерация картинок
«Не слушай его. Этот монстр скажет что угодно, лишь бы тебя убедить!»
На этом этапе у меня в голове уже была почти цельная картинка сайта. И логика казалась очевидной: если ИИ может генерировать отдельные элементы и даже объяснять принципы интерфейсов, значит он сможет помочь собрать визуальный драфт целиком — так, чтобы расставить всё по местам и уже от общего двигаться к частному.
Но здесь я столкнулся с проблемой. Чем более абстрактной становилась картинка, тем хуже ИИ понимал, что именно я хочу куда подвинуть и как это вообще должно работать вместе. Для него это всё ещё была просто красивая сцена, а не будущий интерфейс с ограничениями, размерами и зависимостями. Каждый новый запрос приводил к новой версии картинки — с другими углами, пропорциями и деталями, которые невозможно было нормально переиспользовать.
Как я уже говорил, я пришел к выводу собрать витрину элементов, из которых этот дизайн можно собрать: подложки, панели, кнопки, иконки, декоративные элементы.
ChatGPT, кстати, прекрасно знал, как правильно. В какой-то момент он даже предложил использовать подход с Slice-9 и очень красиво описал, почему это хорошая идея: углы отдельно, центр отдельно, всё масштабируется, всё гибко.
┌──────┬────────┬──────┐
│ TL │ TOP │ TR │
├──────┼────────┼──────┤
│ LEFT │ CENTER │ RIGHT│
├──────┼────────┼──────┤
│ BL │ BOTTOM │ BR │
└──────┴────────┴──────┘… и объяснил, как его заиспользовать:
.panel {
border: 32px solid transparent;
border-image: url("/panel.png") 32 stretch;
}Проблема была в том, что на практике он упорно продолжал генерировать цельные картинки, и каждый раз разные. С разными углами, тенями и рамками. Теоретически — всё правильно. Практически — использовать это в проекте было почти невозможно.
Поскольку дизайнера у меня под рукой не было, а мои навыки работы с Figma оставляют желать лучшего, я пошёл самым простым путём: открыл Photoshop и начал делать из уже сгенерированных картинок пустые подложки, которые можно было бы использовать как фон. План был тоже простой — подгонять под них текст и элементы вручную.
Еще спойлер: идеально это не сработало. Особенно дальше, на мобильной вёрстке и айфонах. Но на этом этапе мне было важнее двигаться дальше, чем делать всё правильно с первого раза.
В итоге почти все подложки, фон, имя, иконки, кнопки, контейнеры и декоративные элементы были либо сгенерированы ИИ, либо доработаны мной вручную. Даже мою фотографию ИИ смог довольно круто обработать в стилистике Fallout 2, включая ховер-состояние. Отдельно были сгенерированы сцены с волт-боем на прозрачном фоне, которые я уже сам раскидывал по нужным местам, подгоняя размеры, тексты и разделители.
И вот здесь дихотомия стала особенно заметной. Мне безумно нравилось процентов 90 того, что делал ИИ. Но каждый раз, когда дело доходило до внедрения этого в кодовую базу, оказывалось, что использовать это напрямую либо нельзя, либо слишком больно. В итоге почти всегда приходилось искать компромисс — между тем, что красиво выглядит, и тем, что вообще можно поддерживать дальше.

(греч. διχοτομία: δῐχῆ, «надвое» + τομή, «деление») — раздвоенность, последовательное деление на две части, более связанные внутри, чем между собой.
Здесь важно снова сделать оговорку. У меня есть некоторая база фронтенда, но её всё равно не хватало, чтобы с нуля предвидеть архитектуру не только кода, о чём пойдёт речь дальше, но и архитектуру дизайна.
Да, я сделал некое подобие UI-Kit. Но довольно быстро стало понятно, что он не отвечает требованиям нормальной разработки, где заменой одной картинки или одной строчки кода можно решить проблему. К этому я пришёл не сразу — а именно в тех местах дизайна и кода, где без продуманной архитектуры дальше уже было невозможно.
Получается, вот в этом месте я столкнулся с тем, что ИИ отлично знает, как должно быть, но совершенно не чувствует, как это потом будет жить в реальном проекте. Возможно, ещё и потому, что для генерации кода я использовал других агентов, которые вообще не были в контексте генерации этих картинок и их целей. Даже переиспользование кода, которое мне предлагал ChatGPT, кодогенераторы не всегда могли корректно встроить в нужном месте.
Далее начинается совсем другая история — про код, жёсткие решения и ошибки, которые я сделал сам или с ИИ.

Основной квест: генерация кода
«Есть хорошая идея — не делать ничего неправильно»
На этапе с картинками я уже создал проект и начал пробовать собирать всё это в коде. И здесь я сделал, как мне тогда казалось, самый простой и логичный выбор: native JS + HTML + CSS. Без фреймворков, без сборщиков, без лишней магии. Просто чтобы быстро получить результат и не утонуть в инфраструктуре раньше времени.
И поначалу всё действительно шло неплохо. Я брал сгенерированные подложки, прикручивал к ним стили, расставлял элементы — и сайт начинал выглядеть ровно так, как я хотел. Проблема была в том, что я делал это с мышлением человека, который никогда не писал фронт с нуля под реальный продукт.
В какой-то момент я поймал себя на мысли, что бездумно прописываю жёсткие размеры в пикселях. Width, height, margin — всё гвоздями прибито. Без фоллбэков, без расчёта на изменения, без понимания, что это когда-нибудь придётся трогать. И это было не раз и не два — так была собрана почти вся визуальная база сайта.
Проблема в том, что осознание пришло слишком поздно. К тому моменту у меня уже была почти вся пачка подложек под разные секции, сделанных под конкретные размеры. И вместо того чтобы просто поправить пару строчек CSS, мне пришлось возвращаться назад и перегенерировать часть картинок в строго заданных размерах, а потом ещё и править их вручную в Photoshop. Настоящий пиксельхантинг, от которого у меня начинал дёргаться глаз.
Формально всё работало. Фактически — я сам себе выстрелил в ногу, потому что не оставил никакого пространства для манёвра. И это был момент, когда я на собственной шкуре почувствовал, что код — это не просто «чтобы заработало», а фундамент, который либо помогает дальше, либо начинает тянуть проект на дно.
Тут, конечно, снова активно подключился ИИ. Я использовал разных агентов для генерации кода, правок ошибок и рефакторинга. Иногда они реально помогали — быстро находили очевидные косяки или подсказывали, как сделать аккуратнее. Иногда создавали иллюзию прогресса: код становился длиннее, сложнее, «умнее», но не обязательно лучше.
Например, агенты стабильно пытались использовать в любой дыре флаг !important как затычку от всех болячек (по их мнению), игнорируя то, что это нарушает естественный каскад стилей и делает код сложным для поддержки и отладки:
visibility:visible !important;
opacity:1 !important;После таких приколов я сделал правило для агентов не использовать флаг !important никогда и использовать каскад и специфичность селекторов. Я даже попросил в какой-то момент сделать ревью кода и написать его более сеньорно. Агент это сделал, все работало и смотрелось на самом деле лучше, на забавным фактом было то, что удалил он при этом 86 строчек, а добавил 121 и с покер-фейсом мне пытался даже объяснить такое решение.
Аналогично, агенты использовали невероятно огромные значения z-index, начиная от 100, заканчивая 9999 и считали это обоснованным, несмотря на то, что даже джун знает что использование z-index свыше 10 затрудняет управление контекстами наложения и может привести к «войнам z-index».
.scroll-indicator {
position: fixed;
bottom: calc(min(100vw, 768px) * 85 / 390 + 20px);
left: 50%;
transform: translateX(-50%);
z-index: 9999;
cursor: pointer;
animation: bounce 2s infinite;
opacity: 0.8;
transition: opacity 0.3s ease;
display: block;
}Однако, ИИ помогал в совершенно неожиданных вещах и написал js-функцию скалирования в зависимости от размера экрана. Да, да, я знаю, что вы скажете — это должно решаться на уровне стилей, но помните, что я к тому моменту уже почти весь сайт сделал на гвоздях? Но зато вы посмотрите на красивое решение агента, которое он сделал с 1 раза и оно работает до сих пор:
// Responsive scaling fix: Trim whitespace caused by scale transform
function handleResize() {
const container = document.querySelector('.desktop-container');
if (container) {
const baseWidth = 1669;
const windowWidth = window.innerWidth;
// Calculate scale exactly as in CSS
const scale = Math.min(1, windowWidth / baseWidth);
if (scale < 1) {
// Calculate height difference caused by scaling
const originalHeight = container.offsetHeight; // Natural height
const scaledHeight = originalHeight * scale;
const blankSpace = originalHeight - scaledHeight;
// Apply negative margin to pull footer up
container.style.marginBottom = -${blankSpace}px;
} else {
container.style.marginBottom = '0px';
}
}
}
// Run on load and resize
window.addEventListener('resize', handleResize);
handleResize();К слову говоря, я довольно быстро понял, что без базовой инженерной гигиены можно очень больно обжечься. Где-то на середине пути я перешёл на git — и ни разу об этом не пожалел. Ещё до перехода на антигравити у меня уже был удалённый репозиторий, и reset --hard я делал не один раз. Без гита этот проект, скорее всего, просто бы не дожил до финала.
Плюсом для меня и моего обучения на практике, было то, что я прогонял сайт через крутой веб-аудит (о чем я расскажу в следующей статье), и каждый раз узнавал о себе и своем сайте много нового. Например, что часть анимаций сделана через свойства CSS, которые не используют аппаратное ускорение, и это бьёт по производительности. Или что размеры картинок можно было уменьшить в разы с помощью специализированных библиотек — без визуальной потери качества. Некоторые из этих правок дали нехилый буст перформанса, некоторые — почти никакого, но сам процесс стал для меня вдохновляющим на новые знания.
В этом месте дихотомия стала ещё очевиднее. С одной стороны, без ИИ я бы не разобрался в половине этих вещей так быстро. С другой — ИИ не чувствовал архитектуру проекта целиком. Он исправлял конкретные симптомы, но не видел систему. И каждый агент работал в своём узком контексте, не зная, зачем вообще существует этот код и как он должен жить дальше.
В этом моменте я сформулировал свой первый вывод: ИИ может быть отличным помощником, но плохим архитектором. Он умеет подсказывать и ускорять написание кода (или говнокода). Но ответственность за решения, которые аукнутся через неделю или месяц, всё равно остаётся на человеке. В данном случае — на мне.
И если с веб-версией сайта мне в итоге удалось прийти к состоянию «нормально работает и не стыдно», то впереди меня ждал главный босс, борьба с которым заняла много времени и нервов.
Фрэнк Хорриган: мобильный адаптив
«Если ты выпустил в воздух ВРЭ, это ещё не значит, что ты герой. Ты просто очередной мутант, которому не место на земле»
Если предыдущие этапы были про боль, то мобильный адаптив оказался про страдание. Ведь всё, что я делал до этого, было в основном про десктоп. Красивый, аккуратный, зафиксированный в пикселях десктоп. Он отражал всё то, что я хотел.
Стоило открыть его на мобилке — и я сразу расстроился, что чего-то сильно не хватает. А в мире mobile-first я прекрасно осознавал простую вещь: большая часть людей откроют сайт с телефона. И они точно не будут мучиться, приближать, скроллить по пиксельным панелям и пытаться «понять задумку». Они просто закроют вкладку.
Поэтому я сел продумывать на листочке бумаги лэйаут: как этот же смысл и тот же Fallout-вайб должны выглядеть на маленьком экране. Получился примерный план — что куда переедет, где будет фотка, где атрибуты, где перки, где текст:

Легко сказать — оказалось сложно сделать. И тут началась очередная сложность: агенты вроде бы понимают, что такое адаптив, но в реальном проекте начинают упираться в свою любимую «универсальную пилюлю».
Антигравити, например, упорно пытался сделать мобильную версию только через стили и media query. Причём даже с толстыми намёками он не хотел делать то, что мне казалось очевидным: нормальную структуру файлов и отдельную разметку. Архитектура сайта изначально делалась под десктоп, и попытка «просто адаптировать» её под мобильные устройства начала ломаться на уровне концепции. Мы бодались какое-то время, и в определенный момент я просто принял решение, которое изначально сам считал плохим. Если я уже построил десктоп «на гвоздях», то честнее будет сделать мобилку отдельной версией, с отдельной разметкой и логикой отображения, чем бесконечно лепить костыли на существующую.
Это был момент принятия. Не лучшего решения, а реалистичного.
В итоге я пришёл к варианту: отдельный HTML-файл (условно index-mobile.html) и по сути отдельная папка/структура под мобилку со своей логикой.
Но я все равно застрял. Не технически — концептуально. И здесь впервые за весь проект я пошёл за помощью не к ИИ, а к живому фронтенд-разработчику. Не за кодом, а за взглядом со стороны. За тем самым «чувством интерфейса», которого у меня, при всём опыте, просто не было. И за советом — как это сделать «по-людски», чтобы:
я мог проверять всё локально,
чтобы это было mobile-first,
чтобы базовые правила (типа ограничений по z-index) были не хаосом, а системой.
Этот разговор оказался болезненным, но полезным. Мне довольно быстро указали на вещи, которые я упорно не хотел видеть: где я сам загнал себя в угол архитектурными решениями, где пытался чинить следствие вместо причины, и где мобильная версия никогда не станет «нормальной», пока я не приму ряд неприятных компромиссов.
После этого родился первичный промпт (я использовал его для Claude Sonnet):
Создай для меня новую версию сайта под мобильные устройства
- начни структуру в файле index-mobile.html
- дай мне возможность проверять на локалке свои изменения
- нужно мобайл ферст
- мы с тобой сделаем структуру html и пропишем правила типа всех z-index тоже в отдельных файлах, размеров и прочее
- Никаких жестких width, или margin 1000px, но при этом надо сверстать все правильно как надо
- Ну и самое главное. Рутовый контейнер на gridНа всякий случай я сверял план, созданный клодом в md со своим другом, он комментировал, я это обрабатывал с агентом и в итоге мы втроем получили подходящий implementation_plan.md, на который я уверенно нажал proceed.
И на что я только надеялся? Разумеется всё равно всё пошло не так. Даже с новым подходом и консультациями кожаного мешка мне приходилось вручную разбираться почти с каждой проблемой. Потому что мобилка — это не просто «уменьшить». Это другой мир: другой ритм, другие размеры, другие ожидания, другой скролл, другие шрифты, другие баги.
Консультации с другом-фронтендером в итоге стали традицией. И пару раз его советы реально спасали меня быстрее, чем любые агенты. К вопросу «заменит ли ИИ людей».
И тут снова случилась дихотомия — уже не техническая, а личностная. Я одновременно ловил себя на двух противоположных ощущениях:
фронтенд иногда казался интереснее, чем QA — я реально кайфовал от поглощения новых знаний и ловил мысль «может надо было на фронт идти и не слушать бабушку»;
но чем глубже я погружался, тем больше я ненавидел фронтенд всей душой и думал: «зачем я вообще начал писать этот проект на native JS»
В итоге мобильная версия всё-таки заработала. Не идеально. Не так, как мне хотелось бы в мире розовых пони и идеальных архитектур. Но она стала предсказуемой, управляемой и не стыдной. И главное — я на личном опыте прочувствовал, что сайт под мобилу сделать гораздо сложнее, чем просто сделать сайт «гвоздями прибитый» под десктоп. Я меньше чем за две недели собрал сам сайт — и почти три недели воевал с мобильным адаптивом.
Этот бой я выиграл не потому, что стал лучше писать фронтенд. А потому, что научился вовремя признавать ограничения — свои, архитектурные и инструментальные. И если предыдущие этапы были про эксперименты и эйфорию, то мобильный адаптив стал моментом взросления проекта.

До титров: эндгейм, хостинг и реальные девайсы
«Ты выжил. Избранный не может быть слабым, иначе мы все обречены. Ты готов к своему заданию?»
Когда основной сюжет был пройден — сайт заработал, мобильная версия перестала разваливаться, а я перестал ненавидеть фронтенд каждую минуту — начался тот самый эндгейм. Момент, когда вроде бы всё готово, но именно сейчас начинают всплывать вещи, которые в туториалах обычно не показывают.
Первым таким квестом оказался выбор хостинга и домена. Я не хотел усложнять себе жизнь и пошёл по самому быстрому пути — одной кнопкой развернул master-ветку через Vercel и уже тогда мог делиться промежуточными результатами. Это было удобно: быстро, без лишних телодвижений, с нормальной интеграцией с репозиторием. Примерно в этот же момент я решил, что пора выбирать домен — красивый, запоминающийся, в два слова. В голове крутилось что-то вроде pavel works, но этот домен оказался занят примерно с теми же целями, но с очень скучным визуалом, на мой взгляд.
Дальше был классический ад перебора доменов. Были занятые, были свободные, были красивые, но дорогие. Например, .company или .expert. В итоге я выбирал между .expert и .rocks. Оба мне нравились и оба хорошо отражали суть визитки, но победил прагматизм: первый стоил около 100 долларов в год, второй — всего 20. Ну и дальше я уже убедил себя, что .rocks подходит даже лучше, потому что отлично ложится в дерзкую, немного стёбную Fallout-стилистику.
Казалось бы — купил домен, да настроил. Но, разумеется, всё оказалось не так просто. В процессе настройки я столкнулся с проблемами проброса IP-адресов и конфигурации Vercel ↔ хостинг домена. Ради этого мне пришлось прибегнуть к древней магии миллениалов — смотреть обучающий видос на YouTube и разбираться, почему оно вообще не работает.
Когда всё наконец завелось, я поделился ссылкой с парой друзей — и внезапно выяснилось, что часть людей из РФ получает только HTML, но не получает ни одного ассета. Картинки и стили оставались в бесконечной загрузке. Небольшой анализ показал, что домены Vercel довольно часто блокируются на уровне сетей в РФ, и без VPN на сайт просто не зайти.
Более вдумчивый разбор привёл меня к неприятному, но логичному выводу: мне нужен отдельный веб-сервер, развёрнутый на хостинге, доступном из любой точки. В итоге выбор пал на Fornex — и там я уже нормально развернул сайт.
Но и на этом эндгейм не закончился. Когда я открыл сайт на реальных устройствах, не в DevTools, не в эмуляторе, а на живых телефонах, реальность снова отличалась от идеальной картинки в голове.
Оказалось, что шрифты и картинки на живых телефонах просто не загружаются, отображаются шрифты по умолчанию, не влезают в рамки и как итог — опять едет вся верстка. Причина была максимально прозаичной: относительные пути (../) и локальные ассеты, которые нормально работали в браузере на десктопе, ломались в реальной среде. Для всего пришлось указывать абсолютные пути, а шрифты — подключать напрямую через Google Fonts:
<!-- Google Fonts (Roboto Condensed, IBM Plex Mono, Roboto Mono) →
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:wght@500;700&family=Roboto+Condensed:wght@400;700&family=Roboto+Mono:wght@700&display=swap" rel="stylesheet">Это, кстати, подсказал агент — и это действительно сработало. С путями к картинкам он тоже помог, за что ему отдельное спасибо. Но именно в этот момент меня по-настоящему поразило, насколько всё в реальном вебе держится на соплях. То, что выглядит логичным и «правильным» в изолированной среде, разваливается при первом контакте с реальностью.
Например, мне пока так и не удалось починить поехавшие и залезающие шрифты на айфонах.
Но в какой-то момент я сознательно решил остановиться. Не потому, что всё идеально, а потому, что проект достиг состояния «достаточно хорошо». Он работает, он выполняет свою задачу, и даёт тот опыт, ради которого всё и затевалось. Дальнейшие улучшения — это уже не про необходимость, а про перфекционизм.
И вот здесь вайб эндгейма оказался очень точным. Я мог бы ещё долго полировать анимации, подгонять пиксели, переписывать куски кода и спорить с агентами. Но вместо этого я предпочёл зафиксировать результат и честно ответить себе на главный вопрос: что я вынес из этого эксперимента.
Этот сайт стал для меня не просто визиткой. Он стал способом на практике прожить дихотомию вайбкодинга: между скоростью и качеством, между «красиво» и «поддерживаемо», между ИИ как усилителем и ИИ как источником иллюзий.
И, пожалуй, самое важное — он дал мне опыт, который невозможно получить, просто читая статьи или глядя на чужие проекты. Опыт, который остаётся с тобой и после титров.

Титры: что будет с Пустошью
«Эксперимент с вайбкодингом был завершен.
Сайт был построен.
Но последствия этого стали понятны только сейчас.»
Я уверен: если вы откроете DevTools — особенно если вы профессиональный фронтенд-разработчик — вы без труда найдёте здесь места для улучшений. Возможно, увидите архитектурные косяки. Возможно, на больших экранах заметите менее читаемый текст поверх картинок. Этот сайт точно можно сделать лучше.
Вопрос только в одном: а нужно ли мне в моём случае гнаться за идеалом, которого я сам до конца не понимаю — в силу ограниченности своих знаний? Или, возможно, кто-то из вас даже поможет мне наконец починить адаптив под айфон 🙂
Если отбросить иронию, я пришёл к довольно простому выводу. Мне был нужен сайт-визитка с визуалом, который я чётко видел в своей голове — и я реализовал его примерно на 95%. И да, без современных инструментов вайбкодинга я бы никогда не сделал этот сайт сам. Тем более — за две недели вечерами.
Но могу ли я при этом говорить, что ИИ «не понял, чего я хотел»?
ИИ отлично помог создать визуал и даже дал мне инструменты, чтобы собрать его на пусть и топорно прибитых гвоздями стилях. Но вот качество продукта — архитектура, работа со стилями, подготовка к мобильному адаптиву — оказалось уже за пределами того, что я мог требовать от вайбкодинга в текущем виде. Особенно с моей профдеформацией в отношении качества.
Генератор картинок не способен увидеть продукт целиком. А кодогенераторы пока не умеют читать визуал так, как это делает человек. Тот же антигравити опирается в первую очередь на HTML-структуру и эвристику, а не на ощущение интерфейса. В то время как опытный фронтенд-разработчик может увидеть проблему и исправить её в три строки — не потому что «знает лучше», а потому что чувствует контекст.
Я думаю, что сейчас LLM ещё не готовы заменить человеческий опыт. Хотя это активно пушится и хайпится, и во многих компаниях менеджмент уже начинает верить машине больше, чем человеку. Возможно, когда-нибудь это изменится. Я не исключаю, что настоящий ИИ действительно заменит текущие роли в IT, и появится что-то принципиально новое.
Но в ближайшие годы, как мне кажется, будет особенно востребована профессия говночиста за LLM-ками. И уж точно человека, который знает больше, понимает контекст и способен контролировать машины — пока они не научатся чистить за собой сами и строить архитектуру проектов на базе размытых требований заказчика.
Мир меняется очень быстро. Полгода назад тот же Claude не умел и половины того, что умеет сейчас. Полтора года назад ChatGPT генерировал картинки с кучей ошибок и был ограничен данными за 2023 год. И уже даже дядя Боб согласился с тем, что ЛЛМ стали полноценными помощниками. И мой опыт (не стаж, а именно опыт) обесценивается быстрее, чем я успеваю к этому адаптироваться.
Я не могу повлиять на хайп LLM-ок или на слепую веру людей в правильность машинных решений. Но я хотя бы попытался использовать эти же инструменты, чтобы получить новый опыт. Зайти в ту часть разработки, где раньше я был в роли качества. Пройти через грабли, о которых раньше знали только люди — а не машины.
Этот сайт был попыткой сохранить информацию обо мне как о человеке. Со своими сильными сторонами, слабостями и реальным опытом. Чтобы те ребята, которым нужна не функция, а нужен человек, могли меня найти, понять и, возможно, начать новый этап хорошего сотрудничества.
И если эта статья вдохновит хотя бы часть людей перестать гнаться за фильтрами ATS и советами «консультантов по продвижению идеального резюме», а вместо этого сделать своё настоящее резюме — от души, которое честно отвечает на вопрос «кто ты и чем можешь быть полезен компании», чтобы задача найма наконец выполнялась адекватно, то всё это будет точно не зря.