Институциональная память команды: как мы перестали зависеть от "незаменимых" сеньоров

Каждый тимлид знает эту боль: уходит старожил — уходят знания о том, почему сервис написан именно так, почему этот подход запрещён, почему вот этот угловой случай обрабатывается именно здесь. Новый человек (или AI-агент) приходит и делает «технически правильно, но не как у нас». Ты это ловишь в ревью, объясняешь, объясняешь снова следующему новичку. Мы решали ту же проблему — и решили её не через Confluence, а через граф знаний кодовой базы.

AI Council строит живой граф: 11 000+ узлов (классы, функции, файлы, зависимости), 16 000 рёбер, плюс машиночитаемые конвенции команды и архитектурные решения. Когда AI-агент начинает задачу, он получает не весь проект целиком, а точечный контекст — именно те части кода и именно те решения команды, которые релевантны его задаче. Это же работает для нового разработчика при онбординге. В докладе — конкретные кейсы из двух внедрений: как сократился цикл «задача → PR» и как mentor-агент автоматически ловит нарушения конвенций до того, как они попадают в ревью тимлида.

Поговорим о том, что тимлид реально контролирует в схеме с AI: какие точки approve обязательны (ТЗ, реализация, деплой), как выглядит human-in-the-loop на практике, и почему «AI без надзора» — это найм джуна без испытательного срока. Разберём dual-agent схему: dev-агент (пишет код) + mentor-агент (проверяет конвенции) — прямая аналогия с парой «исполнитель / старший ревьюер», которую тимлид уже знает.