Дискуссии об агентном программировании обычно крутятся вокруг выбора IDE или модели. Куда реже обсуждается другой вопрос: сохраняют ли привычные архитектурные подходы смысл, если код пишет система с ограниченной памятью и конечным контекстным окном?
Автор разбора предлагает оценивать архитектуры по четырём критериям. Первый — может ли агент судить о фрагменте кода локально, не видя всей системы. Второй — есть ли механический способ проверить результат. Третий — насколько явен поток управления. Четвёртый — какова доля реальной логики относительно шаблонного кода. Именно по этим осям архитектуры расходятся принципиально.
| Архитектура | Локальное суждение | Механическая верификация | Явный поток управления | Высокий сигнал/шум |
|---|---|---|---|---|
| TDD | ✓ | ✓ | ✓ | ✓ |
| Функциональное программирование | ✓ | ✓ | ✓ | ✓ |
| MVC / MVVM | частично | ✗ | ✓ | частично |
| ООП | частично | ✗ | частично | частично |
| Микросервисы | частично | частично | частично | частично |
| Событийно-ориентированная архитектура | ✗ | ✗ | ✗ | частично |
| DDD | ✗ | ✗ | частично | ✗ |
TDD (разработка через тестирование) получает высшую оценку по всем четырём критериям. Ключевая слабость агента — эпистемологическая: он генерирует код, который выглядит корректно, но не имеет встроенного механизма проверки. TDD решает эту проблему напрямую. Агент пишет тест, запускает его, получает двоичный сигнал — красный или зелёный — и пишет минимальную реализацию, которая тест проходит. Никаких архитектурных суждений «на вкус», только механическая верификация.
TDD получает высшую оценку: набор тестов работает как внешняя память агента между сеансами работы.
Отдельное свойство TDD, которое автор называет «уверенной компонуемостью»: агент может написать функцию B на основе функции A, не перечитывая реализацию A — достаточно знать её интерфейс, а тесты гарантируют соблюдение контракта. Набор тестов при этом работает как внешняя память между сеансами: агент не помнит, что писал три сеанса назад, но тесты остаются и по-прежнему выполняются. Каждое новое изменение автоматически проверяется по всей накопленной истории.
Функциональное программирование занимает второе место в этом рейтинге. Чистые функции без скрытого состояния позволяют агенту проверять небольшой фрагмент кода, не удерживая в контексте всю кодовую базу. Если transformOrder(order) возвращает правильный результат на правильных входных данных — с функцией всё в порядке. Нет разделяемых переменных, которые другая функция могла бы изменить незаметно. Неизменяемость исключает целый класс багов, которые агенты особенно плохо отлавливают: когда функция A меняет общую переменную, а функция B читает её, считая неизменённой. Такой баг невидим ни в коде A, ни в коде B по отдельности — его можно заметить, только представляя систему целиком.
Последовательность «распарсить → валидировать → преобразовать → сохранить» агент воспринимает как чёткий рецепт: каждый шаг тестируется независимо, и после каждого можно двигаться дальше с уверенностью, что предыдущее работает. Автор оговаривается: чисто функциональный стиль применим не везде — ввод/вывод, состояние и побочные эффекты неизбежны. Рабочая стратегия — максимально продвинуть функциональный подход в логику предметной области, а менее чистые элементы оставить на периферии системы.
На другом конце рейтинга — событийно-ориентированная архитектура и DDD (предметно-ориентированное проектирование). Событийно-ориентированные системы используют неявный поток управления: публикуется событие, а где-то в другом месте его обрабатывает неизвестная заранее сущность. Чтобы понять, кто именно, нужно просмотреть все файлы в поисках подписчиков. Агент справляется с явным потоком управления как с рецептом, но при неявном его производительность падает по той же причине, по которой неявный поток управления затрудняет работу начинающих разработчиков: слишком много важного поведения остаётся за пределами экрана.
DDD в полной реализации — с агрегатами, объектами значений, событиями предметной области, репозиториями и ограниченными контекстами — может на 80% состоять из шаблонного кода, прежде чем появится первая строка осмысленной логики. Каждая строка такого кода потребляет контекст и несёт риск незаметного бага. Чем больше ритуалов, тем дороже обходятся изменения при ограниченном контексте.
MVC (модель-представление-контроллер) и MVVM занимают промежуточное положение: явный поток управления делает их понятными для агента, но качество ООП-кода сложно проверить механически — агент ориентируется на обучающие данные как на шаблон, а в них полно примеров плохого объектно-ориентированного кода. Микросервисы добавляют сложность на уровне границ сервисов, которую агент с ограниченным контекстом воспринимает плохо.
