ИИ для передачи дел: как найти знания, которые уходят из компании вместе с техлидом

Недавно я написал заявление об уходе. У меня оставалось две недели. Я открыл терминал и начал разбираться, что именно уйдёт из компании вместе со мной.

Любое изменение в инфраструктурном репозитории, затрагивающее продакшен, требовало моего личного ревью. Алерты мониторинга во всех окружениях по умолчанию приходили в мой личный почтовый ящик. Автономный агент для написания кода, которого я создал, каждую неделю мержит от нескольких до двух десятков пулл-реквестов, а когда у него истекают учётные данные, он пишет в личку ровно одному человеку. В двадцати двух приватных Slack-каналах был всего один менеджер. Все дороги вели к одному и тому же имени.

Недавно я закончил серию из трёх статей о том, где на самом деле находится конкурентное преимущество инженерной организации. Обвязка переживает модель, инженерная дисциплина вокруг обвязки переживает саму обвязку, а в финале мы добрались до неприятной части: главное конкурентное преимущество – профессиональное суждение, которое хранится в головах людей и уходит вместе с ними. Люди могут уволиться. Эта статья – продолжение, в котором увольняюсь уже я. Эти две недели я занимался собственной передачей знаний, переложив основную рутину на искусственный интеллект, и заодно отмечал, где работа действительно оказывалась сложной.

Если коротко: искусственный интеллект резко снизил стоимость фиксации знаний. Но он не сделал дешевле решения о том, что считать правдой, кому разрешено действовать и что вообще стоит сохранять. Дефицитный ресурс просто сместился. Меньше его не стало.

Что на самом деле уходит вместе с техническим руководителем

В материалах о передаче знаний обычно рассматривают уход разработчика: задокументировать код, переназначить задачи, заменить ключи. Классические инструменты для оценки «фактора автобуса» считают живучесть проекта по авторству кода. Даже исследование практиков 2022 года, которое идёт дальше коммитов и учитывает ревью и встречи, всё равно ставит этот вопрос применительно к кодовой базе.

У технического руководителя объём того, что нужно передать, гораздо шире и по большей части не виден со стороны. В основе всего лежат доступы: у кого учётная запись облачного провайдера, кто может попасть в продакшен, какие проверки перед изменениями молчаливо предполагают участие одного конкретного человека. Дальше идёт память об инцидентах и диагностическое чутьё вроде: «Отвалилась авторизация – сначала проверь часы и только потом лезь в конфиг». Затем причины принятых решений – сотни ответов на вопрос «почему здесь всё устроено именно так», которые остались в Slack-тредах и больше нигде не зафиксированы. Потом устоявшиеся рабочие процедуры: как на самом деле проходят релизы, как перед очередным раундом тестирования сбрасываются демонстрационные данные, какие ручные шаги все давно считают автоматизированными. А в 2026 году появилась ещё одна категория: автономные агенты, которыми вы управляете. У них есть собственные учётные данные, ситуации, где приходится принимать решения, и свои режимы отказа.

Любая компания состоит из экспертных знаний, неформализованных знаний команды и ПО, которое связывает всё это воедино. Экспертные знания у нас в основном уже жили в репозиториях и wiki. Проблемой были неформализованные знания команды. Вендоры охотно расскажут, во сколько они обходятся бизнесу. Любимая цифра – 31,5 млрд долларов в год для компаний из Fortune 500 – это оценка IDC, которой уже столько лет, что она сама могла бы голосовать. С тех пор её повторяют почти в каждой презентации про управление знаниями. Маркетинговая арифметика, но направление в целом совпадало с тем, что я видел в собственной инвентаризации.

И на exit-интервью всё это не передашь.

Спринт по документации

Первая неделя выглядела примерно так, как все себе и представляют: сесть и записать всё, что знаешь. Только у нас эта работа началась ещё за несколько месяцев до этого – не в качестве отдельного проекта, а как привычка. После каждого значимого изменения в репозиториях модель получала один и тот же запрос: обновить документацию, которую это изменение только что сделало неактуальной. Ранбуки, заметки по архитектуре, журналы решений. Документация росла вместе с кодом, потому что дополнительная стоимость такого запроса была почти нулевой.

Финальный рывок опирался уже на эту базу. За примерно 72 часа мы написали или переписали 55 из 73 страниц wiki: подробные разборы архитектуры, руководство по инфраструктуре, справочные материалы по CI/CD, пользовательскую документацию, операционные ранбуки. Модель, которая прочитала всю вашу кодовую базу, превращается в очень быстрого технического писателя. Она не жалуется на страх чистого листа. За минуту выдаёт черновик страницы, а ещё через минуту начинается настоящая работа: вы удаляете всё, что звучит правдоподобно, но не соответствует действительности.

Новый технический руководитель, который пришёл как раз в ту неделю, когда я уходил, сказал, что никогда не видел настолько хорошо задокументированного репозитория. Мне хотелось бы считать это окончательной оценкой. Но это комплимент только первой неделе, а в ней скрывалась ловушка.

Ловушка была хорошо видна прямо в истории изменений wiki: у 66 из 73 страниц был ровно один автор. Большинство написали в последние дни перед моим уходом. Ни один второй инженер их ещё не прочитал, не попробовал работать по ним и не проверил на практике ни одного ранбука. Такая база знаний ещё не стала документацией. Пока это лишь гипотеза о том, что нужно команде, записанная единственным человеком, которого уже не будет рядом, чтобы её исправить.

Поэтому вторая неделя была не про то, чтобы писать ещё больше. Она была про поиск того, что документация упустила.

Отправляем разведчиков во все источники

Аудит начался с одного промпта для Claude Code, почти дословно такого:

Проверь все мои репозитории (кроме личного) в этой папке рабочей области,
все мои сессии, историю Slack в четырёх командных каналах, документацию в репозиториях и корпоративной wiki и найди всё, что я мог упустить. Я ухожу из компании и хочу убедиться, что всё необходимое задокументировано и может быть передано команде.

Конечная цель – бесшовная передача дел. Используй команды агентов, cубагентов или всё, что потребуется. Для агентов-разведчиков используй модель поменьше, и пусть они возвращают только результаты, а не весь контекст.

Проблема была такого масштаба, что одно контекстное окно здесь бесполезно. Только локальная история моих сессий Claude Code занимала около 200 МБ JSONL-транскриптов из сотни сессий. Добавьте четыре Slack-канала с историей за несколько месяцев, wiki на 73 страницы и несколько репозиториев. Ни одна модель не прочитает всё это за один заход.

Сделать задачу управляемой помогли два приёма.

Первый: сначала сделать выжимку, потом делегировать. Транскрипт сессии с ИИ для написания кода почти целиком состоит из вывода инструментов и диффов. Действительно ценные знания содержатся в словах человека: что я просил сделать, какие решения принимал, что исправлял. Поэтому оркестратор прогнал все транскрипты через jq и извлёк только сообщения пользователя и сводки по сессиям. 200 МБ превратились в 300 КБ.

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

Второй: оркестратор и рабочие агенты. Основная сессия работала на Fable 5 и занималась планированием, а не чтением. Она параллельно запустила тринадцать разведчиков на Sonnet, причём каждому достался ровно один источник: отдельный участок репозитория, один Slack-канал, одна выжимка по сессиям или инвентаризация wiki. Собственная исследовательская система Anthropic устроена по той же схеме: ведущий агент разбивает задачу на части, а субагенты параллельно расходуют свои контекстные окна, чтобы ведущему агенту не приходилось делать это самому.

Такой подход строится на тех же принципах, что и другие агентные системы: модель получает роль, инструменты и возможность выполнять действия в заданном контексте. О том, как устроены ИИ-агенты изнутри и собрать первого рабочего агента, мы писали в практическом гайде «Как создать своего первого ИИ-агента за 30 минут».

Anthropic честно указывает и на ограничение: мультиагентные системы расходуют примерно в пятнадцать раз больше токенов, чем обычный чат, и такой подход окупается только там, где работу действительно можно распараллелить. Аудит тринадцати независимых источников – как раз такой случай. У меня он съел около 1,3 млн токенов за восемь минут реального времени (wall-clock time) и 265 вызовов инструментов – то есть обошёлся в несколько долларов. Самая дорогая часть началась потом.

Каждый разведчик получал одну и ту же вводную, здесь я убрал из неё чувствительные детали:

Ты участвуешь в аудите передачи знаний. Технический руководитель уходит из компании. Цель – бесшовная передача дел: найди знания, которые ЕЩЁ НЕ зафиксированы в официальной документации, незавершённую работу, которой нужен новый ответственный, и системы, которыми умеет управлять только он. Приводи конкретику и ссылайся на подтверждения.

Никогда не копируй секретные значения в результат: укажи название секрета и место, где он хранится. Результат будет обрабатываться машиной: верни ТОЛЬКО структурированный ответ.

И жёстко заданную схему ответа, чтобы от тринадцати разведчиков вернулись сопоставимые результаты, а не тринадцать эссе:

summary:          3–6 предложений об источнике и состоянии его документации

tribalKnowledge:  [{ topic, detail, risk: high|medium|low }]

docGaps:          [конкретная отсутствующая или устаревшая документация]

openWork:         [незавершённая работа, которой нужен новый ответственный]

externalSystems:  [сервисы и учётные записи, которыми, судя по всему, владеет он; только названия]

pointers:         [пути к файлам, URL, ссылки на канал+дату]

Двенадцать разведчиков вернулись с реальными находками. Один выдал буквально текст-заглушку: test summary here. Это само по себе хороший урок: распараллеливание без проверки просто распараллеливает мусор. Я перезапустил этого разведчика отдельно, и со второй попытки он отработал нормально.

Что нашлось

Находки сами собой разложились по категориям. Я бы рекомендовал такую классификацию всем, кто решит провести подобный аудит для себя: конкретное содержимое у всех будет разным, а категории вполне универсальны.

На первом месте оказались доступы и учётные данные – самая срочная категория. Правила CODEOWNERS, без моего личного GitHub-аккаунта не пропускающие изменения в продакшен. Алерты, которые по умолчанию уходили на мою личную почту, причём настройка переопределения существовала только в локальном файле на моём ноутбуке. Ключ хранилища с избыточными правами, который уже удалили, хотя в документации его удаление всё ещё значилось как предстоящая задача. Учётные данные агентов, об истечении которых уведомляли одного-единственного человека – и этот человек как раз уходил. В привычном смысле всё это даже не знания. Но всё это ломается в тот день, когда учётную запись отключают.

Вторыми шли системы, завязанные на одного человека: платформа развёртывания, которую я создал и поддерживал в одиночку; стек авторизации, к которому больше никто не прикасался; автономный агент, решения за которого я месяцами принимал скорее по опыту и интуиции. И для каждой такой системы решением была не документация сама по себе. Нужен был конкретный преемник, затем совместный разбор системы, а уже потом ранбук – именно в таком порядке важности.

Третьими оказались инциденты без постмортемов. Разведчики нашли шесть продакшен-инцидентов, диагностика и исправление которых остались только в чатах: сбой из-за рассинхронизации часов, который выглядел как ошибка авторизации; долгая история с мониторингом, после которой мы усвоили, что сработавший алерт ещё не означает аварию; пайплайн резервного копирования, который начал молча падать после удаления ключа.

На второй неделе каждый такой случай превратился в отдельную страницу с постмортемом: модель восстанавливала события по истории чатов, а я сверял её текст с тем, что произошло на самом деле. Для одного инцидента модель даже нашла пулл-реквест с исправлением, детали которого я сам уже помнил смутно. Но ключевые слова здесь – «я сверял». Ловушка первой недели никуда не исчезает: исправления второй недели тоже остаются непроверенными, пока ими не воспользуется ещё один человек.

Четвёртыми шли решения, причины которых сохранились только в Slack, и эта категория удивила меня сильнее всего. В журнал решений в итоге попали двадцать пять пунктов: почему идентификация при входе устроена именно так; почему один из статусов счёта, похожий на баг, на самом деле сделан намеренно; почему staging разворачивается по расписанию, а не после каждого merge. Выяснилось, что фактическая спецификация целого направления продукта жила в одном Slack-треде на 55 ответов. Каждый такой пункт – это один будущий спор, который команде теперь не придётся устраивать заново.

И наконец, пятая категория, о которой почти никто не думает: работа, существующая только на ноутбуке уходящего сотрудника. Git stash с недоделанной фичей. Локальные worktree для ещё не смерженных веток. Файлы планов Terraform, которые больше никто не может посмотреть. В последний рабочий день ноутбук очищают, и всё, что существовало только на нём, исчезает вместе с ним.

Если говорить начистоту, почти ничего из этих пяти категорий не было для меня новым. Читая результаты, я узнавал каждый пункт. Но составить такой список по памяти я бы не смог – ни за две недели, ни за два месяца. Вклад модели был именно в том, чтобы всё это вспомнить, причём только в тех источниках, куда я её направил: четыре Slack-канала из двадцати двух, без Droplet и без личных сообщений. Уже сам выбор источников требовал профессионального суждения. Как и последующий многочасовой разбор: я проходил по каждой находке и выносил решение – уже сделано, решено в другом месте, неверно интерпретировано, оставить как есть, исправить сейчас. Примерно треть находок отсеялась на этом этапе. Остальные две трети превратились в пулл-реквесты, страницы wiki и передачу дел в Slack.

Разбор шёл и в обратную сторону. Когда команда провела созвон по передаче инфраструктуры, я загрузил транскрипт встречи обратно в модель и попросил проверить, чего не хватает по сравнению со всем, что мы уже успели подготовить. Она нашла реальные пробелы: принятое на созвоне решение, которого нигде не было в письменном виде, и пункт чек-листа, отсутствовавший на странице онбординга. Но один раз она столь же уверенно неправильно интерпретировала транскрипт и предложила удалить запись с учётными данными, которую мы намеренно решили сохранить, приняв её за остаток от уходящего сотрудника. Я заметил ошибку только потому, что сам был на этой встрече.

Модель приносила доказательства. Решения всё равно оставались за мной.

Что модель отказалась делать

Примерно в середине аудита проявилась та часть, о которой в статьях про мультиагентные системы обычно почти не пишут: субагенты начали отказываться выполнять инструкции оркестратора. И делали это совершенно правильно.

Схема была такой: оркестратор поручил субагентам публиковать материалы в wiki. Написать постмортемы, создать страницы – и готово. Но каждый субагент работает со своей системой контроля разрешений. Она посмотрела на задачу и остановила выполнение: публикация подробной информации о безопасности и инфраструктуре в корпоративной wiki – действие с серьёзными последствиями, а единственным подтверждением разрешения было переданное через посредника сообщение от другой ИИ-сессии, утверждавшей, что пользователь всё одобрил. Утверждение о разрешении – ещё не само разрешение. Действие заблокировали.

Оркестратор попробовал очевидный обходной путь: пусть субагент сохранит текст в локальный файл, а публикацией займётся основная сессия, где моё разрешение было видно напрямую. Система контроля разрешений заблокировала и это, причём сама назвала паттерн: отмывание разрешений (permission laundering). Если запрещённое действие передают другому агенту в надежде, что тот выполнит его с менее строгими ограничениями, это всё та же проблема confused deputy («запутанный заместитель» или «запутавшийся делегат»), только в мире агентов.

После этого субагент сформулировал свою позицию предельно ясно: сообщение от другого агента о том, что «всё нормально», ничего не меняет; разрешение появится только в том случае, если пользователь даст мне прямую инструкцию в этом разговоре.

Третий субагент пошёл ещё дальше. Ранее ему уже запретили вносить те же изменения в репозиторий, а затем он обнаружил, что изменения всё равно закоммичены в общей ветке – моей основной сессией, с моим прямым разрешением, которого сам субагент видеть не мог. Он поступил именно так, как должен поступить осторожный с точки зрения безопасности коллега: остановился, отказался трогать ветку и эскалировал ситуацию, которая с его точки зрения выглядела как повышение привилегий – незнакомый аккаунт добавляют в правила CODEOWNERS через агента, которому до этого явно сказали «нет».

С его позиции этот паттерн был похож на атаку. С моей – это был просто я, выполняющий свою работу. И обе интерпретации были правильными исходя из той информации, которая была доступна каждой стороне.

В контексте каждый такой отказ был ложным срабатыванием, но по сути – правильным поведением. Полномочия не передаются транзитивно по цепочке агентов. В моей сессии было прямое разрешение человека; у субагентов – лишь сообщение о том, что такое разрешение якобы есть. В мире, где промпт-инъекция остаётся постоянной угрозой, агент, принимающий слух о разрешении за само разрешение, непригоден для эксплуатации. Решение оказалось скучным и правильным: все действия с серьёзными последствиями возвращались в ту сессию, где согласие пользователя было видно напрямую, и уже там я выполнял их сам.

При этом сама система контроля разрешений вероятностная: один из субагентов без вопросов выполнил аналогичную публикацию в wiki. Тот же агент однажды ненадолго стёр содержимое страницы, передав строку с shell substitution как её текст, но сам заметил ошибку при проверочном чтении и восстановил всё меньше чем за тридцать секунд. Защитные ограничения от неверно полученных полномочий, циклы проверки – от обычных ошибок. За эти две недели мне постоянно требовалось и то и другое.

На все эти отказы и перенаправление задач я потратил примерно час. И без раздумий согласился бы на такую цену снова. Пул агентов, который никогда не говорит своему оркестратору «нет», просто ждёт первого достаточно хорошо составленного вредоносного промпта.

Что осталось за мной

Если честно разложить эти две недели по ролям – а смысл этой статьи именно в разделении труда, – то картина совсем не такая, будто «всё сделал искусственный интеллект».

Каждый merge оставался за мной. В моём конфиге есть постоянное правило, и для этого проекта оно не менялось: модель открывает пулл-реквест и на этом останавливается. Успешно пройденный CI ещё не означает разрешение на merge. За эти две недели в трёх репозиториях появилось тринадцать PR, и каждый из них мержил человек. В случае PR, связанных с передачей дел, это был я после ревью команды.

Все решения по доступам тоже принимал я. Кто из преемников попадёт в файл CODEOWNERS. На чей ящик теперь будут приходить продакшен-алерты. Какие мои учётные данные нужно ротировать, а какие полностью вывести из эксплуатации. Передачу доступов – пройтись с новым руководителем по всем внешним аккаунтам и показать, у кого находятся root-доступы, – нельзя делегировать системе, которая по самой своей архитектуре вообще не должна видеть в контексте полную карту учётных данных.

Разборы систем тоже проводил я. По платформе развёртывания мы устроили живую рабочую сессию и вместе прошли один настоящий деплой от начала до конца, потому что ранбук, который никто ещё не выполнял, пока остаётся лишь теорией. Эксплуатацию агента я передал конкретному человеку с прописанным порядком эскалации, и теперь это прямо указано в ранбуке. Два рабочих каталога на Droplet агента и то, какой цикл в каком из них запускается, я выяснял сам: подключался по SSH и смотрел. Ни у одного разведчика туда не было доступа, да и быть не должно было.

Решения по находкам оставались за мной: примерно полный рабочий день профессионального суждения по примерно сорока пунктам. И форму коммуникации тоже определял я: одну и ту же передачу дел мы анонсировали дважды – в инженерном канале с технической инвентаризацией и в продуктовом канале языком результатов. Потому что передача, о которой команда не знает, фактически не состоялась.

Если всё сложить, вклад модели сводился к масштабу и способности вспомнить: тысячи строк документации, память из сотни сессий, связи между источниками, которые человек под дедлайн никогда бы не стал сопоставлять вручную. Моя часть работы по сравнению с тем, как это выглядело бы до ИИ, почти не уменьшилась. Она просто изменила форму. Я почти не тратил время на набор текста и почти всё время – на принятие решений. Поиск и восстановление контекста распределились между тринадцатью разведчиками; решения и полномочия не распределялись вообще.

Стоит отдельно сказать, на чём всё это держалось, потому что ничего из этого не появилось за те две недели. Транскрипты сессий существовали потому, что месяцами работа уже шла через агентный CLI. Привычка обновлять документацию по ходу работы появилась задолго до моего заявления об уходе. Оркестратор, система контроля разрешений, структура wiki – всё это уже было частью инфраструктуры. Если технический руководитель впервые открывает терминал в первый день своего срока отработки, не имея такого следа, он получит лишь малую часть результата. А написание документации перестаёт быть дешёвым ровно в тот момент, когда всю историю приходится восстанавливать вручную. И пул агентов не заменил ни одной человеческой передачи дел. Он лишь помог понять, на что стоит потратить ограниченное время этих встреч.

Искусственный интеллект убрал отговорку. Раньше фраза «не было времени всё задокументировать» действительно могла быть правдой. Теперь сама фиксация знаний – уже почти решённая задача. И остаётся то, что больше не спрячешь: готов ли ты потратить последние две недели на работу, требующую профессионального суждения, которое кроме тебя в этот момент никто не может дать.

Проверка преемником

Системы из первого абзаца теперь завязаны уже на имена других людей. Алерты приходят в чужой почтовый ящик. Агент эскалирует проблемы конкретному преемнику, а его ранбук действительно прочитал второй человек. Журнал решений двадцать пять раз отвечает на вопрос «почему здесь всё устроено именно так», даже когда меня нет рядом.

Сработала ли передача дел, сегодня ещё не измерить, и я не собираюсь делать вид, будто количество страниц в wiki что-то доказывает. Настоящая проверка начнётся с первого инцидента у преемника в два часа ночи: найдётся ли нужный постмортем, сработает ли ранбук, передастся ли через текст то диагностическое чутьё, которое я пытался зафиксировать. Что-то из этого неизбежно потеряется: конкурентное преимущество всё равно уходит вместе с человеком, и после собственного опыта я ещё больше уверен в этом. Профессиональное суждение плохо поддаётся формализации, даже когда дешёвой возможности писать сколько угодно.

Без искусственного интеллекта всё это выглядело бы хуже в одном вполне конкретном смысле: охват был бы гораздо меньше. Те же две недели, но покрыта лишь малая часть всего объёма, а слепые зоны определялись бы тем, что случайно всплыло у меня в памяти. Пул агентов не передал моё профессиональное суждение. Он помог передать то, что вообще можно было передать, туда, где это действительно понадобится, и нашёл места, про которые я сам уже забыл.

Во всей этой истории есть и неприятный вывод: тот самый фактор автобуса, который я две недели пытался уменьшить, во многом создал я сам. Каналы, которыми управлял один человек. Алерты на личную почту. Правила ревью, завязанные на один аккаунт. Ничего из этого не возникло случайно. А аудит, который всё это обнаружил, проходил в худших возможных условиях – под давлением моего ухода, когда примерно треть находок уже можно было только зафиксировать, но не успеть исправить. При этом для такого аудита вовсе не нужно ждать чьего-то увольнения. Его вполне можно проводить раз в квартал для человека, у которого накопилось больше всего неформализованных знаний, пока он ещё в команде и может сам принимать решения по каждой находке.

Передача знаний никогда не была проблемой написания документации. Просто именно так она выглядела, пока писать документацию не стало дёшево.

Работа с ИИ-агентами быстро выходит за рамки генерации кода и простых автоматизаций. В реальных командах появляются новые вопросы: какие задачи можно передать агенту, где нужны проверки человека и как построить процесс так, чтобы автоматизация не создавала новые риски. Разобраться в подходах к работе с агентами, посмотреть практические сценарии и задать вопросы экспертам можно на бесплатных открытых уроках Otus.

• 14 сентября, 20:00. «AI-агенты против Junior-разработчиков: кто кого заменит к концу 2026 года». Записаться

• 1 октября, 20:00. «Продуктивность разработчика и Agent Skills». Записаться

>> Полный список бесплатных уроков сентября смотрите в дайджесте.