ИИ-агенты программирования могут помогать командам разработчиков решать архитектурные проблемы, выходящие за рамки простой написания кода, однако их польза зависит от ясности целей и ограничений, заданных командой. В статье, опубликованной в InfoQ, авторами которой являются Pierre Pureur, Kurt Bittner и Todd Miller, а рецензентом — Daniel Bryant, предупреждается, что предоставление агенту только функциональных требований не гарантирует масштабируемую, безопасную или удобную в сопровождении архитектуру.
Предлагаемый подход опирается на требования к атрибутам качества (Quality Attribute Requirements, или QARs), такие как производительность, безопасность и масштабируемость, а также на разъяснение компромиссов, которые агент должен учитывать. В статье также подчёркивается необходимость проверять результаты работы агента с помощью чётких измерений, а не ограничиваться проверкой кода или доверием к его рекомендациям.
1. Документирование устаревших сервисов перед их использованием
Современная архитектура может зависеть от устаревшего сервиса, выполняющего определённую функцию, например извлечение данных страховых документов из устаревшей системы на базе базы данных IMS. Проблема заключается в том, что у таких сервисов может отсутствовать точная документация, из-за чего трудно понять потоки данных или обнаружить логические и уязвимости системы безопасности, которые могут проявиться на поздних этапах разработки или после перехода в эксплуатацию.
Агент может построить схему сервиса и задокументировать потоки данных, а затем проверить код и предложить исправления или рефакторинг, если сервис трудно понимать и сопровождать. Однако это не отменяет необходимости в принятии человеком инженерного решения о том, можно ли сохранить сервис или связанные с ним риски требуют его замены.
2. Поиск архитектурных дефектов
Агенту можно поручить поиск нарушений архитектурных стандартов, деградировавших практик разработки или частей, требующих рефакторинга. Примеры проверок включают проектирование API, сложные, небезопасные или неэффективные интерфейсы, а также нарушения границ предметно-ориентированного проектирования (DDD).
В статье отмечается, что агент, скорее всего, найдёт множество улучшений, поэтому команда должна отличать важные проблемы от предложений с низкой ценностью. Качество результатов повышается, когда инженеры определяют измеримые цели, известные альтернативы и чёткие компромиссы, а не ограничиваются описанием требуемых функций.
3. Аудит безопасности с изоляцией агента
Агента можно использовать для построения потоков данных, определения файлов высокого риска, проверки сложных логических дефектов, создания тестов или сценариев, имитирующих попытки эксплуатации, а затем предложения исправлений для обнаруженных проблем. В статье описывается эксперимент с пакетами npm, классифицированными как представляющие угрозу безопасности: два пакета были обновлены, один заменён, а ещё один оставлен после того, как предупреждение было признано ложным срабатыванием.
Однако такое использование требует чётких эксплуатационных ограничений: ограничить доступ агента утверждёнными файлами, скрыть пароли баз данных и секреты, запускать тесты в изолированной сети и требовать проверки человеком перед интеграцией любых изменений.
4. Создание архитектурной основы для прототипов
Скорость работы агентов позволяет быстро создавать прототип, однако полученная модель может быть временной и непригодной, если для неё не определены архитектурные цели. В статье предлагается подготавливать структурные шаблоны приложений, включающие стиль написания кода, проектирование базы данных, интерфейсы, предпочитаемые платформы и фреймворки, а также QARs, записанные в формате Markdown.
Также можно использовать шаблоны GitHub для унификации начальной структуры приложений и включения стандартов команды с самого начала. Лучше описывать цель, ограничения и способ проверки их выполнения, а не заранее навязывать агенту детализированное решение.
5. Генерация первоначальных тестируемых архитектур
В статье предлагается использовать агента для создания Minimum Viable Architectures, или MVAs, которые не ограничиваются кодом, демонстрирующим работу функций, а также включают тесты, тестовые данные и среду выполнения, необходимые для проверки QARs. Агент может генерировать инструменты тестирования и конфигурации контейнеров, однако команда должна убедиться, что тесты действительно измеряют требуемые атрибуты.
Также следует оценивать способность MVA поддерживать сценарии архитектурных изменений, поскольку расширение архитектуры, сгенерированной автоматически, может оказаться дорогостоящим, если она не спроектирована для развития.
Что меняется на практике?
Основная мысль статьи заключается в том, что агенты программирования ускоряют создание кода, но повышают важность формулирования требований, ограничений и тестов. Навыки, связанные с написанием кода, не исчезают, однако определение того, что именно нужно построить, что считается приемлемым качеством и как оно будет измеряться, становится более критичным. Поэтому к агенту следует относиться как к инструменту, находящемуся под архитектурным контролем, а не как к замене инженерного суждения.