В последнее время меня стал преследовать один и тот же сценарий. Приходит в проект новый разработчик, чаще всего джун или мидл. Первую неделю он героически пытается вникнуть в архитектуру, задаёт много вопросов. А потом начинается самое утомительное: он подходит к тимлиду (он же у нас почти ведущий разработчик) и спрашивает: «А почему вот этот микросервис общается с БД напрямую, минуя основной бэкенд?».
Сеньор отрывается от своей задачи, лезет в схему, начинает объяснять контекст и историю принятия того или иного архитектурного решения. Через час он возвращается к своему коду, но контекст уже потерян. А через два дня — новый вопрос по тому же поводу, но уже от второго новичка. Знакомая боль?
Если раньше я мирился с этим как с неизбежной платой за рост команды, то теперь, после внедрения ИИ-ассистента на этапе онбординга, я понял, что мы просто сливали часы сеньоров на механическую работу. И главное — решение оказалось проще, чем я думал.
Онбординг — это не про доступы, а про контекст
Обычно под онбордингом мы понимаем техническую рутину: выдать доступы к репозиториям, настроить окружение, добавить в чаты. Это делается за полдня. А дальше начинается самое сложное — передача неявного знания (tacit knowledge).
Новичку нужно понять не только то, как написан код, но и почему он написан именно так. Почему выбрана эта СУБД? Почему мы не используем очередь здесь, а сделали синхронный запрос? Какие грабли лежат в этом легаси-модуле?
Раньше единственным источником этого знания были сеньоры и местами устаревшая Confluence. В итоге тимлид или ведущий разработчик тратил до 5–7 часов в неделю на ответы на одни и те же вопросы от разных людей. Механическая работа. Я подсчитал: если у нас за полгода приходит трое новичков, сеньор теряет примерно 80 человеко-часов продуктивной работы. Это же целая двухнедельная задача!
Мне пришла идея: а что, если я попрошу нейросеть выступить в роли «вечно доступного сеньора», который не раздражается от глупых вопросов и помнит всю историю проекта?
Решение: База знаний с RAG и GPT-прослойкой
Мы не стали изобретать велосипед и писать своего бота с нуля. Пошли прагматичным путём.
Первое. Мы взяли всю нашу документацию: ADR (Architecture Decision Records), описание API в Swagger, старые презентации с архитектурных комитетов, комментарии из Jira по сложным багам и, самое ценное — записи наших внутренних митапов, где сеньоры объясняли логику проекта. Всё это загрузили в корпоративное облако.
Второе. Мы развернули простого Telegram-бота, который использует LLM (пока остановились на локальной GPT-OSS для чувствительных данных, но для открытых частей можно и ChatGPT) и связку с векторной базой данных (RAG — Retrieval-Augmented Generation).
Третье. Настроили промпт. Суть промпта: «Ты — опытный разработчик и архитектор. Отвечай на вопросы новых членов команды строго на основе загруженных документов. Если ответа в базе нет — не выдумывай, а честно скажи, что не знаешь, и посоветуй, к кому из команды обратиться и в каком контексте».
Как это работает вживую
В первый же день после настройки окружения я отправляю новичку ссылку на бота и говорю: «Сначала спроси у него. Если не найдёшь ответа — иди к тимлиду, но с конкретикой: что ты уже понял, а что осталось непонятным».
Результаты меня удивили.
На днях новый бэкенд-разработчик спросил у бота: «Почему в сервисе оплаты мы используем синхронный REST, а не асинхронную очередь?».
Бот залез в ADR за прошлый год, нашёл решение архитектурного комитета и выдал структурированный ответ: «Согласно документу ADR-2024-11, выбор синхронного взаимодействия обусловлен требованиями банка-партнёра к гарантиям доставки и транзакционности. Очередь создавала риск неконсистентности при дублях. Подробнее смотри в описании интеграции».
Новичок получил ответ за 10 секунд. Сеньор не отвлёкся. И, что важнее, новичок увидел, что решения не берутся из воздуха, а документируются.
Почему это прагматичнее, чем кажется
Можно подумать: «О, ещё одна игрушка, будем тратить время на настройку бота». Но если считать по-взрослому:
- Быстрота ответа: Сеньор может отвечать 5–10 минут, если он глубоко в контексте. Бот отвечает мгновенно.
- Терпение: Сеньор на 5-й похожий вопрос за месяц может начать раздражаться (и его можно понять). Бот спокоен всегда.
- Актуализация знаний: Чтобы бот работал хорошо, мы вынуждены держать документацию в порядке. Если ADR не заполнены, бот бесполезен. Это дисциплинирует команду.
Это не просто FAQ, это инженерная культура
И вот тут я прихожу к главному выводу. Онбординг с помощью ИИ — это не просто способ сэкономить время сеньоров.
Это способ превратить скрытое знание в документированный актив компании. Раньше знания жили в головах тимлида и ведущего разработчика. Если они уходили в отпуск или, не дай бог, покидали проект, знания уходили с ними. Теперь мы создаём культуру, где любое архитектурное решение должно быть объяснено и положено в базу. ИИ выступает не просто переводчиком, а интерфейсом к этой базе.
Мы перестали быть заложниками «мудрецов» и начали строить самодокументируемую систему. Новичок теперь учится не методом «спроси у Васи», а методом «прочитай базу знаний и задай уточняющий вопрос боту». Это формирует правильную культуру работы с информацией с первого дня.
А сеньоры наконец-то начали заниматься реально сложными задачами, а не ходить по кругу с одними и теми же объяснениями.