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

Кто такой системный аналитик, чем он отличается от бизнес-аналитика, какие навыки и инструменты ему нужны и как его работа выглядит со стороны разработчика. На сквозном примере с уведомлениями о смене статуса заказа разбираем три уровня постановки задачи — «плохо», «хорошо» и «правильно» — и вопросы, которые стоит закрыть до того, как задача уйдёт в разработку.

Большинство разработчиков знакомятся с ИИ через окно чата: задал вопрос — получил ответ, скопировал код — вставил в проект. Это удобно, но это «ручной» режим. Настоящая польза для продукта начинается тогда, когда модель становится обычной зависимостью вашего приложения — такой же, как база данных или очередь сообщений. Именно об этом статья: что такое ИИ через API, как устроены ключи, какие задачи так решают чаще всего, какую модель выбрать, стоит ли экономить на бесплатных моделях, когда нужен агент, а когда достаточно одного вызова, и почему промпты никуда не исчезают, а наоборот становятся частью кода.

Этот большой вопрос касается не кода, а процесса. Нужно ли сначала писать спецификацию? Насколько дробить задачи? Что делать, когда агент «забывает» договорённости? Популярным ответом стала разработка через спецификацию (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%.

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

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