Вайбкодинг — это когда ты описываешь задачу человеческим языком, модель пишет код, ты запускаешь — и оно работает. Иногда. Какое-то время.
А потом ты приходишь на собеседование, и тебя просят объяснить, что делает твой собственный проект. И ты произносишь фразу: «Ну... оно как бы... в общем, я сейчас промпт покажу».
Меня зовут Сергей Куриленко, я ML-разработчик, соавтор курса «Нейросети для работы» и ревьюер на курсе «Нейросети для бизнеса» в Яндекс Практикуме. За последний год я не раз сталкивался с ситуацией: человек осваивает вайбкодинг и создаёт проекты с невероятной скоростью — а потом обнаруживает, что всё это время строил не карьеру, а карточный домик. Сценарий настолько типовой, что я решил оформить его в жанре вредных советов — чтобы было весело читать и неловко узнавать.
1. Копируй код, не читая. Модель же умная
Если LLM выдала тебе код, значит, код правильный. Зачем тебе знать, что такое async, если оно и так запускается? Зачем разбираться в useEffect, если можно попросить: «сделай, чтобы данные подгружались»? Ты же не хирург — тебе не обязательно знать, что внутри пациента.
Ну, то есть проекта.
Это самый сладкий из антипаттернов. Код работает, дофамин идёт, зачем портить кайф чтением? Я сам так делал. Два дня генерировал React-приложение, которое делало ровно то, что нужно. А на третий день понадобилось поменять одну кнопку — и я 40 минут не мог найти, где она вообще рендерится, потому что в собственном проекте ориентировался как турист в токийском метро.
На собеседовании это выглядит ещё краше. Тебя просят добавить фичу в твой же проект — и ты сидишь, как студент, который купил дипломную работу и теперь объясняет комиссии, что «ну, тут такой подход, потому что... потому что так получилось».
Противоядие: прежде чем вставить код, прочитай его. Если видишь незнакомую конструкцию — спроси модель: «объясни вот эту строку, как будто мне 10 лет». Это займёт минуту. Зато через неделю ты будешь ловить баги глазами, а не пятнадцатым промптом.
2. Тесты — для трусов и бюрократов
Тесты — это для тех, кто не уверен в себе. А ты уверен. LLM написала код. Если бы что-то было не так, она бы сказала. Правда?
...правда?
Любимый сценарий: проект готов, всё локально работает, даже скриншоты для README сделаны. Показываешь заказчику. Он вводит своё имя кириллицей в поле, которое ты тестировал только латиницей. Приложение падает. Без ошибки. Просто белый экран и ощущение экзистенциальной пустоты.
Или лучше: ты пишешь API, модель радостно генерирует эндпоинт за эндпоинтом. Всё работает на localhost:8000/docs. Деплоишь. Первый пользователь отправляет null в обязательное поле — и Postgres вежливо сообщает, что constraint violation. А фронтенд показывает «undefined is not a function». Классика.
Противоядие: проси модель сразу писать тесты. Прямо в промпте: «напиши функцию и юнит-тесты, включая edge cases — пустые строки, null, Unicode, числа за пределами диапазона». И запускай их. Каждый раз. Тест — это не бюрократия, это ремень безопасности. Можешь ездить без него, но однажды пожалеешь.
3. Документацию пусть читают нёрды. Ты — вайбкодер
Зачем читать доку, если можно просто попросить: «подключи мне Stripe»? Модель наверняка знает все API наизусть. А то, что она обучалась на данных двухлетней давности и с тех пор API три раза поменялся — ну, это мелочи.
Вот конкретная история. Человек попросил модель написать интеграцию с Telegram Bot API. Модель написала. С answerCallbackQuery, с инлайн-кнопками, всё как у людей. Только использовала синтаксис библиотеки, которой не существует. Просто скомбинировала названия из python-telegram-bot и aiogram в один франкенштейновский импорт. И код выглядел настолько уверенно, что человек три часа искал баг в своей логике, а не в несуществующем модуле.
Модели галлюцинируют. Причём делают это с покерфейсом. Они не краснеют, не мнутся, не говорят «слушай, я не уверена». Они выдают чушь с интонацией профессора.
Противоядие: перед интеграцией с чем угодно — открой актуальную документацию. Скопируй нужный раздел и вставь в контекст: «вот дока Stripe Checkout API от 2025 года, напиши интеграцию строго по ней». Модель с актуальным контекстом — это другая модель. Это как один и тот же студент с шпаргалкой и без.
4. Безопасность — проблема будущего тебя. А будущий ты — крепкий парень, справится
API-ключ прямо в коде? Ну он же на localhost. SQL-инъекции? Кому нужен мой to-do-list? CORS отключён? Зато всё работает. Пароли хранятся в открытом виде? Да тут три пользователя, все мои друзья.
Реальная хронология:
Понедельник: ты заливаешь проект на GitHub. Токен OpenAI лежит в
config.py, строка 14.Понедельник, +14 секунд: бот сканит публичные репозитории и находит твой токен.
Вторник, утро: на аккаунте $200 за чужие запросы к GPT-4.
Вторник, обед: ты узнаёшь, что GitHub теперь помечает такие репы предупреждением, и все твои будущие работодатели это увидят.
И это оптимистичный сценарий. В пессимистичном — через незащищённый эндпоинт утекает база данных. Даже если в ней только email'ы твоих трёх друзей — тебе будет неприятно объяснять им это.
Противоядие: чеклист перед каждым коммитом. Секреты — в .env, файл — в .gitignore. Запросы к БД — параметризованные (никаких f-строк с пользовательским вводом!). Входные данные — валидируются. И да, попроси модель провести аудит: «проверь этот код на типовые уязвимости из OWASP Top 10». Она не найдёт всё, но очевидные дыры закроет. А ломают обычно через очевидные.
5. Не ставь задаче границ. Пусть ИИ сам разберётся, что ты хотел
«Сделай приложение для учёта финансов». Точка. Промпт закончен. Какие тут БД, роли, аутентификация — пусть модель решает, ей виднее. Ты здесь за вайб, а не за спецификации.
Модель не умеет читать мысли. Но она умеет делать вид, что умеет. Ты пишешь «сделай приложение» — она сделает. С собственной реализацией крипто (пожалуйста, нет), с ORM на коленке, с архитектурой, которую нельзя ни тестировать, ни масштабировать. Ты получишь монолит на 2000 строк, где бизнес-логика перемешана с отрисовкой кнопок, и переписать его дороже, чем начать заново.
Я однажды попросил модель «написать CRM». Без уточнений. Она выдала Flask-приложение с SQLite, которое хранило данные клиентов в одной таблице вместе с заметками, задачами и... прогнозом погоды. Нет, я не знаю, зачем там прогноз погоды. Модель тоже не знала. Но она его добавила — с полной уверенностью.
Противоядие: декомпозируй задачу до того, как откроешь чат. «REST API на FastAPI, CRUD для таблицы expenses, PostgreSQL, Alembic для миграций, Pydantic-схемы. Авторизацию пока не трогаем, это следующий шаг». Вайбкодинг — это не «делегируй и забудь», а «ставь задачу и контролируй результат». Ты — продакт-менеджер своего кода.
6. Ошибка? Напиши «исправь». Повтори 15 раз
Ошибка в консоли. Копируешь → вставляешь → «исправь». Модель что-то поменяла, появилась новая ошибка. «Исправь». Ещё одна. «ИСПРАВЬ». Через 20 минут код разросся вдвое, работает хуже, чем вначале, а в git log (если он у тебя вообще есть) написано «fix», «fix2», «fix pls», «fix final», «fix final real».
Это лечение головной боли гильотиной. Модель без контекста не чинит причину, а прячет симптом. Каждое «исправление» — это обходной путь поверх предыдущего обходного пути. Код превращается в архитектурную лазанью: слоёв много, но есть невозможно.
Мой личный рекорд: 11 итераций «исправь» подряд, после которых модель начала отменять свои предыдущие исправления. То есть баг совершил полный кругосветный маршрут и вернулся в исходную точку. С сувенирами в виде трёх лишних try/except и одного бессмысленного time.sleep(2), который, видимо, был добавлен из надежды, что баг просто устанет и уйдёт сам.
Противоядие: перед тем как написать «исправь», прочитай ошибку. Traceback — не ругательство, а карта. Найди строку, пойми, что сломалось. Потом напиши: «TypeError в строке 42: функция ожидает list, получает None. Похоже, fetch_data() возвращает None при пустом ответе. Как лучше обработать этот edge case?» Один хороший промпт бьёт пятнадцать слепых «исправь».
7. Git — для корпоратов. У тебя есть Ctrl+Z и папка «проект_финал_v2_FINAL(3)»
Система контроля версий — это для команд. Ты же один. У тебя есть «Отменить» в редакторе и файловая система с богатым именованием. app.py, app_backup.py, app_old.py, app_DO_NOT_DELETE.py. Кому нужен Git?
Тебе. Git нужен тебе.
Первая причина прагматическая: ты попросил модель «отрефакторить» файл, она весело переписала 200 строк — и оно перестало работать. Ctrl+Z отматывает последние пять правок. А тех 200 строк больше нет. Всё. Предыдущая версия утрачена, как Атлантида.
Вторая причина карьерная: работодатели смотрят GitHub. И «Initial commit» с 50 файлами и идеальным кодом — это красный флаг. Это говорит либо «я сгенерировал всё за один присест», либо «я не умею пользоваться Git». Оба варианта плохие. А вот аккуратная история коммитов с внятными сообщениями — это история твоих решений. Доказательство того, что ты думал, а не просто копировал.
Противоядие: git init — первая команда в любом проекте. Коммить маленькими осмысленными порциями. «Add expense validation», «Fix Unicode handling in CSV parser», «Refactor DB queries to use parameterized statements». Это не занудство, а профессионализм.
8. Одна модель на все случаи жизни
Ты влюбился в ChatGPT? Прекрасно. Используй его для всего: код, SQL, DevOps, резюме, письма бабушке. Зачем пробовать что-то ещё, если уже есть «тот самый»?
Это ловушка первой любви. Ты привыкаешь к одной модели, упираешься в её ограничения — и решаешь, что это ограничения ИИ в целом. GPT плохо работает с длинным контекстом, а ты делаешь вывод, что модели не тянут большие проекты. Одна модель слабо пишет тесты, а ты думаешь, что ИИ не умеет в тестирование.
При этом CLI-агенты вроде Claude Code работают совершенно иначе, чем чат. Copilot в IDE — это третий опыт. Cursor — четвёртый. Каждый инструмент хорош в своём контексте: один лучше рефакторит, другой генерирует тесты, третий лучше держит контекст всего проекта.
Противоядие: пробуй разные модели для разных задач. Ищи не «лучшую», а подходящую. Хороший вайбкодер — это не фанат одной модели, а дирижёр оркестра. У него скрипки для мелодии и барабаны для ритма, а не одна волынка на все случаи жизни.
9. Портфолио не нужно. Промпты — вот твой главный скил
Зачем портфолио, если можно прямо на собеседовании попросить модель написать всё, что нужно? Покажешь им мастер-класс по промптингу в реальном времени. Это же будущее, они оценят.
Они не оценят.
Вариант А: тебе дают тестовое без доступа к ИИ. Ты сидишь перед пустым редактором, как пианист, который учился играть только с автоаккомпанементом. Пальцы помнят клавиши, но мелодию вытянуть не могут.
Вариант Б (хуже): тебе дают тестовое с доступом к ИИ и просят объяснить каждое решение. «Почему тут useCallback, а не useMemo?» — «Ну... потому что модель так написала». Занавес.
Противоядие: собирай портфолио из проектов, которые можешь объяснить вдоль и поперёк. В README пиши не только что проект делает, но и почему ты принял конкретные решения. «Выбрал SQLite вместо PostgreSQL, потому что это однопользовательское десктопное приложение и мне не нужен сетевой доступ к БД» — одно это предложение стоит дороже, чем 500 строк сгенерированного кода. Потому что за ним стоит понимание.
10. Фундамент — это прошлый век. Нынче главное — промпт-инжиниринг
Алгоритмы, структуры данных, сети, паттерны проектирования — кому всё это нужно в 2026-м? Главный навык современности — уметь формулировать промпт. Зачем знать, как работает хеш-таблица, если модель напишет любой словарь?
А затем, что без фундамента ты не сможешь отличить хороший сгенерированный код от плохого. Модель предложила вложенный цикл по двум массивам по 100 000 элементов? O(n²) на ровном месте, но ты этого не видишь — и пропускаешь. Модель выбрала пузырьковую сортировку? Звучит мило, «пузырьки» — что может пойти не так? А потом продакшен ложится, когда данных становится больше, чем три тестовые записи.
Или вот: модель написала SQL-запрос, который на 100 строках работает за 5 мс, а на 100 000 — за 40 секунд. Если ты знаешь, что такое индекс и EXPLAIN, ты это поймаешь на ревью. Если не знаешь, поймаешь в три часа ночи, когда позвонит мониторинг.
Противоядие: используй модель как репетитора, а не как замену знаниям. «Объясни, почему тут лучше set, а не list, для проверки вхождения». «Какая сложность у этого алгоритма и можно ли лучше?». «В чём разница между JOIN и подзапросом в этом случае?». ИИ — отличный учитель. Но учиться всё ещё нужно тебе.
Бонус: тест на зависимость
Открой свой последний проект. Выключи Wi-Fi. Попробуй добавить что-нибудь простое — фильтрацию списка, валидацию формы, пагинацию.
Если через 15 минут ты сидишь и смотришь в экран, как в бездну, — эта статья была для тебя.
И это ладно. Это нормально. Мы все через это проходили. Главное — заметить это сейчас, а не в момент, когда HR спросит: «А расскажите поподробнее про ваш проект».
Вместо заключения
Вайбкодинг — отличный инструмент. Но «умею генерировать код» — это примерно как «умею заказывать еду через Delivery Club». Техническая грамотность, понимание архитектуры, способность читать чужой код (включая код, который модель написала «за тебя») — вот что отличает разработчика от оператора промптов.
LLM — это джуниор-разработчик с энциклопедическими знаниями и нулевой ответственностью. Он напишет всё, что попросишь. Он не скажет «стой, это плохая идея». Он не остановится и не спросит «а ты уверен?». Это твоя работа — думать, проверять, принимать решения.
И чем раньше ты начнёшь это делать, тем быстрее перестанешь быть «тем парнем, который вайбкодит» и станешь тем, кого нанимают.
А если тебе кажется, что ни один из десяти пунктов — не про тебя, перечитай шестой. Он точно про тебя.