Сегодня специфичный пост для инженеров.
Много юзаю Claude Code в последнее время и не отпускает одна мысль. В своё инженерное прошлое я всегда угорал по «лучшим практикам» — SOLID, TDD, Clean Architecture, DDD, property-based testing и тд. Большинство команд их игнорировали: сложно, долго, вэлью непонятно. И аргумент про сложность был честным — поддерживать чистую архитектуру и писать тесты до кода реально дорого по времени и когнитивной нагрузке.
Так вот. Кажется, агенты снимают порог входа в эти практики — написать тесты, нарезать интерфейсы, разложить по слоям стоит копейки, когда это делает Claude Code. А сами практики в ответ снимают ключевое ограничение агентов — контекстное окно.
Агент не может держать в голове весь проект. 250к токенов звучит много, но реальная кодовая база вылезает за эти пределы быстро. А даже если влезает — качество падает. Даже с 1м контекстом. Модель теряет детали, путает зависимости, начинает галлюцинировать.
И тут
Clean Architecture начинает выглядеть как идеальный интерфейс между тобой и агентом. Чёткие слои, определённые контракты между ними — и для работы с конкретным куском агенту достаточно видеть архитектуру, интерфейсы и код текущего модуля. Не всю кодовую базу, а только нужную часть и интерфейсы взаимодействия с другими слоями.
DDD усиливает эту же идею:
bounded contexts — это готовые границы того, что агенту нужно загрузить, а
ubiquitous language делает код читаемым без дополнительной документации.
SOLID вообще читается как готовый чеклист «как сделать кодовую базу, с которой агент справится»:
- Single Responsibility — меньше кода нужно видеть для одного изменения
- Open/Closed — агент добавляет новую реализацию, не трогая существующий код, который даже не нужно грузить в контекст
- Liskov Substitution — можно подменить реализацию и ничего не сломается, а тесты это верифицируют
- Interface Segregation — агент видит только нужный ему срез интерфейса, а не всё подряд
- Dependency Inversion — для меня самый показательный. Модуль зависит от абстракции, не от реализации. Агенту не надо тащить в контекст код базы данных, чтобы написать бизнес-логику — хватит интерфейса репозитория
С
TDD та же история. Тест — это спецификация поведения, которая влезает в контекст и однозначно верифицирует результат. Агент получил тест, написал реализацию, запустил — красный, зелёный, рефакторинг. Цикл обратной связи без необходимости понимать всю систему.
Отдельно про
property-based тестирование. Штука всегда была нишевой — мало кто хотел возиться с генераторами и инвариантами, когда можно накидать пять юнит-тестов. Но с агентами property-based тесты должны давать непропорционально много фидбека при минимуме тестового кода. Один тест с правильно описанным свойством — это тысячи кейсов, которые агент прогоняет за секунды. При этом llm’ки куда быстрее придумывают все инварианты для тестирования, что снимает с разработчика когнитивную нагрузку на имплементацию подхода.
И вот что мне кажется самым интересным: property-based тесты идеально ложатся в цепочку PRD → TDD → реализация. Свойства системы из PRD («баланс не может быть отрицательным», «сумма позиций равна итогу заказа») транслируются в property-тесты почти один к одному. Агент получает свойства как спецификацию и пишет код, который им удовлетворяет. По сути requirements (R из PRD) становятся исполняемой верификацией — без ручной работы по переводу в десятки отдельных тестов.
Годами шли споры, стоит ли Clean Architecture и другие практики своих накладных расходов — всех этих дополнительных абстракций и интерфейсов. Будет забавно, если окажется, что именно эти «лишние» абстракции делают кодовую базу пригодной для работы с AI.
