Я активно использую YouGile в разработке и управлении несколькими проектами. Когда-то перешёл на него с Trello, остался доволен, а со временем с моей подачи YouGile начали использовать ещё несколько команд.
Параллельно всё больше работы у меня перешло в Codex. В какой-то момент процесс стал выглядеть странно: задача находится в YouGile, я передаю её агенту, он меняет код и проверяет результат, после чего я снова иду в YouGile — обновить статус, написать комментарий, отметить чек-лист.
Возник естественный вопрос: если агент уже выполняет саму задачу, почему он не может работать и с таск-трекером?
Так появился мой плагин для YouGile, который позволяет Codex и Claude Code читать и изменять задачи, работать с досками, комментариями, чек-листами, файлами и другими объектами проекта.
«Проверь баги после тестирования, исправь и обнови статусы»
Один мой знакомый frontend-разработчик использует довольно показательный сценарий. После тестирования в YouGile появляется колонка с найденными багами, и агенту можно дать примерно такую команду:
Проверь новые задачи в колонке с багами после тестирования, исправь их и обнови статусы в YouGile.
Codex читает карточки, работает с текущим репозиторием, а затем возвращает результаты обратно в таск-трекер. Не нужно отдельно копировать каждую задачу в чат, а после исправления вручную обновлять карточки.
Для меня это один из самых интересных сценариев интеграции. Речь уже не о том, что «ИИ умеет создать карточку через API», а о замкнутом рабочем процессе:
задача → выполнение → проверка → результат → новый статус
Причём YouGile остаётся общей точкой состояния проекта для команды. Агент просто становится ещё одним инструментом работы с этой системой.
Что ещё можно делегировать агенту
Второй полезный сценарий — разбор текущего состояния проекта. Например:
Проверь спринт. Покажи просроченные задачи, задачи без исполнителя и карточки, которые давно не обновлялись. Ничего не меняй.
Или можно превратить обсуждение новой функциональности в структуру проекта:
Разбей реализацию реферальной системы на backend, frontend, тестирование и документацию. Подготовь задачи, исполнителей и чек-листы, но сначала покажи план.
После проверки план можно применить одной командой. Агент создаст нужные карточки и разложит их по доске.
Это особенно полезно именно в рутинных операциях. Создать одну задачу руками быстро. Создать двадцать задач, заполнить описания, добавить чек-листы, исполнителей и сроки — уже хороший кандидат на автоматизацию.
Самая сложная часть оказалась не в ИИ
Изначально мне казалось, что получится небольшой Python-клиент к YouGile API плюс skill с инструкциями для Codex.
Но как только агент получает право менять реальные рабочие данные, появляются вопросы, которые почти не связаны с LLM: что делать при timeout, как не повторить мутацию дважды, как убедиться, что пользователь подтвердил именно тот payload, который уйдёт в API, и как не перепутать две компании с одинаково названными досками.
Один из таких случаев я поймал непосредственно во время разработки.
Плагин создавал несколько колонок. Локальная операция закончилась по timeout, после чего workflow был запущен повторно. В результате появились дубли: сервер продолжил выполнять первый запрос даже после того, как клиент перестал ждать ответа.
Из этого получился довольно важный принцип:
timeout ≠ запрос не выполнился timeout = результат запроса неизвестен
Теперь автоматически повторяются только операции чтения. После timeout у POST или PUT сначала выполняется GET и проверяется фактическое состояние системы. Если изменение уже произошло, оно считается выполненным; если результат нельзя определить однозначно, агент останавливается вместо повторной мутации.
Для таск-трекера ошибка обычно означает лишнюю карточку или колонку. Но тот же принцип применим к CRM, рассылкам, рекламным кабинетам, облачной инфраструктуре и другим системам, где повторный запрос может иметь гораздо более неприятные последствия.
Между LLM и API появился детерминированный слой
В итоге workflow выглядит примерно так:
команда пользователя ↓ LLM разбирает намерение ↓ формируется точный план ↓ preview и подтверждение ↓ повторная проверка состояния ↓ мутация выполняется один раз ↓ GET readback ↓ проверка результата
Я стараюсь разделять две задачи. LLM хорошо понимает запрос вроде «перенеси исправленные баги на проверку». Но окончательное определение ID объектов, допустимых значений и содержимого API-запроса лучше делать обычным кодом.
Сам план тоже фиксируется. Для его канонического JSON вычисляется SHA-256, поэтому после подтверждения нельзя незаметно заменить список задач или payload. План одноразовый и имеет ограниченный срок жизни.
При этом пользователь не обязан подтверждать каждый POST отдельно. Если нужно создать доску, четыре колонки и пятнадцать задач, он видит общий preview и подтверждает весь workflow один раз. Технически операции выполняются последовательно, а ID следующего объекта берётся только после проверки предыдущего шага.
Если процесс остановится посередине, плагин честно вернёт частичный результат. Я не стал изображать поверх обычного REST API транзакцию, которой там нет: автоматический rollback сам по себе означал бы новые мутации и мог создать ещё больше проблем.
Несколько компаний тоже оказались важным случаем
В YouGile один пользователь может работать с несколькими компаниями. В обеих вполне могут существовать проекты «Разработка» и доски «Backend».
Поэтому одного названия недостаточно. План привязывается к конкретной компании и профилю, а перед изменением дополнительно проверяется удалённая identity текущего credential. Если между созданием плана и его применением поменялся контекст, операция блокируется.
По той же причине API-ключ не передаётся модели. Он хранится локально через системное хранилище credentials: DPAPI в Windows и соответствующий keyring backend в macOS/Linux. В конфигурации, планах и обычных логах самого секрета нет.
Для пользователя всё это выглядит намного проще: агент может работать с YouGile, но ключ не приходится вставлять в prompt или хранить рядом с проектом.
Даже OpenAPI нельзя считать окончательной истиной
Во время разработки встретилась и ещё одна характерная проблема. Некоторые поля официально присутствовали в OpenAPI-схеме, но реальное облако YouGile отвечало HTTP 400 при попытке их записать. В другом случае запрос завершался успешно, но последующий GET показывал, что сервер сохранил другое значение.
Поэтому для плагина HTTP 2xx сам по себе не считается доказательством успеха. После изменения выполняется независимое чтение и проверяется фактически сохранённое состояние.
Мне кажется, это полезный принцип для любых агентных интеграций:
Агент должен сообщать не «я отправил запрос», а «я проверил, что нужное изменение действительно произошло».
В итоге получилось больше, чем API-клиент
В релизе 2.1.0 плагин состоит из 29 Python-модулей — примерно 11,5 тыс. строк кода. Для него есть 21 тестовый файл и 244 тестовых метода, а CI проверяет Python 3.10–3.13 на Windows, macOS и Ubuntu.
Большая часть этого объёма появилась не из-за сложности самого YouGile API. Создать карточку несложно. Сложнее сделать так, чтобы агент не перепутал контекст, не повторил неизвестно чем закончившийся POST, не применил устаревший план и не сообщил об успехе до проверки результата.
Именно поэтому я всё меньше воспринимаю такие интеграции как «дать LLM доступ к API». Более точная модель для меня сейчас выглядит так:
LLM понимает намерение, а детерминированный исполнитель отвечает за реальные изменения.
Что это изменило в работе
Сам YouGile я использовать меньше не стал. Я просто реже открываю его исключительно ради механического обслуживания карточек.
Вместо последовательности «найти задачу → поменять статус → написать комментарий → открыть следующую» всё чаще можно написать:
Проверь исправленные баги этого релиза, добавь результаты и перенеси задачи на проверку.
Или:
Проверь доску и подготовь список проблем к созвону.
Или:
Создай задачи по утверждённому плану.
На мой взгляд, в этом и заключается наиболее практичный вариант интеграции AI-агентов с рабочими инструментами. Не заменять Jira, YouGile, GitHub или CRM очередным AI-чатом, а дать агенту возможность безопасно работать с теми системами, где команда уже ведёт свою работу.
Пять копий плагина отдам для тестирования
Сейчас мне интересно проверить плагин уже на чужих процессах, а не только на собственных сценариях. Поэтому первым пяти читателям Хабра, которые оставят осмысленный комментарий с желанием его попробовать, дам плагин бесплатно.
Достаточно коротко написать, как вы используете YouGile и что хотели бы автоматизировать. В ответ я рассчитываю прежде всего на обратную связь после реальной работы: что оказалось удобным, что мешает и каких сценариев не хватает. Для разработки такой фидбек сейчас значительно полезнее формального положительного отзыва.
