Появление AI-агентов в разработке радикально поменяло то, как работают инженерные команды — от ролей разработчиков и тимлидов до структуры QA и обязанностей инженерного руководства. Производительность реально выросла примерно в два раза, но вместе с этим появилась куча новых рисков: выгорание, повышенная когнитивная нагрузка, необходимость пересмотреть роли и принципы устройства команды. В этой статье — как эти изменения отражаются на каждой роли в процессе разработки.
Разработчики
Может казаться, что работа разработчиков должна резко ускориться с AI-агентами. На деле ускорение есть, но не такое драматическое, как ожидалось. Вот почему.
Давай посмотрим на workflow разработки до и после AI-агентов.
До агентов разработчик сначала думал над задачей, потом монотонно писал код. Сейчас он на каждом шаге занят high-load когнитивной работой. Глубокое мышление, промптинг, ревью — всё требует полной концентрации и непрерывного принятия решений. 30–40% высокой нагрузки до — против 70–80% сейчас. Разработчики постоянно принимают решения — и в этом ключевая проблема.
Когнитивная нагрузка и decision fatigue
The Strength Model of Self-Control показывает, что «все акты контролируемого мышления используют один и тот же ограниченный когнитивный ресурс, и как только он исчерпан, сложное рассуждение и обнаружение ошибок резко деградируют». AI убирает рутинную часть (набор кода), но оставляет самое тяжёлое: думать, проверять, решать.
В итоге разработчику нужно больше времени на отдых. Иначе падает внимание и после прохода агента в код просачиваются баги. Так что если ты часто видишь разработчика на кухне с кофе — это не потому что он плохо работает. Ему просто нужно больше восстановления после high-load работы. Парадокс: работаем быстрее, а отдыха нужно больше.
Переключение контекста становится хуже
То же исследование показывает: переключение между задачами и удержание нескольких целей ускоряют это истощение и заметно ухудшают перформанс. А когда разработчик выполняет задачи быстрее — он чаще переключается между ними. У нас в команде мы мониторим количество параллельных задач из разных эпиков на инженера и стараемся держать не больше двух — это сильно снижает переключение контекста.
QA
Роль SDET уходит
Всё больше компаний осознают: разработчики или QA-инженеры теперь сами быстро пишут автотесты с помощью AI. QA пишет тест-кейсы, агент генерирует автотесты, разработчик помогает на сложных сценариях.
Ручное тестирование тоже уменьшается
Зачем руками проверять сценарий, если одним промптом получаешь автотест, который можно гонять бесконечно? Это не лень — это оптимизация. Velocity растёт, ручных прогонов меньше.
Правда, есть домашка. Например, мы загружаем Swagger-спеки прямо в контекст агента — он понимает структуру API и генерирует корректные HTTP-запросы. Можно также собрать документацию по коду и подкладывать её в промпт автотеста.
Уверен: в ближайшем будущем у нас будет качественная автоматизация всего флоу. Агенты будут генерировать тест-кейсы из требований, автоматизировать их и запускать. QA — оркестраторы.
Тимлиды
Тимлидам больше не нужно писать максимально детальные ТЗ — нужны разработчики, которые могут делать без жёстких инструкций. Потому что написать детальную задачу — это уже 80% работы. По сути то же самое, что промптить агента. А тимлиду надо продолжать заниматься архитектурой — без этого решения агентов рано или поздно становятся неподдерживаемыми.
AI даёт тимлидам больше свободного времени, и нужно выбрать как его использовать — hands-on разработка, ресёрч, более глубокое погружение в продукт. Каждый выберет своё, но лично я предпочитаю лидов, которые фокусируются на ресёрче и продуктовом направлении — это даёт долгосрочный импакт.
Джуны
Впервые за много лет мы сталкиваемся с дилеммой — а нужны ли вообще джуны в эпоху AI?
Ответ — да, но только мотивированные и с потенциалом. Многие сеньоры теряют мотивацию после лет в индустрии — не все, но многие. А сеньор с сильной энергией и драйвом — редкий и крайне ценный кадр. Чтобы закрыть этот дефицит, надо набирать молодых. Мотивированный, энергичный джун — это долгосрочная инвестиция.
Техническое руководство
В наших обязанностях больших изменений нет. Поменялось то, что двигаться нужно быстрее. Как всегда, мы должны внедрять новые технологии — но теперь делать это быстрее. Нужно нанимать правильных инженеров, поддерживать их, направлять их рост.
Впервые опубликовано на Medium 10 декабря 2025.