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

Ставьте задачу так же, как новому человеку в команде: с контекстом, ограничениями и понятным результатом.

Начните с политики вашей компании: какие инструменты разрешены, какие модели одобрены и куда уходят данные.

Агенту стоит отдавать то, что вы умеете сделать сами и можете быстро проверить: шаблонный код (boilerplate), тесты, маппинг DTO, миграции, однотипный рефакторинг, документацию.

Себе оставьте архитектурные решения, модель предметной области (domain model), безопасность и всё, что вы пока не понимаете. Если вы не можете оценить результат, агент не ускоряет работу, а прячет проблему до продакшена.

Доверять можно настолько же, насколько коду незнакомого коллеги, то есть только после проверки. За код, который попал в репозиторий, отвечаете вы, а не агент.

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

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