Три года назад ИИ подсказывал строчку кода. Сегодня он сам делает коммиты, запускает тесты и исправляет ошибки. В материале Дмитрий Иванов, руководитель платформы SourceCraft, рассказывает, как изменился рабочий процесс разработчика — и что нужно знать, чтобы работать с агентами эффективно.
Развитие ИИ в разработке
2022–2023: эра автодополнения, или как все начиналось
Когда в 2022 году ИИ-ассистенты для кода стали общедоступными, реакция сообщества была предсказуемой: кто-то назвал это концом профессии, кто-то — очередной игрушкой. Реальность оказалась прозаичнее и интереснее одновременно.
Разработчики с ИИ-помощником справлялись с типовыми задачами на 55% быстрее — не потому что ИИ писал за них, а потому что исчезла потеря времени на поиск синтаксиса и чтение документации. Все это звучало обнадеживающе. Но ровно до тех пор, пока разработчики не начали смотреть не на скорость, а на качество. Простые, повторяющиеся задачи — например, написание стандартных заготовок кода — они спокойно отдавали ИИ в 87–96%.
Но как только задача выглядела нешаблонной и требующей понимания всего проекта целиком, доверие резко падало — без тщательной проверки код от ИИ был готов принять только каждый восьмой. Интуиция их не подвела, ведь простыми и маленькими задачами первые ИИ-ассистенты справлялись отлично и начинали ошибатьсякак только нужно соединить много частей воедино. Ошибки в таких местах могут дорого обойтись.
ИИ-ассистент образца 2022 года был отличным автодополнением и слабым архитектором.
Тем не менее рынок проголосовал однозначно: более 70% разработчиков давали положительные оценки ИИ-инструментам в 2023–2024 годах. По оценкам аналитиков, к 2025 году 41% всего промышленного кода создавался с участием ИИ. Маятник качнулся, и назад он уже не вернется.
2024–2025: агенты выходят на сцену
К 2024 году модели научились обрабатывать гораздо больше текста за раз — теперь ИИ охватывает проект целиком, а не несколько абзацев. Они получили возможность не просто писать ответы, а выполнять действия, например, запускать код, читать файлы, обращаться к базам данных. И главное — научились рассуждать: сначала выстраивать логическую цепочку шагов, потом выдавать результат.
Так появился ИИ-агент — автономная система, способная решать задачи в несколько шагов без постоянного участия человека. Эксперименты 2025 года показали, что группа с ИИ-агентом справлялась с заданием за 2,8 часа против 6,2 у контрольной, код содержал на треть меньше ошибок. За второе полугодие 2025 года сегмент разработчиков, которые пользуются в своей работе ИИ-агентом вырос в 3,6 раза, достигнув 79% всех пользователей платформы SourceCraft.
Агент 2024 года — это уже не подсказчик. Это исполнитель с инициативой.
Пользователи SourceCraft Code Assistant в 60% случаев используют ИИ-агента для рефакторинга кода, и всего в 15% — для проектирования архитектуры. При этом, тренд набирает обороты, разработчики тестируют агентов для разных, нетривиальных задач.
Анализ более двадцати экспериментов с тысячами программистов показал, что агенты великолепны на задачах с четко определенным контекстом и заметно слабее там, где нужно глубокое понимание предметной области или решение сложных задач, связанных с проектированием архитектуры приложений.
Один агент — это мало
У разработчиков есть соблазн в том, чтобы поставить одного умного агента и поручить ему все. Это не работает — и не только потому, что агент может ошибиться. При усложнении задач одиночный агент деградирует сразу по двум осям: теряет в качестве рассуждений и в качестве результата. Во-первых, универсальный агент, обученный делать все, делает все посредственно. А во-вторых, модели теряют качество рассуждений после 15–20 шагов — при длинных задачах агент буквально «забывает» начало своих рассуждений.
Ответом стали многоагентные системы: каждый агент отвечает за свою область, старший распределяет задачи между остальными, агенты проверяют работу друг друга и все видят один общий контекст. Команда из пяти специализированных агентов — планировщик, кодировщик, тестировщик, отладчик, рецензент — полностью решала задачи в 52,7% случаев против 34% у одиночного агента. Вмешательство человека потребовалось лишь в 28% случаев.
Мультиагентная система — это не просто «больше ИИ». Это другая архитектура мышления: разделение труда, взаимная проверка, специализация. Примерно то, что отличает команду от одиночки.
Однако один слабый агент в команде снижает итоговый результат на 30–50%. Он выдает некачественный результат — следующий агент принимает его как достоверный, строит на нем свою работу. Ошибка умножается — это каскадный эффект. На основе этого, в многоагентной системе важна однородность качества.
Оркестрация: как не дать агентам запутаться друг в друге
Успех многоагентной системы на 70% зависит от правильной оркестрации и только на 30% от мощности отдельных моделей. Стоит подумать об этом заранее. Самая проверенная стартовая конфигурация — триада из трех ролей:
- Планировщик получает задачу, разбивает ее на шаги и расставляет приоритеты.
- Исполнитель берет один конкретный шаг и делает его.
- Критик проверяет результат по заранее определенным критериям. Если не устраивает — возвращает на доработку с конкретными замечаниями.
Эта схема покрывает большинство задач разработки и не перегружена лишними связями.
Добавлять больше ролей стоит осторожно: система из пяти агентов работает на 12% лучше по качеству кода, чем из трех, но на 40% медленнее. После семи-восьми ролей выигрыш от специализации перестает окупать сложность координации.
Отладка таких систем усложняется тем, что поведение распределено. Нельзя просто «посмотреть состояние» и понять, где проблема — приходится восстанавливать полную цепочку выполнения задачи. Это требует заранее выстроенной системы наблюдения:
- Первый уровень — фиксация всех действий каждого агента. Например,что он делал, с какими входными данными работал, какой результат получил, сколько времени заняло выполнение и какие ошибки возникли.
- Второй — агрегированные метрики, отражающие производительность системы в целом. Например,скорость, стабильность, частоту ошибок и нагрузку. Они позволяют увидеть не отдельные сбои, а системные ограничения — перегруженные участки и устойчивые узкие места.
- Третий — граф прохождения задачи, который показывает как запрос движется между агентами. Например,где возникает зацикленность, где появляются лишние переходы и в каких местах процесс фактически застревает.
- Четвертый — периодический ручной анализ результатов, необходимый для выявления устойчивых паттернов ошибок, которые не видны в числовых метриках.
Практика показывает, что большинство проблем мультиагентных систем повторяются. Одна из самых частых — зацикливание. Агенты бесконечно передают задачу друг другу: один возвращает на доработку, другой снова исправляет, и процесс не завершается. Такие ситуации видны на графе выполнения как циклические маршруты. Решение — ограничение числа итераций и эскалация задачи человеку при превышении лимита.
Другой класс проблем — каскадные ошибки. Сбой в одном агенте распространяется дальше по цепочке и приводит к последовательному отказу остальных. Источник таких ошибок обычно выявляется по журналам как первая точка, с которой начинается цепочка сбоев. Основная защита здесь — ранняя проверка входных данных и более строгая обработка ошибок на первых этапах обработки задачи.
Отдельная проблема — потеря контекста. При передаче полной истории между агентами объем информации быстро растет и выходит за допустимые пределы. В результате система начинает игнорировать ранние условия задачи. Эта проблема решается не накоплением истории, а передачей краткого состояния — только ключевых решений и текущего шага выполнения.
Еще один эффект проявляется при усложнении цепочек — постепенная деградация качества. Чем больше шагов проходит задача, тем выше вероятность накопления ошибок и отклонения результата от исходного намерения. Вероятность этой ошибки снижается он за счет сокращения цепочек и добавления промежуточных проверок.
Наконец, отдельным ограничением становится стоимость системы. Без контроля количества запросов к моделям мультиагентная архитектура начинает генерировать избыточные вычисления, что приводит к резким скачкам затрат. Здесь помогают простые меры оптимизации: повторное использование промежуточных результатов, объединение запросов и использование более легких моделей там, где не требуется высокая точность.
Навыки: как научить агента быть экспертом
Когда разобрались с тем, сколько агентов нужно, возник следующий вопрос: как сделать так, чтобы они знали, как именно принято работать в конкретной команде.
Идея навыков состоит в том, что перед работой агент получает пакет инструкций: какие правила действуют в этой команде, чего делать нельзя, несколько примеров работ из этого проекта и четкие критерии, когда задача считается выполненной. Не нужно переобучать модель — достаточно правильно ее подготовить. С навыком агент получает тот самый брифинг автоматически. Концепцию навыков активно развивают несколько глобальных игроков. На российском рынке мы интегрировали концепцию ИИ-навыков в платформу для разработки SourceCraft.
Более слабая и дешевая модель с хорошо собранным навыком обгоняет дорогую без него: 84% соответствия требованиям против 71%. Та же дорогая модель с навыком выходит на 94%.
Навык — это не магия промптинга. Это формализованная экспертиза команды, упакованная в переиспользуемый артефакт. Он работает как документация, только ее еще читают.
Как писать промпты, которые работают
Промпт в эпоху агентных систем — это архитектурное решение.Например, «Оптимизируй этот код» и «Оптимизируй по скорости: узкое место здесь, используй кеширование, не трогай внешний интерфейс, добавь замер до и после» — это два разных промпта. Первый дает 40% успешных выполнений, второй — 75%. Разница не в умности агента, а в качестве постановки задачи.
Агент работает ровно с тем, что ему дали. Расплывчатая задача — расплывчатый результат, поэтому чем конкретнее формулировка ( с контекстом, ограничениями и критериями готовности), тем предсказуемее поведение агента. Показать два-три реальных примера из проекта часто эффективнее длинного объяснения: агент схватывает логику быстрее, чем усваивает инструкции. И отдельно стоит явно написать, чего делать не нужно — это работает не хуже позитивных указаний.
При длинных задачах качество результата напрямую зависит от того, сколько лишнего агент тащит в голове. Не нужно давать весь проект — только те файлы, которые реально нужны для задачи. Большую задачу лучше разбить на цепочку шагов. А после каждых нескольких шагов — фиксировать итог: что сделано, какие решения приняты, что осталось. Это работает лучше, чем бесконечно накапливать историю переписки.
Исследования подтверждают: те, кто ведут версии промптов как исходный код и тестируют их, получают на 40% более стабильные результаты. Промпт — не одноразовая инструкция. Это артефакт, который живет, меняется и требует поддержки. Как и код.
Разработчик в 2026 году: та же профессия, другая работа
72% разработчиков говорят, что их роль фундаментально изменилась за последние два года. 58% тратят заметно больше времени на проектирование и архитектуру, и заметно меньше на собственно написание кода.
Опрос фиксирует три новых компетенции, которые разработчики называют критически важными. На первом месте — инженерия промптов к ИИ (89% респондентов). На втором — координация агентов (67%). На третьем — общая грамотность в области ИИ: понимание того, как работают модели, каковы их возможности и ограничения (61%).
Что именно изменилось в повседневной работе:
- Постановка задачи стала важнее написания кода.Чем точнее разработчик формулирует задачу — с контекстом, ограничениями, критериями приемки — тем лучше результат агента. Навык, который раньше требовался только при работе с подрядчиками, теперь нужен каждый день.
- Архитектурные решения остались за человеком. Агенты хорошо реализуют архитектуру, но плохо ее выбирают. Выбор подхода к проектированию — по-прежнему человеческая работа, и, судя по всему, она только дорожает.
- Появилась роль координатора агентов. Кто-то должен выстроить схему взаимодействий, распределить ответственность, настроить точки контроля. Когда агенты делают 80–90% работы, человек сосредотачивается на критически важных 10–20%. Меньше «правильно ли расставлены скобки», больше «правильно ли выбран подход».
Есть и открытый вопрос, который индустрия уже начинает обсуждать: если разработчик годами не пишет код, а только проверяет и координирует — сохраняются ли у него навыки на уровне, достаточном для качественной оценки работы агента? Пока ответа нет.
Какие инструменты реально используют
Рынок ИИ-инструментов для разработки в 2026 году остается фрагментированным. Сотни команд выпускают решения с разной степенью зрелости, крупные технологические компании регулярно обновляют свои платформы, а инструменты с открытым исходным кодом быстро догоняют коммерческие продукты. В результате рынок сложно воспринимать как единую систему — он скорее состоит из нескольких устойчивых классов инструментов, которые решают разные задачи в разработке.
Инструменты внутри среды разработки
Первая группа — это инструменты, которые встроены непосредственно в процесс написания кода. Они работают рядом с разработчиком и помогают на уровне отдельных файлов и фрагментов кода. Их основная функция — ускорять рутинные операции, например,мдописывать код по контексту проекта, предлагать изменения в существующих функциях, переписывать участки кода по текстовому описанию и помогать разбираться в уже написанных модулях.
Ключевое изменение последних лет заключается в том, что такие системы перестали работать только с текущим файлом и научились учитывать структуру всего проекта.
Среды разработки с агентной логикой
Вторая категория — это системы, в которых ИИ выходит за пределы роли помощника и начинает самостоятельно выполнять задачи разработки.
В таких средах агент работает как отдельный исполнитель: он анализирует задачу целиком, строит план, вносит изменения сразу в несколько частей проекта, запускает проверки и тесты, а затем итеративно исправляет результат. В более зрелых реализациях он может взаимодействовать с внешними системами — искать информацию в документации, обращаться к системам постановки задач или задавать уточняющие вопросы команде.
Эти инструменты применяются там, где задачи достаточно формализованы и могут быть описаны без постоянного участия человека: исправление ошибок, реализация заранее сформулированных функций, переработка модулей и работа с накопленным техническим долгом.
Их ключевое ограничение связано не с возможностями модели, а с постановкой задачи. Чем менее однозначно описана цель, тем сильнее падает качество результата.
Фреймворки для создания агентных систем
Отдельный слой рынка — это инструменты, которые не решают прикладные задачи разработки напрямую, а позволяют строить собственные системы агентов.
С их помощью можно задавать роли и специализацию агентов, описывать задачи и порядок их выполнения, а также управлять логикой взаимодействия между ними. Такие системы позволяют строить как линейные процессы, так и более сложные графовые схемы, где поведение определяется результатами промежуточных шагов.
По сути, это переход от использования готового агента к проектированию собственной системы взаимодействующих агентов. В более сложных случаях логика описывается в виде графа состояний, где каждый узел соответствует действию, а переходы зависят от результата выполнения. Это дает высокий уровень управляемости и предсказуемости даже в сложных процессах с ветвлениями и циклами.
Как выбрать ИИ-инструмент?
На практике выбор редко определяется только функциональностью — гораздо чаще типом задач, зрелостью команды и инфраструктурными ограничениями.
Индивидуальные разработчики и небольшие команды выбирают инструменты, встроенные прямо в среду разработки. Их главная задача — быстро двигаться от идеи к коду. Здесь критична скорость итераций, любые дополнительные шаги начинают мешать.
Команды, которые работают с крупными и давно развивающимися системами, чаще сталкиваются с другой проблемой — необходимостью разбираться в большом объеме связанного кода и безопасно вносить изменения в разных частях системы. Здесь ценность получают инструменты, способные выполнять задачи целиком: от анализа кода до внесения правок и проверки результата. Чем меньше требуется постоянного контроля человека, тем эффективнее такой подход.
Стартапы на ранней стадии обычно комбинируют два подхода: инструменты внутри среды разработки — для ежедневной работы, более автономные системы — для ускорения типовых задач вроде стандартных компонентов или серверных интерфейсов.
Корпоративные команды с жесткими требованиями к безопасности исходят из другого ограничения: данные и код не должны покидать внутренний контур. Это смещает выбор в сторону решений, которые разворачиваются внутри инфраструктуры компании. Контроль и предсказуемость важнее скорости внедрения.
Исследовательские команды выбирают инструменты не по стабильности, а по гибкости. Им важно быстро менять подходы и проверять гипотезы. Поэтому они предпочитают наборы инструментов, позволяющие собирать собственные схемы работы, а не фиксированные сценарии.
В итоге различие между инструментами — не в возможностях как таковых, а в том, какую часть работы они берут на себя. Один и тот же инструмент может быть полезен в одном сценарии и избыточен в другом.