Онбординг джунов через Vibe Codex

Самый дорогой этап джуна — первые две недели, когда он не задаёт «глупые» вопросы, потому что стесняется. Хорошо, когда есть кому задать.

Онбординг в большой проект — это не про «прочти README», а про «прими тысячу неписаных решений». Vibe Codex здесь занимает позицию старшего, который никогда не устал отвечать на вопрос «а почему вот это так?». Не заменяет ментора, а снимает с него скучную часть.

Первый день: explain, не edit

Свежий джун получает доступ только к команде vibe-codex explain. Никаких правок, никаких автокоммитов — только чтение и объяснение. Это безопасно для прода и продуктивно для джуна.

$ vibe-codex explain src/billing/InvoiceService.java
[opus] InvoiceService — точка входа в выставление счетов.
[opus] Делает три вещи:
   1) собирает позиции из OrderRepository (только за период);
   2) вычисляет налоги через TaxCalculator (зависит от страны);
   3) сохраняет и публикует событие InvoiceCreated в Kafka.
[opus] Зависимости: 4 интерфейса (внедрены через конструктор),
       все мокаются в тестах.
[opus] Острые места:
   - метод markPaid не атомарен (issue #423, в работе);
   - страна определяется по customer.address, а не по billing.

За полчаса джун понимает архитектуру модуля лучше, чем за день чтения по диагонали. И — что важно — видит «острые места» теми же глазами, какими видит их команда.

Конвенции, которые нигде не записаны

В каждой команде есть негласные правила: «здесь Optional, там null», «здесь Mono.error, там RuntimeException», «здесь короткие commit-message, там conventional». Vibe Codex читает примеры из репозитория и формулирует правила вслух.

$ vibe-codex conventions
[opus] Анализ 547 коммитов и 1200 файлов:
  - Commit message: conventional, prefix с тикетом (PAY-123)
  - Pull request: 1-2 коммита, squash перед merge
  - Ошибки: RuntimeException только в фасадных слоях,
            CheckedException в сервисах ниже
  - Тесты: 1 файл = 1 класс, имя метода = scenario
  - DI: только через конструктор, никаких @Autowired на полях
  - Imports: без wildcards

Первая задача: песочница с лимитом

На вторую неделю джун получает право vibe-codex edit, но в режиме --dry-run: модель предлагает изменения, выводит diff, ничего не пишет на диск. Это идеальный режим, чтобы тренироваться без последствий.

$ vibe-codex --dry-run "добавь endpoint /health в InvoiceController"
[diff] +24 -0 lines (proposed, not written)
[note] вижу в проекте уже есть /actuator/health от Spring Boot —
       уверены, что нужен отдельный?

Заметьте: ассистент сам подсветил, что задача может быть лишней. Это лучшее, что может случиться с джуном — кто-то задаёт вопросы до коммита.

Ментор остаётся ментором

Есть соблазн заменить ментора ассистентом. Это плохая идея. Ассистент знает «как», но не знает «зачем», и точно не знает «как развиваться этому конкретному человеку». Vibe Codex освобождает ментора от шаблонных ответов — тех, на которые он отвечает в десятый раз.

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

Метрики, которые имеет смысл смотреть

• Время до первого мерджа в main: было 7 дней, стало 3.
• Доля PR без замечаний по стилю на ревью: было 35%, стало 78%.
• Количество вопросов в личку ментору: падает на 40-60% — не «никого не спрашивает», а «спрашивает по делу».
• Subjective: джуны меньше выгорают на первой неделе.

Скучные правила, без которых это превращается в анти-онбординг

1. Read-only первые три-пять дней. Никаких --write, никакого commit от ассистента.
2. Ментор смотрит первые пять PR — даже идеальные. Это вопрос доверия, а не качества.
3. Запрет на использование ассистента в архитектурных дискуссиях. Архитектура — это разговор между людьми.
4. Регулярный «час без ассистента»: пусть джун раз в неделю решает задачу руками. Иначе он не научится мыслить, а научится промптить.

Что джун чувствует

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

Vibe Codex — это не «AI учит джуна писать код». Это «AI разгружает ментора и сокращает время одиночества». Разница между двумя формулировками — это разница между хорошим инструментом и плохим.