Разработка после AI: куда переезжают узкие места

Когда код писали вручную, нехватку скорости легко было объяснить нехваткой разработчиков. Ассистенты ускорили набор и редактирование, после чего очередь начала расти перед проверкой кода и тестированием. При параллельной работе нескольких агентов возникает следующий предел: достаточно ли у команды осмысленных задач и умеет ли она проверять конечный результат. Массовое использование инструмента поэтому ещё не доказывает ускорение всей разработки. В исследовании предыдущего года проникновение AI приближалось к 90%, но эффект оставался неодинаковым для разных задач. Программа AI4SDLC Research 2026 продолжает эту проверку: в докладе обсуждаются 91 публикация-кандидат и собственный опрос по логике DORA. Автономность, доступ к агентам и разделение труда сопоставляются с инженерными практиками, надёжностью и результатами команды. Важная оговорка из слайдов: корпус ещё не финализирован, а причинная схема задаёт план анализа; будущие результаты добровольного опроса нельзя заранее объявлять доказанным эффектом внедрения.

В большой организации задача проходит через продукты, аналитиков, разработчиков, тестировщиков и эксплуатацию. Каждый переход требует передать контекст и дождаться следующего участника. Ускорить один участок недостаточно, если остальные продолжают работать в прежнем ритме. Ставка Т-Банка — агентный процесс, в котором необходимые роли сохраняются, но один человек с агентами может выполнять более широкий набор работ. Цель — уменьшить потери на передачах и быстрее доводить задачу до результата. Здесь возвращаются спецификации: продуктовый замысел нужно превратить в понятную агенту постановку с ограничениями и критериями приёмки. Поломодов связывает этот поворот с сокращением времени реализации. Когда написание кода занимало месяцы, было особенно важно получать обратную связь небольшими шагами; теперь формальное описание и проверка результата снова становятся удобным интерфейсом работы. Смысл такой спецификации — согласовать ожидаемое поведение до генерации, чтобы быстро написанный код не оказался столь же быстро реализованной ошибкой в требованиях.

На масштабе десяти тысяч инженеров программу нельзя свести к выдаче подписок. Нужны три оси оценки: скорость прохождения задач и пропускная способность, качество с надёжностью, экономика. Инциденты, откаты и проблемы безопасности служат ограничителями: ускорение, достигнутое отказом от проверок, не считается успехом. Экономика включает затраты на модели и инфраструктуру, её использование и высвобожденное время людей. Для работы в компании агенту также необходим доступ к внутренней платформе разработки. Раньше её продукт строился вокруг экранов, кнопок и посещаемости портала. Теперь востребованы интерфейсы, которыми может пользоваться агент, а доменная логика, политики, лимиты и контроль остаются в платформе. В Т-Банке уже есть модельный шлюз, MCP Hub и CLI, семейство инструментов Nessy, платформа Spirit. Возможность пройти от задачи до запроса на изменение кода показана для отдельных сценариев; доклад не утверждает, что такой путь уже одинаково работает для любой задачи.

У платформы три разных слоя. Модельный шлюз управляет доступом к моделям, квотами и бюджетами; инструментальный шлюз даёт агентам доступ к действиям; реестр возможностей описывает законченные сценарии с владельцами и условиями использования. Пример из доклада — запрос о проблемах сервисов за последний день. Если агенту выдать только разрозненные API, он начнёт выяснять команду пользователя, искать её сервисы, размещение, логи и метрики, фактически собирая часть платформенной логики заново. Готовая возможность диагностики оставляет эту работу внутри платформы и возвращает осмысленный результат. Полномочия при этом растут постепенно: прочитать данные, предложить решение, выполнить действие. Для последнего нужны явные правила доступа, подтверждения там, где они необходимы, пробный запуск, откат и аварийное отключение. Модель угроз помогает различать реальные риски конкретного сценария. Если пытаться устранить все мыслимые угрозы ещё до первого пилота, внедрение остановится; если не разбирать их вовсе, автономность окажется бесконтрольной.

Доля сгенерированного кода удобна для отчёта, но поощряет производство строк и скрывает качество, стоимость и новые очереди. Вместо неё доклад предлагает смотреть на время ожидания проверки, блокировки, переделки и прохождение изменений до эксплуатации. DORA, SPACE и DevEx уже использовались в компании до AI, поэтому есть исходная точка для сравнения. Данные о внедрении помогают понять распространение инструментов, но не заменяют оценку результата. Для автономных агентов дополнительно нужны трассировки и наборы проверочных задач — evals. Если у общего агента проверки кода поменять модель, инструкции или способ сбора контекста, качество может измениться непредсказуемо. Проверочный набор позволяет оценить новую версию до массового запуска. Иначе пользователи становятся испытательным полигоном: команда выпускает изменение, ждёт жалоб и откатывает его. Чем меньше человек сопровождает каждое действие агента, тем важнее заранее построить такую проверку и понимать по телеметрии, где именно агент ошибается.

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