Tickets: режем spec вертикальными срезами

Зачем это нужно

У вас есть spec (см. 6.3): вы знаете, куда идёте. Теперь нужен маршрут — tickets, каждый на одну сессию. Резать работу можно хорошо и плохо, и агент, предоставленный сам себе, обычно режет плохо: по слоям приложения.

Как это устроено

Горизонтальные срезы. В приложении есть слои: база данных, сервисы, API, интерфейс. Агент, разбивая задачу, охотно делает фазу на слой: сначала схема и миграции, затем сервисы, затем UI. План выглядит аккуратно, но это ловушка, давно известная разработчикам. Код первой фазы никто не проверил в работе: хорошо ли спроектирована схема, становится ясно только в третьей фазе, когда сквозь неё впервые проходит реальный запрос. Обратная связь о системе целиком приходит слишком поздно.

Вертикальные срезы. Каждый ticket с самого начала проходит через все слои: узкий, но полный путь от базы до экрана. Первый срез — минимальная страница с одной цифрой из базы. Он сразу проверяет, что слои стыкуются, а следующие tickets достраивают уже проверенный каркас. Идея известна как tracer bullets из книги «The Pragmatic Programmer», и слова «vertical slices» агент понимает без пояснений.

Skill /to-tickets в Cadence разбивает план, spec или разговор на tickets — вертикальные срезы, каждый с указанием, какими tickets он заблокирован. Связи блокировок показывают, что можно делать параллельно: если tickets 3 и 4 зависят только от 2, после 2 их можно вести одновременно.

Где вызывать. Лучше всего — в той же сессии, где только что отработал /to-spec: в контексте лежат все решения, из которых выросла spec. Дальше решение простое:

• места в окне хватает, и контекст относится к делу — продолжайте;
• окно уже заметно заполнено — выполните /compact с инструкцией, что сохранить, например /compact keep every decision behind the spec;
• контекст к следующей задаче не относится — /clear и новая сессия.

Сколько занято, показывает /context.

Размер ticket. Ticket должен помещаться в одну свежую сессию — в smart zone, а не во весь context window. В демонстрации оригинала /to-tickets предложил 10 tickets на дашборд аналитики. Автор прикинул: если на сессию закладывать около 150 тысяч токенов, это полтора миллиона на одну фичу — слишком много. Он попросил три, и агент сам предупредил, что два из них больше одного context window. Сошлись на пяти: groundwork с индексами и seed-данными, каркас страницы и три среза поверх него. Агент заметил: каждый ticket даёт что-то, на что можно посмотреть. Цифры здесь — опыт автора, а не правило; правило — каждый ticket помещается в одну сессию и проходит через все слои.

Практика

Вернитесь в сессию, где вы выполнили /to-spec. Проверьте /context; если окно заполнено больше, чем вам комфортно, сожмите его через /compact. Затем запустите:

/to-tickets

Агент покажет разбивку и спросит ваше мнение. Пройдитесь по каждому ticket с двумя вопросами: проходит ли он через все слои и поместится ли в одну сессию. Если видите ticket вида «implement the database schema» — это горизонтальный срез, попросите переделать. Если tickets слишком много или они слишком крупные, назовите число, как это сделал автор: «I would like to break this down into maximum five tickets».

Подводные камни

• Агент возвращается к горизонтальным срезам. Даже со skill, который требует вертикальных срезов, агент нередко раскладывает работу по слоям. Поэтому разбивку смотрит человек.
• Слишком мелко. Десять tickets — десять сессий и десять раз загрузки контекста. Мелкие срезы не бесплатны.
• Слишком крупно. Ticket больше одной сессии возвращает вас к проблеме из 6.1. Если агент сам предупреждает о размере, верьте ему.

Вывод: хороший ticket — узкий срез через все слои, который даёт видимый результат и помещается в одну сессию.

Проверь себя

Источники

• Anthropic, Best practices for Claude Code
• Anthropic, Explore the context window
• По мотивам AI Coding Crash Course, AI Hero