Google Jules: асинхронный ИИ-разработчик, который открывает pull request

Google Jules предлагает простой сценарий: поставить задачу по репозиторию GitHub, позволить агенту поработать в фоновом режиме, а затем проверить подготовленный pull request. Согласно документации Google, Jules создаёт свежую среду в виртуальной машине, устанавливает зависимости, пишет или обновляет тесты, меняет код, запускает проверки и открывает pull request. Агент может исправлять ошибки, обновлять зависимости, выполнять миграции и добавлять новые функции. 18

Это не обычный помощник автодополнения кода. Разработчику не нужно постоянно находиться в интерактивной сессии и подтверждать каждое изменение. Jules возвращает проверяемый результат: ветку, diff, результаты тестов и pull request.

Что такое Google Jules

Jules — асинхронный ИИ-агент Google для разработки программного обеспечения, работающий на моделях Gemini. Публичная бета-версия появилась 20 мая 2025 года, а выполнение задач на уровне репозитория происходило в защищённой виртуальной машине Google Cloud. 24 6 августа 2025 года Google вывела Jules из беты и представила структурированные уровни использования. 14

Типичный рабочий процесс выглядит так:

1. Разработчик подключает репозиторий GitHub и описывает задачу.
2. Jules изучает проект и формирует план.
3. Агент клонирует кодовую базу в изолированную виртуальную машину и устанавливает зависимости.
4. Jules изменяет файлы, пишет или обновляет тесты и запускает доступные проверки.
5. Результат оформляется в pull request для человеческого ревью. 18

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

Тарифы и лимиты Jules

На текущей странице Google указаны три уровня доступа. Лимиты рассчитываются за скользящие 24 часа — это не обязательно сброс в одно и то же время каждый день. 1

Тариф	Задач за скользящие 24 часа	Параллельных задач	Доступ к моделям по описанию Google
Вводный доступ	15	3	Gemini 2.5 Pro
Jules в Google AI Pro	100	15	Расширенный доступ к новым моделям, начиная с Gemini 3 Pro
Jules в Google AI Ultra	300	60	Приоритетный доступ к новым моделям, начиная с Gemini 3 Pro

Google позиционирует Pro как вариант для регулярной ежедневной разработки, а Ultra — для более интенсивной и параллельной работы. 9 При запуске в августе 2025 года подписки Google AI Pro и Ultra стоили 19,99 и 124,99 доллара в месяц соответственно. 13 Цены и условия могут меняться, поэтому перед закупкой следует проверить актуальную страницу тарифов Google.

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

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

Место Jules среди ИИ-агентов для программирования

Рынок постепенно переходит от автодополнения отдельных строк к агентам, которые умеют планировать, редактировать код, запускать тесты и отправлять изменения на ревью. Главное позиционирование Jules — асинхронная работа со всем репозиторием: разработчик ставит задачу и возвращается позже, чтобы изучить результат.

Однако этот сценарий уже нельзя считать уникальным преимуществом. Облачный агент GitHub Copilot также работает асинхронно: получает назначенную issue, создаёт ветку, пишет код и открывает pull request из временной изолированной среды с автоматическим сканированием безопасности. 17

Поэтому Jules конкурирует не столько самой автономностью, сколько качеством работы моделей Gemini, пониманием контекста репозитория, средой выполнения, интеграцией с экосистемой Google и доказательствами, которые сопровождают каждое изменение. Anthropic, в свою очередь, подчёркивает возможности Claude Opus 5 в сложных длительных агентных задачах — многофайловых функциях и крупных рефакторингах. 28

При выборе инструмента практичнее спрашивать не «какой агент самый автономный?», а:

• вписывается ли он в принятую в команде модель работы с Git и pull request;
• может ли безопасно работать с зависимостями и политикой доступа к секретам;
• показывает ли он достаточно подробный план и ход выполнения;
• способны ли независимые CI- и security-системы отклонить плохое изменение;
• хорошо ли он работает на собственных репозиториях команды, а не только на публичных бенчмарках.

CLI, API, рекомендации и запланированные задачи

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

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

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

Почему успешные тесты — ещё не доказательство

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

Разницу между функциональным успехом и качеством программного обеспечения иллюстрируют независимые оценки моделей. Sonar сообщил, что Claude Opus 5 выполнил 88,6% из 544 задач с исполняемыми тестами против 82,9% у Opus 4.8. Одновременно компания зафиксировала снижение плотности ошибок и уязвимостей на строку кода, но отметила: Opus 5 генерировал в 2,3 раза больше кода, а общее число обнаруженных проблем выросло в 2,7 раза. 30

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

Предоставленные материалы также не содержат достаточных первичных данных для проверки точных утверждений о блокировке примерно 25% сессий в Spotify или о 38 дефектах в 554 сгенерированных тестах First Mate. Без методологии, параметров выборки, определений и исходных сравнений эти примеры не следует использовать как статистику для принятия решений.

Как выстроить независимую проверку ИИ-кода

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

1. Защищённые ветки и обязательное одобрение человеком. Агент не должен иметь возможности самостоятельно слить код в критически важные ветки.
2. Неизменяемый или отдельно контролируемый CI. Агент не должен переписывать проверки, определяющие, прошёл ли его код.
3. Заранее существующие регрессионные и интеграционные тесты. Тесты, созданные агентом, полезны, но не должны быть единственным основанием для принятия патча.
4. Независимый анализ безопасности. Статический анализ, поиск секретов, проверка зависимостей и SBOM, лицензий, а также тестирование безопасности приложения должны выполняться за пределами собственного цикла рассуждений агента.
5. Политики для рискованных изменений. Авторизация, доступ к данным, инфраструктура, миграции баз данных и конфигурация требуют правил, выходящих за рамки обычных unit-тестов.
6. Раздельные маршруты ревью. Вторая модель или отдельный проверяющий процесс могут искать пропуски и противоречия, а сомнительные и высокорисковые случаи должны передаваться ответственному человеку.

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

Что Jules меняет для разработчиков

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

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

Модель Jules «виртуальная машина — pull request» задаёт полезную границу: агент получает пространство для работы, а команда сохраняет точку контроля. Но эта граница работает только при содержательном ревью и независимых проверках, которыми не управляет та же система, что создала код.

Кто выиграет в гонке ИИ-агентов

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

В этом и состоит главный урок Jules. Автономное выполнение задач постепенно становится базовой возможностью. Гораздо сложнее создать доверенную систему проверки — и именно она, вероятно, определит, станет ли ИИ-код реальным усилителем команды или просто увеличит объём работы для людей, которым всё ещё придётся его просматривать.