Что такое вайбкодинг и зачем этот курс

В начале 2025 года Андрей Карпати — один из основателей OpenAI и бывший директор по AI в Tesla — опубликовал короткий пост в X. Он описывал свой рабочий процесс: диктует задачи в Cursor голосом, почти не касается клавиатуры, принимает все изменения не глядя, а когда что-то ломается — просто вставляет сообщение об ошибке обратно в чат без единого комментария. Пост назывался «вайбкодинг» — новый способ писать код, где ты «полностью отдаёшься вайбам и забываешь, что код вообще существует».

Пост набрал 4,5 миллиона просмотров. К концу 2025 года термин «vibe coding» быстро стал вирусным. По разным оценкам, к тому моменту значительная доля написанного в мире кода генерировалось с участием AI.

Что это на самом деле означает

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

Ровно через год — в феврале 2026-го — он вернулся с поправкой. Модели стали значительно умнее, и теперь профессиональный AI-assisted workflow выглядит иначе: не «принять всё не глядя», а управлять агентами с контролем и осмысленным надзором. В индустрии это всё чаще называют agentic engineering — вайбкодинг с инженерной дисциплиной.

Здесь важно различать два полюса. На одном — чистый вайбкодинг: описываешь задачу, принимаешь всё, запускаешь, смотришь работает ли, не читаешь код. Это быстро и иногда достаточно для прототипа или личного инструмента. На другом — ответственная AI-assisted разработка: агент пишет, ты направляешь, проверяешь результат и понимаешь, что происходит. Именно этот подход масштабируется на реальные проекты.

Разница не в инструментах — они одни и те же. Разница в том, как мы с ними работаем.

Что здесь действительно меняется

Узкое место в разработке сместилось. Раньше им была скорость написания кода — сколько строк в день может произвести разработчик. Теперь узкое место — качество постановки задачи и осмысленность надзора за результатом. Код стал дешёвым. Дорогим остаётся понимание того, что именно нужно построить, как это проверить и где агент пойдёт не туда.

Это не значит, что можно не знать, как устроен код. Это значит, что знание архитектуры, паттернов и граничных случаев теперь нужно не для того, чтобы писать каждую строку вручную, а для того, чтобы направлять агента и оценивать его работу. Разработчик становится ближе к роли техлида, чем к роли исполнителя.

Данные это подтверждают, но с оговорками. METR в 2025 году провёл рандомизированный контролируемый эксперимент с опытными open-source разработчиками — и обнаружил, что при наивном использовании AI-инструментов они работали на 19% медленнее, хотя сами ожидали ускорения на 24%. Инструменты дают преимущество тем, кто умеет ими пользоваться — не всем автоматически. Ещё один факт: по данным CodeRabbit, AI-код содержит в 2,7 раза больше уязвимостей безопасности, чем написанный человеком. Код нужно проверять — это не опция.

О чём этот курс

Курс — про инженерный подход к AI-assisted разработке. Не про то, как нажать «принять всё» и надеяться на лучшее, а про то, как осознанно выстраивать рабочий процесс с агентами.

Мы разберём, как устроен рынок инструментов: почему провайдер, модель и агент — это три разных слоя, и как это влияет на выбор стека. Посмотрим на разные классы инструментов — от IDE с встроенным AI до CLI-агентов, работающих с репозиторием целиком — и поймём, какие задачи каждый из них решает лучше. Отдельно разберём, как формулировать задачи для агентов так, чтобы получать предсказуемый и проверяемый результат.

Начнём с карты ландшафта — чтобы при появлении нового инструмента (а они появляются постоянно) было понятно, куда его положить.