Как вайбкодинг довел меня до депрессии, а потом привел к вайб‑инжинирингу

Начнём с того, что по‑настоящему «вайблю» я где‑то с ноября 25 года. До этого моё общение с LLM строилось на периодической копипасте из ChatGPT, DeepSeek, Gemini и обратно. Рука наловчилась, и я в целом не замечала, сколько времени это всё‑таки сжирает. Казалось бы, лишнее действие.

Не сказать, что я злоупотребляла общением, но когда ты только начинаешь по‑настоящему кодить, ты очень уверен в себе и думаешь, что всё и всегда делаешь правильно. А как только начинаешь реально понимать процессы, приходишь к выводу, что вообще ничего не знаешь.

Пока я училась в университете, слава богу, ChatGPT был отсталой жабой, которая через раз выдавала код с ошибкой. Поэтому я морщила нос и старалась всё делать сама — и, спасибо Вселенной, что всё так и было. Иначе, мне кажется, сейчас я была бы не разработчиком, а унылым вайбером, который при слове «конструктор» или «указатели» просто представляет лего и какой‑нибудь г. Санкт‑Петербург.

А потом случилась ИИ‑революция. И моя компания, в которой я спокойно кодила задачи ручками, решила не тормозить.

Сначала был Copilot, удобная штука для самопроверок и автокомплита, потом мы вайбили в Replit — хотя это нельзя было назвать вайбингом, это было осторожное щупанье с искренним непониманием, почему нельзя поставить самую последнюю версию Flutter. И вот тут первый честный вывод. Replit — это не твоя машина, это чужая песочница. Ты не контролируешь окружение, версии, зависимости прибиты так, как удобно платформе, а не тебе. Хочешь свежий Flutter или конкретную версию ноды, а тебе «нельзя, у нас так». Воспроизвести то же самое локально, чтобы дебажить по‑человечески, — отдельный квест. Плюс ты платишь не только за токены, но и за вычисления самой среды, а как только захочешь вынести проект наружу — выясняется, что половина магии работала только внутри их песочницы. Для «потыкать идею за вечер» — отлично. Для чего‑то, что должно жить и расти, — ты в клетке, ключ от которой не у тебя.

Потом настала эра Cursor. И продолжалась она где‑то с ноября по март. И поначалу было окей: среда, похожая на VS Code, кнопки те же, смысл тот же, просто чуть более умная, куча моделей и оплата за токены. Но я, как человек мелочный, безусловно, считала.

Считала, сколько денег было потрачено на токены (компании) и сколько моего рабочего труда это стоит. И это заставляло меня грустить. Потому что задачу, которую я сама бы сделала за неделю, он делал за три часа и два унылых промпта и брал за это копейки. А другую, которую я могла бы сделать за пять минут, он делал три часа — и выходило совсем дороже. Этот разброс привёл меня к очень умной мысли: неважно, каким инструментом ты пользуешься, если он решает твою проблему качественно и быстро.

Тогда я ещё не думала о rules, тогда ещё не изобрели skills, а о мультиагентной разработке я думала как о чём‑то типа «зачем, почему, как это» (ладно, вообще не думала). Тогда я пыталась писать ему по‑английски, потому что английские слова короче и кодируются меньшим количеством токенов, и не могла себе представить, что упускала саму суть.

do it, fix it, commit this, ну вы поняли…

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

Это произошло очень незаметно. Когда в твои руки попадает инструмент, который, как ты потом выясняешь, способен на великие вещи, ты, конечно, начинаешь думать, что теперь можешь всё.

Я теперь фулл, я теперь стек, я теперь дизайнер, я бог.

И я почувствовала себя всесильной. И решила поучаствовать в конкурсе на работе по вайбингу.

Мы вайбкодили приложение для обедов наших сотрудников. У нас была неделя и неограниченное количество токенов, свободный выбор средств, ТЗ на страничку — в общем, целая песочница для творчества.

Ну и я, как здравый человек, как меня учили, сначала начала думать о полноценных технических требованиях. Подумала, навайбила, насоздавала md и — оп, а день‑то закончился, и у меня осталось ещё шесть.

А теперь ответьте себе на вопрос.

Сколько времени вам нужно, чтобы разработать админку для повара и администратора, бота для заказов обедов, настроить CI/CD с автодеплоем и подготовить свою работу к конкурсу?

Я не знаю, что ответите вы, но знаю, что я сказала бы «не знаю». Потому что тема ботов, админок, CI — это что‑то из фильма ужасов. Я Flutter‑разработчик: я верстаю красивые странички, подключаю апишку, проверяю golden‑тесты и редко (но метко) лезу в нативщину Android и iOS. Ну какие боты, ребята?

Но мы же на инициативе. Я прикинула, что так не пойдёт: если целый день я потратила только на подготовку к выполнению задания (то самое никому не нужное планирование и обсуждение), то на следующий день я разобралась с ботом, с токеном, с подключением, с авторизацией через телегу и со структурой БД. Снова прикинула — время просто утекало. Дальше я психанула и сказала своему ИИ‑бро:

прочитай всё, что мы обсуждали. сделай.

И каково было моё удивление, когда он взял и сделал.

Мне почти с первого раза открылась админка с прикольными фиолетовыми градиентами, с фичами, которые мы обсуждали. Короче, та самая тупая MVP‑шка, на которую смотрят и говорят «о да, мы молодцы», а потом жмут на кнопку — и приложение крашится. Или открываешь Network и видишь дудосинг эндпоинта, потому что он забыл useMemo или useRef. А потом смотришь в код и начинаешь плакать: потому что вместо красивого класса для response он захардкодил JSON. Потому что так ведь быстрее. Мы же это не обсуждали.

Выглядело это примерно так:

// что я ожидала
async function getLunches(): Promise<Lunch[]> {
  const res = await api.get<Lunch[]>('/lunches');
  return res.data;
}

// что я получила
async function getLunches() {
  return [
    { id: 1, name: "Борщ", price: 250, available: true },
    { id: 2, name: "Котлета", price: 300, available: true },
    // ...ещё 40 строк захардкоженного меню
  ];
}

И у меня началась стадия отрицания.

Cursor тупой, он сделал полную чушь, я не знаю, как это разгребать.

На что мне коллега, когда я пришла ныть и сниматься с конкурса, сказал: «Ты потратила всего один день. У тебя что‑то запускается. Если всё совсем плохо — начни заново». А я смотрю на свою шкалу usage, а там уже 18 баксов моей 20-долларовой подписки, и думаю: ну уж нет.

И начинаю разгребать косяки.

Чтоб вы понимали: у меня там монолит на Python и вебка на React, база всех баз (просто не мой стек) — базовый пет‑проект, или та самая хрень, которую можно было бы сдать как диплом на бакалавра и получить пятёрку.

Чем больше я смотрела в код, тем страшнее мне становилось. Потому что сначала ты не понимаешь и думаешь «сойдёт», потом понимаешь и думаешь «не трогаем», потом начинаешь трогать и жалеешь — и так в продукте, которому меньше недели, появляются ЛЕГАСИ и костыли, а ты уже думаешь: да пошло оно всё, хочу к своим старым рабочим задачам.

Я сделала что смогла, прихорошила UI — я ж фронтендер, стыдно было бы показывать совсем говно. Ещё скажут, что не работала.

И начался конкурс. Нас было трое.

Я — показала пару багов, но для MVP это было позволительно. Систему я сделала слабо расширяемой и только в рамках ТЗ: скидки, выбор блюд, заказы, планирование меню и всё такое. Мою работу отметили лаконичной — я не успела наплодить кучу фич, а те, что были, довела до хорошего и понятного UX.

Мой коллега, лид‑Flutter — его детище было микросервисной машиной для убийств с фуллстеком на TypeScript, с кучей функционала, входом по OTP и по QR‑коду и всяким‑всяким но с UI без градиентов, больше напоминающим excel.

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

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

Руководство выбирало между мной и моим лидом. И конечно выбрало задумку лида — с точки зрения функционала он был гораздо шире, хоть и не устраивал с точки зрения UI. Я выдохнула и начала злорадно смеяться: и повайбила, и бесплатно кушать буду (победу в итоге разделили, и мы втроём стали нахлебниками офиса за инициативу).

А потом случилось страшное. Мне сказали:

мы взяли его наработку, но до ума доведёшь её ТЫ (у него же куча дел)

И так в мои руки попал проект, в котором не разбирался никто, кроме Claude Sonnet 4.5 и Composer. С документацией, которая вроде бы есть, а вроде бы и нет, и одной простой фразой: «ну там чуть‑чуть доделать». И я кивнула.

Довайбились, как говорится.

Основная задача стояла — добить UI до терпимого и удовлетворить нашу главу по обедам, чтобы ей было понятно, как и что куда делать. Но и там уже появились тонкости: есть люди, которым можно брать несколько обедов, есть те, кому нельзя вообще, есть ещё что‑то, и всё должно быть приватно, а потом еще отчетность, а потом еще что‑то (открылась тёмная бухгалтерия обеденного бизнеса).

Ну и я вайбила. Отчаянно вайбила, требования менялись на ходу со словами А ДАВАЙТЕ и я думала: какой смысл вникать? Завтра они снова передумают.

Господи, как вспомню — хочется стукнуть себя по голове.

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

Тогда в моём словарном запасе появились правила:

НЕ КОММИТЬ, НЕ ПУШЬ, НЕ УДАЛЯЙ (ну вы поняли)

И правила добавлялись поэтапно, каждое после очередной шишки. А потом правил стало очень много, и одно говорило «НЕ создавай лишних.md», а второе — «ДОКУМЕНТИРУЙ СДЕЛАННОЕ», и мои агенты, наверное, рыдали, пытаясь понять приоритет.

Потом я поняла, что дело не только в UI… В бэке тоже были косяки и недочёты, он был не оптимизирован. А чего вы хотите от mvp?

И я начала ОПТИМИЗИРОВАТЬ.

Не надо оптимизировать то, что уже работает, если вы не понимаете контекста оптимизаций.

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

В общем, не бейте меня тапками, но я как фронтендер, конечно, знаю и про БД, и про индексы, и про первичные ключи. Но я позволила ему создать таблицу, которая связывает три таблицы сразу между собой и ставит null, если связи нет.

Думаю, меня сейчас поняли: да — вайбинг удался.

И конечно, всё это обнаружилось мной же, когда проект вышел в свет и был задеплоен. Когда вдруг потребовалось что‑то расширить, а я такая: не‑не, ребята, тут вообще песня. То есть работа уже налажена, но добавлять новые фичи — это просто перехуячивание всего проекта сразу. И хорошо, когда у тебя есть нейронка: пара иттераций, вечер дебага и проверок — и вроде бы окей, новая версия. Но что если её не будет? Что если нужен хотфикс, а обеды придут через 15 минут? Что если это не корпоративный проект, а сервис, которым пользуются миллионы…

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

Я хотела проект с чистым, интуитивно понятным кодом, а получила какое‑то говно, где компоненты по 1000 строк, бизнес‑логика размазана, бэкенд дрочит сам себе запросами, а микросервисы моего лида (изначально тоже неидеальные) получили себе гору ненужной ответственности. Скорее всего, в этом проекте вы найдёте все нарушения принципов SOLID, паттернов проектирования БД, DRY — и какие там ещё есть паттерны. Это кусок говнокода, который чудом работает, чудом помогает людям заказывать еду и ждёт, когда я вернусь в него решать технические долги (не только мои).

Лид потратил на проект неделю и сделал рабочий MVP. Я потратила ещё два месяца и вывела этого бро в люди без стороннего надзора. Могла бы и быстрее, если бы не пыталась сделать конфетку — которой и так не получилось даже после попыток.

И я думала… вот оно, сейчас они увидят, как я форс‑пушила в мастер, как испоганила БД, как не предусмотрела очевидную логику, как захардкодила константы, как не соблюдаю никаких правил нормальной, принятой в цивилизованной разработке, как трачу по дню на добавление новой фичи, потому что приходится рефакторить существующие, и как он чинит одно и ломает другое, а я просто сижу и получаю свою зарплату за какую‑то хуйню, честное слово. У меня была дизайнер, которая только говорила «норм», видя очередную страничку, и я, которая помнила про те самые таблицы с null вместо первичных ключей.

И я загналась. Довайбилась. Решать задачи становилось страшнее, потому что нужно было больше контекста, файлы росли, и в целом контекстного окна на 200k токенов мне еле стало хватать на одну задачку.

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

Зато в моём резюме появится гордая строчка: «получила MVP и развернула его в настоящий функционирующий продукт с 50 пользователями, стабильно работающий уже полгода». Есть чем гордиться!

В промежутке между отладкой багов я судорожно искала на hh вакансии, а потом вдруг поняла, что за то время, пока я вайбила этот проект, я просто разучилась писать руками.

И началась стадия гнева.

ИИ отупляет, он не может, он не способен, проще сделать руками, надо-надо-надо, я лучше сама.

Но в нашей компании революция прошла насильственно, и выбора как бы не было — пришлось вайбить дальше. На такой вайбинг уходила куча денег: каждый вайбил на 200–1000 баксов в месяц, а это, извините, нихрена так. Вот только вайбили все, а новых продуктов не выходило (кроме моего бота).

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

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

Сейчас я сижу за двумя проектами: на одном я бэкенд на Rust и снова фронтенд на React, на другом наконец вайблю на Flutter мобильное приложение.

Как только стало понятно, что Cursor — это дорого, мы открыли для себя Claude. И наша жизнь поменялась.

Почему Cursor в итоге начал бесить. Дело не в том, что он плохой — он хороший. Дело в модели оплаты, которая прячет от тебя цену решения. Ты не видишь заранее, сколько будет стоить задача: одна правка на пять минут сжирает копейки, другая на «подумать» — улетает в десятки центов за один прогон, а ты узнаёшь об этом постфактум по шкале usage. Когда вайбит вся компания на 200–1000 баксов в месяц, это уже не «удобный редактор», это статья расходов, которую никто не закладывал. И главная подстава: дорого ≠ контролируемо. Ты платишь больше, но всё равно не понимаешь, что именно он сделал и почему столько. Claude с подпиской (через CLI и skills) дал то, чего не хватало, — предсказуемость и управляемость процессом, а не только результатом, удобные лимиты, а также независимость от ide.

Теперь в моём лексиконе есть такие противные слова как скиллс, воркфлоу и агенты, открыто по 4 чата с задачами, и всё, что я успеваю, — это переключаться между вкладками и смотреть, что сделал мой маленький раб. Я обязательно смотрю и стараюсь не нагружать его задачами:

а перепиши-ка мне весь репозиторий на go и не допусти ни одной ошибки

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

Я убрала правило «не коммить» и настроила себе скиллы для осмысленных коммитов, осмысленных пушей, осмысленных мерж‑реквестов — так что теперь он делает всё по моей команде (хотя иногда всё ещё продолжает чудить).

Я практически не использую встроенный memory и rules. В memory у меня хранится что‑то, что я реально не могу запомнить, например IP сервера, к которому постоянно подключаюсь (просто не лезет в голову). Зато он знает: когда я говорю «подключись к этой поеботе», я имею в виду 10.168.10.224 и ничто иное.

И моя работа с Claude вышла на уровень дальше. Если изначально MCP для меня был днищем, засирающим контекст, то теперь я сама пишу себе MCP, чтобы читать отзывы на свои работы на фикбуке.

Если выжать из всей этой истории то, что я бы хотела сказать себе год назад, получится короткий список. Это не «10 лайфхаков продуктивности», это шишки, каждая из которых стоила мне нервов, денег компании, в которой я работаю или профессионального выгорания.

Правила общения с ИИ, которые я выстрадала:

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

2. Бэкап до того, как разрешишь ему трогать данные. Не после первой потерянной БД, а до. Они правда могут случайно стереть или удалить а потом сказать ОЙ.

3. НЕ УДАЛЯЙ без твоей команды. Любое необратимое действие — только через тебя. Это первое правило, которое я завела, и единственное, о котором ни разу не пожалела.

4. Читай дифф, а не «вроде работает». «Должно быть норм» — это начало легаси в проекте, которому три дня. Если ты не прочитал код — его не прочитал никто. Или заставляй его читать код.

5. Не давай оптимизировать то, что работает, если не понимаешь контекста. Оптимизация без понимания — это не ускорение, это лотерея. Он скажет тебе, что это будет лучше работать — и это будет ложь.

6. Проси думать на твоём языке. Экономия на токенах за счёт английского и обрезанных промптов — ложная. Дешевле один раз нормально описать контекст, чем три раза переделывать. Ну и, конечно, следя за ходом его размышлений, ты видишь момент когда он сворачивает не туда.

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

8. Память — для того, что не помнишь ты, а не для всего подряд. IP сервера, к которому лень лезть, — да. Пересказывать ему весь проект в memory — нет, это просто шум.

9. Знай, где заканчивается твоя компетенция. Я фронтендер. Когда я полезла строить связи в БД через таблицу с null вместо ключей — вайбинг «удался». ИИ не закроет дыру в твоих знаниях, он её масштабирует. И я не хочу прикрываться что вот я не знала, что так не делают. Всё я знала, просто не увидела во время.

10. Не доводи до конфетки то, что должно быть рабочим. Мой перфекционизм стоил мне двух месяцев и депрессии. Лид сделал MVP за неделю; иногда «работает и понятно» важнее «идеально». Возможно я чересчур запарилась.

Я не говорю, что коддинг ручками умер. Но я верю, что правильный инструмент в руках правильного человека раскрывается с правильной стороны.

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