От автора до руководителя: как меняется работа разработчика с агентами

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

Ниже разберём, как это описывают исследования и отчёты последних двух лет: четыре способа работать с агентом, выбор способа под задачу и то, что называют "намерением и планкой качества". Во второй половине поговорим о том, почему роль разработчика становится шире, чем написание кода. Данные на сентябрь 2026 года. Цифры стоят в отдельных блоках со ссылкой на источник. Где пересказываю позицию авторов, называю их, а свои выводы так и помечаю.

Четыре способа работать с агентом

Самую ясную схему предложил Джаред Спатаро из Microsoft в мае 2026 года. Он описывает четыре способа, которыми человек и ИИ делят работу. Схема понятная, и разработчик узнает в ней собственный путь с инструментами.

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

Способ под задачу, а не лестница

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

На практике выбор упирается в четыре вопроса:

• насколько ясна цель. Если вы сами пока не знаете, что должно получиться, отдавать задачу целиком рано;
• можно ли проверить результат автоматически. Хорошие тесты позволяют отпустить агента дальше, потому что ошибку поймает проверка, а не ваша внимательность;
• сколько стоит ошибка. Опечатку в подсказке исправить легко, неверный расчёт денег дорого;
• повторяется ли задача. Для разовой задачи отдельный процесс строить невыгодно, для задачи каждую неделю вполне.

Как это раскладывается на конкретные задачи:

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

В Claude Code этот выбор настраивается напрямую. Plan mode и правила разрешений работают как регулятор, который выставляете вы сами. Для дорогой задачи включаете план до правок и подтверждение рискованных действий, для рутинной отпускаете агента дальше.

Намерение и планка качества

Чем больше работы вы отдаёте, тем важнее то, что вы говорите до начала. Исследование Microsoft формулирует это так: самыми эффективными пользователями ИИ станут не те, кто делает больше и быстрее, а те, кто строит свою ценность вокруг того, что может только человек. Задать ясное намерение, то есть описать желаемый результат и планку качества, и продумать, как работа делится между людьми и ИИ.

В разработке у этой идеи давно есть привычные названия. Намерение - это спецификация: что сделать и зачем. Планка качества - это критерии приёмки и то, что в Scrum называют Definition of Done: список условий, при которых работа считается готовой. Дальше будем называть это просто планкой готовности.

Дэниел Эпштейн из Microsoft, который строит агентов по Agile, сформулировал это совсем коротко в первой статье серии Agentic-Agile (19 мая 2026): "Every capability is an issue. Every issue has acceptance criteria." Каждая возможность - это задача, у каждой задачи есть критерии приёмки.

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

Было:

Сделай экспорт расходов в CSV, чтобы было нормально.

Стало:

Зачем: бухгалтер каждый месяц переносит расходы команды в свою таблицу
вручную. Это час работы и ошибки в суммах.

Задача: добавить кнопку "Экспорт в CSV" на страницу расходов за месяц.

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

Не трогать: формат хранения расходов и существующий экран списка.
Сначала покажи план и способ проверки каждого пункта.

Во втором варианте агенту почти нечего угадывать. А главное, вам есть с чем сравнивать результат: три пункта проверяются руками за пару минут. Слово "нормально" из первого варианта проверить нельзя. Его можно только принять на веру.

Агент не знает, что такое хорошо

Дальше в основном мои выводы из данных, а не сами данные. Отмечу это сразу, чтобы не выдавать мнение за результат исследования.

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

"Хорошо" не лежит в коде. Оно зависит от того, кто будет пользоваться результатом, что для этого человека дорого и какие ошибки недопустимы. В примере с экспортом агент вполне мог сделать технически правильный CSV, который у бухгалтера откроется кракозябрами. С точки зрения кода всё верно. С точки зрения задачи - нет.

Вывод простой. Задать критерий и проверить результат по нему - та часть работы, которую нельзя делегировать. Агент может помочь сформулировать критерии, задать уточняющие вопросы, предложить проверки. Решение, что критерии правильные, остаётся за вами.

Сначала понять процесс

Откуда берутся критерии? Почти никогда не из кода. Они берутся из бизнес-процесса: кто откроет файл, что он с ним сделает дальше, что случится, если строка потеряется или сумма округлится не туда.

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

Компании это уже замечают и перестраивают роли.

У этой истории есть и противоположная позиция, её стоит знать. Например, консалтинговая компания Converteo в своём блоге описывает роли продакт-менеджера, дизайнера и AI product builder как дополняющие друг друга, а не конкурирующие: первый отвечает за "зачем", второй за пользователя, третий быстро превращает идею в работающий прототип. Converteo сама продаёт услуги в этой области. Я бы не ставил на одну из версий. Для вас практический вывод одинаковый: разработчик, который понимает процесс заказчика, ценнее того, кто ждёт идеально написанного тикета.

Разговор как рабочий инструмент

Раньше soft skills часто подавали как приятное дополнение к технике. С агентами это меняется. Критерии качества живут в головах людей, а не в репозитории, и достать их оттуда можно только разговором.

Вот что на деле оказывается частью работы:

• спросить. Не "что сделать", а "что вы будете делать с результатом" - на этот вопрос люди отвечают точнее;
• уточнить. Переспросить про крайний случай, пока он не стал багом: что делать с тратой без категории?
• записать. Договорённость, которая осталась только в разговоре, агент не прочитает, а коллега забудет;
• согласовать границы. Что входит в задачу, а что нет, и сказать "это отдельная задача", когда просят "заодно поправить";
• объяснить компромисс. "Сделаем за день без выбора периода или за три дня с выбором" - решение за заказчиком, но варианты даёте вы.

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

Каждый немного CEO

Если собрать всё вместе, получается знакомая картина. Поставить цель, задать критерии, распределить работу, проверить результат и отвечать за него - это работа руководителя. Работая с агентами, разработчик делает её каждый день, пусть и в маленьком масштабе.

Метафора CEO хороша одним: она правильно показывает, где ответственность. CEO может делегировать почти всё, кроме ответственности за результат. С агентами так же. Если агент сделал экспорт, который ломает таблицу бухгалтера, отвечать будет не агент.

Стоит сказать и то, чего метафора не значит. Это не повышение в должности, и никто не станет руководителем от того, что запустил трёх агентов. Скорее навыки руководителя понадобятся раньше, чем было принято, уже на первой работе. И есть риск: разработчики долго росли через написание кода руками, и этот путь меняется. Понимать код, который вы принимаете от агента, по-прежнему обязательно. Без этого проверка превращается в "вроде работает".

Как читать эти данные

Все цифры выше выпущены компаниями, которые продают ИИ или продукты вокруг него. Это не делает их ложными, но это стоит учитывать. Короткая сводка:

Все проценты здесь - самооценка людей в один момент времени. Они показывают, что люди думают и ожидают, а не что произошло на самом деле. Авторы Work Trend Index 2026 прямо пишут, что связи в их анализе - статистические ассоциации, а не причины и следствия.

К любой цифре про ИИ и работу полезно задать три вопроса. Кто заплатил за исследование? Что именно измерили: мнение, ожидание или реальный результат? Кого спросили и похожи ли эти люди на вас? Если ответы вас устраивают, цифру можно использовать. Если нет, она всё равно может быть интересной, просто весит меньше.

Ради чего это всё

Всё, что выше звучит как язык отчётов, в работе с Claude Code превращается в конкретные привычки:

• план до правки - это и есть намерение. Попросите агента сначала показать, что и как он будет менять, и сравните с тем, чего хотели вы;
• критерии приёмки в запросе - ваша планка готовности. Два-три проверяемых пункта вместо "чтобы было нормально";
• режим работы и правила разрешений - выбор способа. Чем дороже ошибка, тем чаще агент останавливается и спрашивает;
• просмотр diff и честная проверка - оценка результата по вашим критериям, а не по отчёту агента;
• короткий итог: что сделано, чем проверено, что не проверено - ответственность за результат, которую нельзя передать агенту.

Данные на сентябрь 2026 года. Исследования в этой области выходят часто, и цифры устаревают быстрее, чем выводы.