Вайбкодинг — это когда вы описываете задачу на человеческом языке, модель генерирует код, вы запускаете — и оно работает. Иногда. Какое-то время.
А потом вы на собеседовании и не можете объяснить, что делает ваш собственный проект. И произносите: «Ну... оно как бы... в общем, я сейчас промпт покажу».
Я — ML-разработчик, соавтор и ревьюер курсов по нейросетям. За последний год я не раз видел, как люди осваивают вайбкодинг, создают проекты с невероятной скоростью — и в итоге строят не карьеру, а карточный домик. Сценарий настолько типичный, что я оформил его в виде вредных советов — чтобы было весело читать и неловко узнавать себя.
1. Копируй код, не читая. Модель же умная
Если LLM выдала код — значит, он правильный. Зачем разбираться в async или useEffect, если можно просто попросить «сделай, чтобы данные подгружались»? Вы же не хирург — вам не нужно знать, что внутри пациента. Ну, то есть проекта.
Это самый сладкий антипаттерн. Код работает, дофамин идёт, зачем портить кайф чтением? Я сам так делал: два дня генерировал React-приложение, а на третий не мог найти, где рендерится одна кнопка. В собственном проекте я ориентировался как турист в токийском метро.
На собеседовании это выглядит ещё хуже. Вас просят добавить фичу — и вы сидите, как студент, который купил дипломную работу и теперь объясняет комиссии: «ну, тут такой подход, потому что... потому что так получилось».
Противоядие: прежде чем вставить код, прочитайте его. Если видите незнакомую конструкцию — спросите модель: «объясни эту строку, как будто мне 10 лет». Это займёт минуту. Зато через неделю вы будете ловить баги глазами, а не пятнадцатым промптом.
2. Тесты — для трусов и бюрократов
Тесты — для тех, кто не уверен в себе. А вы уверены. LLM написала код. Если бы что-то было не так, она бы сказала. Правда?
Любимый сценарий: проект готов, всё работает локально. Показываете заказчику — он вводит имя кириллицей в поле, которое вы тестировали только латиницей. Приложение падает. Без ошибки. Просто белый экран и экзистенциальная пустота.
Или: вы пишете 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. Запросы к БД — параметризованные. Входные данные — валидируются. И попросите модель провести аудит: «проверь код на уязвимости из OWASP Top 10». Она не найдёт всё, но очевидные дыры закроет.
5. Не ставь задаче границ. Пусть ИИ сам разберётся, что ты хотел
«Сделай приложение для учёта финансов». Точка. Промпт закончен. Какие тут БД, роли, аутентификация — пусть модель решает.
Модель не умеет читать мысли. Но делает вид, что умеет. Вы получите монолит на 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», «Refactor DB queries». Это не занудство, а профессионализм.
8. Одна модель на все случаи жизни
Вы влюбились в ChatGPT? Отлично. Используйте его для всего: код, SQL, DevOps, резюме, письма бабушке. Зачем пробовать что-то ещё?
Это ловушка первой любви. Вы привыкаете к одной модели, упираетесь в её ограничения — и думаете, что это ограничения ИИ в целом. GPT плохо с длинным контекстом — и вы решаете, что ИИ не тянет большие проекты. Одна модель слабо пишет тесты — и вы думаете, что ИИ вообще не умеет в тестирование.
CLI-агенты вроде Claude Code работают иначе. Copilot в IDE — это третий опыт. Cursor — четвёртый. Каждый инструмент хорош в своём контексте: один лучше рефакторит, другой генерирует тесты, третий держит контекст проекта.
Противоядие: пробуйте разные модели для разных задач. Хороший вайбкодер — не фанат одной модели, а дирижёр оркестра. У него скрипки для мелодии и барабаны для ритма, а не одна волынка на все случаи.
9. Портфолио не нужно. Промпты — вот твой главный скил
Зачем портфолио, если можно на собеседовании попросить модель написать всё? Покажете мастер-класс по промптингу. Это же будущее, они оценят.
Они не оценят.
Вариант А: вам дают тестовое без доступа к ИИ. Вы сидите перед пустым редактором, как пианист без автоаккомпанемента. Пальцы помнят клавиши, но мелодию вытянуть не могут.
Вариант Б: вам дают тестовое с доступом к ИИ и просят объяснить каждое решение. «Почему тут useCallback, а не useMemo?» — «Ну... потому что модель так написала». Занавес.
Противоядие: собирайте портфолио из проектов, которые можете объяснить вдоль и поперёк. В README пишите не только что делает проект, но и почему вы приняли решения. «Выбрал SQLite, потому что это однопользовательское десктопное приложение» — одно такое предложение стоит дороже 500 строк сгенерированного кода. Потому что за ним стоит понимание.
10. Фундамент — это прошлый век. Нынче главное — промпт-инжиниринг
Алгоритмы, структуры данных, сети, паттерны — кому это нужно в 2026-м? Главный навык — уметь формулировать промпт. Зачем знать, как работает хеш-таблица, если модель напишет любой словарь?
А затем, что без фундамента вы не отличите хороший сгенерированный код от плохого. Модель предложила вложенный цикл по двум массивам по 100 000 элементов? O(n²) на ровном месте, но вы этого не видите. Модель выбрала пузырьковую сортировку? Звучит мило. А потом продакшен ложится, когда данных становится больше, чем три тестовые записи.
Или: модель написала SQL-запрос, который на 100 строках работает за 5 мс, а на 100 000 — за 40 секунд. Если вы знаете, что такое индекс и EXPLAIN, вы поймаете это на ревью. Если нет — в три часа ночи, когда позвонит мониторинг.
Противоядие: используйте модель как репетитора, а не замену знаниям. «Объясни, почему тут лучше set, а не list». «Какая сложность у этого алгоритма и можно ли лучше?». «В чём разница между JOIN и подзапросом?». ИИ — отличный учитель. Но учиться всё ещё нужно вам.
Бонус: тест на зависимость
Откройте свой последний проект. Выключите Wi-Fi. Попробуйте добавить фильтрацию списка, валидацию формы, пагинацию.
Если через 15 минут вы сидите и смотрите в экран, как в бездну, — эта статья была для вас.
И это нормально. Мы все через это проходили. Главное — заметить это сейчас, а не когда HR спросит: «А расскажите поподробнее про ваш проект».
Вместо заключения
Вайбкодинг — отличный инструмент. Но «умею генерировать код» — это как «умею заказывать еду через Delivery Club».
Техническая грамотность, понимание архитектуры, способность читать чужой код (включая код, который модель написала «за вас») — вот что отличает разработчика от оператора промптов.
LLM — это джуниор-разработчик с энциклопедическими знаниями и нулевой ответственностью. Он напишет всё, что попросите. Он не скажет «стой, это плохая идея». Он не остановится и не спросит «а ты уверен?». Это ваша работа — думать, проверять, принимать решения.
Чем раньше вы начнёте это делать, тем быстрее перестанете быть «тем парнем, который вайбкодит» и станете тем, кого нанимают.
А если кажется, что ни один из десяти пунктов — не про вас, перечитайте шестой. Он точно про вас.