Ключевые выводы

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

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

Главный дефицит — проверка. Генерировать изменения можно параллельно, а ответственность за их корректность остаётся у команды. Если скорость запросов на слияние растёт быстрее тестов, ревью и наблюдаемости, появляется долг проверки.

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

ИИ усиливает существующую инженерную систему. Исследование DORA описывает ИИ как усилитель: зрелая платформа и быстрые циклы обратной связи превращают его в ускорение; тесно связанная архитектура и слабые проверки — в дополнительную нестабильность.

От автодополнения к агентной разработке

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

Разница не только в длине задачи. У агента есть исполнительная поверхность: файловая система, командная оболочка, браузер, Git, CI, система учёта задач, иногда инфраструктура. Чем шире поверхность, тем ближе агент к новому участнику команды — и тем меньше подходит модель «поставили расширение и пользуемся».

Уровни автономности удобно различать так:

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

Разработка по наитию и агентная инженерия решают разные задачи

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

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

Агентная инженерия меняет единицу работы. Результат — не разница изменений, а пакет изменения:

• сформулированное намерение и границы;
• план с допущениями;
• минимальная разница изменений;
• выполненные проверки;
• известные риски и непроверенные области;
• способ отката или безопасного отключения.

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

Что говорят исследования — и чего они не доказывают

Разговор об ИИ-разработке страдает от двух крайностей: примеров поставщиков с огромной экономией времени и тезиса «ИИ всегда замедляет опытных разработчиков». Данные сложнее.

В рандомизированном исследовании METR 16 опытных участников выполнили 246 задач в знакомых им зрелых репозиториях с открытым кодом. С инструментами начала 2025 года они в среднем работали на 19% дольше, хотя после эксперимента считали, что ускорились на 20%. Это сильный сигнал о расхождении ощущения и измерения. Но это не универсальный коэффициент: выборка мала, участники были экспертами именно в своих кодовых базах, а модели и инструменты быстро меняются.

Отчёт DORA 2025, основанный почти на 5000 специалистах, показывает другой масштаб: внедрение ИИ коррелирует с ростом пропускной способности и продуктовых показателей, но всё ещё связано с ухудшением стабильности доставки. Вывод не «ИИ полезен» или «ИИ вреден», а ускорение обнаруживает слабости последующих частей системы.

Anthropic сообщает, что разработчики применяют ИИ примерно в 60% работы, но полностью делегируют лишь 0–20% задач. Это данные поставщика, их нельзя считать нейтральным аудитом; однако они хорошо иллюстрируют практическое различие между использованием инструмента и передачей ответственности.

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

Контекстная инженерия: что агент должен знать

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

Контекст состоит из четырёх слоёв.

Постоянные правила

Короткий AGENTS.md, правило проекта или навык: стек, запрещённые действия, команды тестов, принципы архитектуры, требования к ответу. Это не энциклопедия репозитория. Десятки страниц постоянных инструкций съедают окно и размывают приоритеты.

Контекст задачи

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

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

Поиск по коду, документация, схемы БД, ADR, журналы, API через протокол контекста моделей. Свежий гайд по этому протоколу в промышленной среде объясняет, как давать агентам инструменты без скрытых сеансов и теневых интеграций.

Обратная связь среды

Компилятор, тесты, линтер, сканер безопасности, предварительный просмотр, метрики. Это самый ценный контекст: не мнение, а наблюдаемое последствие изменения.

Правило простое: статически передавайте неизменные ограничения, динамически находите детали, исполняемо проверяйте поведение.

Декомпозиция задач для агента

Плохая задача: «перепиши авторизацию, улучши архитектуру и добавь тесты». Она смешивает исследование, дизайн, миграцию и реализацию; критерий завершения отсутствует.

Хорошая задача укладывается в один проверяемый инкремент:

1. Цель в терминах поведения пользователя или системы.
2. Разрешённые каталоги и интерфейсы.
3. Неизменяемые контракты.
4. Команды проверки.
5. Условия эскалации.

Для долгих работ полезна схема исследование → план → реализация → верификация. Не потому, что модель обязана «думать вслух», а потому, что этапы дают человеку дешёвые точки остановки. Ошибочный план дешевле отменить до изменений в двадцати файлах.

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

Когда агент должен остановиться

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

Циклы проверки: тесты важнее красноречия

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

Хороший цикл проверки:

1. Выполняется автоматически.
2. Даёт локализованную ошибку.
3. Проверяет требование, а не только синтаксис.
4. Имеет ограничение по времени и числу попыток.
5. Не позволяет «исправить тест», если тест и есть контракт.

Иерархия доказательств зависит от задачи:

• проверка типов и линтер ловят структурные дефекты;
• модульный тест подтверждает локальную логику;
• интеграционный тест проверяет границы;
• сквозной тест или проверка в браузере — пользовательский сценарий;
• сканирование безопасности — известные классы угроз;
• наблюдение метрик после канареечного выпуска — реальное поведение.

Нельзя требовать «все проверки» для каждого изменения: цикл станет дорогим и агент начнёт ждать CI дольше, чем работать. Нужна матрица на основе риска. Изменение текста требует сборки и краткой визуальной проверки; миграция данных — резервных копий, пробного запуска, интеграционной проверки и репетиции отката.

Долг проверки: новый вид технического долга

Долг проверки возникает, когда объём сгенерированных изменений превышает способность команды доказать их корректность. Он проявляется не только непроверенными запросами на слияние.

Сигналы:

• PR становятся больше, потому что генерировать «ещё немного» дёшево;
• тесты написаны той же моделью и повторяют её предположение;
• проверяющие читают сводки вместо разницы изменений;
• зелёный CI проверяет только успешный сценарий;
• документация и архитектурные решения расходятся с кодом;
• скорость слияния растёт, а число откатов и срочных исправлений — тоже.

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

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

Один агент или несколько

Многоагентная оркестрация оправдана не модой, а структурой работы.

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

Несколько агентов полезны, когда:

• части задачи действительно независимы;
• исследование можно распараллелить по подсистемам;
• проверяющий получает другой набор инструментов;
• есть формальный контракт между результатами;
• интегратор отвечает за общий итог.

Рабочая схема:

Пять ролей не означают пять моделей в каждом тикете. Это логическое разделение ответственности; для простой задачи один агент может проходить этапы последовательно.

Безопасность: права агента равны потенциальному ущербу

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

Минимальная модель безопасности:

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

Контейнер — не абсолютная граница. Для недоверенного кода надёжнее микровиртуальная машина или специализированная песочница. Детали разобраны в статье о безопасности песочниц для агентного ИИ.

Безопасность должна быть непрерывной: разрешение на чтение репозитория не означает разрешения на публикацию пакета; доступ к промежуточной среде не означает доступа к промышленной. Проверяйте полномочия при каждом чувствительном действии.

Как встроить агентов в жизненный цикл разработки

Не добавляйте «шаг с ИИ» поверх старого процесса. Посмотрите на поток целиком.

Исследование и планирование

Агент собирает связанные задачи, находит код и ADR, формирует вопросы. Человек утверждает объём и компромиссы.

Реализация

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

Проверка

Автоматические проверки создают доказательства; обзор от ИИ ищет классы проблем; владелец подсистемы принимает архитектурное решение. Сводка не заменяет разницу изменений.

Поставка

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

Обучение

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

Практики сильных команд подробнее собраны в разборе внедрения ИИ в жизненный цикл разработки.

Метрики: как понять, что агентная разработка работает

Количество инструкций модели, токенов и строк кода — операционные данные, но не ценность. Нужны три слоя.

Поток

• Полное время от принятой задачи до промышленной среды.
• Время цикла от начала реализации до проверенного запроса на слияние.
• Размер пакета изменений и число параллельных задач.
• Время ожидания проверки и CI.

Качество

• Частота неудачных изменений.
• Доля откатов и срочных исправлений.
• Дефекты после релиза.
• Переделки: сколько изменений от ИИ существенно переписано человеком.
• Покрытие требований исполняемыми проверками.

Экономика и опыт

• Стоимость запуска агента, CI и проверки.
• Время старшего разработчика на постановку и проверку.
• Доля задач, где агент остановился корректно.
• Удовлетворённость разработчиков без подмены объективных метрик.

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

Как меняется роль разработчика

Роль не сводится к «промпт-инженеру». Чем дешевле синтаксис, тем дороже:

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

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

Старший разработчик перестаёт быть самым быстрым автором кода и становится владельцем системы производства изменений. Это согласуется с карьерной логикой из карты развития Go-разработчика от начального до старшего уровня: уровень определяется зоной ответственности, а не количеством знакомых инструментов.

План внедрения на 90 дней

Дни 1–30: измеряемый пилот

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

Дни 31–60: контур качества

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

Дни 61–90: масштабирование

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

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

Типичные ошибки

Купить лицензии и назвать это трансформацией. Инструмент без процесса усиливает текущие узкие места.

Максимизировать автономность с первого дня. Сначала узкий контур чтения и записи с доказательствами, затем расширение.

Загрузить весь репозиторий в контекст. Поиск по требованию дешевле и точнее.

Доверить одной модели генерацию, тесты и ревью. Одинаковое допущение проходит все три слоя.

Измерять внедрение вместо результата. 90% активных пользователей ничего не говорят о стабильности.

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

Запретить ИИ полностью из-за риска. Теневое использование останется, но без песочницы, политики и аудита.

Частые вопросы

Дальнейшее чтение

• Новый жизненный цикл разработки: разработка по наитию и агентная инженерия
• Как сильные команды внедряют ИИ в разработку
• Протокол контекста моделей в промышленной эксплуатации в 2026 году
• Безопасность песочницы для агентного ИИ
• Безопасная разработка корпоративного ИИ
• Наблюдаемость корпоративного ИИ
• Путь Go-разработчика от начального до старшего уровня

Внешние источники: отчёт Google 2025 года о разработке программного обеспечения с помощью ИИ, исследование влияния ИИ начала 2025 года на производительность опытных разработчиков открытого кода, Anthropic — восемь тенденций, определяющих разработку программного обеспечения в 2026 году.

Заключение

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

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

Нужно внедрить у себя?

Если нужен продакшен-срез — RAG, агенты, инструменты Model Context Protocol или LLM-шлюз с бюджетами — см. услугу внедрения ИИ.