Какие архитектуры кода подходят AI-агентам лучше всего

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

Почему архитектура вдруг стала важнее Когда агент пишет код, он не видит всю систему целиком.

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

Какие архитектуры работают с агентами

Наиболее полезны для AI-агентов: TDD (разработка через тестирование) — тесты — это спецификация, записанная в коде. Агент может быстро понять, что делает функция, посмотрев на тесты. Функциональное программирование — функции изолированы друг от друга, не требуют глубокого контекста о состоянии системы.

DDD (предметно-ориентированное проектирование) — явно разделяет домены, каждый домен почти независим. Гексагональная архитектура — четкие границы между слоями, адаптеры явно описывают взаимодействие. * CQRS (раздельная обработка команд и запросов) — команды и запросы явно разделены, логика понятна.

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

* Событийно-ориентированная архитектура — требует отслеживания глобального состояния и событий, которые разбросаны по системе.

Почему контекст решает всё Человек может держать в голове архитектуру целой системы.

Агент — нет. Для агента значит только то, что лежит в его контекстном окне прямо сейчас. Архитектуры типа TDD или DDD работают потому, что они ставят информацию в очевидное место. Тест скажет агенту, что делает функция. Граница домена скажет, где заканчивается одна область ответственности и начинается другая. Функции, которые не зависят от глобального состояния, легче понять без контекста. Интерфейсы, явно описывающие, как компоненты взаимодействуют, экономят контекстное окно.

«В эпоху агентов архитектура — это не про красоту кода, а про

сжимаемость информации в контекстное окно».

На практике Проекты, которые уже используют TDD или DDD, получают преимущество прямо сейчас.

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

Что это значит

Разработчики и архитекторы могут начать выбирать подходы не только потому, что они правильные в теории, а потому, что они работают с ограничениями AI. TDD и DDD не просто хорошие практики — они становятся конкурентным преимуществом в мире AI-программирования.