Как AI меняет роль техлида: позиция к круглому столу

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

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

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

Я не строю позицию на том, что AI никогда не сможет рассуждать об архитектуре. Он может помогать и с постановкой, и с поиском рисков, и с проверкой. Но способность предложить ответ сама по себе не устанавливает обязательств перед пользователями и соседними командами. Техлид организует принятие решений с учётом этих обязательств; часть решений команда должна уметь принимать без него.

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

Поэтому мой вопрос к роли звучит так: если техлид на неделю ушёл в отпуск, команда продолжает безопасно менять систему и понимает, когда остановиться? Если нет, увеличение числа агентов скорее усилит зависимость от одного человека.

В позициях к Deep Tech Night и докладе на DotNext я связывал удешевление генерации со смещением нагрузки в постановку и проверку. Для круглого стола здесь важно управленческое следствие: недостаточно сделать каждого исполнителя быстрее. Нужно понять, куда попадает произведённая им работа.

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

Схема показывает мою рабочую гипотезу о смещении очереди. Она не означает, что реализация перестала быть ограничением во всех командах. Где-то медленнее всего согласуются требования, где-то недоступна тестовая среда, где-то сложнее всего найти нужную клиенту задачу. Техлиду нужно найти свою очередь по фактическому прохождению изменений.

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

Первое вмешательство может быть простым: уменьшить размер изменений, ограничить одновременно начатую работу, назначать проверяющего заранее. Это согласуется с общей рамкой DORA 2025: AI усиливает уже существующие свойства организации. Из неё не следует гарантированное ускорение каждой команды.

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

В истории о письменной культуре я объяснял, зачем начал активно писать RFC, ADR и инструкции: информация переставала замыкаться на мне. С агентами критерий остаётся тем же. Хороший документ позволяет следующему инженеру понять решение и оспорить его. Количество сгенерированных страниц этого не гарантирует.

В разборе Regenerative Software Чада Фаулера мне особенно близка идея: реализация может меняться, а контракты, проверки и причины решений должны переживать замену. Для техлида это вполне конкретная работа. Выделить обещания системы, вынести существенное знание из случайных деталей кода и убедиться, что проверка опирается на нужное пользователю поведение.

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

Что я хочу увидеть в RFC

Это моя практическая памятка, не требование выпускать RFC на каждую правку. Для небольшой локальной задачи хватит короткого описания. Масштаб согласования должен зависеть от последствий, а не от способности модели написать большой документ.

AI может искать дефекты, замечать несогласованность, объяснять сложный участок и предлагать дополнительные тесты. Я бы использовал это до передачи изменения коллеге. Но ответ «другой агент посмотрел и одобрил» ещё не доказывает, что проверка была независимой: оба исполнителя могли принять одну неверную трактовку требования.

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

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

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

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

Фраза «за всё отвечает человек» слишком удобна, если после неё ничего не меняется. Человеку нужны полномочия ограничить действие агента, увидеть проверяемое изменение, отклонить его и организовать восстановление. Назначить ответственного без времени, информации и права остановки — значит создать формальность.

В позиции к Deep Tech Night я держал строгую границу: выпуск в рабочую среду проходит через человека. В статье «Когда код пишет агент» я отдельно обсуждал условия возможного расширения автономии. Эти две мысли нужно различать: направление развития не отменяет действующую политику допуска.

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

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

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

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

В повседневной работе это три связанных умения. Первое — сформулировать намерение и ограничения. Второе — выбрать способ проверки, который может опровергнуть красивый ответ. Третье — договориться с людьми о последствиях решения. AI помогает на каждом шаге, но техлид должен понимать, на каких основаниях команда действует.

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

В «Джуне после кода» я разделял два результата: что человек сделал с агентом и чему научился. Быстро закрытая задача может дать оба результата, один из них или ни одного. Из красивого готового проекта уже нельзя уверенно вывести самостоятельность автора.

В эксперименте Anthropic с 52 инженерами, осваивавшими библиотеку Trio, группа с AI получила на немедленной проверке знаний в среднем 50%, группа без AI — 67%. Это разница в 17 процентных пунктов; выигрыш во времени не был статистически значимым. Небольшой эксперимент об освоении нового инструмента не устанавливает долгосрочную судьбу профессии. Он даёт основание проверять обучение отдельно от скорости выполнения.

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

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

Для этого нужны реальные ограниченные задачи, время наставника и право ошибиться в безопасной среде. Часть упражнений разумно делать без генерации; в других нужно учиться делегировать. Общий запрет AI и полная передача ему учебной работы одинаково плохо учитывают цель конкретного упражнения.

Это касается и опытных инженеров. Если один старший сотрудник постоянно исправляет ответы агентов за всех, он перегружается, а команда не становится самостоятельнее. Техлиду стоит распределять разборы, просить объяснять причины решений и возвращать важные ошибки в общие учебные примеры.

Начал бы с одного повторяемого класса задач в одном сервисе. Например, небольшие изменения API без изменения модели доступа и необратимых миграций. Такой масштаб позволяет увидеть эффект и исправить процесс до расширения. Следующий план — рабочая эвристика, а не обещание трансформации за четыре недели.

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

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

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

Сопоставлять нужно сходные задачи при заранее заданной приёмке. Иначе дробление работы или выбор только лёгких примеров создаст видимость прогресса. Четырёх недель может не хватить для оценки редких отказов и долгосрочного роста навыков; отсутствие инцидента на маленькой выборке не доказывает безопасность.

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

Вступительная реплика — примерно на минуту

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

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

Три возражения, которые стоит обсудить

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

«Все эти проверки съедят ускорение». Иногда съедят — это тоже результат эксперимента. Тогда стоит менять размер задачи, инструменты и способ проверки. Если единственный способ показать пользу заключается в исключении затрат проверяющего, экономика посчитана неполно.

«Вы просто переименовали хорошего техлида». В части принципов — да. Новизна в соотношении объёмов: вариантов и изменений становится больше, а внимание и способность команды понимать последствия не растут автоматически. Старые обязанности требуют другого распределения времени, полномочий и автоматизации.

Вопросы другим участникам

• Какое решение в вашей команде агент уже может довести до результата без техлида и на каких основаниях?
• Где после внедрения AI выросла очередь и кто получил дополнительную работу?
• Как вы проверяете, что инженер научился чему-то, помимо получения правильного ответа?
• Какая проверка или граница доступа позволила вам действительно уменьшить ручной контроль?
• Какой наблюдаемый результат заставит вас пересмотреть текущие границы автономии?