Как я резюме в стиле Fallout 2 с нуля делал или Дихотомия Вайбкодинга

Всем привет, меня зовут Паша и я 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 и советами «консультантов по продвижению идеального резюме», а вместо этого сделать своё настоящее резюме — от души, которое честно отвечает на вопрос «кто ты и чем можешь быть полезен компании», чтобы задача найма наконец выполнялась адекватно, то всё это будет точно не зря.