AI-агент — это не просто генератор кода, это автономный инженер. Но только если вы дадите ему «глаза»."

Posted on Feb 23, 2026

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

Мы работаем с dotnet, и проблема решается просто. Я перестроил работы с кусочной автоматизация, но полный автономный контур разработки:

  • Создал docker-файлы для сборки проектов-микросервисов, в настроить все linters (all warnings as error), dotnet format, dotnet test и прочие
  • Создал docker-compose для запуска всех сервисов, включая инфраструктуру (база данных, брокер сообщений и т.д.)
  • В код добавил opentelemetry и настроил сборку метрик и трасировок
  • В docker-compose добавил Jaeger для визуализации трасировок и Prometheus для сбора метрик
  • создал smoke-тестов для проверке core функциональности, которые запускаются при сборки образов и при запуске контейнеров

Теперь агент может работать в режиме автономного инженера разработчика и вести полный цикл разработки:

  • изменение кода
  • проверки линтерами, статический анализ и прочие
  • тестирование регрессии стандартной функциональности и поиска проблемы в конкретном случае
  • чтение логов и docker-контейнеров, мониторинг метрик и трасировок для поиска проблем, если у нас появился регресс или мы хотим проверить, как работает новая фича

Промпт в целом будет следующим:

1. Спланирую изменения по новой фиче
...
2. Спланирую e2e-тесты для проверки новой фичи
3. Внеси изменения в код
4. Собери новый docker-образ
5. Перезапусти тестовое окружение
6. Запусти тесты
7. Проверь работу новой фичи через e2e-тесты, логи, метрики и трасировки

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

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

При использовании MS GitHub Copilot Chat это будет один premium-запрос, а не 10 на выполнение каждого шага отдельно, и плюс больший шанс, что агент выполнит всю фичу в рамках одного запроса.

Цикл разработки становится более эффективным и быстрым.

Но что делать, если у нас нет такой возможности? Например, мы пишем CI/CD пайплайн. Цикл: правим yaml-файлы, пушим код, ждём, пока запустится пайплайн, и проверяем результат. Если ошибка, то нужно идти в пайплайн, смотреть логи, копировать их в чат и просить агента помочь найти проблему. И повторять. Тогда разработка вместо того, чтобы идти 10-20 минут, может занимать 30-40 минут, а то и больше. Это неэффективно.

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

Приведу пример: у меня была задача внедрения автодокументирования SQL-кода. Процесс находится в pipeline Azure DevOps Server 2022 :

  • на Azure DevOps agent запущен инстанс MS SQL Server Windows окружения для сборки и тестирования
  • в рамках пайплайна запускается скрипт, собирает базу, делает некоторое интеграционное тестирование
  • после тестирования мы запускаем скрипт наполнения документации базы данных
  • далее нужно добавить шаги, которые с помощью утилиты tbls и PowerShell проверяем покрытие ключевых таблиц и сгенерируют документацию для артифактов сборки

Агент написал изменения в pipeline за 30 секунд, но проверка его через pipeline займёт 25-30 минут. Далее проблема выкачивания логов, копирования вывода системы в чат агента для обратной связи и повторения цикла. Это неэффективно. Первичная идея «давайте меняем ручные операции на использование azure devops cli» не сработала: да, её можно направить на on-prem сервер, но в ней нет возможности получить логи конкретных сборок и их шагов. Да, можно написать PowerShell-скрипт, который будет использовать API Azure DevOps для получения логов, но опять цикл обратной связи будет занимать 30 минут, работа даже в фоновом автономном режиме будет занимать рабочий день.

MS SQL Server в Docker использовать нельзя, так как в сборке есть unsafe CLR, и работа PowerShell под macOS отличается от работы под Windows.

Меняем среду:

  • в среде разработки есть MS SQL Server для e2e-тестов, настраиваемся на его использование
  • запускаем скрипт PowerShell не локально, а через Invoke-Command -ComputerName devSQL -ScriptBlock ‘…’. Если нет возможности работы через внешнюю виртуальную машину, то запускаем её локально под macOS (есть сборки Windows 10 ARM64, но нет MS SQL server для ARM64)
  • запускаем сессию агента, который проверяет работу tbls и PowerShell на внешней Windows-машине, подключаясь к тестовому серверу, реализуя по факту полное поведение Azure DevOps pipeline
  • 4+ круга изменений и тестирования по 1 минуте и мы решили проблему Итого: смена среды и обёртка над существующими скриптами, написание через агента заняло 10 минут, исправления кода ещё 5 минут, а не день работы.

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