Лучшие практики агентного ИИ от JetBrains Air
В нашем совершенно новом отчете рассматривается, что требуется лидерам разработки ПО для внедрения агентов в работу.
В одной организации уровень внедрения ИИ достиг 95% без какого-либо улучшения скорости работы разработчиков. Другая утроила пропускную способность пулл-реквестов, сократив при этом бэклог дефектов на 54%.
В чем разница?
Чтобы узнать, что делает ИИ-агентов эффективными за рамками индивидуальных разработчиков, я пообщался с инженерными лидерами и практиками из Fin, Semrush, Skiller Whale и других организаций.
Результаты теперь доступны в нашем новом отчете Как ведущие команды масштабируют ИИ-агентов, который включает девять реальных тематических исследований и рассказов практиков, а также инсайты от наших собственных инженерных команд в JetBrains.
В отчете рассматриваются не только показатели внедрения и прирост индивидуальной производительности, но и то, что на самом деле меняется, когда команды начинают полагаться на ИИ-агентов: как они организуют работу, поддерживают качество кода, делятся знаниями, управляют затратами и измеряют результаты.
Вот три урока, которые запомнились мне больше всего.
#1. Большее количество агентов не исправит сломанный рабочий процесс разработки
В Fin первоначальной целью было удвоение пропускной способности пулл-реквестов без ущерба для качества кода, безопасности или производительности.
Вместо того чтобы просто внедрять больше агентов для кодинга, Fin создала специализированную команду — Team 2x, — которая занялась управлением инфраструктурой вокруг них, включая общие навыки, плагины, серверы MCP и оценку эффективности.
Команда протестировала навыки агентов на реальных примерах, провела ретроспективное тестирование своего навыка код-ревью на исторических пулл-реквестах и проанализировала сессии агентов для выявления повторяющихся ошибок и недостающего контекста.
Но рост производительности создал новые проблемы. Система CI оказалась под нагрузкой, а качество кода стало нестабильным. В ответ Fin инвестировала средства в линтинг и стандартизацию.
За 16 месяцев компания Fin сообщила о следующих результатах:
- в 3 раза выросла пропускная способность пулл-реквестов;
- на 54% сократился бэклог дефектов;
- на 50% снизилась стоимость одного пулл-реквеста, несмотря на рост общих расходов на ИИ.
Особенно интересным является то, сколько работы Fin вложила в то, чтобы остальная часть ее инженерной системы не отставала.
#2. Ваша кодовая база должна быть готова к агентам
Даже способные агенты испытывают трудности, когда не могут надежно собрать проект, запустить тесты или найти необходимый контекст.
Это особенно сложно в крупных и сложных репозиториях, где разработчики часто полагаются на годами накопленные знания о конфигурациях сборки, зависимостях и соглашениях проекта.
В JetBrains мы решаем эту проблему в нашем собственном крупном монорепозитории. Наш опыт указывает на несколько практических требований: стандартизированные инструменты сборки, быстрые тесты, доступные API и окружения, которые агенты могут настраивать самостоятельно.
Вывод прост: прежде чем инвестировать в новых агентов, посмотрите, что мешает уже имеющимся у вас агентам надежно выполнять задачи.
#3. Индивидуальное внедрение ИИ не автоматически повышает производительность команды
В одной из организаций, которую обсуждала Энджи Джонс, уровень внедрения ИИ достиг 95%, но скорость работы разработчиков осталась прежней.
Команда сместила фокус с поощрения использования ИИ на помощь разработчикам в делегировании значимой работы. Энтузиасты, создавшие более богатый контекст на уровне репозитория, в конечном итоге открывали пулл-реквесты в три-четыре раза быстрее, чем раньше.
Компания Skiller Whale столкнулась с другой версией той же проблемы. В одном из проектов с клиентом группа, прошедшая обучение по надзору за ИИ-агентами, примерно удвоила пропускную способность пулл-реквестов, в то время как во всей остальной организации этот показатель снизился.
Эти примеры подчеркивают то, что легко упустить из виду при инициативах по внедрению ИИ: разработчикам необходимо научиться структурировать задачи, предоставлять контекст, оценивать результаты и делиться эффективными практиками с коллегами. В противном случае организации рискуют получить горстку высокопродуктивных «пауэр-юзеров» ИИ вместо более продуктивных инженерных команд.
Что требуется для масштабирования ИИ-агентов?
В ходе этих разговоров постоянно возникала одна закономерность: организации, добившиеся значимых результатов, последовательно меняли системы и практики вокруг себя.
Это означало подготовку сред разработки к работе с агентами, установление общих стандартов, улучшение процессов ревью, инвестиции в командное обучение и измерение результатов не только по уровню внедрения.
Не существует единого руководства, которое подходило бы для каждой инженерной организации, но есть конкретные подходы, у которых стоит поучиться, включая те, которые не сработали с первого раза.
Общение с этими командами дало мне пищу для размышлений, и я уверен, что есть еще много историй, которыми стоит поделиться. Я буду рад услышать в разделе комментариев о вашем опыте работы с ИИ-агентами, извлеченных уроках или проблемах, которые вы все еще пытаетесь решить.
