Вайбкодинг без ревью: код, который никто не читал, и что это даёт бизнесу

Четыре месяца назад Flowwow разрешил сотрудникам без инженерного бэкграунда выкатывать в прод приложения, написанные ИИ-агентом. Итог, зафиксированный в разборе на Habr: более 260 проектов от 150 человек, код не читал ни один программист. Новость не в том, что ИИ пишет код: к этому уже привыкли. Новость в том, что компания сознательно отказалась от чтения кода глазами инженера и работает так месяцами, а не днями.

Считать выгоду надо не в сэкономленных часах разработчика, а в закрытых задачах, которые раньше не доходили до очереди. Внутренняя автоматизация живёт по жестокому правилу: если инструмент экономит два часа в месяц, инженера на него не выделят никогда. Этот пласт задач размыкается, когда сотрудник собирает инструмент сам: 260 проектов за четыре месяца — около 65 новых приложений в месяц (наш расчёт по данным разбора). Даже если часть из них эксперименты, речь о рутине, которая до появления агента не автоматизировалась.

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

Если код никто не читает, читать нужно контур вокруг него. Проверка исходников — лишь один способ снизить риск; его заменяют изоляцией среды, ограничением доступов, отсечением денег и публичности от действий приложения. Песочница здесь не деталь, а несущая стена: без неё правило «инженер не смотрит код» превращается в лотерею. В разборе не раскрыто, какие права выданы приложениям, к каким данным они имеют доступ и как контролируется вывод наружу. Это первые вопросы, если вы собираетесь повторить подход.

Есть и то, о чём разбор молчит, а собственнику знать обязательно. 260 приложений — это 260 объектов, которые могут упасть, и у каждого есть автор, но не обязательно владелец. Не раскрыто, кто сопровождает проекты и что происходит с инструментом, когда автор уходит. Не ясно, как считаются ошибки, попадают ли туда данные клиентов и как это соотносится с 152-ФЗ. Это не повод не пробовать — это чек-лист вопросов, на которые лучше ответить до первого выката, а не после инцидента.

1. Автор задачи — лучший автор инструмента. Сотрудник, который ежедневно сводит одну и ту же выгрузку вручную, описал процесс агенту и получил рабочий инструмент, минуя очередь к инженеру. Обобщение: там, где исполнитель собирает инструмент сам, исчезает потеря на переводе требований — и повод не автоматизировать мелочь.
2. Разрешение масштабнее инструмента. 150 авторов за четыре месяца — не пилот на одном отделе, а право писать, выданное широко по компании. Обобщение: доступ для одного отдела даёт локальный эффект, который умрёт после первого же инцидента; объём результата создаёт именно ширина доступа.
3. Отказ от ревью кода компенсируется жёстким контуром. Раз инженер не смотрит исходники, границы задаёт среда: что доступно приложению, к каким данным, какие действия оно может совершить. Обобщение: нельзя одновременно не проверять код и не ограничивать среду — один из двух барьеров должен быть на месте всегда.
4. Считайте стоимость владения, а не только создания. 260 проектов — это 260 объектов на сопровождении, а не строчка в отчёте. Обобщение: до запуска практики определите владельца каждого инструмента, порядок вывода из эксплуатации и то, что происходит, когда автор перестаёт им заниматься.
5. Правила пишутся до инцидента. Если код не читает программист, вопрос «кто отвечает, когда падает» требует ответа заранее. Обобщение: отсутствие ревью — это не отсутствие ответственности, а её перенос на регламент, контур и конкретного владельца продукта.

««Вайбкодинг: запретить нельзя возглавить»»

Двойное чтение этого заголовка — развилка для любого бизнеса. «Запретить нельзя» — путь, при котором ИИ-разработка остаётся тенью, а сотрудники всё равно пользуются агентами, только без контура и правил. «Нельзя возглавить» — путь, при котором право писать дают официально, вместе с песочницей, ответственными и учётом. Кейс Flowwow — попытка пройти вторым маршрутом; открытым остаётся вопрос, чем компания платит за это через год.