Почему большинство разработчиков по-прежнему получают мало пользы от кодирующих агентов.

Два исследования 2026 года, проведенных компаниями JetBrains и Anthropic, приводят цифры, показывающие, каким образом инженеры на самом деле работают с агентами для написания кода. Согласно их выводам, разница между получением реальной пользы от такого агента и получением бесполезных результатов заключается в способе делегирования работы, а не в выборе модели.

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

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Почему приложение для торговли — хорошая проверка

Возьмем приложение для торговли под управлением iOS, разработанное для финансовой компании. UIKit и SwiftUI сосуществуют рядом, а сверху используются паттерны MVVM и Clean Architecture. В такой структуре кода неверное число на экране подтверждения заказа не превращается в задачу на устранение ошибки — это становится поводом для звонка из отдела соответствия нормам.

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

Что показал опрос JetBrains

С мая по июль 2026 года JetBrains провёл опрос среди более чем 15 000 работающих разработчиков. Девять из десяти ответили, что используют ИИ-агентов для программирования на работе как минимум раз в неделю, а 68% — ежедневно.

Claude Code лидирует с долей 39% в мире и 47% в США, что примерно в два раза больше, чем у GitHub Copilot с его показателем 21%, который сам по себе снизился с 29% в прошлом году. Codex вырос с 3% до 16%.

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

Опыт не замедлил внедрение ИИ, а, наоборот, способствовал ему. Примерно у каждого четвертого старшего разработчика ИИ-агенты пишут более 80% кода, что больше, чем среди младших разработчиков, которые предпочитают получать помощь построчно. Это опровергает мнение о том, что ИИ делает младших разработчиков ненужными. Те, у кого лучшее чувство оценки ситуации, передают больше задач на обработку ИИ, и это вряд ли случайность.

Что показывают 400 000 сессий

Собственное исследование компании Anthropic охватило примерно 400 000 интерактивных сессий Claude Code, проведённых около 235 000 пользователей с октября 2025 года по апрель 2026 года. Распределение результатов оказалось проще, чем это показывает маркетинговая стратегия:

• Работа с кодом составила 56% всех сессий: 25% — написание кода, 26% — его исправление, 5% — тестирование или организация процессов.
• Работа с программным обеспечением заняла 17%.
• Планирование и исследование составили 14%.
• Анализ и написание текстов — 13%.

Самый важный вывод касается того, кто принимает решения. Люди принимают примерно 70% решений по планированию, в то время как Claude принимает около 80% решений по выполнению задач. Люди определяют *что* делать, а агент — *как*.

Никто не разрабатывал этот принцип разделения. Это равновесие, к которому независимо пришли сотни тысяч инженеров, потому что оно эффективно. Многие жалобы на агентов для программирования исходят от тех, кто перевернул порядок действий: сначала определили «что» нужно сделать, а затем спорили с агентом о «как».

Экспертиза влияет на результат

Цифры разрушают миф о том, что «теперь любой может программировать». Работы оценивались с учётом предполагаемой экспертизы пользователя в соответствующей области по трём критериям: насколько точны были инструкции, что пользователь просил проверить у Claude и как происходили корректировки. Затем результаты сравнивались друг с другом.

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

Последняя строка также имеет большое значение. После того как сессия сбивалась с курса, около 19% новичков сдавались без создания кода, в то время как у экспертов этот показатель составлял 5–7%. Ключевым навыком здесь является не формулировка запроса, а способность вернуть сбившуюся с курса сессию в правильное русло.

Одно предложение из статьи подытоживает ситуацию: у новичков Claude склонен корректировать пользователя, а у экспертов — пользователь корректирует Claude. В этом и заключается разница между использованием агента и управлением им.

Трехэтапный цикл, который терпит неудачу

Типичная процедура выглядит следующим образом:

Bad:
Prompt → AI writes code → Accept

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

Семиступенчатый цикл, который работает

Рутина, выдержавшая взаимодействие с производственным торговым приложением, состоит из семи этапов:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

Инженер отвечает за первые три этапа и последние два, а агент — за то, что находится между ними. Это соотношение отражает результаты исследований, где 70/30 приходится на планирование, а 80/20 — на выполнение, представленные в виде конвейера. Каждый этап имеет свою собственную стоимость.

Требование

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

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

Последним пунктом этого спецификация является знание конкретной области, которого нет ни у одной модели. Именно это отличает работающий экран от такого, который приводит к регуляторным нарушениям. Это соответствует показателю «точности направления» в исследованиях, и это самый дешевый способ его устранения.

Контекст

Когда UIKit и SwiftUI сосуществуют в рамках Clean Architecture, агент создает собственные шаблоны, если никаких не предоставлено, и каждый такой изобретенный шаблон впоследствии становится объектом обзора. Поэтому сначала агенту показывают реальные примеры: текущий протокол использования, реализацию в одном репозитории, ViewModel, выполняющий ближайшую по функции задачу, а также файл CLAUDE.md модуля с правилами его структурирования. Три файла и документ с правилами всегда эффективнее трех абзацев объяснений. Почти все пропускают этот этап, хотя именно он приносит наибольшую пользу.

План

Запросите план заранее, указав, какие файлы изменяются, какой слой обрабатывает каждое изменение, что предоставляет ViewModel и что принимает тесты. Читайте его как описание PR. Отклонение плана занимает примерно девяносто секунд. Отклонение реализации занимает двадцать минут и оставляет diff, который необходимо мысленно проигнорировать.

Примерно треть планов подвергается изменениям, почти всегда из-за вопросов, связанных с структурой слоев — например, когда агент помещает вычисления в ViewModel, которые должны находиться в use case. Исправление этого проблемы в текстовом виде стоит недорого, тогда как исправление в Swift — дорого.

Реализация

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

Проверка

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

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

Проверка

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

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

Как развивается работа

Тренд за семь месяцев в рамках 400 000 сессий заслуживает внимания:

• Доля сессий, посвящённых отладке, снизилась с трети (33%) до 19%.
• Запуск программного обеспечения в рабочем режиме вырос до 21% после начальных 14%.
• Написание кода и анализ данных примерно удвоились, увеличившись с примерно десятой до примерно пятой части сессий.

Поиск ошибок занимает меньше времени, тогда как управление и анализ работающих систем требует больше времени. За тот же период оценочная стоимость задач выросла примерно на 25%, а объем задач по их созданию — примерно на 43%. Работа не исчезает; она просто переходит на более высокий уровень, от простого написания реализаций к их определению, координации и проверке, что соответствует способу работы старшего инженера с командой.

Узким местом является цикл

Девять из десяти разработчиков используют эти инструменты каждую неделю, однако только 15–33% сессий заканчиваются успешной проверкой. Следовательно, модель никогда не была ограничивающим фактором. Большинство людей просто используют трехэтапный цикл с инструментом, предназначенным для семи этапов.

Улучшение формулировки запроса не решит проблему. Решение заключается в том, чтобы определить критерии оценки на этапе формирования запроса, то есть заранее установить понятие «правильного» результата и в конце проверить, было ли оно достигнуто. Агент занимается исполнением в промежуточном этапе и делает это хорошо, в зависимости от того, насколько четко заданы границы задачи.

В 2026 году те, кто получает наибольшую пользу от агентов для программирования, не пишут самые изощренные запросы. Это те, кто определяет, что считается «завершенной» работой.