Implementation Loop в ИИ-разработке: наконец, появляется продукт!

Implementation Loop — это контур реализации в AI-native разработке, в котором ИИ-агенты превращают подготовленное человеком намерение и спецификацию в работающий программный результат. Если Discovery отвечает на вопрос «какую проблему нужно решить», а Intent Loop — «что именно должна делать система», то Implementation Loop отвечает на следующий вопрос: как реализовать это решение с помощью агентов, кода, тестов и инструментов разработки.

После выработки требований и создания спецификации начинается Implementation Loop — этап реализации [с помощью ИИ-агентов, конечно]. На выходе ожидается готовый ИТ-продукт.

Появление Implementation Loop связано с изменением самого процесса разработки. В традиционном SDLC основным исполнителем технических операций остается разработчик: он анализирует задачу, пишет код, запускает тесты, исправляет ошибки и подготавливает результат к поставке. В AI-native подходе значительную часть этих операций можно передать агентам. Человек при этом не исчезает из процесса, но его роль смещается от непосредственного исполнения к постановке задачи, управлению контекстом, контролю и принятию результата.

Для CIO и ИТ-руководителя это означает, что внедрение AI в разработку нельзя сводить к покупке AI-IDE или подключению корпоративной подписки на кодогенератор. Максимальный эффект возникает тогда, когда вокруг модели создается полноценная среда исполнения агента: инструменты, контекст, политики безопасности, автоматические проверки, наблюдаемость, маршрутизация задач и механизмы возврата результата человеку.

Что такое Implementation Loop

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

В модели AI-Disrupt PDLC Implementation Loop противопоставляется Intent Loop. В первом контуре человек работает с намерением, спецификацией и результатом, а во втором агенты выполняют техническую работу. Поэтому Implementation Loop можно рассматривать как своеобразный машинный конвейер реализации, который работает значительно быстрее человеческого контура.

Функция человека — определить намерение и принять результат. Функция агента — исполнить заданное намерение.

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

Поэтому зрелый Implementation Loop строится не вокруг одной модели, а вокруг harness — детерминированной инженерной среды, которая задает агенту доступные инструменты, контекст, разрешения и правила работы. В этом подходе модель становится одним из компонентов системы, а не всей системой целиком.

Расшифровка

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

Loop означает «цикл» или «петлю». Такое название принципиально: агент не просто генерирует код один раз. Он может выполнить последовательность действий — создать реализацию, проверить ее, обнаружить проблему, внести исправление и снова провести проверку.

Таким образом, Implementation Loop можно перевести как «петля реализации» или «цикл реализации». В англоязычной терминологии обычно сохраняется исходное название, поскольку оно связано с общей архитектурой AI-native SDLC.

Место в AI SDLC

В рассматриваемой модели AI SDLC разработка начинается с Discovery Loop, затем переходит в Intent Loop и только после этого — в Implementation Loop. Такое разделение позволяет не смешивать исследование проблемы, формулирование решения и его техническое исполнение.

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

Стадия	Основной участник	Главный вопрос	Результат
Discovery Loop	Человек + ИИ	Что на самом деле нужно решить?	Проблема, гипотезы, требования, ограничения
Intent Loop	Человек + ИИ	Что именно должна делать система?	Намерение, спецификация, критерии приемки
Implementation Loop	ИИ-агенты + человек	Как реализовать заданное?	Код, тесты, исправления, документация, работающий результат

Главное отличие Implementation Loop от традиционной разработки заключается в скорости и степени автоматизации итераций. Человек может формировать намерение в течение часов или дней, тогда как агент способен за минуты пройти несколько циклов генерации, запуска тестов и исправления кода.

Однако высокая скорость создает и новый риск. Если в Intent Loop была сформирована неправильная спецификация, Implementation Loop способен очень быстро произвести большое количество технически качественного, но ненужного результата. Поэтому скорость агентного контура имеет ценность только при наличии качественного человеческого контура.

Простыми словами

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

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

Вместо одного цикла «человек написал код → человек проверил» возникает цепочка «агент сделал → система проверила → агент исправил → система проверила снова». Человек подключается там, где требуется решение, которое нельзя безопасно или корректно автоматизировать.

Простой пример

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

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

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

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

Как работает: алгоритм и важные нюансы

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

В AI-разработке качество реализации определяется не только моделью, но и средой, в которой агент получает контекст, действует и проверяет результат.

Этап	Действие агента	Результат
1. Получение задачи	Чтение спецификации и критериев	Понимание задачи
2. Сбор контекста	Поиск кода, документации и данных	Рабочий контекст
3. Планирование	Разбиение задачи на действия	План реализации
4. Выполнение	Изменение кода и конфигурации	Новая реализация
5. Проверка	Запуск тестов и evals	Результаты проверки
6. Исправление	Анализ ошибок и повторная реализация	Исправленный результат
7. Передача результата	Формирование отчета и артефактов	Результат для человека
8. Возврат в Intent Loop	Обнаружение проблемы в постановке	Уточненная спецификация

Получение задачи

Первым шагом агент получает спецификацию, сформированную в Intent Loop. Она должна содержать не только функциональное требование, но и ограничения, критерии приемки и, при необходимости, архитектурные решения.

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

Сбор контекста

Затем агенту необходимо получить контекст, необходимый для выполнения работы. Это может быть существующий код, документация API, описание архитектуры, стандарты программирования, данные тестовой среды, настройки CI/CD и другие сведения.

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

Планирование

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

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

Выполнение

На этом этапе происходит непосредственная работа с программным продуктом: агент создает новый код, изменяет существующий, обновляет конфигурацию, документацию и тесты. В зависимости от архитектуры среды ему могут быть доступны IDE, терминал, репозиторий, системы сборки, базы данных и другие инструменты.

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

Проверка

После выполнения изменений агент запускает проверки. Это могут быть unit-тесты, интеграционные тесты, статический анализ, security scanning, линтеры, сборка приложения и специализированные evals.

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

Исправление

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

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

Передача результата

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

Человек при этом оценивает не только качество кода. Его главная задача — проверить, соответствует ли результат исходному намерению. Это возвращает нас к границе между Implementation Loop и Intent Loop.

Возврат в Intent Loop

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

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

Так возникает замкнутая система Discovery → Intent → Implementation → Validation → Intent. Ее цель — не максимально быстро производить код, а максимально быстро получать корректный бизнес-результат.

Инструменты

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

Основу такого контура составляют AI-IDE и coding agents, репозитории исходного кода, терминал, CI/CD, системы тестирования и статического анализа. В более зрелой архитектуре к ним добавляются Agent Runtime, маршрутизация инструментов, управление контекстом, observability, policy enforcement и механизмы управления правами.

Особое значение имеет harness — детерминированная инфраструктура вокруг модели. В рассмотренных источниках именно среда выполнения агента рассматривается как один из ключевых активов AI-native разработки. Модель может меняться, а правила доступа, контекст, инструменты, проверки и политики должны оставаться управляемыми внутри корпоративной среды.

Для CIO это означает необходимость смотреть на AI-разработку как на платформу, а не набор индивидуальных подписок разработчиков. Единая платформа позволяет централизовать безопасность, контекст, аудит, стоимость использования моделей, управление агентами и корпоративные стандарты.

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

Ошибки разработчиков

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

Считать модель главным компонентом системы

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

Для корпоративной системы критичны контекст, инструменты, permissions, тесты, маршрутизация, observability и policy enforcement. Сильная модель без качественной среды может давать менее предсказуемый результат, чем менее мощная модель, встроенная в хорошо спроектированный инженерный контур.

Давать агенту слишком широкие права

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

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

Пытаться контролировать каждый шаг вручную

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

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

Не управлять контекстом

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

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

Не учитывать стоимость агентных циклов

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

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

Автоматизировать реализацию без автоматизации проверки

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

Если агент генерирует код в десять раз быстрее, а проверять его по-прежнему приходится человеку, организация получает не полноценный AI-native SDLC, а ускоренный генератор очереди на ревью. Поэтому автоматические тесты, evals и контроль качества должны развиваться одновременно с агентной реализацией.

Не возвращаться к спецификации

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

Это приводит к бесконечному циклу технических исправлений. В зрелой архитектуре необходимо уметь остановить Implementation Loop и вернуться в Intent Loop, если проблема находится в намерении, а не в реализации.

Не учитывать каскадное поведение агентов

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

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

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

Для ИТ-руководителя главный вывод заключается в том, что внедрение Implementation Loop требует изменения не только инструментов разработчика, но и архитектуры всей среды разработки. Модель является лишь частью решения. Не менее важны контекст, harness, права доступа, автоматические проверки, observability, управление стоимостью и механизм возврата к Intent Loop.

Именно связка Discovery Loop → Intent Loop → Implementation Loop позволяет перейти от простого использования генеративного ИИ к AI-native SDLC. При этом человек не исчезает из разработки: его роль становится более концентрированной — определить, что нужно создать, принять архитектурные решения, задать критерии качества и убедиться, что быстро созданный машиной результат действительно решает бизнес-задачу.