Почему ИИ‑разработка не равна вайбкодингу и что с нами будет дальше

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

Разработчики на этом фоне разделились на два лагеря. Одни демонстративно сторонятся ИИ или прямо его отрицают. Другие бросили штурвал: шлют в чат «давай дальше», «сделай красиво» и пьют кофе, пока агент разбирается сам. Я хочу рассказать про третий путь, потому что обе крайности одинаково не работают.

Как это выглядело в 2019

Я начал использовать нейросети в работе еще тогда, когда большинство считало это чем‑то вроде научных игрушек, далеких от практики. Вау‑эффекта не было. Были черновики SEO‑текстов, аудио и визуальные артефакты, которые экономили время на старте задачи и помогали быстрее нащупать идею.

Потом появились Artbreeder, Amper Music и целая россыпь разношерстных LLM, и это уже начало влиять на реальную работу: продвижение идей, подготовку текстов, местами даже прод. Как только появились модели, которые прилично писали код и отдавали это через доступный API, я сразу начал внедрять их в Unity и Jenkins для анализа логов и кода. Кажется, одним из первых в своем окружении собрал десктопное приложение с адаптерами под разные модели для внутреннего использования в компании.

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

Первый провал: вайб на уровне всего проекта

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

На практике вышло иначе. Изучение и правки за агентом занимали больше времени, чем если бы я сразу сделал все руками. Запрос, ожидание ответа, копирование, вставка, проверка. Ощущение скорости пьянило, но оно же отдаляло от понимания собственного проекта, а разбираться потом все равно приходилось вручную.

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

Правило инкапсуляции

С этого момента я стал делать отдельные блоки, обкладывать их тестами, и если блок стабильно давал нужный результат на разных кейсах, дальше не разбирал, как он устроен внутри. Он работает, он независим, он укладывается в нужное время: что еще от него нужно? Мы же не читаем исходники каждой DLL, которую подключаем в проект. Здесь работает тот же принцип.

До появления моделей с большим контекстным окном, способных прочитать значительную часть проекта за один проход, это решение сильно поднимало скорость. На ревью коллеги все равно интересовались, как оно устроено внутри и нельзя ли сделать иначе, но суть была в другом: если блок работает, трогать его без причины не нужно. В разработке в конечном счете решают не красота кода и не архитектура сама по себе. Решает то, сколько стоит поддержка и сколько денег приносит продукт. Если код пишется быстрее и требует меньше поддержки при росте, он полностью выполняет свою функцию. Приучить к этому команду получалось с переменным успехом.

От компонентов к фичам

С каждым новым поколением моделей масштаб задачи, которую можно доверить агенту, рос. Раньше это был компонент, теперь целая фича со связкой интеграционных тестов. CI/CD удалось заметно оптимизировать, а собственные плагины и системы для Unity стало выгоднее писать самим: адаптировать под себя чужие решения из стора вышло дороже.

При этом чистый вайбкодинг все так же перегружал QA, давал постоянные регрессы и рано или поздно заставлял лезть под капот проекта. Тогда я и пришел к ролевой ИИ‑разработке.

Ролевая система: архитектор, разработчик, публикатор

Идея простая: вместо одного агента на все руки держим несколько независимых ролей, каждая в своем чате.

Архитектор не пишет код. Он получает описание фичи так, как если бы мы объясняли ее человеку, и на основе текущего состояния проекта готовит план разработки для продакшена.

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

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

Раньше у меня этот чат просто писал файл с саммари для вставки в другие инструменты, сейчас делает то же самое через MCP, отправляя отчеты в таск‑трекер и мессенджеры.

Схема работы такая: по плану архитектора идет разработчик. После важного этапа или группы связанных изменений можно вернуться к архитектору и попросить оценить работу по дереву изменений. Он находит проблемы, оформляет их как коррективы, и они уходят обратно разработчику на доработку. Когда план закрыт и у архитектора нет замечаний, тестируем сами и передаем публикатору. Если все хорошо, отправляем.

Это ощутимо подняло качество и заодно расходы на подписки и API, но выхлоп того стоил.

Почему разработчик живет недолго

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

По мере развития Cursor, Claude и Codex у каждого семейства моделей нашлись свои сильные кейсы, и со временем стало неэффективно держаться одного инструмента. Я пробовал автоматические системы, где агенты в песочнице сверяют друг друга без моего участия, и это правда освобождает время. Но чаще на практике использую обычное перекрестное копирование между чатами, просто потому что одновременно запущенных агентов и проектов слишком много, чтобы доверить всю цепочку автоматике.

Декларации и контракты до старта агентов

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

Если проект стартует с нуля, тут проще всего. Определяетесь со стеком, смотрите на актуальные решения и опыт похожих проектов, и составляете файлы CODEX, CLAUDE, AGENTS так, чтобы все они ссылались на один общий документ. В нем стек для бэкенда и фронта, границы ответственности, границы модулей, правила работы с зависимостями, требования к тестам, безопасности и обработке ошибок. Это тоже можно делать через агентов, и после настройки архитектору всегда есть с чем сверять прогресс.

Здесь есть нюанс: даже сильные модели склонны все усложнять, поэтому промежуточные чекапы на оверинжиниринг обязательны. Чем больше сложности в системе, тем больше токенов и денег уходит на поддержку и дальнейшую разработку.

public static float GetVisibleTargetDistance(
    Transform observer,
    Transform target,
    float radius,
    float fieldOfView)
{
    Vector3 toTarget = target.position - observer.position;
    float distance = toTarget.magnitude;

    if (distance > radius)
        return -1f;

    float angle = Vector3.Angle(observer.forward, toTarget);

    return angle <= fieldOfView * 0.5f
        ? distance
        : -1f;
}

public static bool TryGetVisibleTargetDistance(
    Transform observer,
    Transform target,
    float radius,
    float fieldOfView,
    out float distance)
{
    distance = 0f;

    if (observer == null)
        return false;

    if (target == null)
        return false;

    if (!observer.gameObject.activeInHierarchy)
        return false;

    if (!target.gameObject.activeInHierarchy)
        return false;

    if (radius <= 0f)
        return false;

    if (fieldOfView <= 0f || fieldOfView > 360f)
        return false;

    distance = Vector3.Distance(
        observer.position,
        target.position);

    if (distance > radius)
    {
        distance = 0f;
        return false;
    }

    Vector3 direction =
        target.position - observer.position;

    if (direction.sqrMagnitude <= Mathf.Epsilon)
        return true;

    float angle = Vector3.Angle(
        observer.forward,
        direction);

    if (angle > fieldOfView * 0.5f)
    {
        distance = 0f;
        return false;
    }

    return true;
}

Простота как главный принцип

Если выбирать одно правило над всеми остальными, это будет простота. Любой код, компонент или продукт должен быть простым в использовании и в работе. Усложнить всегда успеете, а вот задача разработчика в том, чтобы этого не допустить. Тогда и разработка, и тестирование остаются в радость. В раскопки они уже не превращаются.

Это не вайб

Вайбкодинг заканчивается там, где начинается ответственность за результат. В этой схеме она есть с первого шага: за план отвечает архитектор, за код разработчик, за релиз публикатор, и никто из них не работает на ощущении «получилось красиво».

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

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

Разрыв, за которым не угнаться

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

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

Легко скатиться в громкое заявление «разработчики больше не нужны». Пока что ИИ требует участия человека, который задает волю и рамку задачи, и моя ролевая схема держится именно на этом. Но это не гарантия навсегда: зона, которую можно отдать агентам, растет, зона ручного контроля сужается. Рано или поздно человек может остаться в роли потребителя, тем, кто выбирает из готового и оценивает результат, примерно как сегодня никто не думает об ассемблере, компилируя на C#. Я в этом убежден.

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

Вместо вывода

Я не осуждаю вайбкодинг. Он хорош для MVP, для поиска идей и для быстрого черновика. Плохо гнать прототип в прод и называть это инженерией. Не нужно воевать с ИИ и не нужно полностью на него полагаться, нужно с ним работать: держать контракты, проверять план, тестировать результат.

Пока воля еще остается за вами. Вопрос в том, пользуетесь вы ей или просто ждете результата.