Урок 4.3. Размер задачи

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

Даже если Agent Task оформлена по шаблону, она может быть слишком большой. Это одна из самых частых причин drift: задача вроде бы имеет goal и verification, но внутри все еще прячется несколько независимых изменений.

Размер задачи напрямую влияет на:

• качество контекста;
• размер diff;
• сложность review;
• вероятность unrelated changes;
• стоимость rollback;
• надежность verification.

Этот урок дает практическое правило курса:

Одна Agent Task = один проверяемый результат.

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

Task хорошего размера должна быть достаточно маленькой, чтобы:

• агент мог удержать relevant context;
• diff можно было быстро review'ить;
• failure было понятно локализовать;
• verification была конкретной;
• rollback не затрагивал всю feature.

Плохо:

Сделай authentication.

Лучше:

Создать ResetTokenRepository и unit tests для create/find/consume.

Еще лучше, если repository слишком большой:

TASK AUTH-010:
Добавить method create reset token в ResetTokenRepository.

TASK AUTH-011:
Добавить method consume reset token в ResetTokenRepository.

Правильный размер зависит от проекта, но критерий один: результат должен быть проверяемым.

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

Почему размер задачи важен для агента

Человек может держать в голове долгий контекст проекта, хотя тоже ошибается. Агент работает в рамках текущего context window и transcript. Чем больше task, тем больше:

• файлов нужно прочитать;
• решений нужно принять;
• tool outputs попадает в контекст;
• промежуточных ошибок появляется;
• вероятность, что старое assumption останется в контексте;
• соблазн "заодно" изменить соседний код.

Маленькая task не делает модель безошибочной. Но она уменьшает blast radius.

Признаки oversized task

Task почти наверняка слишком большая, если:

Число строк не является абсолютным правилом. Маленький diff может быть risky, а большой generated file может быть harmless. Но для учебного курса мы хотим tasks, которые легко проверить и обсудить.

Как уменьшать задачу

Разделить по слоям

Oversized:

Реализовать password reset backend.

Меньше:

T1. Добавить ResetTokenRepository.
T2. Добавить PasswordResetService.
T3. Добавить request reset endpoint.
T4. Добавить confirm reset endpoint.
T5. Добавить API integration tests.

Разделить по behavior

Oversized:

Добавить confirm reset endpoint.

Меньше:

T1. Valid token changes password.
T2. Expired token returns TOKEN_EXPIRED.
T3. Consumed token returns TOKEN_USED.
T4. Weak password returns PASSWORD_POLICY_FAILED.

Разделить tests и implementation

Для хорошо определенного behavior:

T1. Add failing tests for expired and consumed token.
T2. Implement minimal service logic to pass tests.

Это полезно, когда нужно заставить agent работать через TDD loop.

Разделить discovery и edit

Если кодовая база незнакомая:

T1. Inspect existing auth/email/audit patterns and write implementation notes.
T2. Implement request reset endpoint using approved notes.

Это снижает риск, что агент начнет писать код до понимания существующих patterns.

Пример: authentication

Плохо:

Сделай authentication.

Лучше как feature breakdown:

1. Login
2. Logout
3. Refresh token
4. Password reset
5. Session management
6. Authorization middleware

Password Reset breakdown:

1. ResetTokenRepository
2. Token generation service
3. Request reset endpoint
4. Email sending integration
5. Confirm reset endpoint
6. Expired/consumed/invalid token behavior
7. Frontend request form
8. Frontend confirm form
9. E2E happy path

Task-level examples:

TASK AUTH-010:
Create ResetTokenRepository.createToken with unit tests.

TASK AUTH-011:
Create ResetTokenRepository.consumeToken with unit tests.

TASK AUTH-012:
Add PasswordResetService.requestReset for existing user.

TASK AUTH-013:
Ensure unknown email returns generic accepted response.

Обратите внимание: каждый task можно проверить отдельно.

Stop conditions

Agent должен остановиться, если task оказалась больше, чем ожидалось.

Примеры stop conditions:

- Required change touches files outside allowed scope.
- Existing architecture differs from task assumptions.
- Verification requires database migration not listed in task.
- Acceptance criteria conflict with current spec.
- Implementation requires product decision.
- More than one unrelated bug blocks verification.

Остановка - это нормальный outcome controlled workflow. Лучше остановиться и уточнить, чем тихо расширить scope.

Практика: уменьшить 3 задачи

Возьмите три oversized tasks:

1. Реализовать authentication.
2. Добавить систему уведомлений.
3. Улучшить dashboard.

Для каждой сделайте:

## Original task

## Why it is too large

## Hidden outcomes

## Smaller tasks

## First task ready for agent

## Verification for first task

Итоговый артефакт:

labs/04-task-sizing/task-sizing.md

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

• каждая original task разбита минимум на 5 smaller tasks;
• первая task имеет один verifiable outcome;
• для первой task указан allowed scope;
• для первой task указана verification command или checklist.

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

Ошибка 1. Дробить задачу до бессмысленных микрошагов

Слишком мелкие tasks создают overhead. Хороший размер - не "одна строка кода", а один проверяемый результат.

Ошибка 2. Оставлять в task несколько outcomes

Если task одновременно добавляет repository, endpoint и UI, review будет сложным.

Ошибка 3. Не выделять discovery task

Если агент не знает existing patterns, иногда сначала нужна read-only task.

Ошибка 4. Игнорировать rollback

Если task невозможно откатить без потери всей feature, она слишком большая.

Ошибка 5. Уменьшать только implementation, но не tests

Tests тоже должны соответствовать размеру task. Targeted tests дают быстрый feedback.

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

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

• объяснить правило "one task - one verifiable outcome";
• распознать oversized Agent Task;
• уменьшить задачу по слоям, behavior, tests/implementation или discovery/edit;
• определить stop conditions;
• подготовить first task ready for agent;
• связать размер task с review и rollback.

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

Размер Agent Task - один из главных рычагов надежности AI-разработки. Чем меньше и четче task, тем проще удержать контекст, проверить результат, review'ить diff и откатить ошибку.

Маленькие tasks не должны терять общую картину. Для этого в следующем уроке мы соберем их в dependency graph.

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

1. Почему большой diff особенно опасен в AI-generated work?
2. Что означает verifiable outcome?
3. Когда нужна отдельная discovery task?
4. Какие stop conditions должен иметь agent run?
5. Почему слишком мелкие tasks тоже могут быть проблемой?

Что дальше

В следующем уроке мы научимся связывать маленькие tasks в dependency graph. Это позволит сохранить общую структуру feature и понять, какие tasks должны идти последовательно, а какие можно выполнять независимо.