Вы запускаете несколько AI-агентов для написания кода в одном репозитории. Может быть, три. Может быть, тринадцать. Каждому нужно отслеживать свою работу: создавать задачи, обновлять статусы, проверять зависимости, отчитываться о прогрессе. Десятки записей в минуту по всему флоту.
Это agentic engineering: люди координируют флоты AI-агентов для выпуска программного обеспечения. Рабочий процесс новый, но первое, что делает каждый, — тянется к знакомому инструменту. Jira. Linear. GitHub Issues. Notion. То, чем ваша команда управляет проектами.
Это не работает. И несоответствие не поверхностное. Оно архитектурное.
Задержки убивают пропускную способность
Вызов Jira API занимает 200–800 мс. Linear API быстрее, но всё равно 100–300 мс. Создать одну задачу, прочитать её зависимости, обновить статус — три раунд-трипа через HTTPS, DNS-резолвинг, TLS-рукопожатие и JSON-сериализацию. В хороший день — 500 мс.
Локальная запись через CLI в базу SQLite — менее 50 мс. Часто менее 10 мс.
Звучит как погрешность округления, пока не умножишь на количество операций. Агент, работающий над задачей, может создать 2–3 подзадачи, обновить статус родительской задачи, проверить блокеры и оставить комментарий о прогрессе. Шесть операций. По 500 мс каждая — 3 секунды чистого ожидания. По 10 мс — 60 миллисекунд. Агент, который мог бы завершить рабочий цикл за 30 секунд, теперь тратит 10% времени на ожидание HTTP вместо написания кода.
Масштабируйте это на 13 агентов — и накладные расходы измеряются минутами в час.
Инфраструктура аутентификации — хрупкий клей
Каждому агенту нужен API-токен. Токены истекают. Существуют лимиты запросов. Один агент отправляет серию из 20 быстрых обновлений — и получает 429 Too Many Requests. Теперь он застрял в цикле повторных попыток с экспоненциальным откатом вместо выполнения своей работы.
Вы добавили целый класс сбоев, не имеющий никакого отношения к самой работе. Ротация токенов, управление секретами, распределение лимитов запросов между агентами. Это операционные издержки ради возможности, которая должна быть тривиальной: записать строку в локальную базу данных.
Когда трекер задач — файл на диске, аутентифицироваться не перед чем. Если агент может читать файловую систему, он может читать и записывать задачи. На одну точку отказа меньше.
Модель данных рассчитана на людей
Откройте Jira. Вы увидите спринты. Стори-поинты. Ответственных с фотографиями и адресами электронной почты. Рабочие процессы с состояниями вроде «На ревью» и «Готово к грумингу». Вся модель данных спроектирована для команды людей, которые проводят стендапы, планируют спринты и ретроспективы.
Агенты не проводят стендапы. Они не оценивают в стори-поинтах. Им не нужен рабочий процесс с семью состояниями и четырьмя воротами согласования.
Агентам нужен граф зависимостей. Эта задача заблокирована той задачей. У этого эпика 12 дочерних элементов, 7 завершены. Этот агент забрал эту задачу 45 секунд назад и не отчитался. Фундаментальная структура данных — это дерево задач с отношениями блокировки, а не доска карточек, перемещаемых по столбцам.
SaaS-инструменты приделывают функции «автоматизации», но базовая модель под ними — всё та же Kanban-доска для людей. Можно написать плагин для Jira, позволяющий агентам создавать задачи. Но нельзя изменить то, что Jira считает вашего агента человеком в спринт-команде.
Зависимость от облака — единая точка отказа
Ваши агенты работают локально. Читают локальные файлы, пишут локальный код, коммитят в локальные git-репозитории. Могут работать оффлайн, в самолёте, в сети с задержкой 2000 мс. Им всё равно.
Но если трекер задач — это SaaS-продукт, каждая операция агента требует доступа в интернет. Linear лёг на 10 минут? Весь флот стоит. Домашний интернет моргнул на 30 секунд? Каждый агент уходит в цикл повторов. Трекер задач, который должен координировать работу, превращается в единую точку отказа всей системы.
Локальный подход означает, что трекер задач надёжен как файловая система. Всегда доступен, всегда быстр, всегда под вашим контролем.
Объём записи на порядки выше
SaaS-инструменты управления проектами рассчитаны на команду из 5–10 человек, вносящих несколько обновлений в день. Может быть, 50–100 записей на всю команду.
13 агентов, обновляющих задачи каждые несколько минут, генерируют сотни API-вызовов в час из одного проекта. Это не небольшое увеличение нагрузки. Это принципиально другой паттерн использования. Лимиты запросов, которые кажутся щедрыми для человеческих команд, становятся непреодолимыми стенами для флотов агентов.
И дело не только в объёме. Дело в параллелизме. Три агента одновременно обновляют дочерние элементы одного эпика. Состояния гонки в полях статуса. Сбои оптимистичных блокировок в ветках комментариев. Это проблемы, которые SaaS-инструментам никогда не приходилось решать, потому что люди не обновляют одну и ту же задачу из трёх терминалов в один и тот же момент.
Сотрудничество означает отказ от данных
Чтобы поделиться проектом в Jira с коллегой, обоим нужны аккаунты Jira. Данные хранятся на серверах Atlassian. Вы платите за каждое место ежемесячно за привилегию доступа к собственным данным проекта через их API.
Хотите перейти на другой инструмент? Экспортируйте, что сможете, в CSV и распрощайтесь с остальным. Комментарии, вложения, пользовательские поля, история аудита — удачи извлечь это в пригодном формате. SaaS-модель обменивает владение данными на удобство.
Но для сотрудничества не нужен посредник. Если ваша база задач управляется чем-то вроде Dolt (Git для баз данных), вы отправляете её на удалённый сервер, а коллега забирает. Создавайте ветки базы задач так же, как ветки кода. Мёржьте так же. Разрешайте конфликты теми же инструментами и с тем же ментальным подходом. Ваши данные остаются вашими. Сотрудничество работает как git, а не как подписка.
Что действительно работает
Уберите названия брендов и подумайте, что агентам реально нужно от трекера задач:
- Локальный подход. Никакой зависимости от сети. База данных — файл на диске.
- CLI-нативность. Агенты живут в терминале. Интерфейс тоже должен.
- Git в основе. Версионируемо, мёржится, аудируется. Без привязки к вендору.
- Без накладных расходов на аутентификацию. Если агент может читать файловую систему, он может отслеживать задачи.
- Низкая задержка. Менее 50 мс на операцию, а не 500 мс.
- Синхронизация без посредника. Push и pull как git-репозиторий, а не через API webhooks.
Это то, чем я пользуюсь каждый день. beads — Git-нативный трекер задач, созданный именно для такого рабочего процесса. Всё хранится в локальной базе SQLite с версионированием и синхронизацией через Dolt. CLI — основной интерфейс. Агенты создают, обновляют и запрашивают задачи так же, как выполняют любую другую команду.
Beadbox — визуальный слой, который я построил поверх этого. Он отслеживает изменения в локальной базе данных и отображает деревья зависимостей, прогресс эпиков и активность агентов в реальном времени. Агенты используют CLI. Я использую дашборд. Оба читают из одной и той же локальной базы данных.
Старые инструменты — не проблема
Jira отлично справляется со своей задачей: координацией человеческих команд через структурированные рабочие процессы. Linear прекрасен для небольших команд, ценящих скорость и стиль. GitHub Issues не создаёт трения для open-source-сотрудничества.
Ни один из них не плох. Они решают другую задачу. Если ваш рабочий процесс — команда из пяти человек с двухнедельными спринтами, продолжайте ими пользоваться.
Но если вы запускаете 5, 10 или 13 AI-агентов, координирующихся в реальном времени в одном репозитории, вы переросли SaaS-модель. Agentic engineering нуждается в инструментах, созданных для agentic engineering, а не в человеческих рабочих процессах с прикрученным API.