Код перестал быть дефицитом: как агентная разработка меняет команду

Разговор об ИИ в разработке не обходится без темы скорости: насколько быстрее и лучше программист пишет код с помощью Claude Code или Copilot. Но как только агент начинает выполнять заметную часть работы, выясняется, что написание кода было лишь одним из ограничений процесса.

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

Агентная разработка меняет не только способ написания кода. Вместе с ней перестраивается весь цикл разработки, а следом — работа аналитиков, разработчиков, тестировщиков, архитекторов и руководителей проектов.

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

ИИ перестраивает производственный цикл разработки

Мы в SVK.Digital начали внедрять ИИ с локальных задач. Это естественный первый шаг: найти операцию, которая отнимает много времени, автоматизировать её и быстро увидеть эффект. Но несколько успешных автоматизаций сами по себе ещё не складываются в новый процесс разработки.

Побочный эффект локальной автоматизации

У нас разные подразделения самостоятельно искали задачи, где ИИ мог дать быстрый и измеримый результат. Одним из первых появился внутренний сервис для подготовки смет. Раньше первичная оценка проекта могла растянуться до двух недель из-за необходимости собрать нескольких специалистов и дождаться свободных слотов. Сейчас первую версию мы получаем примерно за 20 минут, а после нескольких месяцев работы на наших данных расхождение с человеческими оценками составляет около 5–10%.

Руководители проектов автоматизировали часть работы со встречами. Система расшифровывает запись, готовит черновик письма по итогам разговора и данные для недельного отчета. На одного руководителя проекта это освобождает примерно час-полтора рабочего времени в день.

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

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

Если аналитик быстрее подготовил задачу, разработчик быстрее написал код, а руководитель проекта быстрее обработал встречу, это ещё не означает сопоставимого ускорения всего проекта. Требования могут храниться в одном месте, архитектурные решения — в другом, а агент разработчика при этом видеть только текст тикета.

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

Ускорение одного этапа переносит ограничение на следующий

Есть и второй эффект: ускорение одного участка переносит очередь дальше по процессу.

Это хорошо видно на примере кода — если разработчики с помощью агентов производят больше изменений, растёт количество pull request, потенциальных конфликтов и решений, которые нужно проверить перед выпуском. Узким местом постепенно становится ревью.

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

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

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

Оценивать эффект ИИ имеет смысл по всему пути задачи до выпуска. Если разработка стала занимать два часа вместо четырёх, а pull request затем половину дня ждёт ревью, значительная часть выигрыша теряется. Следующее ограничение может также появиться на тестировании, согласовании или релизе.

Как вслед за процессом меняются роли

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

На этом уровне начинает меняться содержание привычных ролей.

Аналитик отвечает за качество исходной задачи

ИИ забирает у аналитика значительную часть подготовки материалов. Из стенограммы встречи он может собрать требования, предложить критерии приёмки, описать API и подготовить черновую диаграмму. То, на что раньше уходили часы, теперь занимает минуты.

Работа аналитика всё сильнее концентрируется на том, чего в исходной задаче нет: скрытых ограничениях, исключениях и противоречиях между участниками бизнеса. Например, по требованию «нужна гибкая система скидок» агент быстро предложит варианты реализации, а аналитику придётся выяснить, можно ли складывать скидки, что происходит при возврате, кто меняет правила и какие ограничения по маржинальности действуют.

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

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

Разработчик управляет изменением системы

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

Главный риск — скорость накопления технического долга через решения, которые хорошо работают в рамках одной задачи. Агент может связать модули, которые по архитектуре должны оставаться независимыми, скопировать бизнес-логику вместо использования общего правила или обратиться к данным в обход сервиса, который контролирует их изменение. Один такой компромисс может быть оправдан. Серия подобных решений постепенно увеличивает связность компонентов, дублирует логику и делает следующие изменения дороже.

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

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

QA отвечает за независимую проверку

ИИ уже умеет генерировать тесты вместе с кодом и забирать часть повторяемых проверок. Работа QA смещается к независимой проверке решения: поиску ошибок в бизнес-логике, граничных сценариях и условиях, которые агент мог не учесть.

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

Ценность тестировщика всё меньше определяется объёмом ручной регрессии и всё больше — способностью доказать, что решение действительно корректно.

Архитектор превращает знания о системе в явные правила

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

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

Задача архитектора всё больше состоит в создании среды, внутри которой агенты способны работать автономно без накопления архитектурных ошибок.

Руководитель проекта управляет потоком работы

У руководителей проектов ИИ забирает часть рутинной работы: стенограммы, письма по итогам встреч, отчёты и сбор статусов.

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

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

Новая кадровая проблема: кого растить в старших разработчиков

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

Такие задачи позволяли младшему разработчику ошибаться на относительно дешевых участках системы, получать ревью, исправлять решение и постепенно собирать инженерную картину мира.

Сегодня опытный разработчик с Claude Code часто способен закрыть подобную задачу быстрее младшего специалиста и требует меньше контроля. В рамках текущего проекта такая экономика выглядит привлекательной. На горизонте нескольких лет возникает другой риск — дефицит инженеров, которые успели пройти путь до уровня старшего разработчика.

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

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

Какие компетенции становятся дороже

Навык работы с Claude Code или Cursor стал базовым. Сам факт использования ИИ мало говорит о квалификации специалиста. Гораздо важнее, насколько хорошо человек управляет задачей и контролирует результат. Для CTO это меняет подход к оценке команды.

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

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

С чего начать

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

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

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

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

Так постепенно появится понимание, где ИИ действительно ускоряет разработку, а где просто переносит ограничение на следующий этап. Дальше задача — расширять автономность агентов без потери качества и перестраивать процесс по мере появления новых узких мест. Именно так формируется зрелая агентная разработка.