THE TAM · PRODUCT
Знакомьтесь: @tam — AI Delivery Partner для работы вокруг кода.
@tam превращает цели в delivery-планы, координирует инженеров и coding agents, следит за блокерами и зависимостями, связывает изменения в репозитории с планом и готовит работу к ревью человеком.
The Tam — delivery-система, в которой работает @tam.
Познакомиться с @tam ↗подготовить новый онбординг к релизу.
@tam подготовил план- 01Дизайн экранов онбординга→ Марк
- 02Изменения API регистрации↳ после дизайна→ Claude Code
- 03Миграция данных→ Codex
- 04Проверка безопасности↳ нужно решение→ Анна
- 05Заметки к релизу→ @tam
Я много лет вёл этот цикл вручную.
Я много лет отвечал за software delivery. Менялись команды, масштаб и инструменты, но удивительно большая часть работы оставалась той же: держать в одной актуальной картине цель, план, ответственных, зависимости, решения, код, ревью и релиз.
Coding agents гораздо быстрее изменили саму разработку. Codex, Claude Code и похожие инструменты уже могут брать на себя заметные куски реализации. Но работа вокруг исполнения никуда не исчезла. Кто-то всё ещё должен понимать, что происходит дальше, замечать остановившуюся работу, связывать pull request с планом, поднимать недостающие решения и разбираться, действительно ли релиз готов.
В большинстве команд этим человеком по-прежнему остаётся основатель, руководитель разработки, продакт или старший инженер. The Tam начался для меня с простого вопроса: какую часть этой delivery-работы может взять на себя сама система?
Та часть работы, которую я хочу отдать системе.
Вы даёте @tam цель или бриф. Он превращает их в работу с исполнителями, зависимостями и планом, который команда может проверить.
Люди и coding agents выполняют работу. @tam держит её в одном контексте проекта, вместо того чтобы каждая новая сессия агента превращалась в ещё один поток, который человеку придётся вручную сводить с остальной работой.
Если работа встала, @tam возвращается к ней. Если нужен продуктовый или технический выбор либо решение по рискам, он приносит вопрос человеку, который за него отвечает, а не придумывает себе полномочия.
И он остаётся с работой дальше. Сессия агента заканчивается. Чат заканчивается. Ответственность за delivery — нет.
Если называть это AI project manager, то ценность не в генерации задач. Она в том, что кто-то постоянно держит нить работы между отдельными запусками агентов.
Как это выглядит на реальной работе.
Допустим, нужно подготовить новый онбординг к релизу. @tam разбивает цель на дизайн, работу с API, миграцию, проверку безопасности и заметки к релизу. Часть работы получают люди, часть — Claude Code или Codex.
@tam · Онбординг v2ведёт работуОтдал API Claude Code, интерфейс Анне
Привязал PR #142 к TAM-58 и перевёл в ревью
TAM-61 два дня ждёт дизайн. Спросил Марка.
→ Продакт
Дизайн не успевает на этой неделе. Убрать пустые состояния или сдвинуть релиз на 3 дня?
Когда появляются коммиты и pull request, связанные задачи обновляются. Если дизайн стоит на месте, @tam возвращается к ответственному. Если для проверки безопасности нужно решение человека, он поднимает вопрос и показывает, как он влияет на план. Когда реализация готова, ревью, приёмка и выпуск остаются за людьми, которые за них отвечают.
Дело не в том, что @tam умеет вызывать других агентов. Оркестрация агентов — один из механизмов внутри этой работы. Сложнее постоянно связывать людей, агентов, решения, данные репозитория и план с одной и той же целью.
Такому агенту мало истории чата.
Чтобы делать эту работу, @tam нужна картина проекта, которой можно доверять. Цель не может жить в одном чате, задачи — в другой системе, код — в GitHub, а решения — где-то ещё, пока у каждого агента своя версия происходящего.
northstar/checkout · pull request
Лимиты запросов на пространство
#151 · codex/tam-73-rate-limits
- Сборка прошла
- Тесты прошли
- 1 одобряющее ревью
Лимиты для публичного API
- Исполнитель
- svc-codex-release
- Цель
- Стабильный массовый импорт
- Ревьюер
- Марк
синхронно
Поэтому The Tam — больше, чем @tam. Система хранит рабочее состояние delivery: проекты, задачи, зависимости, документы, решения, людей и идентичности ИИ-агентов, события из репозитория, состояние ревью и историю того, как проект сюда пришёл.
Одно и то же состояние доступно людям и агентам, которые работают над проектом. Coding agents могут продолжать использовать привычные инструменты; их работа возвращается в общую историю delivery, а не становится ещё одним потоком, который человек должен вручную сверять с проектом.
Куда, как мне кажется, это идёт
Я не думаю, что конечная точка — это улучшенный трекер с ИИ-ассистентом сбоку. И не думаю, что это менеджер перед десятью окнами автономных агентов, который вручную перебрасывает работу между ними.
Мне кажется, сама delivery-система должна вести гораздо большую часть процесса между решениями, которым действительно нужен человек.
Люди задают цель, ограничения и приоритеты. Они принимают продуктовые и архитектурные решения, отвечают за риски, приёмку и релиз. Люди и специализированные агенты выполняют работу. Система держит актуальный план и картину проекта, даёт нужную работу и контекст подходящему исполнителю, замечает остановки, следит за зависимостями, проверяет, подтверждается ли заявленный прогресс доступными данными, приносит решения нужному человеку и продолжает работу после ответа.
Я хочу, чтобы The Tam стал системой, которая сама ведёт software delivery, а не базой данных, которую люди вручную поддерживают, пока ведут delivery сами.
Сегодня самая заметная часть этой идеи — @tam. Со временем та же модель может охватить планирование, процессы delivery, инженерных агентов, ревью, релизы, знания организации и повторяющуюся работу вокруг команды разработки.
Цель не в том, чтобы убрать людей, отвечающих за продукт. Я хочу постепенно убирать ту координационную механику, которой им пока приходится управлять вручную.