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

О том, как меняется подход к автоматизации разработки, рассказали инженеры MTC Web Services на митапе для Go-разработчиков. А еще в эфире разобрали несколько практических сценариев, где в одном случае ИИ-агент получает собственную среду выполнения, в другом типовые инфраструктурные задачи выносятся на общую платформу, а в третьем — код создается на основе описания API.

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

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

От помощника к самостоятельному участнику разработки

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

Как пояснила Вера Касьяненко, Golang-разработчик MWS DevRails, это может быть и чтение файлов, запуск тестов, изменение кода, а также создание коммитов. Модель получает задачу и набор доступных инструментов, выбирает действие, получает результат и продолжает работу до выполнения задачи.

«Модель получает задачу и список доступных инструментов. И далее она отвечает не текстом, а вызовом. Например, прочитай файл, запусти тесты и сделай коммит».

Вера Касьяненко, Golang-разработчик MWS DevRails

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

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

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

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

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

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

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

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

Этот сдвиг в работе разработчика уже обсуждался на пятом MWS Meetup. Тогда участники говорили о том, как ИИ меняет процесс разработки и постепенно смещает фокус с написания кода на постановку задач и проектирование. 

Но сначала нужно построить платформу

Похожий принцип применения нейросетей работает в интеграционной платформе Octapi. Андрей Пушкарев, Golang-разработчик в MWS Octapi, рассказал о системе, через которую проходит около 250 млн запросов в сутки.

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

«Когда мы пишем сервис, чтобы он стал готов к промышленной эксплуатации, нам, кроме бизнес-логики, надо поддержать проверку подлинности пользователей, проверку запросов, мониторинг. Но вот это все можно перенести в общую точку входа (шлюз)».

Андрей Пушкарев, Golang-разработчик в MWS Octapi

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

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

Ситуация усложняется при работе нескольких точек входа (шлюзов). Не получится установить счетчик на одном сервере, все шлюзы должны понимать, сколько запросов уже использовано и сколько еще можно пропустить. Сначала команда рассматривала разные алгоритмы ограничения трафика, но в конечном итоге выбрала алгоритм Sliding Window, который учитывает количество запросов на заданный промежуток времени.

Такой подход позволяет равномернее распределять нагрузку и не допускать резких всплесков числа запросов. В итоге остановилась на алгоритме «Скользящее окно» (Sliding Window), который считает запросы за последнее временное окно. Такой подход позволяет распределять нагрузку более равномерно. В каждом центре обработки данных работает собственный сервис управления квотами, а шлюзы отправляют ему информацию о потреблении, сервис же возвращает квоту на следующий интервал.

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

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

Код тоже можно перестать писать вручную

Еще один доклад на MWS Meetup был посвящен автоматизации на уровне исходного кода. Александр Бухалко, ведущий разработчик MWS Cloud Platform, рассказал о генераторе, который команда использует при разработке платформы. Ее начали развивать в 2024 году, а первая версия вышла в 2025-м.

В основе подхода лежит принцип API-first. Сначала команда описывает интерфейс продукта в специальной спецификации, а затем на ее основе автоматически создает часть необходимого кода и инструментов.

«Подход у нас используется API-first. Это когда продуктовая команда в самом начале разработки своего продукта описывает API в спецификации, и из нее потом генерируется множество инструментов».

Александр Бухалко, ведущий разработчик MWS Cloud Platform

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

Однако готовые инструменты не закрывали все задачи команды. Они умеют генерировать код из OpenAPI, но разработчикам приходится подстраиваться под ограничения инструмента. В MWS стандартные генераторы не позволяли в полной мере учесть собственные правила проектирования API.

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

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

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

Что меняется в работе разработчика

Три кейса MWS показывают, как автоматизация постепенно охватывает разные части разработки:

• в случае с ИИ-агентом автоматизируется сама последовательность действий. Агент может читать файлы, запускать тесты, менять код и готовить результат. При этом разработчик задает среду, доступные инструменты и ограничения;

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

• автоматизируется написание части исходного кода. Разработчик описывает API, а генератор создает на его основе необходимый инструментарий.

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