Claude Code Auto Mode: что автономный агент чинит сам, а где нужен человек
В апреле 2026 один из тех, кто поддерживает большой опенсорс-проект на Python, решил поэкспериментировать. Запустил агентский режим на ночь — дал ему доступ к репозиторию, список из 847 открытых issue и оставил работать. Утром оказалось, что он закрыл 312 тикетов, подготовил 96 пулл-реквестов для проверки и, ну, потратил на токены сумму, сопоставимую, а может и больше, чем зарплата начинающего разработчика за месяц. Из этих пулл-реквестов в основную ветку взяли 41. Остальные оказались либо неактуальными, либо ломали тесты, либо, скажем так, «лечили» не то, что болело.
Это, знаете ли, не история о чуде. И не о провале совсем. Скорее, довольно точное отражение того, как сейчас выглядит работа с агентскими ассистентами в реальных задачах. И поэтому разговоры о том, что ИИ вот-вот заменит программистов, в 2026 звучат как-то... странно. Вспомните разговоры про беспилотники в 2014 — мол, через пару лет таксистов не останется. Ну, как-то не сложилось.
Разберём по делу: что автономный режим умеет на самом деле, где спотыкается, и что это значит для тех, кто только собирается в IT.
Что такое этот Auto Mode вообще
Если вкратце: это когда агенту ставится задача высокого уровня («почини баги в этом репозитории», «напиши тесты для модуля X», «выясни, почему падает CI»), а дальше он сам принимает решения. Какие инструменты использовать, какие файлы читать, что менять, что коммитить — всё сам.
Под капотом там простой цикл. Модель смотрит на текущее состояние, выбирает следующий шаг (прочитать файл, запустить тест, поправить строку, поискать в коде), делает его, смотрит на результат и повторяет. И так может крутиться часами, если задача большая и хватает денег на токены.
Главное отличие от обычного чата в IDE в том, что агент не ждёт, пока ему дадут добро на каждое действие. Он сам понимает, что баг в auth.py может быть связан с middleware/session.py, идёт туда, читает, правит, запускает тесты, видит, что где-то ещё что-то сломалось, идёт чинить и так до тех пор, пока не достигнет цели или не упрётся в ограничения.
Сотни закрытых тикетов за ночь - правда или маркетинговый ход?
В основном правда, но с оговорками. Когда вы видите заголовок вроде «агент закрыл 312 issue из 847 за одну ночь», важно понимать: под «багом» в этих демонстрациях обычно понимают issue в баг-трекере, а не реальную ошибку. Это может быть:
- Опечатка в документации
- Просьба обновить версию зависимости
- Дубликат другого issue
- Жалоба пользователя, которая на самом деле — запрос на новую функцию
- Настоящий баг с чётким описанием и стектрейсом
- Настоящий баг, который сложно воспроизвести и которому требуется дополнительное исследование
Агент в автономном режиме отлично справляется с первыми тремя категориями. Он закроет дубликат, обновит зависимость, исправит опечатку. С четвёртым — справится хуже, потому что нужно принимать решения по приоритетам. С пятым — хорошо, если баг локальный, и плохо, если он связан с разными частями кода. А вот с шестым — почти никак, потому что чтобы разобраться в проблеме, нужно поговорить с пользователем или иметь информацию, которой нет в коде.
Если брать наш опыт работы с теми, кто учится QA Automation, то из 100 реальных багов в обычном рабочем репозитории агент примерно 20-30 починит самостоятельно, без проблем. Ещё 30-40 — он пришлёт в виде PR, но кто-то должен внимательно проверить. Остальные требуют либо архитектурных изменений, либо данных извне, либо доступа к рабочей среде.
Где автономный режим реально помогает
Есть три типа задач, в которых агенты уже сейчас экономят разработчикам время.
Первое — миграции и рефакторинги по чётким правилам. Например, переименовать поле в API, обновить версию библиотеки или заменить устаревший вызов на новый во всём коде. Раньше для этого использовали скрипты и регулярные выражения, а потом вручную чинили то, что сломалось. Сейчас агент проходит по всему репозиторию, вносит изменения, запускает тесты, исправляет ошибки и присылает готовый PR. Это работает, потому что задача чётко определена: есть состояние «до», есть состояние «после», есть тесты, которые подтверждают, что всё работает.
Второе — написание тестов для существующего кода. Если у вас есть модуль без тестов, агент изучит его, поймёт логику и напишет тесты на основные сценарии. Качество, конечно, среднее. Он часто пропускает крайние случаи, использует наивные моки, иногда тестирует реализацию, а не поведение. Но это хорошая отправная точка, которая экономит, ну, часов десять-пятнадцать на модуль. А дальше уже можно отшлифовать.
Третье — типовая разработка по шаблону. CRUD-эндпоинты, формы, скрапперы, парсеры конфигураций, миграции схемы. Любая задача, где 80% кода — это повторение одних и тех же шаблонов, а 20% — специфика. Агент пишет основу, человек правит специфику.
Что объединяет эти три типа задач? Их хорошо проверяют тесты, они довольно изолированы и в них много повторяемого. Если хотя бы что-то из этого есть — автономный режим действительно экономит время.
Где он всё-таки буксует
А теперь о сложностях. Несколько закономерностей, которые мы регулярно наблюдаем при работе с агентами в реальных проектах.
Агент чинит симптомы, а не причину. Это самое частое и самое опасное. Тест падает — агент меняет ожидание в тесте. Linter ругается — агент добавляет исключение. Функция падает на каком-то входе — агент оборачивает её в try/except и возвращает None. Формально задача выполнена, но проблема никуда не делась — просто переехала на другой уровень, где её теперь сложнее заметить.
Единственное решение здесь — код-ревью от опытного разработчика, который понимает, как должен работать этот код. Никакие автоматические проверки не помогут. Поэтому когда вы видите цифру «агент закрыл 312 issue за ночь», нужно сразу спросить: а сколько из них прошли проверку человеком, и сколько из них через пару недель всплывут обратно как новые баги?
Агент теряет нить повествования в длительных задачах. На задачах, которые требуют более 20-30 шагов, начинаются проблемы. Агент забывает, что он решил два часа назад, начинает дублировать функции, теряет из виду первоначальную цель. Попытки «сократить контекст» или «сохранить план в файл» помогают лишь частично, но не решают проблему полностью. Если задача требует одновременного учёта 50+ файлов, агент обязательно ошибётся.
Агент делает то, что ему делать нельзя, с уверенностью. Это самые дорогие ошибки. Удаление файлов, которые «кажутся неиспользуемыми», изменение конфигурации продакшена, коммиты с секретами, принудительные переписывания истории в основной ветке. Всё это случалось. Поэтому в рабочей среде автономный режим работает в песочнице с разрешённым списком команд, без права напрямую отправлять изменения в защищённые ветки и желательно без доступа к сети, кроме необходимых API.
С «историческим» кодом всё сложно. Если в коде есть неявные правила, обходные пути, костыли с комментариями «не трогать, иначе сломается» — агент эти правила не видит. Он видит только код и может спокойно их нарушить. На новом проекте с тестами это не страшно, а вот на десятилетнем монолите без покрытия агента лучше держать на коротком поводке.
Что это значит для тех, кто учится
Самый частый вопрос от ребят, которые приходят к нам на курсы Python или QA Automation в 2026: «А меня не заменят, пока я учусь?»
Ответ: нет, не заменят. Но профессия меняется, и важно учиться, понимая эти перемены.
Что становится менее важным: умение быстро писать типовой код, помнить наизусть синтаксис библиотек, делать механические рефакторинги, писать простые CRUD-эндпоинты. Агенты уже умеют это делать. Если вы учитесь программировать только ради того, чтобы быстро писать однотипный код, то, да, вам будет сложно.
Что становится более важным: понимание архитектуры, умение читать чужой код и оценивать его правильность, умение чётко формулировать задачу, чтобы её можно было проверить, навык разделения большой проблемы на маленькие, легко тестируемые части. И — отдельно — умение делать качественное код-ревью. Сейчас это самый востребованный навык, и в ближайшие годы он будет только дорожать. Ведь объём кода, который нужно ревьюить, увеличивается в разы.
Ещё одна вещь, которая изменилась за последний год: ценность хорошего тестирования. Раньше тесты писали, потому что «так правильно». Сейчас тесты — это единственный способ доверять коду, который сгенерировал агент. Поэтому QA Automation как профессия в 2026 выглядит намного привлекательнее, чем три года назад. И это касается не только тестировщиков — любой бэкенд-разработчик, который умеет хорошо писать тесты, сейчас в выигрышной позиции.
Сколько это стоит на практике
Один момент, о котором редко говорят в восторженных постах об автономных агентах. Запуск агента на ночь на крупном репозитории стоит реальных денег — от десятков до сотен долларов за сессию, в зависимости от объёма работы и выбранной модели. Для индивидуального проекта это небольшая сумма. Но для команды из 50 разработчиков, каждый из которых использует агента несколько раз в день, это уже значительная статья расходов.
И эти деньги нужно сравнивать не с «бесплатным программистом» (агент не бесплатный программист), а с «программистом, который делает то же самое». Иногда выходит дёшево: восемь часов джуновской рутины за двадцать долларов токенов и пара часов ревью. А иногда сеньор потом полдня разбирается в том, что нагенерировалось, — и вся экономия съедается.
В реальных компаниях сейчас идёт большой процесс настройки: кому, на каких задачах и с каким уровнем контроля давать доступ к автономному режиму. Универсального ответа нет и, скорее всего, не будет в ближайший год.
И что в итоге?
Auto Mode — это не магия и не временный хайп. Это новый инструмент, у которого есть чёткие границы применения. Внутри этих границ он экономит время. За их пределами он создаёт проблемы, которые потом приходится решать людям.
Те 312 закрытых issue за ночь из истории в начале — реальная цифра. Те 41 PR, которые приняли в основную ветку — тоже правда. Грубо говоря, если считать от всех закрытых тикетов (а их было 312), то на восемь закрытых тикетов приходится примерно одно изменение, которое реально дошло до кода и пережило ревью, — по нашим прикидкам на серьёзных проектах. Если же смотреть только на присланные PR, картина мягче — там в ветку взяли 41 из 96, почти каждый второй, — но это и есть та часть, которую агент уже отобрал и довёл до состояния «готово к проверке». Через год, наверное, станет получше, но называть точные цифры тут было бы нечестно. Но вот чтобы стало 1 к 1 — это маловероятно, и дело даже не в мощности моделей. Просто разработчик большую часть времени не пишет код, а разбирается в контексте, которого в коде нет.
Если вы сейчас выбираете, куда двигаться в IT, смотрите не на то, что агенты уже умеют делать, а на то, что они постоянно ломают. Именно за это в ближайшие годы будут платить хорошие деньги. А вот сидеть и ждать, пока ИИ всё сделает за вас — ну, это как ждать беспилотники у обочины.