С чего всё началось

Мы сделали HighVibe — сервис для команд, которые пишут код с помощью ИИ и не хотят выпускать изменения вслепую.

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

Без длинных отчётов и абстрактных формулировок. Просто:

  • здесь появился запасной ключ
  • здесь новая зависимость
  • здесь доступ стал шире
  • это лучше не сливать, пока не поправите

Мы к этому пришли не потому, что «так надо рынку», а потому что сами начали упираться в одну и ту же проблему.

Вайб-кодинг уже стал рабочей реальностью

Термин можно обсуждать сколько угодно, но факт простой: команды уже пишут код с ИИ.

Кто-то использует его для отдельных задач.

Кто-то — почти для всего процесса.

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

Но вместе со скоростью появилась другая вещь — код стал появляться быстрее, чем его успевают нормально проверять.

Как сейчас выглядит обычный рабочий день

Представим простую задачу:

доделать авторизацию, дописать интеграцию или немного отрефакторить код.

Раньше:

человек разбирается в коде → пишет → проверяет → допиливает → коммитит

Сейчас:

описывает задачу → получает код → немного правит → просит починить ошибки → просит сделать тесты → получает pull request

Тесты зелёные. Интерфейс работает.

Дальше подключается ревьюер. Открывает diff, смотрит по диагонали, видит знакомые куски и думает: «вроде ок».

Approve.

Это не про лень. Это про объём.

Кода стало больше. Времени на его чтение — столько же.

Что поменялось в процессе

Если разложить по шагам:

Раньше:

написал → понял → проверил → смержил

Сейчас:

сгенерировал → поправил → смержил

Шаг «понял» никуда не исчез полностью. Но стал заметно слабее.

Особенно когда код выглядит аккуратно и уверенно.

Где здесь риск

Проблема не в том, что ИИ иногда ошибается. Люди тоже ошибаются.

Разница в другом:

ИИ пишет быстро, много и выглядит убедительно.

Из-за этого появляется ощущение, что код «скорее нормальный».

И вот здесь проверка становится поверхностной.

Какие проблемы чаще всего пропускают

Это не что-то экзотическое. Обычно это скучные вещи.

Секреты

Тестовый ключ, временный токен, кусок конфигурации.

Иногда видно сразу. Иногда уезжает в файл, который никто не открывает.

Зависимости

ИИ предлагает подключить библиотеку.

Разработчик принимает, не проверяя:

  • что это за пакет
  • насколько он актуальный
  • что он тянет за собой

Авторизация и доступы

Самые чувствительные места — самые незаметные.

  • упростили проверку
  • оставили временный обход
  • расширили доступ «на всякий случай»

Работает — да.

Безопасно — не факт.

Конфиги

  • CORS открыт шире, чем нужно
  • debug-режим забыли выключить
  • права выданы с запасом

На ревью такие вещи легко не заметить.

Почему сканеры не решают проблему полностью

У многих команд уже есть:

  • SAST
  • проверки зависимостей
  • сканеры секретов

И это правильно.

Но у них другая задача.

Они отвечают на вопрос:

что потенциально не так в проекте?

А команде в моменте нужен другой ответ:

можно ли принять вот это конкретное изменение?

Особенно когда изменения приходят быстрее обычного.

Почему нельзя «написать всё, а потом проверить»

На первый взгляд — нормальный подход.

На практике он разваливается.

Пока pull request небольшой — ещё можно быстро разобраться.

Когда изменений становится много — проверка превращается в отдельную задачу.

Плюс теряется контекст:

  • зачем добавили библиотеку
  • почему оставили ключ
  • откуда взялся широкий доступ

Через пару дней это уже просто часть кода.

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

Тесты зелёные, дедлайн близко — любые замечания начинают мешать.

В итоге проверка становится формальностью.

Что с этим делать

Запрещать ИИ — бессмысленно.

Заставлять читать каждый diff полностью — не работает.

Нужен промежуточный вариант.

Нужен способ быстро понять:

это изменение можно выпускать или нет?

Как это решает HighVibe

HighVibe добавляет дополнительную проверку перед merge и релизом.

Он смотрит на изменение целиком:

  • код
  • зависимости
  • сопутствующие файлы

И даёт короткий ответ:

  • где есть риск
  • почему это риск
  • что с этим делать

Как это выглядит в работе

Есть pull request.

HighVibe смотрит и говорит:

здесь слишком широкий доступ

Дальше — рекомендация:

  • перепроверить
  • или не сливать, пока не поправят

Иногда мягче:

код выглядит нормально, но появилась новая зависимость — лучше проверить перед релизом

Смысл — не тормозить всё подряд, а подсветить места, где реально нужен второй взгляд.

Почему без этого становится сложнее

Раньше объём изменений был меньше — их можно было внимательно читать.

Сейчас один разработчик с ИИ может сделать за день столько, сколько раньше делал за несколько дней.

А процесс проверки часто остался прежним.

В итоге он начинает отставать.

Почему без такого слоя уже не обойтись

Если команда активно использует ИИ, у неё неизбежно:

  • больше кода
  • больше зависимостей
  • больше временных решений
  • меньше времени на ревью

Это не проблема людей. Это свойство процесса.

И если ничего не менять, ошибки начинают проскакивать.

Не обязательно сразу критичные. Но они накапливаются.

Что это значит для команд

HighVibe — это не замена всему стеку безопасности.

Это слой поверх него.

Он нужен не «вообще для безопасности», а в конкретной точке — перед принятием изменения.

Когда ещё можно что-то поправить без боли.

Итог

Вайб-кодинг уже стал частью разработки.

Кода стало больше. Пишется он быстрее.

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

Нужен быстрый ответ в моменте:

это изменение можно принимать или нет?

Именно этот вопрос и закрывает HighVibe.

Потому что выпускать AI-код на доверии — плохая стратегия.