Как AI меняет роль техлида

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

На примере Сбера обсуждаются три группы наблюдений: объём произведённых артефактов, длительность работы и поставленные пользовательские истории как компромиссный язык разговора с бизнесом. Участники не предлагают считать строки кода универсальной мерой ценности. Рафаел рассказывает, что на этапе освоения инструмента строгие лимиты способны остановить внедрение, но позднее расходы всё равно придётся относить на конкретные направления бизнеса. Один из способов подготовить людей — показывать денежную оценку потребления и помогать выбирать модель под сложность задачи. Александр предлагает смотреть на рабочие сессии и задачи целиком: сколько времени потратил человек, сколько агент, где пришлось переключать инструменты и ждать. Телеметрия нужна для понимания процесса, а не только для учёта подписок. В разговоре о маршрутизации моделей появляется и техническая цена: перенос контекста, повторная обработка входных данных и возможные потери при сокращении истории. Дешёвый отдельный запрос ещё не означает дешёвую выполненную задачу.

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

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

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

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