// Блог

Вайбкодинг в эпоху ИИ: когда код пишется по настроению

Вайбкодинг в эпоху ИИ: когда код пишется по настроению

В мире разработки традиционно существовало два подхода к созданию программ.

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

Второй — менее формальный.

Вайбкодинг.

Это когда разработчик открывает редактор кода, ловит поток, включает музыку… и начинает писать код по вайбу. Несколько лет назад это было скорее шуткой внутри индустрии. Но с развитием генеративного ИИ вайбкодинг неожиданно получил вторую жизнь.

Теперь код пишется не только по настроению, но и по подсказке нейросети.

Иногда результат получается впечатляющим.
Иногда — смешным.
А иногда — дорогостоящим.

Разберёмся, что происходит.

Что такое вайбкодинг

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

Не через архитектурные диаграммы, а через ощущение:

“Сейчас сделаем вот так. Кажется, будет нормально.”

Типичные признаки вайбкодинга:

  • архитектура формируется по ходу разработки
  • код пишется “как пойдёт”
  • документация появится… возможно
  • тестирование происходит методом “ну вроде работает”

Вайбкодинг чаще всего встречается:

  • в стартапах на ранних стадиях
  • в пет-проектах
  • при создании прототипов
  • в пятницу вечером, когда “надо просто доделать”

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

— Почему здесь три уровня вложенных if? — Так получилось. Был вайб.

Почему вайбкодинг вообще работает

Как ни странно, у этого подхода есть свои плюсы.

Именно поэтому он периодически возникает в любой команде.

Скорость

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

Это полезно, когда нужно:

  • быстро проверить идею
  • собрать демо
  • протестировать гипотезу

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

Творческий поток

Многие хорошие идеи появляются именно в состоянии потока. Разработчик просто решает одну задачу за другой, не думая о том, что через год этот код кто-то будет читать.

Спойлер: этим “кто-то” обычно оказывается он сам.

Низкий психологический барьер

Иногда главная проблема — не технология, а страх начать. Вайбкодинг снимает этот барьер.

Фраза:

“Нужно всё идеально спроектировать”

заменяется на:

“Давайте просто попробуем”.

И благодаря этому иногда вообще появляется первый прототип продукта.

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

Проблемы начинаются в момент, когда вчерашний прототип становится продакшен-системой.

Типичный сценарий выглядит так:

  1. разработчик быстро делает MVP
  2. всё неожиданно начинает работать
  3. появляются пользователи
  4. проект растёт
  5. кто-то открывает код

…и начинается археология.

В таких проектах часто можно увидеть:

  • функции по 300–400 строк
  • переменные temp2, data_new_final, really_final
  • бизнес-логику внутри шаблонов
  • комментарии // TODO: исправить позже пятилетней давности

В этот момент команда начинает задавать философские вопросы:

  • “Почему это работает?”
  • “Почему это иногда не работает?”
  • “Кто это написал?”

Вайбкодинг в эпоху ИИ

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

Цикл вайбкодинга

Теперь процесс часто выглядит иначе:

  1. разработчик формулирует задачу
  2. спрашивает ИИ
  3. получает готовый код
  4. вставляет его в проект
  5. переходит к следующей задаче

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

Так появился новый архетип.

Новый тип разработчика: вайбкодер

Вайбкодер не изучает документацию.

Он задаёт правильные вопросы нейросети.

Пример рабочего процесса:

— Как реализовать загрузку файлов?
— Вот пример на 120 строк.
— Спасибо.

Файл загружается. Задача закрыта.

Через неделю выясняется:

  • ограничений на размер файла нет
  • типы не проверяются
  • путь к файлу можно подменить
  • часть файлов сохраняется в публичную директорию

И начинается расследование.

— Кто писал этот код?
— ИИ.
— А кто вставил его в проект?
— …

Почему это происходит

ИИ отлично генерирует правдоподобные решения.

Но он не знает контекста проекта.

Он не видит:

  • архитектуру системы
  • бизнес-логику
  • ограничения инфраструктуры
  • будущие сценарии развития

Он просто выдаёт рабочий фрагмент кода.
Если разработчик не анализирует результат, получается то, что можно назвать: копипаст-разработкой нового поколения.

Очень типичный пример

Разработчик спрашивает у ИИ:

“Напиши простой API на PHP для получения пользователя по id.”

ИИ отвечает:

<?php

$id = $_GET['id'];

$pdo = new PDO("mysql:host=localhost;dbname=test", "root", "");

$query = "SELECT * FROM users WHERE id = $id";
$stmt = $pdo->query($query);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

echo json_encode($user);

Разработчик радуется:

— Отлично, API готов.

Код отправляется в продакшен.

Через некоторое время выясняется:

  • возможна SQL-инъекция
  • если id не передан — падает ошибка
  • если пользователь не найден — API возвращает false
  • нет заголовков JSON
  • нет обработки ошибок базы
  • нет авторизации

Но формально API работает.

Через пару месяцев новый разработчик открывает этот файл и спрашивает:

“А почему запрос к базе собирается строкой?”

Ответ обычно звучит так:

“Я спросил у ИИ, он так предложил.”

А правильная версия выглядела бы хотя бы так:

<?php

$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);

if (!$id) {
    http_response_code(400);
    echo json_encode(['error' => 'Invalid id']);
    exit;
}

$pdo = new PDO(
    "mysql:host=localhost;dbname=test;charset=utf8mb4",
    "root",
    "",
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

header('Content-Type: application/json');

echo json_encode($user ?: []);

Кода стало немного больше.

Но теперь:

  • нет SQL-инъекции
  • есть проверка входных данных
  • есть корректные заголовки
  • API ведёт себя предсказуемо

Именно в этом и проходит граница между: вайбкодингом и инженерной разработкой.

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

Любимая тема — регулярные выражения

Ещё один классический пример.

Разработчик спрашивает:

“Напиши регулярное выражение для проверки email.”

ИИ отвечает:

^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$

Все довольны.

Пока не выясняется:

  • часть реальных email не проходит
  • часть некорректных проходит
  • стандарт RFC для email занимает десятки страниц

Но проверка же есть.

Главная проблема — исчезает мышление

Самая опасная часть вайбкодинга с ИИ не в коде.

Она в мышлении разработчика.

Когда ответы всегда рядом, появляется соблазн:

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

Раньше программист искал решение и вынужденно разбирался.

Теперь можно просто принять первый ответ.

На короткой дистанции это выглядит как невероятная продуктивность.

На длинной — как ускоренное накопление технического долга.

К чему приводит массовый вайбкодинг

Если система развивается таким способом, возникают характерные симптомы.

Кодовая база превращается в мозаику

Разные части системы написаны:

  • в разном стиле
  • с разной архитектурой
  • с разными подходами

Потому что каждая часть генерировалась отдельным ответом ИИ.

Никто не понимает систему целиком

Даже автор.

Потому что код собирался из:

  • фрагментов
  • подсказок
  • быстрых решений

Ошибки становятся странными

Они не очевидны.

Их сложно воспроизвести. Иногда они проявляются только при определённых условиях.

Любая доработка становится рискованной

Изменение одного модуля неожиданно ломает другой.

В такой системе появляется классический вопрос:

“Если мы удалим этот кусок кода, что сломается?”

Ответ обычно звучит так:

“Лучше не проверять.”

Но ИИ — это всё равно огромный плюс

Важно понимать: проблема не в ИИ.

ИИ — невероятно мощный инструмент.

Он отлично помогает:

  • писать рутинный код
  • ускорять разработку
  • искать решения
  • объяснять сложные вещи

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

ИИ может предложить решение.

Но инженер должен понять:

  • подходит ли оно архитектуре
  • масштабируется ли оно
  • безопасно ли оно
  • не создаёт ли скрытых проблем

Как профессиональные команды используют ИИ

В профессиональной разработке ИИ обычно используется иначе.

Процесс выглядит примерно так:

  1. ИИ генерирует черновой код
  2. разработчик его анализирует
  3. код адаптируется под архитектуру проекта
  4. проходит ревью
  5. покрывается тестами

То есть ИИ ускоряет работу, но инженерия остаётся инженерией.

В этом и заключается разница между:

  • использованием ИИ и
  • вайбкодингом с ИИ.

Итог

ИИ дал разработчикам невероятную скорость. Но вместе со скоростью пришёл соблазн: не думать.

Именно поэтому вайбкодинг стал таким заметным явлением.

Можно быстро собрать прототип. Можно даже собрать работающий продукт.

Но если система строится только из:

  • подсказок
  • фрагментов
  • решений “кажется работает”

рано или поздно наступает момент, когда кто-то открывает репозиторий и задаёт главный вопрос:

“А кто написал весь этот код?”

И ответ звучит примерно так:

“Мы… и немного ИИ.”

А дальше начинается то, что разработчики называют самым дорогим этапом проекта:

разобраться, как это всё работает.

Статья опубликована в разделах:
Статьи
Искусственный интеллект ИИ AI