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

Этот большой вопрос касается не кода, а процесса. Нужно ли сначала писать спецификацию? Насколько дробить задачи? Что делать, когда агент «забывает» договорённости? Популярным ответом стала разработка через спецификацию (spec-driven development) с циклом спецификация → дизайн → план задач → реализация → проверка. Под это уже есть инструменты: GitHub Spec Kit, Kiro, BMAD.

augmentcode

Многие спорят, не возвращение ли это к водопаду. Трезвая позиция звучит так: практический вопрос не в выборе между SDD и вайб-кодингом, а в том, сколько спецификации нужно для конкретной задачи. Отдельно советуют ограничивать задачу одной границей модуля. Если сформулировать задачу как «сделай фичу», агент придумает свою архитектуру, а через неделю другую.

Этот вопрос ближе всего к вашей просьбе, и именно здесь сейчас больше всего практических обсуждений. Сама проблема хорошо задокументирована. 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%.

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

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

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

Как настроить ИИ-агента, чтобы он реально "ловил" архитектурные нарушения, а не только опечатки. В этой статье я покажу, как настроить промпт (prompt) так, чтобы агент реально ловил архитектурные нарушения: с формализацией правил, парными примерами «правильно / неправильно» и защитой от ложных срабатываний на пограничных случаях (edge cases). Заодно разберём, как встроить такое ревью в pipeline, а не держать его как разовую ручную проверку.

Оригинальная статья в блоге или посмотрите видео к статье

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

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

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