В агентскую эпоху не все архитектуры кода одинаково полезны

Дебаты, касающиеся программирования с применением агентов, в основном касаются подбора инструментария — какую IDE, какую модель, какой CLI использовать и т.д. Гораздо меньше внимания ^[1] уделяется более интересному вопросу: а сохраняет ли в таких условиях актуальность сам подход к структурированию кода, которому нас учили, если у той штуки, которая теперь пишет код, ограничена долговременная память ^[2], а также ограничено контекстное окно? Более того, агент зачастую должен добиваться прогресса по задаче, не имея «перед глазами» всей системы.

Ниже проанализированы различные архитектуры кода — TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение ^[3] (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.

Четыре действительно важных свойства

Прежде, чем что-либо ранжировать, давайте определим, что именно понимается под «агенто-ориентированным» (agent-friendly) свойством. По опыту ^[4] многочисленных сеансов работы с агентами и размышлений об этом, я сформулировал четыре свойства, через которые можно объяснить большинство наблюдаемых исходов.

Может ли агент локально судить о фрагменте кода?

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

Может ли агент механически проверять собственную работу?

При TDD мы получаем двоичный сигнал: зелёный/красный. Для качественного ООП требуется своеобразный вкус ^[5], нарабатываемый за годы чтения и написания кода. Понимание, когда предпочесть наследование, а когда композицию, насколько углублять иерархию, какой уровень абстракции приемлем в данном случае и т.д. Агенты не могут как следует справляться с подобными архитектурными суждениями, поскольку просто ориентируются на учебные данные как на шаблон для подстановки, а в учебных данных полно примеров ужасного ООП.

Поток управления явный или неявный?

Архитектура MVC устроена явно – запрос отправляется по маршруту, контроллер вызывает сервис, а сервис возвращает данные. Событийно-ориентированная архитектура устроена неявно — сначала публикуется событие, а затем где-то ещё какая-то другая сущность его обрабатывает. Единственный способ узнать, что это за сущность — прошерстить все файлы в поисках подписчиков. Агенты могут придерживаться явного потока управления как рецепта. При неявном потоке управления производительность агентов обычно снижается по той же причине, по которой неявный поток управления напрягает джунов: слишком велика доля важного поведения ^[6], остающаяся за пределами экрана.

Каково соотношение реальной логики к стереотипному коду?

Функциональный конвейер — это почти чистый сигнал. Полная реализация DDD с агрегатами, объектами значений, событиями предметной области, репозиториями и ограниченными контекстами может на 80% состоять из ритуалов, лишь после которых вы напишете первую строку осмысленной логики. Чем больше таких ритуалов, тем затратнее становится вносить изменения, когда контекст ограничен. В любой строке скаффолда агент может привнести неочевидный баг, причём, любая строка отъедает контекст — даже бесполезная.

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

Сорт S: лучшие из всех

TDD

Самое то. Если вы усвоите из этого поста что-то одно, пусть это будет: надо использовать TDD с программирующими агентами.

Ключевая слабость агента — эпистемологическая: он генерирует код, который выглядит корректно, но не предусмотрен механизм, чтобы это проверить. Применительно к TDD эта задача превращается из генерации случайных данных, соответствующих наиболее распространённым результатам, в итерационный процесс. Напишите тест (написать тест — означает всего лишь перезапустить спецификацию в исполняемой форме), запустите его. Увидите красный — напишите минимальную реализацию, которая проходит тест и даёт зелёный. На каждом шаге агент получает конкретный механический сигнал.

Единственная проблема с данным подходом заключается в том, насколько сложно решать крупные задачи без обучения ^[7]. В таких случаях агенты склонны «жульничать» на тестах. Если такое происходит — то явно свидетельствует, что либо агенту не хватает контекста, либо задача слишком сложна, и агент по какой-то причине не может с ней справиться. 

Но настоящий гвоздь программы здесь заключается в том, что набор тестов подобен внешнему блоку памяти ^[8]. Агент совершенно не в состоянии «припомнить», что именно он собрал три сеанса назад. Но тесты от этих сеансов у вас остались и по-прежнему выполнимы. Каждое новое изменение проверяется по всем уже существующим тестам. Агент получает механизм автоматического обнаружения регрессии в коде, на написание которого у него нет собственной памяти.

TDD также обеспечивает такую вещь, которую я бы назвал уверенной компонуемостью. Агент мождет написать функцию B на базе функции A, не перечитывая реализацию A, так как тесты, которыми покрыта A, гарантируют соблюдение её контракта. До тех пор, пока эти тесты проходят — A работает. Агенту необходимо знать лишь интерфейс A, а не её внутреннее устройство. Это свойство масштабируется: чем больше проект, тем полезнее в нём TDD, тогда как с большинством агентских парадигм складывается прямо противоположная ситуация.

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

Функциональное программирование

У чистых функций есть одно свойство, которое обладает для агентов почти универсальной ценностью: локальная корректность становится гораздо более значимой, если в коде нет скрытого состояния. Если transformOrder(order) возвращает правильный вывод в ответ на правильные варианты ввода — то с этой функцией всё в порядке. Нет никакой разделяемой переменной, которую какая-то другая функция могла бы изменить незаметно для вас, никакого жуткого дальнодействия или срабатывания на расстоянии. Агенту не требуется удерживать в контексте всю базу кода, чтобы проверить её маленький фрагмент.

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

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

На практике есть нюанс: чисто функциональный стиль можно применять не во всякой предметной области. Очевидно, вам понадобится ввод/вывод, понадобится состояние, где-то понадобятся побочные эффекты. Фокус в том, чтобы продвинуть функциональное программирование в максимальном разумном объёме — чистая логика ^[9] предметной области, неизменяемые преобразования данных, конвейеры для компоновки, пр. — а на периферии системы оставить не столь чистые элементы.

BDD

“Допустим, есть пользователь, у которого истекла подписка. Когда он пытается открыть премиум-контент, ему нужно вывести предложение обновить подписку.”

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

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

Сочетание спецификаций BDD и выполнения в стиле TDD — это самая топовая известная мне конфигурация нового проекта, который предполагается писать с применением агентов.

Сорт А: хорошие варианты с небольшими шероховатостями

Гексагональная архитектура (порты и адаптеры)

Ключевое правило: все зависимости поступают внутрь системы через определённые интерфейсы. В логике предметной области ровно ничего не заложено о базах данных, HTTP или файловых системах. Таким образом, агент может написать уровень предметной области в виде чистых функций — практически сорт S – а затем независимо подключить к нему адаптеры.

Каждый адаптер — это самодостаточная единица. Чтобы написать адаптер для PostgreSQL, нужно знать как интерфейс порта, так и PostgreSQL. Для этого не требуется понимать адаптер HTTP, логику предметной области или какой-либо другой адаптер. В контекстном окне агента должны содержаться только интерфейс порта и конкретная технология, к которой он приспосабливается.

Отнести эту технологию к сорту S не получается из-за следующей шероховатости: агенту требуется заранее понять архитектуру. Если не сообщить агенту: «мы используем гексагональную архитектуру, логика предметной области лежит в /core, порты и интерфейсы в /ports, адаптеры реализуют эти интерфейсы в /adapters», то он ничтоже сумняшеся замешает запросы к базе данных в логику вашей      предметной области. Навязать соблюдение правил в данном случае становится гораздо проще, если написать хороший CLAUDE.md ^[10] или системный промпт.

MVC

MVC попадает в категорию A не благодаря своему теоретическому совершенству, а по причине доступности огромного массива данных для обучения volume. Все руководства по фреймворкам, всевозможные ответы на вопросы, размещённые на Stack Overflow, а также во всех проектах из разряда «курс молодого бойца» используется MVC. В принципе, ИИ-агенты уже видели больше кода в парадигме MVC, чем любой человек успел бы прочитать в течение всей жизни.

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

Притом, что «потолок» у  MVC ниже, чем в гексагональной архитектуре – поскольку MVC допускает существование бизнес-логики внутри контроллеров, когда для неё требуется найти альтернативное место — агенты обычно ориентируются в MVC лучше, чем в других паттернах, которые могут содержать уровень абстрагирования или несколько других уровней косвенности. Агенты понимают, что где лежит. Конечно, создаваемый ими код редко получается красивым, зато он хорошо работает и удобен в отладке. Разработчик из вашей команды сможет понять, как работать с этим кодом, и ему даже не придётся обращаться за справкой к информации, накопленной в ходе предыдущего сеанса.

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

Сорт B: хорошие варианты, требующие серьёзных компромиссов

CQRS

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

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

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

ООП

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

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

Как подсказывает мой опыт, агенты обычно перебарщивают с наследованием, склонны создавать god-объекты и многоуровневую иерархию. Когда вы просите агента «пользоваться наилучшими практиками ООП», в ответ вы зачастую получаете средненький код в стиле ООП. Примерно такой, как содержался в учебном датасете, который дали этому агенту. Как правило, такой код довольно плох. 

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

Сорт C: явно ограничивают сильные стороны агента

MVVM

Паттерн MVVM привносит сразу два аспекта, с которыми агенты справляются не без труда: реактивная привязка данных и неявные обновления состояния. Когда свойства ViewModel меняются, словно по волшебству запускается обновление представления. Но из-за привязки к каким именно данным сработало это обновление? Какое значение имеет порядок привязок? Возможен ли цикл обновлений, включающий две или более привязок?

Эти баги — как раз из таких, которые никак не проявляются в вашем коде до тех пор, пока вы явно не провзаимодействуете с UI во время выполнения, то есть, не совершите в пользовательском интерфейсе конкретную последовательность действий. Разработчик может писать код в стиле MVVM при помощи агентской модели, и у него получится, казалось бы, идеально спроектированная система ( ViewModel чиста, все инструкции о привязках, кажется, работают, т.д.). А затем окажется, что приложение вылетает из-за тонкого нюанса в порядке следования операций или из-за того, насколько реактивно обработчики подписываются на события.

Ключевую проблему здесь представляет неявный поток управления. Агент не может прочитать ViewModel и понять, что произойдёт при изменении свойства, если не будет понимать каждую привязку во всех представлениях, ссылающихся на это свойство. Это глобальные рассуждения, с которыми агенты справляются стабильно плохо.

Событийно-ориентированная архитектура

С ней возникают примерно такие же проблемы, как и с MVVM, но в большем объёме. Когда приложение публикует событие, вы не можете только лишь по коду публикации события судить, сколько именно подписчиков станет его слушать (и даже какого они типа). Для отладки событийно-ориентированной системы требуется знать обо всех подписчиках в масштабах всей системы. Агент пишет публикатора и подписчика в отрыве друг от друга и при этом корректно, но его код откажет, если события станут поступать в неправильной последовательности. Обработчик может делать допущения о состоянии других обработчиков, которые пока даже не сформированы.

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

Разумеется, если агент уже писал конкретные обработчики событий для существующих систем или работал с такими компонентами, то у него «есть опыт» локального суждения об ограниченном объёме кода. Но самые серьёзные риски при первичном проектировании новой событийно-ориентированной системы возникают в случаях, когда от агента требуется как создать топологию событий, так и определить верные гарантии упорядочивания этих событий на случаи, когда предполагается конкурентная обработка этих событий.

Сорт D: фундаментально несовместимы с агентным программированием, когда агент специально не обучался работе с ними

DDD

DDD (предметно-ориентированное проектирование) — это в равной степени и процесс коллаборативного моделирования предметной области, и набор паттернов, действующих на уровне кода. Вся суть методологии заключается в выработке ^[11] «единого языка», на котором в ходе итеративного обсуждения проекта общаются разработчики и эксперты-предметники. Этому способствуют и event storming («штурм событий»), и картирование ограниченных контекстов, и выявление корня агрегатов. Это сугубо человеческие занятия, требующие глубокого ориентирования в предмете и обширной совместной работы.

ИИ-агент не в состоянии проконсультироваться с экспертом-предметникром. Он не понимает, что «Account» означает разные сущности в ограниченных контекстах «биллинг» и «аутентификация пользователя». Без обширных знаний в предметной области, которыми агента можно было бы напитать через подробные промпты, агенты, практикующие DDD, как правило, создают поверхностные модели. У них получаются агрегаты и объекты значений с исправно соблюдёнными соглашениями об именованиях, но при этом неверно разграниченные. Пожалуй, это вреднее, чем полное отсутствие DDD, поскольку такая система создаёт ложное ощущение строгости. Код выглядит так, как будто его писал человек, действительно разбирающийся в предметной области.

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

Кроме того, «ритуальная» составляющая обходится жутко дорого. В полноценной реализации DDD доля стереотипного кода колоссально выше, чем объём кода, в котором программируется сама бизнес-логика. Приходится тратить контекстное окно на каждую строку стереотипного кода, и в каждой такой строке агент может привнести малозаметные структурные ошибки ^[12].

Микросервисы

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

Если приказать агенту создать микросервисную архитектуру с нуля, то у него получится множество разрозненных сервисов, для каждого из которых потребуется отдельно сконфигурировать развёртывание, предусмотреть механизм обнаружения сервисов, межсервисную коммуникацию (какой механизм выберем — HTTP? gRPC? очереди сообщений? – агент вполне может взять один и смешать его с другим), распределённую трассировку, обработку согласованности в конечном счёте, а также инфраструктурный слой. По сравнению со всем этим сама бизнес-логика получится крошечной.

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

Основополагающие принципы работы с микросервисами — это независимая разработка и развёртывание (масштабирование). Эти принципы призваны позволить командам разработчиков независимо решать свои задачи, чтобы каждая команда могла действовать в своём темпе. Кроме того, такой подход обеспечивает изоляцию отказов и позволяет командам независимо друг от друга развёртывать новые версии приложений. У вашего нового приложения — ни одного пользователя. Следовательно, никакие из заложенных в него принципов пока не доказаны и не продемонстрированы. А значит, вам придётся столкнуться со всем тем ворохом издержек, которые возникают в первый день эксплуатации новоиспечённой распределённой системы. Возможно, вам так и не доведётся осознать потенциальную пользу от применения микросервисов в этой системе.

Баллы расставлены на основе эвристических суждений «по четырём осям», а не на эмпирическом изучении каких-либо бенчмарков.

Идеальный стек для работы с агентами

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

Ядро проекта написал в парадигме функционального программирования с применением TDD. Логика предметной области пишется в виде чистых функций и тестируется исчерпывающим образом. Каждое правило бизнес-логики — это функция (на вход получает параметры, на выход даёт значения), которую агент может написать за один присест, причём, никаких проблем с тестированием тоже не возникнет.

Разработка через поведение (BDD) – для определения спецификаций, описывающих периферию системы. Важные для бизнеса варианты пользовательского поведения описываются как спецификации в стиле Gherkin, а затем агент пишет конкретный код для их реализации. Таким образом удаётся снизить неоднозначность требований и сформулировать чёткую объективную цель, на которую должна быть направлена агентская реализация.

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

Пограничные слои реализуются при помощи MVC или простой модели  запрос/отклик. Что касается слоёв HTTP и всех связанных с ними паттернов подключения — используйте варианты, которые могли попадаться агенту миллион раз. Не нужно здесь творчества ^[13]!

Монолитное развёртывание. Единый репозиторий, всего один развёртываемый пакет, одна среда/контекст, понятные агенту. Сервисы развёртывайте позже, когда для них появятся данные и возникнет такая потребность ^[14].

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

Выводы

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

Притом, что я ничего в целом не имею против предметно-ориентированного проектирования (DDD), событийно-ориентированной архитектуры (EDA) и/или микросервисов, отмечу, что эти паттерны хороши для реализации силами опытных команд, разрабатывающих большие и сложные системы. Залог их эффективности в том, что крутые специалисты могут уверенно судить о проектируемой системе, они разбираются в предметной области и понимают глобальный контекст, необходимый для поддержки такой системы. В настоящее время агенты в этих отношениях хромают. Если вы требуете от агента следовать парадигме и предполагаете, что он обладает такими способностями к суждению, знаниями и т.д., то с самого начала ставите в невыгодные условия как агента, так и себя.

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

Важный аспект «агентской революции в программировании» связан не с тем, насколько может поумнеть модель (со временем она точно поумнеет), а с тем, насколько разработчики сами научатся решать, какие архитектуры усиливают возможности агентов, а какие лишь приводят к конфликтам. Оптимизируйте вашу архитектуру под те области, с которыми агент справляется лучше всего — ещё раз, это локальные суждения, механическая верификация, явно построенный поток управления — и доверяйте агенту те задачи, под которые он заточен. То есть, пусть он быстро пишет большие объёмы корректного кода, а вы тем временем сможете сосредоточиться на принятии чисто человеческих решений.

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