Техлид и AI: как выстроить систему решений
Содержание
TL;DR: Две команды могут выполнить свои постановки и получить неправильное поведение продукта. На истории сквозной фичи "семейный доступ" показываю, как техлид связывает язык, основания, права на решения, проверки и память проекта. С AI эти связи приходится делать особенно явными, а результат работы лида виден по тому, что команда умеет решать без его постоянного участия.
Перенесите жену в следующий поток
В инвестиционной школе FIN-RA у нас была фича "семейный доступ": одной покупкой клиент получал два места на курсе – для себя и супруга. Каждый учился под своим профилем, выполнял задания и накапливал свою историю обучения.
Обучение шло потоками: каждый новый набор учеников начинал курс в свою дату. Перейти в следующий поток означало присоединиться к более позднему набору.
В сопровождение пришла обычная просьба. Реплики в этой истории передаю по смыслу.
Муж и жена учатся вместе. Муж продолжает, а жена сейчас не успевает и хочет перейти в следующий поток. Перенесите её, пожалуйста. Уже сделанные задания терять не нужно.
Для человека, который это попросил, всё понятно. Один ученик продолжает учиться, другой начнёт позже. Архитектурный комитет семье для этого не нужен.
За выдачей доступа стояли два проекта. Моя кросс-функциональная команда примерно из 15 человек делала учебную платформу и инструменты для начинающих инвесторов: определение риск-профиля, цели, портфели, выбор активов, регулярные покупки и ребалансировку. На той же платформе проходило обучение с уроками, заданиями и кураторами.
Рядом работала меньшая команда. Их проект Andrews начинался как CRM, а постепенно вобрал интеграции с GetCourse и большой объём бизнес-логики школы. Название "CRM" уже довольно скромно описывало его обязанности.
Поэтому выдача семейного доступа проходила через обе системы. В Andrews доступ открывали вручную или по условиям автоматического процесса. Интеграция передавала это решение нашей платформе, а та создавала профили учеников и записывала их в поток и группу.
До этой просьбы сценарий выглядел завершённым. Я тоже считал, что семейное обучение мы предусмотрели: двух учеников создавать умеем, дальше обычная жизнь продукта. Были и другие задачи.
Теперь требовалось изменить обучение одного человека так, чтобы второй продолжал учиться как прежде.
На нашей стороне разработчик видел профиль жены и её участие в обучении. Перенести одного человека технически можно. Но что произойдёт, когда Andrews снова пришлёт обновление? Там семейная покупка по-прежнему связана со старым потоком. Следующее обновление могло вернуть прежнюю привязку.
Если менять поток на стороне CRM, появлялась другая опасность: через общую покупку перенести вместе с женой мужа, который никуда уходить не собирался.
Противоречие обнаружилось уже при обсуждении вариантов. Решение ещё предстояло выбрать.
Сначала я примерял привычный способ: добавить индивидуальное исключение. На одной стороне отметить, что человека перенесли отдельно, на другой – учитывать это при синхронизации. Выглядело как работа вполне разумного размера.
И тут разработчик уточнил:
А если потом муж тоже захочет перейти, но в другой поток, как мы поймём, какое состояние правильное?
Сам флаг не был заведомо плохим решением. Но он ещё не отвечал на вопрос, какая система определяет поток каждого ученика после следующих обновлений. Мы могли добавить признаки для обоих супругов и всё равно не договориться об этом.
Я принял создание двух профилей за полную поддержку двух учеников. Пока они шли вместе, ошибка не мешала. Когда их обучение разошлось, стало видно, сколько смысла интеграция достраивала из общей покупки.
Эта история происходила до нашей работы с AI-агентами. Сегодня я возвращаюсь к ней, потому что агент вполне может быстро реализовать такое индивидуальное исключение. Вопрос разработчика останется таким же неприятным, даже если код уже скомпилирован и к нему приложен аккуратный набор тестов.
Чтобы ответить на него, нам пришлось сначала разобраться, что каждая система считает переводом и какие данные действительно нужно менять.
Что означает перевод ученика для двух систем
Для Andrews отправной точкой была покупка клиента и связанные с ней права на обучение. Для нашей платформы – конкретный ученик, его поток, группа и выполненные задания. Поэтому команды по-разному читали одну просьбу: изменить привязку семейной покупки или перевести одного человека.
В исходной интеграции мы хорошо ответили, кого нужно создать при выдаче доступа. А независимые изменения после создания проработали хуже. Из того, что семейная покупка породила два профиля, не следовало, что перевод одного ученика можно выразить изменением клиентской карточки.
Пришлось разбирать ситуацию вместе с обеими командами и человеком, отвечавшим за правила сопровождения. Программисты могли объяснить последствия вариантов. Но решать за школу, какие переносы она разрешает и как учитывает пройденное, было бы странно.
На семейном примере стало проще разделить эти изменения. Покупка даёт два учебных места, но пользуются ими разные люди. Каждый может менять своё участие в обучении независимо от второго. Его выполненные задания при этом остаются частью его собственной истории.
Полезно было также разделить три разных вопроса.
| Вопрос | Что даёт ответ |
|---|---|
| Что сейчас хранится и передаётся между системами? | Код, данные и фактическое поведение интеграции |
| Что означает индивидуальный перевод для ученика? | Правило продукта и сопровождения |
| Как провести перевод, сохранив нужные свойства? | Техническое решение и его проверка |
По коду и данным можно установить нынешнее поведение интеграции. Чтобы выбрать новое, нужны правила школы: допустим ли такой перевод и что происходит с результатами ученика. Только после этого можно оценить, какая реализация сохраняет нужное поведение.
Например, "сохранить задания" звучит понятно до первого уточнения. Сохранить историю выполненной работы и засчитать её в новом потоке – разные действия. Можно технически не удалить ни одного результата и всё равно неверно исполнить договорённость с учеником. Здесь нужно отдельное правило обучения, а не только осторожный SQL.
Так привычное слово проверяется конкретным поведением. Муж остаётся, жена переходит – и одного понятия "клиент" уже недостаточно, чтобы описать изменение.
При этом существующий код не выбирает новое правило за нас. Одна привязка к потоку описывала прежнюю интеграцию, но не делала семейное обучение неделимым. Такое различие между наблюдаемым поведением и нужным правилом особенно важно при разборе противоречащего себе легаси.
Для меня здесь важна собственная ошибка. Я довольно быстро перешёл к выбору места для исключения. Хотя сначала стоило проверить, правильно ли мы сформулировали задачу. Техническое мышление нужно уже в этот момент: заметить скрытое предположение, предложить контрпример и уменьшить неопределённость до начала реализации.
AI можно использовать и для этой работы. Я бы попросил его перечислить, какие объекты меняются при переводе одного ученика, и разобрать соседние ситуации: супруги расходятся по потокам, один уже закончил обучение, приходит очередное обновление по общей покупке.
Сам ответ агента остаётся набором гипотез. Он может предложить удачную модель, а может убедительно выбрать неподтверждённое правило. Как в эксперименте с анемичными и богатыми моделями: архитектурная форма помогает увидеть решения, но не сообщает, какие из них действительно принял бизнес.
Разбор вариантов помогает понять цену каждого решения. Но даже убедительная модель оставляет ещё один вопрос: кто вправе выбрать условия перевода, а кому можно поручить их реализацию?
Кто принимает бизнес-решение и выбирает реализацию
В нашем случае договорились так: Andrews хранит, какие учебные места предоставлены по покупке, а наша платформа ведёт участие людей в потоках и группах. Поэтому индивидуальный перевод нужно передавать как изменение конкретного ученика. Из общего обновления карточки клиента получатель не должен угадывать, кому и зачем меняют поток.
Это давало разработчикам границу, внутри которой можно двигаться самостоятельно. Детали хранения и обработки внутри своей системы они могли выбирать сами. Если изменение затрагивало смысл покупки, условия перевода или поведение второй системы, требовался разговор с соответствующими участниками.
Сегодня я бы описал распределение этих решений так. Таблица составлена для статьи по смыслу договорённостей, а не взята из проектного документа.
| Решение | Кто и на каком основании решает |
|---|---|
| Почему у клиента есть два места и сохраняется ли это право | Владелец коммерческого правила; Andrews хранит, какие права предоставлены по этой покупке |
| Можно ли перевести этого ученика и как учесть сделанное | Уполномоченный участник сопровождения по принятому правилу обучения |
| Как хранить и менять участие ученика в потоке | Команда платформы внутри принятых продуктовых ограничений |
| Что передаётся между системами и что получатель вправе менять | Обе команды согласуют контракт под выбранное поведение продукта |
| Можно ли выпускать конкретное изменение | Ответственный за выпуск по предусмотренным проверкам и правилам допуска |
Техлид участвует в этой системе сразу в нескольких местах, но должность не выдаёт ему все права разом. Я могу объяснить стоимость технического варианта, найти скрытый риск и предложить другую границу. Если школа обещает ученику перенос результатов, я должен помочь сделать обещание выполнимым. Но это не даёт мне права менять обещание ради удобной реализации.
При этом было бы нелепо собирать обе команды на каждый последующий перевод. Согласованное правило должно разрешать целый класс случаев. Если школа уже определила, когда отдельный ученик может перейти в другой поток, обычную операцию выполняют по этим условиям. Заново обсуждают случай за их пределами или предложение изменить сами условия.
Так разработчик получает самостоятельность, сохраняя обязанность выяснить последствия для других. Близкий способ работы описывает Andrew Harmel-Law в Advice Process: перед архитектурным решением нужно обратиться к затронутым участникам и профильным экспертам. Их советы выслушивают и записывают, но согласие всех не является обязательным итогом. Предусмотренные организацией обязательные согласования при этом сохраняются.
В исследовательской работе Intelligent AI Delegation передача работы между людьми и агентами также рассматривается вместе с полномочиями, ответственностью, наблюдением и проверкой результата. Это предложенная рамка, не доказательство эффективности конкретного командного процесса.
Для задачи с агентом я бы явно назвал тот же предел: какие технические решения он принимает сам, а какие вопросы возвращает владельцу продукта или другой команде.
Если я даю агенту задачу реализовать перевод ученика, он может исследовать код, предложить изменение и выполнить разрешённые проверки. Из этого не появляется право решить, что история заданий больше не нужна, массово поправить реальные записи учеников или изменить условия предоставления места. Эти действия могут быть связаны с задачей, но каждое требует своего основания.
Иначе делегирование работает странно: в постановке я оставил вопрос открытым, агент принял ответ за меня, а на ревью я вижу уже готовый код. Чем убедительнее он оформлен, тем проще пропустить момент, в котором техническое решение стало продуктовым.
Граница самостоятельности должна быть понятна и следующему исполнителю. Если один агент поручил часть работы другому, у второго не становится больше полномочий. Он должен видеть смысл исходной задачи, ограничения и точку, в которой нужно вернуть вопрос владельцу. При передаче задачи эти условия должны сохраняться.
Когда эти пределы понятны, две команды могут работать параллельно. Теперь нужно проверить, что их самостоятельные изменения по-прежнему складываются в один правильный перевод.
Как проверить совместимость изменений двух команд
Для супругов результат один: жена переходит, муж продолжает учиться. Чтобы подтвердить его, нужно проследить всю последовательность действий, включая очередное обновление из Andrews. Проверка одного обработчика не покажет, вернёт ли соседняя система прежний поток.
Мы договорились о таком результате: жена в новом потоке, муж в прежнем, история жены доступна, а обычное обновление покупки с действующими правами не отменяет перевод. Теперь разработчики обеих систем могли проверять своё решение по одной и той же ситуации.
Посмотрим на учебном примере, как я проверял бы такую задачу с агентами сегодня.
В учебной реализации обе стороны уже знают об индивидуальном переводе жены. Обычное обновление покупки не меняет коммерческих прав. От возврата в старый поток защищают две проверки: отправитель не включает общую привязку к потоку в обновление для отдельно переведённого ученика, а получатель не применяет такую привязку поверх индивидуального перевода.
Первый агент убирает проверку у отправителя как дублирующую: получатель ведь всё равно защищает перевод. Второй убирает проверку у получателя по обратной причине: отправитель уже отфильтровал неподходящее обновление. Каждый проверяет своё изменение с прежней версией соседней системы. В обоих случаях жена остаётся в новом потоке.
А потом обе версии собирают вместе.
| Сочетание версий | Кто защищает индивидуальный перевод | Результат обычного обновления |
|---|---|---|
| Обе прежние | Отправитель и получатель | Жена остаётся в новом потоке |
| Новый отправитель, прежний получатель | Получатель | Жена остаётся в новом потоке |
| Прежний отправитель, новый получатель | Отправитель | Жена остаётся в новом потоке |
| Обе новые | Ни одна сторона | Общая привязка возвращает жену в прежний поток |
По отдельности изменения сохраняют перевод благодаря старой версии соседа. Вместе они убирают обе защиты, поэтому двух прежних положительных результатов недостаточно для выпуска. Это учебная модель, не найденный дефект FIN-RA и не выполненный сейчас тест. Знание об индивидуальном переводе уже есть у обеих сторон; гонки доставки в этом примере не рассматриваются.
Две проверки не обязательно нужно хранить вечно. Но прежде чем убирать одну, надо договориться, какая сторона обеспечивает гарантию, и проверить допустимые сочетания версий при выпуске. Сохранение индивидуального перевода было общим правилом; распределение его технической защиты оказалось ещё одним решением.
Общая проверка даёт командам возможность самим обнаружить такое расхождение. Пока скрытые правила двух систем приходится сопоставлять только в голове одного человека, работа будет зависеть от его доступности.
Поэтому самостоятельность команд упирается и в устройство кода. Если покупка и участие ученика слиты в одну модель, понадобится разделить их; если система меняет чужое состояние без явного запроса, нужно уточнить границу записи. Иногда достаточно договориться, что означает сообщение и какие изменения оно разрешает получателю.
В материалах DORA о слабо связанных командах самостоятельность связывается с возможностью изменять, проверять и выпускать свою часть без постоянной зависимости от соседей. Технологическая вывеска этого не гарантирует. Нужные свойства можно получить в разной архитектуре; микросервисы сами по себе проблему не решают.
Я бы не требовал совместного согласования каждого изменения после того, как общий контракт определён. Проверки должны позволять командам работать отдельно до тех пор, пока они сохраняют эту договорённость. Когда меняется сам контракт, его нельзя считать внутренней деталью одного репозитория.
Здесь же возникает практическое ограничение параллельной работы. Даже когда поведение продукта согласовано, команды могут по-разному понимать, какая сторона его обеспечивает. Прежде чем менять обе реализации, нужно договориться об этом и связать их проверки. Задачи, которые не зависят от этой договорённости, можно выполнять дальше.
В статье о делегировании я разбирал, сколько самостоятельности дать исполнителю на конкретном участке работы. На семейной интеграции видно следующее ограничение: самостоятельные участки могут зависеть от одной общей гарантии. Тогда прежде, чем распараллеливать изменения, нужно определить, кто её обеспечивает.
Если всё готовое постоянно ожидает меня, я бы выяснил причину: нужен ли недостающий факт, совместная проверка, решение другого владельца или действительно моё мнение. Для этих причин нужны разные действия. Ещё один ревьюер полезен не во всех случаях, а ещё один исполнитель способен увеличить очередь.
У общей проверки остаётся своё слабое место: кто-то должен определить правильное ожидание. В истории с семейным доступом моё первое представление о задаче как раз оказалось неполным.
Кто проверяет решение техлида
В истории с семейным обучением полезный вопрос задал разработчик. А я к этому моменту уже примерял техническое исключение. Если бы моё предложение автоматически становилось последним словом, мы бы закрепили в коде именно его.
Я пытался помочь командам закончить задачу и учесть известные условия. Это, кстати, вполне совместимо с ошибочной моделью. Опыт позволяет быстрее узнать знакомую ситуацию, но иногда вместе с ней узнаёшь и ответ раньше, чем стоило.
Для команды важно, что происходит после возражения. Можно выслушать человека и всё равно продолжить как решили. Можно потребовать, чтобы он сразу принёс полностью готовую альтернативу. А можно остановиться на конкретном контрпримере и проверить, выдерживает ли его исходное решение.
Мне ближе последний вариант. Чтобы усомниться в индивидуальном флаге, разработчику не требовалось заново спроектировать две системы. Достаточно было показать следующий нормальный случай: муж тоже меняет поток независимо от жены.
После возражения должно быть понятно, что именно мы проверяем. Сначала определяем спорное условие, затем находим основание или выполняем проверку. Если ошибка подтвердилась, меняем решение независимо от того, кто предложил первую версию.
Для сегодняшнего процесса с агентами я разделяю три вопроса. Проверка поведения устанавливает, соответствует ли код правилу. Перед выпуском нужно определить, разрешено ли применять это изменение здесь. После применения – увидеть, получили ли люди нужный результат. Один положительный ответ не закрывает остальные вопросы.
Предположим, агент написал тест индивидуального перевода. Если ожидаемое поведение он вывел из той же неподтверждённой трактовки клиента, тест может добросовестно закрепить ошибку. Другой агент, прочитавший только постановку и этот тест, способен согласиться с ним. Различие названий ролей в отчёте ещё не говорит, что у проверки появилось независимое основание.
В нашем примере таким основанием служит согласованный сценарий обучения: два участника одной покупки могут учиться отдельно. А затем нужна последовательная проверка поведения обеих систем, включая очередное обновление из CRM. Рецензент должен понимать, откуда взялось это ожидание и что именно проверили.
Для этого и нужен инженерный harness – процесс выполнения и проверки работы. Но его критерии тоже кто-то устанавливает. Исполнитель может предложить поправку к требованию и поменять тест вместе с кодом. Он не должен незаметно ослабить правило, получить зелёный результат и единолично разрешить себе выпуск.
Это разделение уже появляется в инструментах. В auto mode Anthropic отдельный классификатор сопоставляет действия агента с сообщениями пользователя. Объяснения исполнителя и результаты инструментов ему не показывают, чтобы они не подменяли исходное разрешение. Проверяется и передача задач субагентам. Авторы описывают пропуски опасных действий: отдельная проверка полезна, но не гарантирует безопасность.
Человеческое участие тоже нужно устроить так, чтобы оно имело смысл. Проверяющему необходимы время, доступ к основаниям и возможность остановить применение изменения. Если он получает большой diff за минуту до обещанного запуска, подпись ответственного вряд ли добавит ему понимания.
И наоборот, не всякое несогласие даёт право бесконечно удерживать задачу. Возражение о факте ведёт к проверке. Разные предпочтения сравниваются с целью задачи. Выход за допустимые условия возвращается тому, кто вправе эти условия изменить. Иначе любой спор можно переименовать в "архитектурный риск", после чего работа будет ждать самого настойчивого участника.
После проверки можно принимать решение о выпуске. Важно сохранить, какой код, какие условия и какое сочетание систем мы проверили: следующая задача может изменить любую из этих частей.
Когда нужно пересмотреть разрешение на выпуск
Позже эту работу продолжит инженер, который не участвовал в нашем обсуждении. Ему нужно понять, к какому случаю относилось разрешение и что нельзя потерять при новом изменении. Старый тест или короткая заметка помогут только в той мере, в какой сохраняют эти условия.
Например, запись "CRM главная" скрывает нужное различие. Andrews хранит право на учебные места, но не каждое изменение карточки клиента должно менять поток конкретного ученика. Именно такую область и причину правила важно сохранять в памяти проекта.
Обратное обобщение тоже было бы ошибкой: "после перевода изменения из CRM игнорируем". Учебное место по-прежнему связано с действующим коммерческим правом. Если по согласованным правилам это право прекратилось, нельзя автоматически считать индивидуальный перевод основанием сохранить доступ навсегда.
Для следующей задачи я бы явно записал: обычное обновление покупки с действующим правом на место не отменяет индивидуальный перевод ученика. Рядом стоит сохранить, почему принято это правило, к каким изменениям оно относится и где найти полную договорённость. Тогда новый исполнитель сможет проверить свой случай, а не угадывать смысл фразы "CRM главная".
До выпуска: проверить новое сочетание версий
Теперь продолжим учебный пример с двумя агентами. Каждый убрал проверку, рассчитывая на её наличие у прежнего соседа. В комбинации обе защиты исчезли, и синхронизация отменяет индивидуальный перевод.
Бизнес-правило от этого не устарело. По-прежнему требуется перевести одного человека и сохранить обучение другого. Недостаточными стали прежние проверки и разрешение на выпуск: они относились к другому сочетанию изменений.
Я бы останавливал выпуск этой комбинации, сохраняя возможность продолжать независимые задачи. Дальше нужно договориться, какая сторона сохраняет защиту, исправить выбранную реализацию и проверить совместное поведение. Слово "готово" из предыдущего отчёта не переносится на новую комбинацию автоматически.
Перед выпуском защищённый CI или сервис выпуска должен проверить: к выпуску подготовлено именно то сочетание версий Andrews и учебной платформы, которое прошло общую проверку по действующим требованиям и получило разрешение на выпуск. Если изменилась хотя бы одна версия или сами требования, нужно заново оценить, достаточно ли прежних результатов и разрешения для нового сочетания. Исполнитель не должен иметь возможности ослабить эту проверку или обойти её при выпуске. Если такого механизма нет, запись "разрешение отозвано" сама не остановит инструмент.
Такой допуск я предлагаю для нынешней работы с агентами. Его внедрение в FIN-RA эта история не показывает.
После выпуска: выяснить, какие данные изменились
Если версия уже работает у пользователей, остановить следующий выпуск недостаточно. Нужно выяснить, каких учеников затронули изменения, и выбрать допустимое восстановление. Откат кода не вернёт автоматически прежнюю группу ученику и не восстановит потерянное значение. Работа с реальными последствиями требует соответствующих полномочий и понимания состояния данных.
Если школа меняет само правило обучения
Бывает и другая причина пересмотра: школа действительно меняет условия перевода. Тогда нужно найти известные зависимые задачи, проверки и заметки, определить, что ещё применимо, а что требуется обновить. Исправить код, нарушивший прежнее правило, и реализовать новую договорённость с учениками – разные задачи, даже если обе затрагивают один обработчик.
Можно заранее договориться, при каких результатах команда останавливает выпуск и кто разбирает спор. В примере политики error budget из Google SRE описаны условия ограничения изменений, исключения и маршрут разрешения спора. Нам полезен сам механизм: наблюдаемый результат имеет предусмотренное последствие для работы команды. Конкретные пороги из этого примера к образовательной платформе отношения не имеют.
При разборе я бы также отделял плохой исход от слабого решения. Можно обоснованно выбрать вариант при известных ограничениях и всё равно столкнуться с неприятным результатом. Можно случайно получить хороший результат на неверном основании. Поэтому важны сведения на момент выбора и то, что команда сделала после нового факта.
Полезный результат такого разбора виден в следующей задаче: другой инженер понимает, какое правило действует и как проверить его соблюдение. Если он снова должен искать меня, чтобы расшифровать запись, передачу знания мы ещё не закончили.
Как развивать самостоятельность инженеров
После совместного разбора семейного доступа в FIN-RA разработчики уже отделяли изменение покупки от изменения участия конкретного ученика и приходили с тем вопросом, который действительно оставался открытым. Всю цепочку каждый раз заново объяснять не требовалось.
Я не считал, на сколько процентов это ускорило работу. Но качественная разница для меня была заметной: общая договорённость позволяла людям самостоятельно разбирать похожие случаи.
Здесь легко поставить себе неправильную цель. "Команда перестала меня беспокоить" может означать, что люди стали самостоятельнее. А может означать, что они перестали показывать сомнения. Если им всё равно приходится угадывать недостающие правила, отсутствие вопросов ещё не повод радоваться.
Мне важнее, способен ли следующий инженер понять причину правила, заметить случай за его пределами и найти человека, с которым нужно его разобрать. В семейном обучении он должен отличить обычное обновление покупки от индивидуального перевода и прекращения права учиться. Это знание должно быть доступно и тем, кто не участвовал в первоначальном обсуждении.
Объяснение модели, защита выбора и следующая похожая задача помогают проверить обучение отдельного инженера – об этом была статья о делегировании. Теперь нужно посмотреть, сколько людей в команде способны делать эту работу. Если всё это умеет один человек, зависимость от него остаётся.
Для нынешнего процесса я бы проверял это на следующем переводе, который ведёт уже другой инженер. Возьмём тот самый вопрос о муже, теперь как учебную задачу. Инженер сам находит основание семейного доступа, выясняет допустимость отдельного перевода и привлекает сопровождение только к действительно открытому условию. Затем вместе с коллегой из второй команды определяет, какие сообщения и состояния изменятся и как проверить результат.
Я бы подключался к оставшемуся существенному конфликту, если он есть. Чтобы инженер мог дойти до него сам, ему нужны доступ к правилам, возможность обсудить вопрос с их владельцем и способ проверить обе части интеграции. Просто назначить его автором кода, а коллегу ревьюером для этого мало.
AI может помочь ему исследовать код, подготовить варианты и написать реализацию. Понимание человека видно по действию: он заранее объясняет, что произойдёт после следующего обновления из CRM, находит зависимость от версии соседа и проверяет её. Затем такую работу могут брать другие участники. Для команды важно, что несколько человек умеют довести вопрос от неизвестного правила до проверенного результата.
Связь между выполнением задачи и усвоением навыка отдельно проверяли в эксперименте Shen и Tamkin. В нём 52 разработчика осваивали незнакомую библиотеку Trio с AI или без него. После работы проверяли понимание без AI. Группа с AI хуже усвоила материал; значимого ускорения выполнения задачи в этих условиях не установили. Это короткое исследование нового навыка, а не доказательство многолетней деградации разработчиков или результат работы современных автономных агентов.
Для меня здесь достаточен более узкий вывод: выполненная задача не сообщает автоматически, чему человек научился. Если мы рассчитываем, что дальше инженер будет проверять работу агента, нужно отдельно убедиться, что он понимает полученное решение и умеет его проверить.
Техлида это касается в той же степени. Если я постепенно перестаю понимать, как проверить предложенную границу или восстановить данные после ошибки, моё согласование теряет цену. Сохранение практики я бы оценивал через способность воспроизвести спорное поведение, найти его причину и понять ограничения решения. Процент кода, набранного руками, на эти вопросы отвечает плохо.
Обучение требует времени, в том числе времени проверяющего. Если в плане есть только скорость закрытия задач, а разбор предположений должен происходить где-нибудь между делом, команда получает противоречивый сигнал. Мы просим людей думать самостоятельно и одновременно делаем эту работу помехой их видимому результату.
Я бы включал в оценку полезной работы и обнаруженное ложное предположение, и правильно остановленное изменение, и обоснованный пересмотр моего собственного предложения. Разумеется, с конкретным основанием: бесконечные сомнения без проверки тоже умеют останавливать продукт.
В нашей истории разработчику хватило вопроса о возможном переводе мужа, чтобы изменить направление обсуждения. Хотелось бы, чтобы такой вопрос мог задать и новый человек в команде. Когда люди умеют находить подобные пробелы и знают, что делать дальше, моя работа перестаёт быть обязательным промежуточным шагом каждой задачи.
В чём работа техлида в команде с AI
Техлид выстраивает работу так, чтобы команда могла сама выяснить нужное правило, принять решение в своих полномочиях, проверить его и вернуться к последствиям. Для меня это ответ на вопрос первой статьи цикла: какая работа остаётся моей, когда понятное исполнение можно всё чаще отдавать агенту.
Сначала мне пришлось признать неполноту постановки, которую я сам недооценил. Затем – собрать участников, помочь разделить коммерческое право и участие в обучении, договориться, что передавать между системами и какой результат считать правильным. Это давало командам пространство для самостоятельной реализации.
Система решений команды определяет, кто вправе выбирать правила, что исполнители могут делать самостоятельно, чем проверяется результат и когда выбор нужно пересмотреть. Это моё рабочее описание, собранное из практики и известных подходов; отдельного отраслевого стандарта под этим названием я не предлагаю.
Вернёмся к просьбе сопровождения и посмотрим, как эти решения связаны в предлагаемом процессе.
Правило индивидуального перевода ограничивает обе реализации: общая покупка не должна неявно двигать мужа и жену вместе. Команды договариваются, какая сторона защищает эту границу, и внутри договорённости работают самостоятельно. Общая проверка затем оценивает именно сочетание изменений, а не только два отдельных отчёта.
Если проверка обнаружила отмену перевода, выпуск останавливается. При прежнем правиле команда исправляет реализацию и проверку. Если же уполномоченный участник действительно изменил условия обучения, пересматриваются само правило, зависимые задачи и записи. Сохранённое основание должно помочь следующему инженеру отличить эти ситуации и организовать работу без восстановления всей истории через меня.
Здесь и соединяются практики цикла. Вопрос о супруге заставил нас уточнить модель и понять, что нужно менять в каждой системе. В современной работе с агентами эту договорённость нужно связать с их полномочиями и общей проверкой версий. А следующему инженеру понадобится причина решения, чтобы продолжить работу без повторного разбора всей истории.
Я бы начинал с одного повторяющегося класса изменений, который регулярно застревает на общей границе. Посмотрел бы, какое решение там ожидается, кто должен его принимать и что мешает проверить результат. Затем изменил бы один участок процесса и проследил следующую задачу от запроса до последствий.
При этом считал бы время ожидания вместе с проверкой и переделкой. Смотрел бы, какие риски обнаружены, какие пропущены и кто способен разобрать новый случай. Если согласований стало меньше, но ошибки теперь обнаруживает поддержка, улучшения не произошло.
Самая неприятная проверка для техлида тоже довольно простая: если меня некоторое время нет, команда может восстановить смысл и принять допустимое решение? Она умеет остановиться на настоящем исключении? И сможет ли она показать мне, что прежнюю договорённость нужно изменить?
Муж хотел продолжить обучение. Жена – перейти позже и сохранить сделанное. Ради этого нам понадобились и модель, и разговор между командами, и право на решение, и проверка, и передача знания. Ни один из этих элементов по отдельности не закрывал просьбу.
Так я и понимаю результат работы техлида: команда учится самостоятельно разбирать более сложные задачи, замечать ошибки раньше и сохранять смысл дольше, чем длится один разговор со мной.
Это финал цикла "Инженер и машина". Если у вас похожие решения всё ещё держатся на одном человеке, интересно обсудить в Telegram, что именно к нему постоянно возвращается: недостающий контекст, право выбора или невозможность проверить результат без его участия.
Что почитать
- Andrew Harmel-Law, Scaling the Practice of Architecture, Conversationally – архитектурные решения, консультации и распределение экспертизы.
- Tomašev, Franklin, Osindero, Intelligent AI Delegation – исследовательская рамка делегирования между людьми и агентами.
- DORA, Loosely coupled teams – технические условия самостоятельной работы команд.
- Anthropic, How we built Claude Code auto mode – отдельная оценка допустимости действий и её ограничения.
- Shen, Tamkin, How AI Impacts Skill Formation – эксперимент об усвоении нового навыка при работе с AI.
- Google SRE Workbook, Example Error Budget Policy – пример заранее согласованной связи между наблюдением и действием.