Вайбкодинг (vibe coding) — способ писать ПО, описывая намерение модели. AI-assisted coding в команде OtherCode — про процесс: кто имеет право принимать код модели, какие проверки обязательны до merge, как измерять ускорение без самообмана. Это разные статьи и разные риски. Про культуру вайба мы писали отдельно: вайбкодинг. Здесь — как устроена ежедневная инженерная практика студии и почему «просто включить Cursor всем» без правил почти всегда заканчивается либо хаосом в main, либо тихим запретом инструментов, который убивает реальный выигрыш.
Чем AI-assisted coding отличается от вайбкодинга
| | AI-assisted coding (процесс команды) | Вайбкодинг (метод) | |--|--------------------------------------|---------------------| | Фокус | Правила, ревью, метрики, онбординг | Диалог с агентом до рабочего артефакта | | Единица работы | Задача в трекере → MR → CI | Промпт → итерации агента | | Ответственность | Всегда автор MR (человек) | Легко размыть («модель так сделала») | | Допуск | По грейду и зоне продукта | Часто «пока на прототипе» |
Оба подхода используют Cursor, агентов и LLM. Разница — в контракте перед merge. Ускорение без контракта мы разбирали в скорости разработки с AI: считать нужно время до принятого изменения, а не до первого файла от модели.
Инструменты в ежедневной работе
Cursor и агенты в IDE
Типичный день инженера OtherCode:
- автодополнение и точечный рефакторинг в знакомом модуле;
- агент на задачу «добавь тест на этот хендлер» или «объясни этот legacy-файл»;
- чат для черновика SQL / regex / миграции — с последующей ручной правкой.
Агент работает в feature-ветке, без prod-секретов, предпочтительно на локальном docker-compose. Self-hosted GitLab остаётся местом истины для MR и CI.
Где используем осознанно
| Зона продукта | Допустимо для AI-кода | Ограничения | |---------------|----------------------|-------------| | Next.js-сайты, лендинги | UI-секции, SEO-черновики, тесты | Контентные факты — от человека | | Content Factory | Обвязка очередей, админка | Промпты и политики — review техлида | | URAP OCR/NLP | Парсеры зон, тесты схем | Критичные поля — валидация + разметка | | Synapse Stream | Утилиты, дашбордные виджеты | Hot-path потока — усиленный review | | Diom (Flutter) | Экраны на дизайн-системе | Платежи / античит — без авто-accept | | Galvatec / Typhoon STM32 | Черновики тестов на стенде | Прошивка и команды — только человек |
Граница ответственности: кто отвечает за строку
Правило студии, которое не обсуждается:
Автор merge request несёт ответственность за каждую строку, включая сгенерированную.
Формулировки «так предложил Cursor» в ревью не принимаются. Если не понимаешь дифф — не мержишь, дробишь задачу или переписываешь участок. Это защищает и джуниора (не тонет в чужом коде), и заказчика (нет «бесхозных» модулей).
Чеклист PR-ревью для AI-generated кода
Ревьюер (и автор перед Assign) проходит явный список поверх обычного review:
- Понятна цель MR? Одна задача, не «агент заодно поправил соседнее».
- Нет секретов и внутренних URL в коде, фикстурах, комментариях, скриншотах CI.
- Инварианты домена сохранены (деньги, ACL, идемпотентность, OT-команды).
- Тесты покрывают новое поведение; не только happy-path, который сгенерировала модель.
- Нет лишней абстракции «на будущее», которую агенты любят плодить.
- Зависимости не добавлены без нужды; версии pinned.
- Миграции БД обратимы / с планом отката; нет деструктивных сюрпризов.
- Логи и PII — модель часто логирует слишком много.
- Производительность — N+1, лишние запросы в цикле, unbounded retries.
- CI зелёный на актуальном пайплайне, не «у меня локально ок».
Если дифф > того, что ревьюер может осмысленно прочитать за 30–40 минут — MR режется. Агенты провоцируют большие диффы; процесс их запрещает.
CI как контракт
Человек может ошибиться в ревью; CI ловит класс ошибок автоматически:
- lint / typecheck;
- unit + ключевые integration;
- secret scan;
- сборка Docker-образа;
- для фронта — хотя бы smoke e2e на критичный путь.
Политика: красный pipeline = нет merge, даже если «агент уверен». Настройка контура — в духе GitLab CI/CD. Для Dockerfile и attack surface — оптимизация образов.
AI не отменяет контракт: он обязан удовлетворять тем же job’ам, что и ручной код. Иногда агент «чинит» тест, ослабляя assert — ревьюер обязан это ловить (п.4 чеклиста). На self-hosted runners студии те же правила, что для ручных MR: кэш зависимостей, без утечки variables в лог, воспроизводимая сборка. Если агент предлагает «для скорости» allow_failure: true на линтере — отклоняем.
Что джуниорам можно и нельзя auto-accept
| Действие | Junior | Middle+ | |----------|--------|---------| | Принять автодополнение 1–3 строк в знакомом файле | Да, если понимает | Да | | Принять большой дифф агента без чтения | Нет | Нет | | Сгенерировать тест и сразу merge | Нет | Только после review | | Трогать платежи, античит, прошивку STM32 | Только пара с сеньором | Review + стенд | | Вставлять prod-логи / ключи в чат модели | Запрет всем | Запрет всем | | Менять CI variables / SSH / secrets | Нет | По runbook |
Онбординг включает 30-минутный разбор «как читать AI-дифф» на реальном MR из репозитория студии. Без этого джуниор либо тормозит (боится любого автокомплита), либо ускоряется в сторону аварии. После онбординга первые две недели yellow-зона только в паре с middle/senior: так быстрее передаётся вкус к доменным инвариантам, чем любой внутренний гайд.
Ритуалы команды: синк, ретро, обучение
Раз в спринт на 15 минут смотрим: какие MR страдали от AI-шума (лишние файлы, ослабленные тесты), какие задачи реально выиграли. Это не «отчитываемся перед руководством», а калибровка правил. Раз в квартал обновляем чеклист ревью — модели и привычки агентов меняются.
Онбординг нового инженера включает:
- Политику секретов и LLM (одна страница).
- Разбор двух MR: хороший AI-assisted и плохой «агент нафантазировал».
- Карту зон green/yellow/red по продуктам студии.
- Обязательный pair на первый MR в yellow-зоне.
Без этого джуниор копирует скорость сеньора, не копируя вкус к риску.
Связь с вайбкодингом — коротко и явно
Вайбкодинг допустим у нас на spike и внутренних тулах при изоляции ветки — см. вайбкодинг. AI-assisted coding — режим по умолчанию для коммерческих репозиториев Content Factory, URAP, Synapse Stream, Diom, клиентских Next.js и промышленных репозиториев. Путать режимы в одном MR запрещено: нельзя половину «по вайбу без тестов», половину «в prod завтра».
Примеры из продуктов: что генерируем, что нет
URAP: генерация тестов на парсеры зон, черновик JSON Schema под новый тип документа, вспомогательные скрипты миграции разметки. Не генерируем без ревью логику, которая пишет в учётную систему заказчика финальные суммы и идентификаторы.
Content Factory: обвязка воркеров, UI очереди, шаблоны промптов как код. Не auto-accept’им изменения temperature/system prompt на prod без прогона golden-набора.
Synapse Stream: утилиты экспорта, админские формы. Не доверяем агенту оптимизацию hot-path без профилирования человеком.
Diom: виджеты и навигационные потоки по образцу соседних экранов. Платежные и антифрод-подобные куски — red zone.
Galvatec / Typhoon: только тесты и документация на стенде; прошивка — human-owned.
Инфра (GitLab CI, Dockerfile, self-hosted): агент может предложить job, человек проверяет кэш, секреты и non-root. См. Dockerfile tips и GitLab CI/CD.
Метрики реального ускорения
Мы не считаем «строк кода от AI» — метрика токсична. Смотрим на:
| Метрика | Зачем | |---------|-------| | Lead time задачи (to-do → merge) | Видно ускорение end-to-end | | Доля MR с rework после review | Ловит падение качества | | Число инцидентов / hotfix за спринт | Цена скорости | | Время на онбординг в модуль | AI помогает читать legacy — или путает | | % времени на бойлерплейт vs домен | Куда уходит выигрыш | | Средний размер MR (LOC) | Рост размера = сигнал «агент раздул дифф» |
Честный паттерн: AI сильно режет время на boilerplate (формы, клиенты API, тесты-обвязки) и слабо помогает на неявных инвариантах Galvatec/Typhoon или тонком concurrency в Synapse Stream. Если «ускорение 3× на всём» — скорее изменился definition of done, а не качество. Как считать скорость без самообмана — в статье про скорость разработки с AI.
Типичный выигрыш на наших проектах: 20–40% на задачах с чётким контрактом и тестами; около нуля или отрицательный — на задачах «разберись в домене и аккуратно измени одно поле», если агент плодит побочные правки.
Анти-паттерны, которые запрещаем
- Один промпт на целый модуль оплаты с просьбой «сделай как в Stripe».
- Silent merge AI-диффа в main в обход review «потому что зелёный CI».
- Ослабление тестов, чтобы агент «прошёл».
- Копирование архитектуры из ответа модели без сверки с нашими ADR.
- Работа агента на копии prod БД с реальными персданными.
- Оценка людей по количеству принятых AI-строк.
- Смешение вайбкодинг-spike и prod-ветки без переписывания.
- Отключение secret scan «на пять минут».
Как внедрить похожий процесс у себя
- Написать одностраничную политику ответственности автора MR.
- Добавить чеклист AI-review в шаблон GitLab MR.
- Разделить зоны продукта: green / yellow / red для автогенерации.
- Обучить джуниоров на двух реальных разборах диффов.
- Подключить secret scan и не отключать его «для скорости».
- Выбрать 2–3 метрики lead time / rework и смотреть месяц.
- Отдельно запретить AI-auto на OT-командах и платежах.
- Раз в спринт калибровать правила по фактам, не по хайпу инструментов.
- Держать IDE-ключи отдельно от product API ключей.
Итог
AI-assisted coding в OtherCode — это не запрет агентов и не культ вайбкодинга. Это Cursor и LLM в ежедневной работе под жёстким контрактом: человек отвечает за MR, чеклист ловит типичные дефекты генерации, CI не обсуждается, джуниоры не auto-accept’ят то, чего не понимают, а ускорение меряем до merge и стабильности, а не до вау-демо. Продукты студии получают разные зоны допуска — от зелёных UI-задач до красной промышленной прошивки.
Если хотите внедрить такие правила в свою команду или аудит текущего AI-процесса разработки, оставьте заявку — поможем адаптировать чеклист и зоны риска под ваш стек.
