25 сентября 2026

Агенты заменили программистов: разработка и ИИ

Этот текст дополняет четвёртый выпуск подкаста 2ТОК. Аналитический центр red_mad_robot на фактах и примерах разбирает, как ИИ изменил разработку ПО, от зарождения вайбкодинга до последствий для российского рынка и мира.

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

Развитие ИИ в образовании закреплено в «Национальной стратегии развития искусственного интеллекта на период до 2030 года».  Доминирующие категории по времени:
Frame 2136137150.png
По данным исследования OpenRouter State of AI 2025, доля кодинга в общем объёме токенов всех LLM выросла с 11% в начале 2025 года до более 50% к концу года. Написание ПО стало главной задачей, для которой люди используют LLM. Интерес к кодингу с ИИ породил десяток новых терминов: вайбкодинг, Spec-Driven Development, промпт-, контекст-, харнесс-, агентный, loop- и graph-инжиниринг. Ниже пойдёт речь подробнее обо всех этих понятиях. Десятилетиями программирование были только явные инструкции и шаги, которые выполнялись вручную: циклы, память, управление потоком. В 1970-х с появлением SQL первым возник новый принцип. Программист описывает не процесс, а желаемый результат. В 2000-х Model-Driven Development попытался пойти дальше и генерировать код из формальных моделей автоматически, но инструменты оказались негибкими. Генеративный ИИ впервые перевёл естественный язык в рабочий код. В январе 2023 года Андрей Карпаты написал: «Самый передовой новый язык программирования — английский». Формулировка отразила идею, которую позже назвали AI Software 3.0. Естественный язык заменяет синтаксис в роли интерфейса между намерением человека и его машинным исполнением.
Промпт-инжиниринг постепенно стал базовым навыком, ведь теперь важнее уметь сформулировать задачу для модели. Хорошая формулировка при этом не заменяет документацию проекта, а только уточняет выданные модели инструкции.
2 февраля 2025 года Карпаты описал свой способ работы и назвал его вайбкодингом. Он полностью полагался на ощущения, спрашивал у моделей даже незначительные детали и передавал ИИ любые возникающие ошибки без комментариев. Пост стал вирусным, потому что его описал один из самых авторитетных практиков ИИ-отрасли, сооснователь OpenAI и бывший директор по ИИ в Tesla. В июне 2025 года Тоби Лютке, CEO Shopify, предложил новое определение — контекст-инжиниринг. Под ним он подразумевал навык давать модели весь необходимый контекст, чтобы задача стала решаемой. Здесь особенно важно окружение, которое состоит из документов, базы знаний, истории шагов, проектных правил. Позже в 2025 году начинает развиваться Spec-Driven Development (SDD). Он возник как ответ на главный изъян вайбкодинга — отсутствие глобального плана. SDD вернул формальную структуру, не убивая скорость. В SDD спецификация становится машиночитаемым ориентиром. Она описывает, что система должна делать, и к ней прибегают, чтобы строить код и тесты вокруг него. AWS Kiro автоматически переписывает пользовательские истории в формате EARS, и его функция property-based testing генерирует множество входных данных под заданное свойство результата вместо ручных примеров. В начале 2026 года распространился харнесс-инжиниринг. Термин ввёл Митчелл Хашимото, создатель Terraform и Ghostty, под которым он подразумевает следующую ситуацию: если агент ошибся, систему нужно изменить так, чтобы повторить эту ошибку стало сложнее. Харнесс включает оркестрацию, инструменты, память, управление контекстом, обработку ошибок, проверку результата и ограничения доступа.
В апреле 2026 года Карпаты ввёл понятие agentic engineering (агентная разработка). Вайбкодинг опустил порог входа, ведь теперь собрать ПО может каждый. Но агентная разработка, наоборот, подняла планку. Инженер в этом случае управляет ИИ-агентами, пишет спецификации, проверяет архитектуру диффов и строит петли.
С июня 2026 года распространяется идея автоматизированных, циклических систем вайбкодинга без постоянного участия человека. Руководитель Claude Code в Anthropic Борис Черный сказал: «Я больше не промпчу Claude. У меня запущены циклы, которые промптят Claude и разбираются, что делать. Моя работа — писать циклы». Шесть дней спустя Петер Штайнбергер, создатель OpenClaw, опубликовал в X: «Ваше ежемесячное напоминание: вы больше не должны промптить агентов. Вы должны проектировать циклы, которые промптят агентов за вас». На следующий день Адди Османи, бывший директор Google Cloud, назвал это loop engineering. Агенту задают цель, механизм проверки и цикл, который повторяется до выполнения задачи. Но термин быстро сменился на graph engineering — проектирование агентных систем как направленных графов, где агенты выступают исполнителями узлов, а связи определяют зависимости и порядок выполнения. Он разошёлся после твита Питера Штайнбергера о переходе от циклов к графам. Технология не новая — DAG-схемы работают десятилетиями, а LangChain выпустил LangGraph ещё в январе 2024 года. Новизна здесь в роли языковой модели внутри архитектуры.

А что использовать?

Для разговора и простоты закрепился «вайбкодинг» — его знает словарь Collins. Для профессионального контекста употребляется термин «агентная разработка». В чистом виде во время вайбкодинга пользователь не следит за работой агента и не проверяет код. 
Но на деле большинство инженеров-разработчиков на самом деле не так используют ИИ-агентов. Они выступают как инструмент, при котором человек сохраняет контроль 
и ответственность за результат. Поэтому корректнее использовать «агентную разработку». 
Теперь, когда агентная разработка становится нормой, разработчики понимают, что контроль над ИИ-агентами отнимает много времени. Например, известный разработчик и летописец ИИ-трансформации Саймон Уиллисон отмечал, что уже к одиннадцати утра чувствует утомление от надзора за агентами.

Что дальше?

Термин в разработке ПО, скорее всего, снова сменится, например, уже существует Metagraph Engineering. Но инженерные задачи остаются прежними: как разделить работу между компонентами, как управлять выполнением, как независимо проверять результаты и как оставить ключевые решения за человеком.

Рои / флот ИИ-агентов

Модель «один разработчик — один агент» уже не выдерживает нагрузки. Агент занят от минут до часов на задачу, и к моменту завершения разработчик переключается на другие задачи. 
В будущем произойдёт переход к флотам агентов, где внимание человека направлено только на лучшие результаты, как 
у менеджера команды. Флот — это параллельные сессии без общего управления, дающие десять разрозненных PR, каждый из которых требует отдельного ревью. Настоящее управление флотом разделяет стадии выпуска ПО — план, код, ревью, слияние — и оркестрирует агентов по всему конвейеру. 

Инфраструктура

Больше параллельных агентов пишут больше кода, и спрос на вычисления растёт быстрее предложения, потому что кодинг — один из самых токеноёмких видов нагрузки. Даже когда проприетарные модели снижают стоимость, тяжёлые задачи кодинга ломают экономику закрытых API. Системный промпт несёт кодовую базу и определения инструментов, и токенов на входе требуется в разы больше, чем для обычной задачи. Anthropic уже ограничила Claude Code недельными лимитами, потому что активные пользователи на плане за $200 в месяц сжигают токенов на порядок больше этой суммы. Microsoft отменил внутренние лицензии Claude Code в подразделении Experiences and Devices и переводит инженеров на GitHub Copilot. Uber потратила весь годовой бюджет на ИИ за четыре месяца 2026 года, поскольку расходы на одного инженера при активном использовании достигали $500–2000 в месяц. Спрос на кодинг растёт экспоненциально, а вычислительные мощности — по темпам строительства дата-центров. Альтернативой становится открытый исходный код. MiniMax M2.5 приближается к Claude 4.5 Opus по SWE-bench при стоимости в 10 раз ниже, инструменты Cline и Opencode уже работают в инженерных процессах, а JPMorgan разворачивает open source агентов внутри своей инфраструктуры из соображений безопасности и стоимости.

Верификация

Дешёвый инференс и параллельные интерфейсы позволяют агентам выпускать больше кода, чем когда-либо, но теперь его нужно кому-то проверять. Самое логичное решение — сделать больше тестов и ревью. К примеру, CodeRabbit и Qodo проверяют PR и генерируют тесты автоматически. Эти инструменты оптимизируют процесс, но не гарантируют корректность.

Вайбкодинг — возможность или угроза цифровому суверенитету России?

Компании и ведомства переходят с зарубежных продуктов на российские под давлением санкций, ухода иностранных вендоров 
и законодательства. Но разработчики этих же компаний пишут код 
с помощью иностранных ИИ-инструментов: по данным Napoleon IT и AI Talent Hub ИТМО, 75% российских разработчиков используют ИИ-ассистентов для написания и отладки кода. Среди моделей лидируют GPT (36%) и Claude (31%). А по данным «Кросстеха», крупные российские организации используют в среднем около восьми языковых моделей одновременно, 40% из них — зарубежные, а 60% всех моделей работают как облачные SaaS-сервисы.

Как можно минимизировать работу без отказа от ИИ

Иван Оселедец, гендиректор AIRI, декан факультета ИИ МГУ называет несколько вариантов. 
  • Локальное развёртывание открытых моделей внутри контура компании. Qwen2.5-Coder, DeepSeek-Coder и StarCoder2 показывают конкурентоспособное качество в задачах генерации кода и могут работать на корпоративной инфраструктуре без передачи данных во внешний контур.
  • Не передавать ИИ задачи целиком. Вайбкодинг можно использовать в формате парного программирования: разработчик формулирует задачу, модель предлагает решение, человек его проверяет. 
  • Разграничение контекста. В модель передаются только те фрагменты кода, которые нужны для конкретной задачи, без конфигураций, ключей и полных архитектурных схем.
  • Использовать российских ИИ-агентов. Например, GigaCode от СберТеха, SourceCraft от Яндекса, Kodify от MWS AI или T-Code от Т-Банка. Есть даже специфичные продукты только для российского рынка — 1С:Напарник внутри среды разработки 1С:EDT.
  • Разработка собственного ИИ-инструмента. Но нужно быть готовым к увеличению бюджета. По данным MWS AI, команда, которая разрабатывает, внедряет и сопровождает ИИ-решения в крупном российском бизнесе, обходится в среднем примерно в 108 млн рублей ФОТ в год.

Как российские компании подходят 
к разработке с ИИ

В июле 2026 года Яндекс объявил программу «75/75/75»: к концу года не менее 75% разработчиков компании должны регулярно применять ИИ, а сам ИИ — участвовать не менее чем в 75% изменений кода. На момент объявления 73% разработчиков уже регулярно использовали ИИ-инструменты, а по целевой модели работали 17,2%.  Команда измеряет не факт использования инструмента, а пять параметров: активацию, скорость, качество, экономику и обратные сигналы — рост доли ИИ-слопа. За абстрактными коэффициентами стоят конкретные результаты: Яндекс Браузер создал 80% новой архитектуры с помощью ИИ и увеличил скорость спринтов в 3,3 раза; Яндекс Лавка собрала прототип кабинета франчайзи силами одного инженера за три недели; Яндекс Поиск сократил цикл внедрения обновлений с шести месяцев до двух недель с помощью внутренних агентов. ДОМ.РФ Технологии прошла три ступени внедрения: сначала разработчики просто консультировались с LLM, затем модель встроилась в IDE с доступом к кодовой базе, а на третьей ступени агенты стали работать самостоятельно. В пилоте задачи с оценкой 
в два рабочих дня решались примерно за полчаса, с ростом эффекта в ×3 и выше. 
Но у ускорения обнаружились и риски. Код нужно проверять, но тимлиды не успевают ревьюировать его выросшие объёмы. Через 4–6 месяцев такой работы команда рискует получить кодовую базу, архитектурные решения в которой никто из людей уже не понимает.
Несколько компаний оформили свой подход в методологию. Сбер показал AI-Disrupt PDLC — переосмысление жизненного цикла разработки вокруг ИИ-агентов, среды исполнения Agent Runtime 
и Specification-Driven Development.  IT_One создала фреймворк, который определяет нужный ИИ-инструмент на каждом этапе SDLC, и сообщает о росте производительности команды на 30–40%.  «Группа Астра» представила методологию «Астра ИИ Траектория»: на каждом этапе конвейера используется модель, направленная на конкретную задачу. По собственным данным компании, у команды «Боцман» трудоёмкость снизилась на 50% при росте производительности на 70–90%, у других команд эффект скромнее — от −24% до −34,5% трудоёмкости при росте производительности на 30–50%.

Где ИИ уже работает, а где — нет

Ассоциация ФинТех (АФТ) на примере финансового сектора разобрала, как ИИ проходит пять этапов жизненного цикла разработки — данные опроса за второй квартал 2026 года:
  • Исследование и постановка задач. ИИ синтезирует пользовательские интервью и генерирует черновики пользовательских историй; продуктивность менеджеров на этих задачах растёт на 40%. Но такая работа рискует превратиться 
в «вайб-исследования», когда реальных пользователей подменяют ИИ.
  • Проектирование и архитектура. ИИ хорошо генерирует типовые архитектурные варианты и диаграммы, но плохо справляется 
с нестандартными ограничениями конкретной организации.
  • Реализация и написание кода. Генерацию и автодополнение кода применяют 77% опрошенных, генерацию тестов и автоматизацию QA — 73%, вайбкодинг — 68%, документирование — 63%, автономных агентов — 59%. Заметно отстают сценарии проверки кода: автоматизированный код-ревью используют 40%, поиск уязвимостей — 39%.
  • Тестирование и контроль качества. Одно из самых перспективных направлений, но рост объёма ИИ-кода затрудняет код-ревью и его валидацию.
  • Развёртывание и эксплуатация. Здесь сопротивление максимально: 76% разработчиков не планируют применять ИИ для развёртывания и мониторинга, 69% — для проектного планирования. Тем не менее ИИ уже применяется там, где задача сводится к поиску паттернов в данных.

Как меняется позиция разработчика

Как меняются требования

По данным опроса АФТ, важнее всего становятся системное мышление и архитектура (86%) и безопасная разработка вместе с ревью ИИ-кода (85%) — именно те компетенции, которых требует контроль над машинным кодом. Растёт спрос на навыки постановки задач (64%), расширяется круг обязанностей (45%). Одновременно ценность джуниор-разработчиков снижается (41%), а требования к чисто техническим навыкам падают (14%).

Вопрос доверия

Уровень доверия к результатам ИИ АФТ описывает пропорцией 
«70 на 30»: 46% разработчиков выражают умеренное доверие, ещё 24% — большое или очень большое, 23% доверяют лишь в малой степени, 7% не доверяют вовсе.

Парадокс продуктивности

Генерация кода, тестов и документации ускоряется заметно. 
Но на уровне всей системы разработки картина сложнее, поскольку совокупная продуктивность растёт непропорционально, а порой 
и вовсе стагнирует. В феврале 2026 года лаборатория METR попыталась повторить своё исследование 2025 года и не смогла набрать контрольную группу — разработчики массово отказывались участвовать без ИИ даже ради науки. Исходное исследование 2025 года показало контринтуитивный результат. Участники ожидали ускорения на 24% и были уверены, что выиграли около 20% времени, но по факту работали с ИИ на 19% медленнее — время уходило на поиск и исправление ошибок, управление агентом и ожидание. Опрос METR в мае 2026 года, где разработчики уже сами оценивали свою продуктивность, показал обратную картину. Респонденты сочли, что ИИ сделал их вдвое ценнее для компании, но эта оценка прямо противоречит замеренным 19% замедления. Есть и более фундаментальная проблема. ИИ-код увеличивает затраты на поддержку, а не снижает их. Основательница Entelligence AI Айшварья Санкар заявила, что компании тратят до 44% токенов на исправление багов, сгенерированных их же ИИ. К похожим выводам пришли и исследователи CMU (Сингапурского университета менеджмента): в апреле 2026 года они предупредили, что ИИ-код создаёт долгосрочные скрытые издержки на поддержку. Опрос АФТ фиксирует похожую неоднородность в России. Скорость разработки повышается у 95% респондентов, но по качеству решений мнения расходятся почти поровну (41% — повышается, 41% — снижается). Несмотря на это, разработчик экономит около 10 часов в неделю: 45% тратят меньше времени на написание кода, а 42% выделяют больше времени на ревью.
Frame 2136137151.png
Похожий разрыв показывает опрос McKinsey «The State of AI in 2026», но уже на уровне финансовых метрик. За четыре квартала число пул-реквестов на разработчика выросло на 37%, доля ИИ-кода в слитых изменениях — с 34% до 52%, расходы компаний на ИИ-инструменты — с $1,5 тысячи до $44 тысяч. Каждый разработчик экономит 4–6 часов в неделю, но доля времени на создание новой функциональности почти не изменилась. Индекс опыта разработчиков DXI снизился с 67 до 65 пунктов, а медианный пул-реквест почти удвоился — с 44 до 72 строк. Рост личной продуктивности отмечают 76–81% сотрудников, но влияние на EBIT увидели только 37% компаний, а прирост от 5% и выше — лишь 6%. 
McKinsey связывает результаты не с недостатками технологии, 
а с тем, что организации ещё не адаптировали процессы под новые возможности.

Заменит ли ИИ разработчиков?

В феврале 2026 года компания Block (Cash App, Square, Afterpay) сократила четыре тысячи сотрудников. Основатель компании Джек Дорси объяснил это тем, что ИИ «открывает новый способ работы» с меньшими командами. Дата-сайентист Cash App Наоко Такеда написала, что реальный прирост продуктивности от ИИ в компании был «крайне ограниченным», и уволилась, отказавшись от повышения зарплаты на 75%. В мае Intuit сократила три тысячи позиций одновременно с партнёрствами с Anthropic и OpenAI; на этот раз руководитель компании публично опроверг связь с ИИ, заявив, что сокращения затронули «роли с избыточной координацией».
«ИИ-вошинг» сокращений — явление всей экономики, это подтверждают опросы: 59% американских руководителей, ответственных за найм, признали, что ссылаются на ИИ, объясняя сокращения, потому что это звучит убедительнее, чем финансовые трудности. Forrester отмечает, что в девяти случаях из десяти у компаний, готовящих сокращения под предлогом ИИ, нет зрелого ИИ-сервиса, готового заменить эти позиции.
Исследования показывают, что эффект ИИ на занятость проявляется не через рост увольнений, а через замедление найма. Работа экономистов ФРС фиксирует, что занятость разработчиков ПО в США продолжает расти, но темпы роста после появления ChatGPT ниже, чем в сценарии без ИИ, примерно на 3 п.п. в год. Отдельно стоят два вида потерь рабочих мест, связанных с ИИ, но не напрямую: 
  • ИИ снижает спрос на сам продукт, как в случаях с Chegg и Stack Overflow. Технология в этом случае устраняет саму потребность в работе сотрудников.
  • Компании, которые продают ИИ, а не покупают его. Их сокращения лучше описывать как перераспределение штата на быстрорастущие продуктовые линейки, а не как вытеснение сотрудников технологией.

Почему разработчики нужны: модель «сэндвича»

Работа разработчика ПО складывается из трёх слоев: решения, исполнения и сдачи результата. ИИ изменил содержание среднего слоя — исполнения, — но остальные остались почти без изменений. Исследование «Writing Code vs. Shipping Code» подтверждает это на выборке из ста тысяч разработчиков GitHub. Число написанных строк кода выросло в восемь раз, а число релизов — лишь на 30%. Слой решения с трудом поддаётся автоматизации, поскольку требует учитывать потребности пользователей, рыночные сигналы и приоритеты организации. По мере роста возможностей ИИ ему можно делегировать больше решений, но в таком случае они перестают быть источником конкурентного преимущества, 
и ценность человеческого выбора становится больше.  Сегодняшний ИИ недостаточно надёжен, чтобы полный отказ от проверки стал приемлем для команды и её клиентов. Ускоренная генерация кода создаёт пять типов риска:
  • Риск качества: ИИ может выдать синтаксически корректный, но логически ошибочный или уязвимый код, и разработчик, принявший его, также ответственен за ошибки.
  • Риск передачи данных: большинство ИИ-ассистентов работают как облачные сервисы, и для компании это риск утечки кода.
  • Риск концентрации: зависимость отрасли от ограниченного числа ИИ-провайдеров превращает сбой одного игрока в системную угрозу. 
  • Риск отсутствия объяснимости: если логику ИИ никто в команде не понимает, это создаёт регуляторный и операционный риски. 
  • Риск роста технического долга: код, принятый без понимания, работает функционально, но его архитектурная согласованность и поддерживаемость снижаются со временем.
В ответ на проблемы с генерируемым кодом три инженера из Варшавы запустили Slopfix — сервис, который чистит код за вайбкодерами. Он находит и удаляет лишний «ИИ-слоп», накопившийся в репозиториях.

Что ждёт разработчиков

Совокупный спрос на труд в разработке ПО, вероятнее всего, останется устойчивым. Он эластичен по цене, поскольку удешевление разработки увеличивает объём создаваемого ПО, 
а значит, и производный спрос на инженеров. Заметно это и по масштабу задачи — в современном автомобиле работает порядка ста миллионов строк кода.
Тут можно упомянуть концепцию «ИИ-роллапов», когда фонды скупают классический малый и средний бизнес и перестраивают его с нуля в «ИИ-нативном» формате, интегрируя в такие компании инженеров-разработчиков или ИИ-инженеров. Возможно, это окажется не более чем шумихой — пока рано судить.
При этом существует обратный сценарий — демократизация разработки, при которой ПО создают не инженеры, а специалисты в других областях. История языков программирования уже проходила через похожие процессы, но каждый раз профессионалы сталкивались с барьером не в синтаксисе языков программирования, а в профессиональном суждении, нужном для принятия решений. Несмотря на различие очевидно одно — объём времени, которое люди тратят на то, чтобы заставить ИИ делать что-то новое, со временем будет расти. Возможно, это будет разработка ПО, управление сложными процессами с помощью агентов или чего-то ещё. Специалисты должны будут сочетать навыки разработки, работу с ИИ и экспертизу в предметной области. Останутся ли именно сегодняшние инженеры-разработчики теми, кто лучше всего адаптируется к новым ролям,  покажет время.