Агентное инженерное дело становится все более популярным термином в области искусственного интеллекта и программирования. Оно связано с использованием больших языковых моделей (LLM) для автоматизации сложных процессов в разработке программного обеспечения. Однако реальность работы с такими инструментами часто далека от идеала — попытки заставить ИИ работать в больших и сложных проектах нередко приводят к хаосу и потере контроля. Один из ключевых выводов последних исследований и практик — промпты (подсказки), которые мы передаем моделям, по сути, являются кодом, а .json и .
md файлы служат хранилищем состояния наших программных агентов. Понимание этой метафоры открывает путь к более структурированному и инженерному подходу к решению задач с помощью ИИ. Сам термин «агентная инженерия» часто звучит громко, но на деле многие пытаются «на удачу» использовать ИИ, не понимая глубины проблемы и не имея четкой методологии. Большинство инструментов отлично справляется с быстрыми задачами или новыми маленькими проектами, но при работе с устоявшимися большими кодовыми базами испытывает серьезные трудности. Главной проблемой здесь является контекст.
Модели ограничены объемом информации, которую они могут одновременно учитывать, а большие многокомпонентные системы требуют понимания взаимосвязей, последовательности исполнения и архитектуры. Даже первые шаги в решении этой проблемы — «продуманное мышление шаг за шагом» — оказываются недостаточными для отслеживания сложных сценариев, таких как параллельные процессы, обмен сообщениями между частями приложения, или многопоточность. Эта ограниченность приводит к созданию кода, который часто противоречит архитектурным решениям, принятým в проекте. Дополнительно, модели создают средний статистический продукт, основанный на данных из интернета, что проявляется в генерировании излишне сложных и негибких решений. В отличие от опытных инженеров, которые стремятся к минимализму и элегантности, ИИ часто превращает «лучшие практики» в избыточные конструкции, которые сложно поддерживать и которые могут быть источником ошибок.
Еще один вызов — деградация контекста по мере нарастания объема обрабатываемых данных в сессии. Когда количество вводимых токенов достигает сотен тысяч, качество понимания резко падает. Компании, создающие инструменты на основе ИИ, часто ограничивают контекст пользовательских запросов, чтобы сократить издержки на оплату токенов моделей, что еще больше усугубляет проблему. На фоне этих ограничений стоит выделить особую позицию Claude Code от компании Anthropic. Этот инструмент предоставляет практически неограниченный контекст при использовании премиального тарифа, что позволяет работать с большими проектами более эффективно.
Тем не менее, и здесь пользователи сталкиваются с проблемами ограниченного контроля над системным сообщением, дополнительными инструкциями и не всегда прозрачной интеграцией с редактором кода. Всё это показывает, что истинным прорывом в agentic engineering может стать не сам ИИ, а подход к организации и структурированию взаимодействия с ним. Достижение повторяемости, детерминированности и точности в работе с агентами зависит от способности разработчиков мыслить в терминах системного программирования, понимая LLM не как непредсказуемого собеседника, а как очень медленный, но программируемый компьютер. Такой сдвиг меняет разговор с AI на инженерную задачу: промпты становятся кодом — они задают поведение и «логику» агента, а .json и .
md файлы выступают хранилищем состояния и данных, которые можно сериализовать, сохранять, загружать и обновлять в ходе работы. Это позволяет снимать ограничение на контекст, делая процесс более управляемым и воспроизводимым. На практике применение такой модели показано на примере портирования рентаймов анимационного движка Spine с Java на другие языки, включая C++ и C#. Это очень трудоемкая задача, связанная с поддержкой идентичного функционала на разных платформах. Использование агентного программирования с продуманным управлением состоянием позволило значительно сократить время и снизить количество ошибок.
Отдельное внимание уделяется функции генерации планов портирования, которая предобрабатывает изменения между ветками Git, извлекает информацию о типах и зависимости, и формирует структурированный JSON-файл с состоянием всего процесса. Это избавляет LLM от необходимости самостоятельно сканировать кодовую базу и строить сложную логику, экономит ресурсы и избавляет процесс от случайностей. Программирование такого агента практически напоминает написание классической программы: инициализация с загрузкой необходимых данных, импорт функций (например, для открытия файлов и просмотра диффов), анализ и применение изменений, взаимодействие с пользователем для принятия решений и обновление состояния, сохраненного на диске. При этом весь процесс разбит на детерминированные блоки с возможностью приостановить и возобновить работу без потери позиции. Такой подход позволяет преодолеть основные ограничения работы с LLM — небольшое окно контекста, отсутствие устойчивого состояния, сложность контроля и масштабирования логики.
