Есть отдельный риск, который легко упустить: сводка работы во внешнем канале. Агент, отчитываясь о сделанном, может включить в сообщение пути к файлам и фрагменты кода - и это не дефект, а природа отчёта: объяснить, что именно изменилось, без имён файлов невозможно. В канале команды это нормально; в общем канале с подрядчиками или в общем корпоративном пространстве аудитория шире, чем аудитория репозитория. Для этого есть отдельная настройка, и её стоит выключить там, где читателей больше, чем людей с доступом к коду.

Это частный случай общего правила: интеграция переносит не только удобство, но и содержимое. Задача, созданная из обсуждения, приносит в трекер фрагменты кода; сводка в мессенджере приносит имена файлов; документ, подключённый как контекст, уносит в модель то, что в нём написано. Важно то, что каждый такой перенос необратим: удалить сообщение из канала можно, а вернуть его из чужой памяти и чужих уведомлений - нет. Поэтому вопрос о том, кто увидит результат, задают до подключения, а не после первой сводки.

Отдельного внимания заслуживает идентичность в командных каналах. Запуск из общего пространства означает, что действие совершается от чьего-то имени и с чьими-то правами. Если это ваши права, то любой участник канала фактически получает возможность инициировать работу с вашим доступом, причём без умысла и часто не подозревая об этом. Граница доверия здесь совпадает с границей канала, а не с границей команды, и состав канала меняется без вашего участия. В таких местах правильнее использовать служебные учётные записи с узкими правами и явными правилами о том, кто и что может запускать.

Самый частый сценарий - запуск работы прямо из задачи в трекере - стоит разобрать целиком. Текст задачи в этот момент становится постановкой, а значит, качество ваших задач напрямую переходит в качество результата. Задача из двух строк даёт понимание из двух строк, а условия приёмки, которые обсудили голосом или в соседней ветке обсуждения, в постановку не попадают вовсе. Признак этой болезни узнаваем: агент возвращает аккуратное изменение, которое решает не ту задачу, и виноватой объявляют модель, хотя она честно отработала то, что было написано. Интеграция с трекером поэтому даёт больше всего там, где задачи и до неё писали внятно.

Каждая дополнительная интеграция имеет свою цену, и она не в деньгах. Это ещё одна выданная авторизация, ещё одно место, где нужно помнить про отзыв доступа при уходе человека, и ещё один канал, по которому содержимое репозитория утекает наружу. Особенно это верно для интеграций, которые требуют согласия администратора на весь корпоративный контур: выдаётся такое согласие за минуту, а отменяется через тех людей, до которых ещё надо дойти. Отсюда правило: интеграцию ставят под конкретный сценарий, а не на всякий случай, и снимают, когда сценарий перестал быть нужным.

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

Типичные провалы предсказуемы. Ждать доступа к обсуждению без подключённой и авторизованной интеграции. Оставить включённой подробную сводку в канале, где аудитория шире репозитория. Запускать общие автоматизации от личной учётной записи. Ставить интеграции на всякий случай и не снимать ненужные. И считать, что интеграция в другой среде разработки повторяет весь набор возможностей настольного приложения.