Сергей Калабонга 

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

Ответ сообщества называют инженерией контекста (context engineering): это файлы AGENTS.md, CLAUDE.md, правила и скиллы. Есть интересный практический вывод: если просто перечислить SOLID, KISS и YAGNI в заголовке CLAUDE.md, на результат агента это почти не влияет. Работают конкретные указания, например «используй валидатор из core/validation, не пиши новый», а также ADR: подкладывать в контекст нужное архитектурное решение вместе с обоснованием, например «здесь репозиторий, а не прямой доступ к БД, потому что X». Сюда же относятся вопросы о размере файла. Рекомендации держать CLAUDE.md в пределах 200 строк, потому что содержимое отправляется с каждым запросом, и каждая лишняя строка ослабляет важные.

Это главный вопрос, и цифры показывают, почему. В опросе Stack Overflow 2025 84% разработчиков используют или планируют использовать ИИ-инструменты, но 46% не доверяют точности их результатов, хотя годом ранее таких было 31%. Чаще всего жалуются на решения, которые почти правильные, но не до конца: так ответили 45% опрошенных, а 66% говорят, что тратят больше времени на исправление такого кода. Опытные разработчики доверяют ИИ меньше остальных: «высоко доверяют» около 3%.

Вопрос задают в разных формах. Чему можно поручить ИИ, а чему нельзя? Как ревьюить ИИ-код? Почему код выглядит чистым, а потом ломается?

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

Друзья, прошу вас ответить на простой вопрос. Пожалуйста будьте предельно честны.

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

Я сравниваю это с изучением грамматики русского языка: можно говорить и без неё, но как только текст становится сложнее — правила нужны, чтобы понимать, где текст ломается и почему.

Знание паттернов и DDD — это как раз тот словарь, на котором можно вести содержательный диалог с ИИ-инструментом, а не просто принимать его вывод на веру.

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

На короткой дистанции это ускоряло разработку, но каждое изменение требования потом превращалось в поиск логики по всему проекту.

Сейчас, применяя предметно-ориентированное проектирование (Domain-Driven Design) и чистую архитектуру (Clean Architecture), я закладываю границы контекстов (bounded contexts) и явные интерфейсы между слоями с самого начала — даже если проект выглядит небольшим.

Это кажется избыточным в начале проекта, но именно оно спасает через полгода, когда в проекте появляется третий разработчик и вторая интеграция.

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