Предыдущие части серии были про технику: слои harness, переносимый слой, верификация, guardrails. Но за всем этим стоит вопрос, который мне задают чаще всего: а кто всё это должен делать? Кто пишет AGENTS.md, настраивает проверки, следит за трасами и лестницей доступа? И что в это время делают остальные?
Отвечаю из своего опыта и из того, что вижу у команд, где агенты уже работают, а не стоят на витрине. Короткая версия: профессия меняется сильнее, чем кажется, и бутылочное горлышко переехало туда, где его никто не ждал.
Бутылочное горлышко переехало в ревью
Когда генерация кода ускоряется в разы, а всё остальное остаётся как было, система упирается в самое медленное звено. Самым медленным звеном оказались мы с вами. Агент пишет код быстрее, чем команда способна его осмысленно проверить. Я наблюдал это на себе: после недели активной работы с агентами у меня скопилась очередь из PR, и поймал себя на желании нажать «approve» пачкой. Это ровно та усталость от подтверждений, про которую была прошлая часть, только на уровне всего процесса.
Из этого следует неприятный вывод: мерить инженера по скорости написания кода потеряло смысл окончательно. Строки и количество PR теперь говорят о производительности агента, а не человека. Ценность инженера сместилась в три вещи: как он ставит задачу, как он проверяет результат и какую среду строит вокруг агента. Команды, которые это поняли, меняют и найм, и оценку. Команды, которые не поняли, получили в пять раз больше кода и в пять раз больше проблем с ним.
Кто строит harness
В больших компаниях под это уже выросли отдельные роли: люди, которые проектируют обвязку, поддерживают evals, следят за дрейфом поведения агентов. Названия разные, суть одна — это платформенная работа на стыке инфраструктуры и разработки.
В команде из пяти-пятнадцати человек отдельной роли не будет, и это нормально. У меня это выглядит так: есть человек (сейчас это я), который владеет обвязкой как продуктом. Не «настроил один раз и забыл», а ведёт: смотрит трассировки, заводит задачи на улучшение harness, решает, какой слой требует вложений в этом квартале. Процентов двадцать его времени. Остальные пользуются обвязкой и приносят боль: «агент опять сделал вот так», — а владелец превращает боль в правило, проверку или инструмент.
Важно, что это не роль «главного по промптам». Harness-инженерия — обычная инженерия: CI, права доступа, инструменты, метрики. Лучший кандидат — сильный инженер с чувством процесса, а не тот, кто лучше всех разговаривает с моделью.
Как меняются роли
Теперь по грейдам, самое личное.
Senior меняется меньше всех по названию и больше всех по сути. Его работа всё меньше про написание кода и всё больше про проектирование рамок: архитектура, границы модулей, критерии приёмки, решения, которые потом исполнят агенты. Хороший senior в этой системе усиливается кратно, потому что его главный навык — понимание, что вообще надо сделать, — как раз не автоматизируется.
Middle становится оператором агентов. Его эффективность теперь измеряется тем, сколько задач он проводит через цикл «постановка, контроль, приёмка» с сохранением качества. Кто-то расцветает в этой роли, кто-то тоскует по рукам на клавиатуре, и это надо проговаривать честно: работа реально другая, не всем она нравится.
Junior — самый сложный случай. Старый путь «пиши простой код, набирайся опыта» сломан: простой код пишет агент. Зато появился новый: junior с первого дня работает внутри хорошей обвязки и учится на её обратной связи. Проверки объясняют, что не так. AGENTS.md учит правилам проекта. Трассы показывают, как опытные коллеги ведут задачи. Я сейчас вхожу в новые проекты быстрее, чем когда-либо, просто потому что знания проекта вынесены из голов в harness, — и для junior это работает ещё сильнее. Но есть и риск: если человек только принимает готовое от агента, не разбираясь, он не растёт. Поэтому правило из моего поста про инженерное мышление никто не отменял: принял изменение — будь готов объяснить его как своё.
Чему учить команду
Если собрать компетенции, которые реально окупаются, получается шесть:
Ставка задачи: сформулировать цель, границы и критерии приёмки так, чтобы исполнитель с любым контекстом сделал правильно.
Управление контекстом: что агенту показать, что убрать, когда сессию пора перезапустить.
Проектирование проверок: тесты от требований, evals, рубрики.
Валидация: чтение результата агента с калиброванным доверием и понимание, куда смотреть в первую очередь.
Оркестрация: разложить большую задачу на агентные этапы и стыковать их.
Ревью как отдельная дисциплина: быстро читать чужой diff, включая агентный, и ловить «улучшения, которые никто не просил».
Заметьте, чего тут нет: нет «промпт-инженерии» как отдельного навыка. Она растворилась в остальных. Спрашивать на собеседовании «а как вы пишете промпты» в 2026 году — примерно как спрашивать «а как вы печатаете».
Сколько людей нужно
Отдельно скажу про размер команды, потому что тут тоже сдвиг. Маленькая команда с хорошей обвязкой сейчас тянет объём, который раньше требовал отдела. Три-шесть человек плюс платформа: один владеет продуктом и постановкой, один-два ведут агентные сессии и приёмку, один держит harness и инфраструктуру. Работает это только при условии, что обвязка построена. Маленькая команда без платформы — это просто маленькая команда. А маленькая команда с платформой — это рычаг.
Чего я не делаю
Не оцениваю людей по объёму сгенерированного кода. Это поощряет мусор: агент радостно произведёт ещё тысячу строк, и метрика вырастет, а проект сгниёт.
Не внедряю агентов «сверху приказом» без перестройки процесса. Автоматизировать старый процесс — получить маленький прирост и большое разочарование. Выигрыш даёт перепроектирование процесса под новые возможности, а не ускорение старого.
Не объявляю зрелость по декларации. «У нас агенты работают автономно» проверяется не слайдом, а простыми вещами: есть ли чекпоинты и откат, ведутся ли трассы, может ли команда показать стоимость задачи. Если нет — автономии нет, есть надежда.
И не жду, что люди перестроятся сами. Смена ролей — это разговоры, обучение и честные ожидания, а не рассылка «с понедельника работаем по-новому».
Главный вывод
Код дешевеет, суждение дорожает. Когда генерация перестаёт быть ограничением, ценность команды концентрируется в постановке задач, проверке результатов и качестве среды, в которой работают агенты. Роль владельца обвязки появляется в любой команде, которая использует агентов всерьёз, — вопрос только, назначите вы её явно или она размоется сама собой между всеми и никем.
Роли меняются у всех: senior проектирует рамки, middle оперирует агентами, junior растёт внутри harness или не растёт вовсе. И размер команды перестаёт коррелировать с её мощностью: маленькие команды с платформой обгоняют большие без неё.
Практический чеклист
Для команды пять-пятнадцать человек, с чего начать:
Назначьте владельца обвязки: явно, с долей времени и правом заводить задачи на harness.
Перестаньте мерить людей строками и количеством PR. Замените на качество постановки задач и подтверждённые результаты.
Сделайте ревью агентных изменений отдельным навыком: чек-лист «относится ли каждая строка к задаче» из заметки про рамки агентам.
Проговорите с каждым, как меняется его работа. Особенно с теми, кому нравилось писать код руками.
Для junior заведите правило: принял от агента — объясни как своё.
Запишите три-четыре типовые задачи команды и проведите их через полный цикл с обвязкой, прежде чем расширять применение.
Финальная часть серии — метрики и дорожная карта: как посчитать, окупается ли harness, и как внедрять его за 90 дней без революций. А у вас в команде уже есть человек, который негласно «главный по агентам»? Вот ему и покажите эту часть.
Discussion
No comments yet - start the thread.