Разработчик становится менеджером в эпоху AI?

Андрей вспоминает начало своей карьеры: от айтишника могли ждать общения с заказчиком, составления требований, разработки, проверки, развёртывания и поддержки. Рост компаний разделил эту работу между специализациями. Руководитель отдавал понятную часть задач другому человеку, а отрасль училась быстро воспроизводить результат большими командами. Александр приводит историю сложной системы экспериментов, где части были написаны на C++, Go и TypeScript. Некоторые инженеры не хотели выходить за пределы своего языка, хотя компании были нужны их знания предметной области: распределение трафика, статистические критерии и корректность выводов. Привычка отождествлять профессию с технологией мешала увидеть, какую проблему человек способен решить. В условиях быстрого роста это разделение позволяло собирать большие команды, но вместе с ним закреплялись профессиональные границы, которые теперь приходится пересматривать. Участники связывают нынешний сдвиг с возможностью поручать агентам работу сразу на нескольких этапах разработки.

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

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

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

Изменение касается и того, для кого проектируют продукты. Андрей описывает интерес JUG Ru Group к тому, как информация о конференциях появляется в ответах ИИ: искать мероприятие может сам человек или его помощник. Александр связывает это с переходом от интерфейса пользователя к взаимодействию через агента. В разговоре о SWE-agent он напоминает, как специализированный интерфейс помогал более ранним моделям работать, а позднее более сильным моделям оказалось достаточно доступа к командной оболочке. Это оставляет два возможных направления: менять среду под агента или ждать, что агент лучше освоит существующую среду. Участники обсуждают и сценарий, в котором помощник собирает нужный процесс из доступных возможностей вместо того, чтобы вести человека по заранее подготовленным экранам. Такие изменения могут затронуть маркетинг, поиск и дизайн. Разговор предлагает смотреть на них как на развивающиеся возможности, а не как на уже завершённую перестройку всех продуктов.

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