Разработка ПО с ИИ: команды агентов в 2026 году

Введение

Два года назад у инженера в нашей команде было открыто одно окно. Редактор кода. Сегодня у того же инженера крутится десяток сессий с агентами, и каждая грызёт свой кусок одной задачи. Это никто не планировал. Оно нарастало месяц за месяцем. Теперь так выглядит работа.

Вот лестница, по которой мы поднимались. Ступень 1: разработчик, редактор, код. Единица работы - файл. Ступень 2: то же самое плюс подсказки ИИ и автодополнение. Ступень 3: разработчик вручную жонглирует Агентом 1, Агентом 2 и Агентом 3 и руками таскает контекст между ними. Ступень 4, куда идут хорошие инструменты: человек называет нужный результат, ведущий агент разбивает его на части, профильные агенты пишут код, что-то проверяет итог, и на выходе появляется пул-реквест. Единица работы - готовая функция.

Корпоративному заказчику всё это само по себе не нужно. Строки сгенерированного кода - не результат. Результат - это предсказуемые сроки, проверяемый итог, безопасность, стыковка с тем, что у вас уже работает, и возможность сопровождать систему пять лет.

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

Про даты, названия и цифры

Всё про цены и тарифы указано на 11 сентября 2026 года. Тарифы меняются быстро. 10 сентября 2026 года OpenAI временно остановил новые подписки Pro за $200 и переходы на них. Полезное напоминание: сам доступ тоже движущаяся цель.

Мы разделяем две вещи, которые постоянно путают. Модели - это одно: Astra и Fable 5.1 это модели. Среды для агентов - другое: Codex и Claude Code это среды, а Work и Cowork вообще отдельные продукты. Когда поставщик говорит "20x", эта цифра относится к его собственному тарифу. 20x у OpenAI и 20x у Anthropic - это разное количество токенов.

Любой тест, который поставщик публикует про свой же продукт, помечен здесь как "по данным поставщика". Оценки с разных стендов между собой не сравнимы. Внутренние проценты Webdelo мы не публикуем: контролируемых замеров внутри компании мы не проводили. Если мы приводим цифру, у неё есть названный внешний источник.

Почему узкое место сместилось с написания кода на координацию работы ИИ

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

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

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

Самая полезная независимая рамка - отчёт DORA 2025 о разработке ПО с помощью ИИ. Главный вывод: ИИ усиливает ту инженерную систему, которая у вас уже есть. Архитектура, короткие циклы обратной связи и качество внутренней платформы решают, превратится ли локальная экономия времени в результат для компании. Если процесс слабый, агенты просто ускорят приход этой слабости. Меньше она не станет.

Что реально ускорилось, а что нет

Быстрее: ограниченные задачи с понятным критерием готовности. Добавить метод API, написать миграцию, покрыть модуль тестами. Агент понимает, что закончил, потому что об этом ему говорит что-то внешнее.

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

Что такое агентная среда разработки (ADE) и чем она отличается от редактора кода с ИИ

Редактор кода с ИИ помогает человеку править файл. Агентная среда разработки запускает и согласует работу нескольких самостоятельных агентов: изолированные рабочие копии Git, параллельные сессии, общий контекст, проверку, тесты, проверку в браузере, пул-реквесты и аудит. Разница в единице работы. В редакторе это вкладка. В агентной среде это функция, задача из трекера или задача бизнеса.

Термин придумали не мы. Он появился, потому что старые слова перестали описывать предмет. Называть "редактором" систему, которая держит восемь агентов на шести рабочих копиях, это как называть склад полкой. Для руководителя, который не пишет код: редактор - это текстовый редактор с электроинструментом, сделанный под одного человека. Агентная среда - это рабочее место небольшой команды, только работники там программы. Она отвечает на те же вопросы, что и любая мастерская. У кого какая копия работы, как они держатся в согласии, кто проверяет результат, кто его принимает.

Настоящая агентная среда выдаёт почти весь этот список, причём в рабочей версии, а не в маркетинговой:

• изолированные рабочие копии Git, обычно worktree, чтобы два агента никогда не правили одни и те же файлы разом
• несколько агентов, работающих параллельно
• сессии, которые переживают перезапуск и обрыв связи
• учёт задач и их состояния
• общий контекст, чтобы второй агент знал, что решил первый
• просмотр изменений, который человек читает быстро
• тесты и CI, встроенные в цикл
• проверка запущенного приложения через браузер
• пул-реквест как формат выдачи результата
• запуск на удалённой машине
• автоматизации для повторяющихся шагов
• API, командная строка и MCP, чтобы средой могли управлять другие программы
• распределение ролей между агентами
• права доступа, наблюдаемость и аудит

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

Три подхода рядом

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

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

Как мы в Webdelo оцениваем агентные среды: изоляция, контекст, оркестрация, проверка, удалённое выполнение и приёмка

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

Изоляция. Могут ли агенты работать, не наступая друг другу на ноги? Отдельные рабочие копии, отдельные порты, отдельные переменные окружения. Проверочный вопрос: что будет, если два агента полезут в модуль авторизации? Если ответ "скорее всего конфликты", то это однопользовательский инструмент с лишними кнопками.

Контекст. Понимает ли инструмент весь репозиторий и всю задачу целиком? Контекстное окно - это сколько текста модель держит перед глазами разом. Кеширование промптов - это когда среда не платит полную цену за пересылку одного и того же фона на каждом шаге. И то и другое - вопрос денег не меньше, чем вопрос качества.

Оркестрация. Может ли один агент командовать остальными? Ведущий агент, профильные исполнители, обмен сообщениями, точки согласования, где работа останавливается, и понятный путь эскалации к человеку. Без этого вы получаете параллельность, но не команду.

Проверка. Можно ли доказать результат, а не просто собрать его? Тесты, CI, проверка через браузер и через систему, доказательства работы, приложенные к изменению. Тут большинство инструментов слабее всего, и именно тут разница важнее всего для клиента.

Удалённое выполнение. Могут ли репозитории, терминалы и агенты жить на сервере, а ноутбук или телефон быть только пультом? Для долгой работы это уже не удобство, а архитектура.

Приёмка. Как человек утверждает изменение? Качество разбора изменений, проверка кода другой моделью, точки согласования, след аудита. Если проверяющий не может прочитать правку за несколько минут, её утвердят не читая.

Таблица со всеми инструментами по этим осям идёт после разделов про инструменты. Мы не ищем лучший инструмент. Мы ищем тот, который меньше всего проваливается по оси, важной для конкретного проекта. На портале CRM выигрывает проверка. На изменении ERP через несколько репозиториев выигрывают изоляция и контекст.

Orca как наша нынешняя сбалансированная база

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

Мы намеренно говорим "база", а не "любимчик". База - это то, к чему вы возвращаетесь, когда у проекта нет особых требований. Значит, она должна быть предсказуемой, а не яркой. Что мы используем в работе: изоляцию рабочих копий, чтобы два агента на одной функции не столкнулись. Несколько агентов из командной строки, чтобы проверка шла на другой модели, а не на той, что писала код. Разбор изменений внутри самой среды. Встроенный браузер, чтобы агент мог открыть запущенное приложение и проверить себя сам. Автоматизации для повторяющихся шагов. Удалённые серверы, чтобы долгая задача не зависела от того, закрыл ли кто-то крышку ноутбука.

Режим дизайна заслуживает отдельного объяснения. Человек тычет в элемент интерфейса. Агент получает DOM этого элемента, вычисленный CSS, картинку, а если есть карта исходников, то ещё файл и номер строки. Вместо "поправь кнопку справа сверху, нет, другую" агент получает координаты в коде.

Orca ещё и разделяет интерфейс и среду выполнения. Репозитории, терминалы, рабочие копии и агенты могут жить на отдельной машине, а ноутбук или телефон работают пультом. Навык оркестрации добавляет запуски, задачи, подчинённых исполнителей, сообщения и точки согласования. Сигнал тут не в списке возможностей. Сигнал в том, что слой координации переезжает внутрь среды. Раньше мы строили этот слой сами, из серверов MCP и склеенных скриптов. Теперь он идёт из коробки.

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

super.engineering и прямое взаимодействие агентов между собой

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

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

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

Почему это важно в B2B. Одна функция может задеть сразу одностраничное приложение, API, сервис авторизации, биллинг и уведомления. Общий контекст принадлежит функции. При этом каждому агенту нужна изолированная рабочая среда внутри своего репозитория. Совместить два этих требования - и есть настоящая инженерная задача.

Честные ограничения: статус "альфа", только macOS, экспериментальная оркестрация. Значит, это хорошее место для практических опытов и плохое место, чтобы ставить на него клиентский проект. Наблюдение за ним заодно поменяло наш взгляд на собственную историю. Мы построили свою оркестрацию на MCP, потому что ничего готового не было. Выглядело как крюк в сторону. Оказалось ранней версией того слоя, к которому сейчас сходится рынок.

ADE и Superset: сильные претенденты с разными козырями

ADE (ade-app.dev) ставит на Lane - единицу, которая упаковывает рабочую копию, терминалы, контекст агента, порты, переменные окружения, историю, набор изменений и состояние пул-реквеста. Плюс граф параллельных рабочих копий с оценкой риска конфликта. Superset ставит на встроенный браузер как общую площадку для человека и агента. Они решают разные половины одной проблемы. ADE управляет зависимостями между изменениями. Superset управляет доказательством, что изменение работает.

ADE и абстракция Lane

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

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

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

Superset и браузер как общая площадка

У Superset есть постоянные рабочие пространства, терминалы, агенты, удалённые устройства, автоматизации и механизм оркестрации. Отличает его встроенный браузер. Его режим дизайна передаёт агенту DOM, стили, данные React и снимок экрана, а сам агент может ещё и управлять браузером программно. Два эти направления складываются в по-настоящему новый цикл: человек видит страницу и показывает пальцем на проблему, агент получает точный технический контекст, правит исходники, перезагружает и проверяет результат на живом приложении.

Формулировать тут надо аккуратно, потому что план развития и выпущенный продукт - разные вещи. Базовая оркестрация есть уже сегодня. Чат оркестрации, самопроверка, снимки состояния и откат, очередь внимания, облачные песочницы и iOS - это план. Мы не выдаём их клиентам за возможности.

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

Emdash, Conductor, Mux, Herdr и Codex: что добавляет каждый подход

Остальное поле - не шум. Emdash это широкая открытая платформа. Conductor дисциплинирован в пути от рабочего пространства к набору изменений, потом к проверкам и пул-реквесту. Mux приносит собственную среду выполнения с несколькими моделями. Herdr спускается на уровень ниже, к постоянной среде терминалов. Приложение Codex показывает то же движение внутри одной экосистемы. Каждый решает одну ось лучше универсалов. Все описания возможностей ниже даны по данным поставщиков.

• Emdash. Параллельные рабочие копии, десятки агентов из командной строки, браузер, автоматизации, задачи, навыки и MCP, CI и удалённая разработка. Стоит посмотреть, если нужна широта и возможность позже передумать.
• Conductor. Дисциплинированный конвейер: рабочее пространство, агент, набор изменений, проверки, пул-реквест. Хостинг MCP и API позволяют внешнему ведущему агенту создавать рабочие пространства, раздавать работу и собирать результаты. Хорош, когда у вас уже есть оркестратор и нужны надёжные исполнители.
• Mux. Своя среда выполнения на нескольких моделях, запуск локально, в рабочей копии или по SSH, разбор изменений и режимы "план" и "выполнение", которые разводят решение и действие.
• Herdr. Постоянная терминальная среда для множества агентов. Сессии продолжают работать после отключения клиента, а другой агент может через API создавать сессии, раздавать задания и опрашивать их состояние: работает, заблокирован, готов. Это инфраструктура, а не верстак.
• Приложение Codex. Параллельные агенты, рабочие копии, навыки, автоматизации и удалённое управление внутри одной экосистемы. Интересно то, что один поставщик пришёл к тем же кирпичикам самостоятельно.
• OpenAI Symphony. Архитектурный указатель. Доска задач становится пультом управления, каждая задача получает изолированную среду и агента, а результат обязан приходить с доказательством работы: тесты, CI и проверка.

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

Таблица возможностей: инструменты по шести осям оценки

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

От сессий к задаче: ведущий агент, профильные исполнители и независимая проверка

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

Щёлкнуло на интеграции ERP, где инженер почти весь день работал шиной сообщений между тремя окнами агентов и трижды пересказывал один и тот же контракт. В какой-то момент прилетел очевидный вопрос. Почему старший инженер занимается маршрутизацией?

Наш конвейер на серьёзных задачах, в какой бы среде мы ни были:

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

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

Запись архитектурного решения, или ADR, - это короткий документ о том, что мы решили, что рассматривали ещё и почему. Одна страница. Мы заставляем агентов её писать, потому что агент, который не может объяснить решение простыми словами, обычно решения и не принимал. Он сделал догадку, которая скомпилировалась. Дальше инженер отвечает за слияние, за релиз и за последствия. Человек в контуре - это здесь проектное решение, а не отписка в конце.

"Перелом у нас случился, когда мы перестали считать агента ещё одной вкладкой чата. Гораздо интереснее управлять задачей: один агент планирует, несколько пишут, отдельный проверяет, а за результат отвечает инженер." - Андрей Попов, технический директор и основатель Webdelo

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

Как мы применяем эту схему на CRM, ERP, нескольких репозиториях и высоконагруженных системах

Схема с командой агентов отбивает себя ровно на тех проектах, которые раньше были самыми медленными. Функции CRM, задевающие права и целостность данных. Работа по ERP через несколько репозиториев. Поддержка больших унаследованных систем. Миграции с кучей механической правки. Форма каждый раз одна: изолированные рабочие копии, один согласованный контракт в общем контексте и проверка всей цепочки, а не одного сервиса. Это реальные схемы работы, описанные без выдуманных цифр. Те же схемы работают и за пределами корпоративного софта. При разработке сайтов недвижимости данные объектов и внешние интеграции ведут себя ровно как данные ERP.

Работа по CRM

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

ERP и многосервисная архитектура

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

Поддержка больших систем и модернизация устаревших систем

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

Миграции, рефакторинг и перенос баз данных

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

B2B-порталы

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

Проверка через браузер и через систему как доказательство работы

Код, который собрался, - это ещё не готовая функция. Мы считаем изменение готовым, когда агент прогнал настоящее приложение в настоящем браузере и пользовательский сценарий реально отработал. Агент открывает страницу, проходит сценарий кликами, читает DOM, делает снимки экрана и прикладывает всё это к изменению. Для CRM, ERP и порталов B2B это и есть разница между "собралось" и "работает".

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

Доказательство работы если конкретно - это пакет, приложенный к изменению: результаты тестов, статус CI, прогон в браузере, снимки экрана на ключевых шагах и написанное словами, какой сценарий проверяли. Проверяющий просматривает это за минуту. Нетехнический заказчик смотрит на снимки экрана и узнаёт свой процесс.

Режим дизайна крутит тот же цикл в обратную сторону. Не агент доказывает, что сценарий работает, а человек показывает место, где он не работает. Описывать визуальный дефект словами - канал с потерями. Ткнуть пальцем - нет. Проверка на уровне системы выводит это за пределы браузера: если продукт не только веб, агент может проверить сценарий на рабочем столе или в окне обычного приложения через саму операционную систему.

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

Почему среда выполнения уходит с ноутбука разработчика

Машина, которая хранит репозиторий и гоняет агентов, больше не обязана быть ноутбуком инженера. Orca Server, удалённые устройства Superset, ADE, Herdr и приложение Codex указывают в одну сторону. Для корпоративных проектов дело не в комфорте. Отдельная среда выполнения даёт реальный контроль над зависимостями, доступами, сетью и долгими процессами, а работа продолжается, когда ноутбук закрыт.

Повод был бытовой. Длительные задачи для ИИ-агентов, то есть работа на часы, а не на секунды, не помещаются в сессию, которая заканчивается, когда кто-то в 18:00 закрывает крышку.

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

Herdr - самый ясный пример модели постоянства. Сессии продолжают работать после отключения клиента, а другой агент через API может создавать сессии, раздавать задания и опрашивать их состояние. Как только это есть, клиент превращается просто в окно: компьютер, терминал, веб или телефон, и все смотрят в одну и ту же среду.

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

Что на самом деле говорят данные о продуктивности разработчиков с ИИ

Честный ответ: зависит от типа работы. В контролируемом эксперименте GitHub с 95 профессиональными разработчиками группа с Copilot закончила ограниченную задачу на JavaScript примерно на 55% быстрее. В исследовании METR 2025 года 16 опытных разработчиков открытого кода на 246 реальных задачах в хорошо знакомых репозиториях потратили примерно на 19% больше времени. Оба результата настоящие. Они отвечают на разные вопросы, и продавать вам один процент мы не будем.

Внедрение и доверие

По опросу разработчиков Stack Overflow 2025, 84% опрошенных уже используют инструменты ИИ или собираются, а 51% профессиональных разработчиков пользуются ими ежедневно. С внедрением всё решено.

С доверием картина из того же опроса другая. 46% скорее не доверяют точности выдачи ИИ против 33% доверяющих, и лишь 3% сообщают о высоком доверии. То есть большая часть профессии пользуется этими инструментами каждый день, но внимательно перепроверяет результат. Опрос называет и характер сбоя: 66% назвали проблемой ответы "почти правильные", а 45% сталкивались с тем, что отладка кода от ИИ занимала больше времени. "Почти правильно" - это дорогой сбой. Явно неверный код удаляют за десять секунд.

Два контролируемых результата, которые спорят

Исследование GitHub: 95 профессиональных разработчиков, ограниченная задача на JavaScript, примерно на 55% быстрее с Copilot. Чистая иллюстрация того, где ИИ действительно ускоряет: задача очерчена, финиш однозначен.

Исследование METR 2025: 16 опытных разработчиков, 246 реальных задач, зрелые репозитории, которые они уже знали глубоко. С инструментами начала 2025 года работа заняла примерно на 19% больше времени.

Самая полезная деталь тут не в заголовке. Разработчики заранее ожидали ускорения примерно на 24%. После работы, реально став медленнее, они всё равно считали, что ИИ ускорил их процентов на 20. Разрыв в восприятии пережил встречу с замером. Это предупреждение про любые внутренние заявления о продуктивности, сделанные по памяти, включая наши. METR прямо предупреждает, что результат не переносится на всю разработку ПО, и мы это предупреждение повторяем, а не заимствуем цифру.

Системный взгляд

Работа DORA 2025 даёт рамку, в которой оба результата становятся понятны. ИИ усиливает существующую инженерную систему. Задача, сделанная на 55% быстрее, внутри процесса, где правки ждут проверки две недели, не даёт компании ничего.

Измеримый вопрос звучит не как "ускоряет ли ИИ программирование". Он звучит так: становится ли этот вид работы внутри этого инженерного процесса быстрее и безопаснее. Ограниченная и проверяемая задача - обычно да. Глубокие правки в зрелой системе, которую команда знает назубок, - часто нет. Внутренние проценты Webdelo мы не публикуем: контролируемых замеров у нас не было, а после разрыва восприятия у METR мы бы и неформальному замеру не поверили.

Где ИИ-агенты тормозят команду и когда мы намеренно не оркеструем

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

Цена оркестрации не спрятана, о ней просто редко говорят. Больше агентов - больше согласований, больше конфликтов при слиянии, больше токенов, больше вычислений и больше работы по проверке. На задаче в два часа настройка трёх агентов стоит дороже самой задачи.

Ловушка "почти правильно" - самая дорогая. Её называют 66% опрошенных разработчиков, а 45% сообщают, что отладка выдачи ИИ занимала больше времени. Правдоподобный код, неверный в одном тонком месте, переживает беглый просмотр, проходит тесты, написанные из того же непонимания, и всплывает в проде. Зрелые репозитории с глубоким негласным знанием - это та же проблема в форме METR. Инженер знает, почему функция выглядит странно, какой модуль хрупкий, что сломалось в прошлом году. Ничего этого в репозитории нет, поэтому агент выдаёт технически разумную правку, которая игнорирует четыре неписаных ограничения.

Наш явный список "не оркестровать":

• мелкие правки, где настройка дороже работы
• разведочные прототипы, где цель - чтобы человек что-то понял
• инциденты, где нужен один решительный человек, а не комитет агентов
• работа, где нет теста, способного доказать правильность
• всё, где контракт ещё обсуждается

В таких случаях мы берём одного агента, узкие рамки и человека за рулём. Или вообще ни одного агента.

"В корпоративной разработке самостоятельность начинается с ограничений. Сначала мы задаём права, контекст, тесты и критерии приёмки, и только потом даём агенту больше свободы." - Андрей Попов, технический директор и основатель Webdelo

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

Безопасность, права, наблюдаемость и управление корпоративными агентами

Агент - это программа с доступами, выходом в сеть и возможностью действовать. Относитесь к нему соответственно. NIST работает над темой личности и полномочий программных агентов, а стандарт OWASP Agent Control Standard говорит прямо: поведение агента должно быть наблюдаемым, прослеживаемым и управляемым во время работы. На практике это означает минимум прав, разделённые доступы, ограниченный набор инструментов, журналы аудита, точки согласования и понятный путь эскалации к человеку. Корпоративный заказчик читает этот раздел первым, поэтому здесь мы копаем глубже.

Личность, доступы и границы действий

Три вопроса по порядку. Кто такой агент как отдельная личность в ваших системах? Что ему разрешено трогать? Какие инструменты он может вызывать? Минимум прав работает ровно так же, как для служебной учётной записи: агенту на фронтенде не нужны доступы к боевой базе данных.

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

Наблюдаемость и контроль во время работы

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

Контроль человека и точки согласования

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

Изоляция среды, контроль сети и цепочка поставок

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

Про ЕС и Германию

Коротко, и это не юридическая консультация. AI Act не выделяет агентов в отдельную правовую категорию, но существующие требования к системам ИИ могут применяться к подходящим сценариям, а отдельные обязанности по прозрачности начали действовать со 2 августа 2026 года. Для немецкого заказчика практический вывод про процесс: знайте, что делает система, умейте это показать и держите документацию, которая переживёт вопрос.

Список, который стоит скопировать в свою анкету для подрядчика: минимум прав, разделение доступов, ограничение инструментов, журналы аудита, точки согласования, изоляция среды, контроль сети, воспроизводимость, эскалация к человеку. Разработка корпоративного ПО с ИИ обязана учитывать данные, права, прозрачность и юрисдикцию клиента, и модель в этом списке - самая скучная переменная. Мы работаем по принципам GDPR и DSGVO и строим процессы в духе ISO 27001 и SOC 2; компания идёт к формальной сертификации, но сертификата пока не имеет.

Как мы встраиваем ИИ-агентов в бизнес-процессы клиента

Большинству компаний не надо объяснять, что ИИ существует. Им надо вшить его в настоящий процесс, с безопасным доступом к данным, понятной ответственностью и повторяемым результатом. McKinsey нашла, что в 2025 году 88% организаций применяли ИИ хотя бы в одной функции, но лишь 7% считали его полностью развёрнутым. Deloitte в августе 2026 года насчитала около 5% организаций, чьи процессы готовы к агентам. Этот разрыв и есть работа. Такой же разрыв есть в маркетинге. Поэтому и сео продвижение сайтов сегодня обсуждается в той же логике процесса.

Цифры целиком, каждая со ссылкой на источник. McKinsey, 2025: 88% где-то используют ИИ, 7% развернули полностью. Deloitte, август 2026: примерно 5% готовы процессно, примерно 15% имеют развёрнутую многоагентную модель между подразделениями, а 74% опрошенных руководителей ждут, что в течение четырёх лет почти половина бизнес-процессов будет перестроена вокруг агентов. Вместе это читается так: экспериментируют почти все, операционной готовности почти нет, а ожидания высокие и на коротком горизонте.

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

Как обычно начинается работа

Хорошо ложится схема 30 / 60 / 90. Первый месяц: берём один ограниченный процесс, снимаем с него метрики, меряем, как он работает сегодня. Второй месяц: запускаем агента, но человек проверяет каждый результат. Третий месяц: расширяем охват только там, где данные это подтверждают, а где не подтверждают - оставляем проверку человеком. Эту схему мы гоняли и на внедрении ERP, и на проектах вроде разработки сайтов красоты. Первый месяц всегда про измерения.

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

Какой может стать обычная агентная среда в ближайшие 6-12 месяцев

Сходятся четыре вещи. Управление задачами вытесняет управление сессиями. Среда выполнения продолжает уезжать с ноутбука. Браузер становится стандартной площадкой для проверки. А общение агентов между собой превращается в инфраструктуру: личности, роли, сообщения, общее состояние, блокировки, владение, жизненный цикл, права и наблюдаемость уезжают из самодельных скриптов внутрь самой среды. Это прогноз, и мы называем степень уверенности. В направлении мы уверены вполне, в сроках не уверены совсем. Пятый сдвиг лежит чуть в стороне от разработки: продвижение в AI и ответные машины меняют то, как заказчик вообще находит подрядчика.

Тренд 1: от управления сессиями к управлению задачами. Главный экран агентной среды становится доской задач, а не сеткой терминалов. Вы называете результат, система разбирает его на части, а терминал вы открываете, только когда что-то требует вас.

Тренд 2: среда выполнения отделяется от интерфейса. Тонкие клиенты, постоянные агенты на сервере, работа, которая продолжается после закрытия ноутбука. В выпущенных продуктах это уже сделано наполовину.

Тренд 3: браузер как общая площадка проверки. Обе стороны цикла: человек показывает на дефект, а агент доказывает, что сценарий работает. Это станет нормой, а не отличием.

Тренд 4: общение агентов между собой становится инфраструктурой. Сегодня любая серьёзная команда строит свою версию слоя координации сама. Через год это будет выглядеть как писать собственный клиент HTTP.

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

Глоссарий: термины из этой статьи

Простые определения терминов выше, все без привязки к поставщикам.

• Агентная среда разработки (ADE). Рабочее место, сделанное для запуска и согласования нескольких самостоятельных агентов-программистов, со встроенной изоляцией, общим контекстом, проверкой и приёмкой.
• Агентный редактор кода. Редактор, где ИИ может спланировать и выполнить многошаговую правку внутри одной сессии. Один агент, одна задача за раз.
• ИИ-агенты для разработки. Программы, которые читают задачу, решают, какие шаги делать, правят код и запускают команды, а не просто подсказывают текст.
• Оркестрация ИИ-агентов. Согласование работы нескольких агентов так, чтобы они делили работу, делились найденным и сводили результаты в одно изменение.
• Ведущий агент. Агент, который разбирает задачу, раздаёт роли, собирает результат и при необходимости передаёт вопрос человеку.
• Рабочая копия и изоляция. Отдельная копия репозитория, чтобы правки одного агента не мешали другому до проверки.
• Lane. Пакет всего, что нужно одной единице работы: рабочая копия, терминалы, контекст агента, порты, переменные окружения, история, набор изменений и состояние пул-реквеста.
• Контекстное окно. Объём текста, который модель держит перед глазами разом. Превысили - самое раннее выпадает.
• Кеширование промптов. Повторное использование уже обработанного фонового текста между шагами, чтобы долгие сессии стоили дешевле и стартовали быстрее.
• Длительные задачи для ИИ-агентов. Работа, которая идёт часами или через множество шагов, а не заканчивается за один обмен репликами.
• Мультиагентный процесс разработки. Заданная последовательность, где разные агенты занимаются планированием, реализацией, тестами и проверкой.
• Параллельные ИИ-агенты. Несколько агентов, которые одновременно работают над разными частями одной задачи.
• Запись архитектурного решения ADR. Короткий документ о том, что решили, что ещё рассматривали и почему.
• Перекрёстная проверка кода разными моделями. Когда код проверяет модель другого поставщика или другого семейства, чтобы у неё не было тех же слепых зон, что у автора.
• Человек в контуре принятия решений. Схема, где человек утверждает заданные шаги, особенно всё, что имеет эффект за пределами системы.
• Доказательство работы. Свидетельства, приложенные к изменению: результаты тестов, статус CI, прогон в браузере, снимки экрана и описание проверенного сценария.
• Проверка на уровне системы. Проверка результата через управление самой операционной системой, для продуктов, которые не сводятся к вебу.
• Удалённая среда выполнения. Репозитории, терминалы и агенты работают на сервере, а ноутбук или телефон служат пультом.
• MCP. Стандартный интерфейс, через который агенты единообразно подключаются к внешним инструментам и источникам данных.
• Точка согласования. Место, где работа стоит, пока конкретный человек её не утвердит.
• Минимум прав. Выдавать минимально необходимый доступ для работы и ничего сверх него.

На что смотреть при выборе компании по разработке ПО с ИИ

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

1. Как вы проверяете, что правка от агента действительно работает? Попросите пример с реального проекта.
2. Кто проверяет работу агента и независим ли проверяющий от исполнителя?
3. Какой доступ к нашему коду и данным есть у ваших агентов и чем он ограничен?
4. Что записывается в журналы и сколько хранится?
5. Кто именно отвечает за слияние в наши боевые системы?
6. Когда вы намеренно не применяете агентов? Дайте три конкретных примера.
7. Что происходит, когда агент ошибся и ошибка дошла до прода?

Шестой вопрос говорит больше всех. Команда, которая гоняла это в масштабе, даст конкретный список со шрамами. Команда, которая не гоняла, расскажет общее про важность контроля.

Что приносим мы: полный цикл работ для платформ B2B, систем ERP и CRM, интеграций и высоконагруженных сервисов - от исследования и проектирования интерфейсов через архитектуру, разработку, эксплуатацию и долгую поддержку, плюс встраивание ИИ и автоматизацию. В этот полный цикл входит и обычная разработка сайтов, а не только проекты с агентами. Мы делаем ПО с 2006 года и работаем в Германии, США и Восточной Европе. Наша позиция - инженерная зрелость, предсказуемость и надёжность. Дешёвым и быстрым вариантом мы себя не считаем и говорим об этом сразу.

Если вы планируете сложный проект по CRM, ERP, порталу, интеграции или ИИ-агентам, запишитесь на установочный созвон с Webdelo. Мы разберём ваш нынешний процесс, покажем, где работа агентов подходит, а где нет, и дадим конкретный план работ для Германии, США или Восточной Европы.

Заключение: почему инженерный процесс важнее названия модели

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

Пять вещей, которые мы бы оставили, если бы пришлось выбросить остальное:

• Единица работы поднялась на уровень выше, с файла до готовой функции. Всё остальное следует из этого сдвига.
• Данные честно двусторонние. На 55% быстрее на ограниченных задачах, на 19% медленнее на глубокой работе в зрелых системах. Подрядчик, который показывает только одну из этих цифр, продаёт.
• ИИ усиливает ту инженерную систему, которая у вас уже есть. Слабый процесс усиливается тоже, и быстрее.
• Управление, изоляция и доказательства работы - это то, что делает правки от агентов приемлемыми внутри крупной компании. Без них у вас есть скорость, которой нельзя пользоваться.
• Инструменты продолжат меняться. Процесс, дисциплина проверки и названный ответственный человек переживут следующий выпуск модели.

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

"Мы не меряем ИИ количеством сгенерированного кода. Нам важно, сколько проверенной работы доезжает до прода, не наращивая технический долг." - Андрей Попов, технический директор и основатель Webdelo

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