Урок 4.1. Как дробить большую задачу

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

В предыдущих модулях мы научились получать approved spec и задавать architecture constraints. Но даже хорошая specification не должна сразу превращаться в команду "реализуй все". Для coding agent это слишком широкий scope: он будет одновременно проектировать детали, менять много файлов, писать тесты, исправлять ошибки и держать в контексте слишком много решений.

Planning и decomposition превращают большую задачу в последовательность маленьких проверяемых изменений.

Цель этого урока - научиться видеть уровни работы:

Initiative -> Epic -> Feature -> Story -> Task -> Code Change

и не отдавать агенту задачу раньше, чем она стала достаточно маленькой для одного controlled agent run.

Основная идея

Большая задача должна стать не большим prompt, а системой маленьких задач.

Плохо:

Сделай authentication.

Лучше:

1. Описать password reset spec.
2. Утвердить token behavior.
3. Добавить reset token repository.
4. Добавить token generation service.
5. Добавить request reset endpoint.
6. Добавить reset confirm endpoint.
7. Добавить integration tests.
8. Добавить UI form.
9. Добавить E2E happy path.

Разница не только в размере. Во втором варианте каждый шаг можно:

• дать агенту отдельно;
• ограничить по scope;
• проверить отдельной командой;
• review'ить как маленький diff;
• откатить без отката всей фичи.

Ключевые термины

Иерархия работы

Пример:

Agent Task находится низко в этой иерархии. Это важно: coding agent хорошо выполняет маленькие инженерные шаги, но плохо работает как единственный владелец всей initiative.

Декомпозиция по поведению и по компонентам

Есть два распространенных способа дробить фичу.

По компонентам

DB
Service
API
UI
Tests

Плюсы:

• удобно видеть слои системы;
• легко распределять ownership;
• хорошо ложится на architecture constraints.

Минусы:

• можно долго не иметь end-to-end behavior;
• тесты иногда откладываются на конец;
• агент может сделать слой без понимания acceptance criteria.

По поведению

Request reset happy path
Expired token behavior
Consumed token behavior
Unknown email behavior
Rate limit behavior

Плюсы:

• каждая задача ближе к acceptance criteria;
• легче проверять observable result;
• меньше риск сделать "слой ради слоя".

Минусы:

• иногда behavior требует подготовительного infrastructure work;
• сложнее выделить независимые технические foundations;
• возможны повторные изменения одних файлов.

В реальном planning часто нужен гибрид:

1. Foundation tasks: model/repository/service skeleton.
2. Behavior tasks: expired token, consumed token, unknown email.
3. Integration tasks: API + UI + E2E.

Как распознать слишком большую задачу

Задача слишком большая, если:

• в ней несколько независимых outcomes;
• она требует менять много слоев сразу;
• невозможно назвать одну verification command;
• нужно принять product decision в процессе реализации;
• unclear allowed scope;
• diff будет трудно review'ить;
• агент должен одновременно писать code, tests, docs и migration;
• в задаче есть слова "все", "полностью", "целиком", "заодно".

Пример oversized task:

Реализуй password reset полностью.

Что в ней скрыто:

• data model;
• token generation;
• email sending;
• request endpoint;
• confirm endpoint;
• password policy;
• audit;
• rate limit;
• UI;
• tests;
• docs.

Это не одна Agent Task. Это feature или epic.

Декомпозиция Password Reset

Начальный approved behavior:

Пользователь может запросить reset link по email
и установить новый пароль по одноразовому token.
Token действует 15 минут.
Unknown email не раскрывается.
Successful reset пишет audit event.

Черновой список tasks:

T1. Создать ResetToken model/repository.
T2. Добавить tests для token expiration и consumption.
T3. Добавить token generation service.
T4. Добавить request password reset endpoint.
T5. Добавить email sending через existing EmailService.
T6. Добавить confirm password reset endpoint.
T7. Добавить audit event при successful reset.
T8. Добавить integration tests для API behavior.
T9. Добавить frontend request reset form.
T10. Добавить frontend confirm reset form.
T11. Добавить E2E happy path.

Но это еще не финальный task plan. Нужно проверить:

• какие tasks зависят от других;
• какие tasks слишком большие;
• какие tasks требуют architecture decision;
• где нужны tests before implementation;
• какие tasks можно выполнить без UI;
• какие tasks являются integration tasks.

Decomposition checklist

Перед передачей задачи агенту проверьте:

[ ] Есть approved spec или понятный requirement
[ ] Есть relevant architecture constraints
[ ] Задача имеет один проверяемый result
[ ] Есть allowed scope
[ ] Есть do-not-modify list
[ ] Есть verification command
[ ] Не требуется unresolved product decision
[ ] Diff ожидаемо reviewable
[ ] Задача ссылается на dependencies

Если хотя бы один пункт не выполнен, задача еще не готова для agent execution.

Практика: разложить Password Reset

Создайте файл:

specs/password-reset/plan.md

Заполните:

# Password Reset Implementation Plan

## Source documents

## Feature goal

## Architecture constraints

## Candidate tasks

## Tasks that are too large

## Questions before task execution

## Verification strategy

Минимальные требования:

• минимум 8 candidate tasks;
• для каждой task один expected outcome;
• минимум 3 architecture constraints из модуля 3;
• минимум 3 tasks должны быть помечены как dependent on earlier tasks;
• минимум 2 задачи нужно явно уменьшить, если они слишком широкие.

Типичные ошибки

Ошибка 1. Декомпозировать только по файлам

Список файлов не равен task plan. Задача должна иметь behavior или технический outcome, а не просто "поменять файл".

Ошибка 2. Откладывать тесты на самый конец

Если tests появляются только после всей реализации, они часто подтверждают уже выбранное агентом поведение, а не specification.

Ошибка 3. Делать tasks без architecture constraints

Agent Task без constraints может выполнить behavior через неправильный слой.

Ошибка 4. Не выделять integration tasks

Отдельные слои могут работать, но интеграция UI/API/DB/email ломается. Integration должна быть частью plan.

Ошибка 5. Путать decomposition и execution

На этом этапе мы еще не пишем production code. Мы готовим карту маленьких проверяемых работ.

Критерии готовности

После урока студент должен уметь:

• объяснить уровни Initiative -> Epic -> Feature -> Story -> Task -> Code Change;
• определить, когда задача слишком большая для agent run;
• разложить feature на candidate tasks;
• сравнить decomposition по компонентам и по поведению;
• связать decomposition с verification;
• подготовить черновик plan.md для Password Reset.

Краткое резюме

Decomposition превращает большую фичу в управляемую инженерную работу. Для AI agents это критично: чем меньше и яснее задача, тем проще удержать context, scope, architecture constraints и verification.

Хороший план не просто перечисляет файлы. Он показывает маленькие результаты, порядок работы и точки проверки.

Вопросы для самопроверки

1. Почему "сделай authentication" не является Agent Task?
2. Чем decomposition по поведению отличается от decomposition по компонентам?
3. Какие признаки говорят, что задача слишком большая?
4. Почему tests нельзя всегда откладывать на конец?
5. Что должно быть известно до передачи task агенту?

Что дальше

В следующем уроке мы возьмем одну маленькую часть плана и оформим ее как хорошую Agent Task: с goal, context, inputs, allowed scope, constraints, acceptance criteria и verification.