Air
Среда разработки на основе агентов
Agentic AI AI JetBrains JetBrains AI
Что инженерные команды рассказывают нам об работе с агентами ИИ. Часть 1 в серии.
За последние несколько месяцев я потратил много времени на ознакомительные звонки с инженерными организациями: от софтверного агентства с 16 разработчиками до телекоммуникационных компаний, игровых студий и консалтинговых фирм с тысячами разработчиков. Почти никто из них не задается вопросом, стоит ли использовать ИИ-агентов. В одном провайдере финансовых данных опрос показал, что примерно 80% инженеров используют их ежедневно.
Когда я классифицирую услышанное на три уровня — отдельный разработчик, команда и организация, — вырисовывается определенная закономерность. Отдельные разработчики теперь могут двигаться намного быстрее с помощью агентов, но прирост неравномерен. Уровень организации касается прозрачности, затрат и контроля. Уровень команды — это то место, где прирост буксует. Несколько человек начинают работать намного быстрее, но даже те команды, которые перестраивают свои рабочие процессы, с трудом превращают более быструю реализацию в более быструю доставку.
Вот три сценария, о которых я слышу чаще всего.
1. У каждого есть агент. Никто не делится настройкой.
Когда я спрашиваю, делятся ли разработчики промптами, правилами или файлами инструкций, честный ответ обычно представляет собой вариацию того, что мне сказал архитектор из ИТ-компании: «Мы еще не дошли до этого. Мы просто делимся знаниями за утренним кофе».
Даже там, где команды начали формализовать свои практики, это распространяется путем осмоса. Руководитель инженерного отдела в компании, занимающейся юридическими технологиями, сказал: «Стандартов нет. Мы задаем их в репозитории [команды ИИ], а затем они постепенно просачиваются и в старые проекты на .NET — просто благодаря обмену тем, что работает».
Там, где обмен знаниями носит систематический характер, он хрупок. Руководитель платформы в транспортной компании с более чем сотней репозиториев, который хранит базовые правила в одном репозитории и копирует их в каждый сервис, объясняет: «Если мы обновляем базу, нам нужно обновлять все репозитории, которые люди могли кастомизировать».
Архитектор решений из консалтинговой компании, который наблюдает за более чем пятьюдесятью клиентскими командами, добавляет, что общая конфигурация часто является показухой:
Люди с энтузиазмом создают агентов, навыки, файлы CLAUDE.md — все подряд. Но они могут обнаружить, что на самом деле это ухудшает качество. Некоторые из них вообще не работают».
Люди с энтузиазмом создают агентов, навыки, файлы CLAUDE.md — все подряд. Но они могут обнаружить, что на самом деле это ухудшает качество. Некоторые из них вообще не работают».
Результатом является растущий разрыв внутри команды. Инженерный менеджер картографической компании иллюстрирует это: «20% инженеров генерируют 80% кода или потребляют 80% токенов. Мы на самом деле не знаем, умнее ли остальные 80%, просто плохо используют инструмент или нуждаются в обучении».
Ведущий инженер провайдера финансовых данных говорит: «Существует большой разрыв в уровне владения инструментом. Если вы составите плохой промпт, кодовая база будет прочитана трижды».
Генеральный директор облачной консалтинговой компании задал вопрос, который кроется за всем этим: «В моей команде есть один суперзвездный разработчик, который примерно в 10 раз лучше всех остальных. Как мне перенять его поведенческие паттерны и распространить их на всю команду?»
Знания о том, как работать с агентами, хранятся в личных конфигурациях, тредах Slack и вики. Агенты начинают каждую задачу с нуля; каждый заново объясняет одни и те же соглашения, и качество результата зависит от того, кто пишет промпт, а не от того, что решила команда. Как выразился старший инженер крупной консалтинговой компании: «Никто еще не дорос до нужного уровня зрелости. Это слишком ново, чтобы быть зрелым».
2. Реализация стала дешевле. Ревью — нет.
«По мере того как мы делаем это все больше, мы видим, как узкие места перемещаются на этап код-ревью и планирования. В наши дни реализация идет довольно быстро», — говорит руководитель инженерного отдела компании в сфере юридических технологий, у которых уже настроен шлюз ИИ-ревью перед тем, как человек посмотрит на пулл-реквест.
Картографическая компания измерила это: «Если посмотреть на чистые цифры, время прохождения PR фактически увеличилось. Вероятно, дело в человеке в контуре или в низком уверенности в качестве, что заставляет людей проверять все подряд. Но ответа мы пока не знаем».
Группа платформ у крупного вендора сетевого оборудования, где все ежедневно используют агентов, выявила тот же предел: «Мы по сути пытаемся применять неагентские процессы к очень и очень быстро меняющейся работе.
То, что вы можете построить 100 вещей, не означает, что вы должны это делать. Люди не могут потреблять столько».
То, что вы можете построить 100 вещей, не означает, что вы должны это делать. Люди не могут потреблять столько».
Главный инженер игровой компании подытожил разницу между демо-версией и реальным рабочим процессом команды: «Одно дело — экспериментировать, и совсем другое — запускать все это в продакшн со всеми потоками, хорошими и плохими, ревью и всем тем, с чем людям приходится иметь дело в 2026 году».
Узкое место также смещается вверх по течению. При соотношении одного продакт-менеджера на пять-шесть разработчиков последние справляются с работой настолько быстро, что доведение элементов бэклога до состояния готовности к взятию в работу человеком или агентом становится сложной задачей.
Процессы код-ревью создавались для изменений со скоростью человека. Если проверка результатов стоит дороже, чем полученная экономия, команда фактически сделала шаг назад.
3. Автоматизация скучной работы создает новую операционную нагрузку.
Команды точно знают, что именно они бы передали агентам. Руководитель инженерного отдела игровой компании делится: «Каждый раз, когда кто-то создает MR [merge request], мы хотим запускать определенные вещи. Каждую ночь мы запускаем скрипт обновления документации, который проходит по всем репозиториям и следит за тем, чтобы все было актуально».
Что следующее в его списке? «Обновление библиотек, обновление фреймворков, более автономное устранение выявленных уязвимостей безопасности». Тем не менее, для многих команд простой запуск этих фоновых автоматизаций остается препятствием из-за нехватки времени и выделенной инфраструктуры.
Некоторые доказали это вручную. Одно агентство взяло расплывчатый тикет от клиента и подготовило пулл-реквест за 10 минут. Теперь они хотят, чтобы этот процесс работал без них, представляя себе сценарий: «Когда мы заканчиваем рабочий день, на следующий день мы возвращаемся, и все запрошенные нами задачи уже выполнены».
Для команд, которым действительно удается выстроить операционные конвейеры, масштабированию мешают не идеи, а то, где запускается автоматизация, кто ею владеет и как она охватывает каждый проект. Старший инженер консалтинговой компании создал именно такую систему — агента в контейнере Docker на виртуальной машине, реагирующего на веб-хуки, — и уперся в стену:
Главная проблема заключается в том, что мы должны ее поддерживать. Если мы развертываем решение у одного клиента, нам также нужно придумать, как распространять обновления на другой проект».
Главная проблема заключается в том, что мы должны ее поддерживать. Если мы развертываем решение у одного клиента, нам также нужно придумать, как распространять обновления на другой проект».
Между тем руководитель платформы превращается в живой API, и когда каждая команда автоматизирует процессы самостоятельно, координация нарушается. Из компании, занимающейся мобильностью: «Сегодня бэкенд-команда спросила: „Можете ли вы предоставить нам ключ в CI внутри GitHub и секрет для автогенерации тестов?“» И когда каждая команда занимается автоматизацией сама по себе, координация рушится. В игровой компании была: «очень жаркая дискуссия о том, как взять под контроль ситуацию, когда каждый хочет создать агента, а у нас нет возможности это регулировать».
Что у них общего
Предоставление каждому разработчику способного агента само по себе не решает эти проблемы. Некоторым командам не хватает общей инфраструктуры, в то время как другие уже строят ее и сталкиваются с постоянной работой, необходимой для ее поддержки. Именно вокруг этого разрыва мы и создаем Air Teams.
В следующих публикациях я поочередно разберу три сценария: общий контекст и навыки, ревью, созданные для вывода агентов, и автоматизацию, которой команда владеет совместно. Основываясь на реальных историях клиентов, я покажу, как обмен намерениями, решениями, влиянием и результатами верификации помогает следующему человеку самостоятельно понимать изменения и снижает нагрузку на проведение ревью.
Следите за обновлениями.
