AI научился создавать задачи быстрее, чем мы успеваем их выполнять

Ещё недавно хорошо поставить техническую задачу было заметной частью работы. Нужно было разобраться в проблеме, собрать контекст, придумать решение, декомпозировать его, описать детали.

Сегодня значительную часть этого делает AI.

Можно за час обсудить новый продукт, получить несколько архитектурных вариантов, разложить каждый на этапы и создать десятки вполне разумных задач. Для вайб-кодинга это выглядит как огромный прогресс: раньше идеи упирались в стоимость разработки, теперь многие из них можно почти сразу превратить в конкретный план действий.

Но здесь возникает новая проблема.

Создать десять задач стало почти бесплатно. Выполнить, проверить и осмыслить десять изменений — нет.

Backlog начинает расти быстрее проекта

Представим простую ситуацию. Мы обсуждаем инфраструктуру сайта и приходим к мысли, что нужен staging. AI раскладывает тему:

• создать отдельное окружение;
• настроить конфигурацию;
• подготовить базу;
• сделать preview;
• добавить deployment;
• настроить rollback;
• проверить секреты;
• добавить health check.

Через день обсуждаем работу AI-агента. Возникают ещё задачи:

• дать агенту preview;
• проверять результат до production;
• хранить состояние изменений;
• добавить автоматические проверки;
• дать человеку возможность принять результат.

Ещё через неделю обсуждаем безопасный deployment — и снова появляется набор задач.

Каждая отдельная декомпозиция выглядит разумно. Проблема в том, что она производится локально. Новый список легко создаётся без полноценного взгляда на всё, что было придумано раньше.

В результате в backlog оказываются три задачи про preview, две про staging, несколько вариантов одного deployment pipeline и десяток вещей, которые после последних изменений системы уже имеют другой смысл.

AI отлично помогает нам создавать работу. Поэтому старый подход «появилась хорошая идея — создай задачу» начинает масштабироваться слишком хорошо.

Ограничить количество задач — плохой ответ

Классическое управление предлагает ограничивать незавершённую работу. Для исполнения это разумно: если человек или команда одновременно начали двадцать изменений, вероятность закончить каждое из них действительно падает.

Но переносить это ограничение на исследование нельзя.

Одно из главных преимуществ AI как раз в том, что стало дёшево пробовать варианты.

Можно попросить:

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

Если из страха перед большим backlog мы начнём ограничивать такие исследования, то добровольно откажемся от значительной части пользы AI.

Проблема не в том, что идей и задач стало слишком много.

Проблема в том, что человеку всё труднее видеть, как они соотносятся между собой.

Большой список — неправильное представление работы

Пусть в проекте 300 задач.

Человек открывает task manager и видит 300 карточек. Можно добавить статусы, приоритеты, проекты, теги и фильтры. Но фундаментально это всё равно список.

Чтобы понять реальную картину, приходится мысленно восстанавливать связи:

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

Для десятка задач это можно держать в голове.

Для сотен — уже трудно.

AI позволяет создать сотни задач значительно раньше, чем организация научилась с ними работать.

Задачи образуют граф

Реальная работа почти никогда не является плоским списком.

Допустим, у нас есть пять задач:

1. Добавить staging.
2. Сделать preview перед публикацией.
3. Дать AI-агенту возможность проверять результат.
4. Сделать deployment pipeline.
5. Добавить отдельное окружение для экспериментов.

Если рассматривать их независимо, получится пять элементов backlog.

Но технически они тесно связаны. Возможно, ближайшее разумное изменение системы — вообще не одна из этих карточек, а более естественная точка: поднять воспроизводимое preview-окружение.

Работая над ней, мы можем полностью закрыть одну задачу, значительную часть второй и создать основу ещё для двух.

Поэтому полезнее представлять работу как граф:

                  Окружения
                 /         \
             staging      preview
                |          /    \
             deploy   AI check  experiments
                |
             rollback

Причём связи здесь богаче обычного A blocks B.

Задачи могут:

• касаться одного участка системы;
• требовать одного и того же контекста;
• использовать одно исследование;
• частично перекрывать результат друг друга;
• становиться дешевле при совместном выполнении;
• быть альтернативными способами решить одну проблему;
• терять смысл после выполнения другой задачи.

Это уже не backlog. Это task graph — карта возможных изменений системы.

Главный критерий: человек должен видеть всю картину

Сам по себе граф из 300 узлов проблему не решит. Если показать человеку 300 кружков и 800 стрелок, получится ещё менее понятный интерфейс, чем список.

Поэтому ключевая функция AI здесь — не создание графа, а его свёртка.

На верхнем уровне собственник или разработчик должен увидеть что-то вроде:

Инфраструктура
├── Воспроизводимый runtime
├── Безопасное изменение проекта
├── Deployment и rollback
└── Backup и восстановление

Это вся картина, которую сейчас необходимо держать в голове.

Если интересует Deployment и rollback, можно раскрыть эту часть и увидеть следующий уровень. А уже внутри — конкретные технические задачи, эксперименты, зависимости и результаты прошлой работы.

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

Следующую работу надо выбирать не среди карточек

Обычный task manager задаёт вопрос:

Какую задачу взять следующей?

Для большого AI-generated backlog вопрос лучше поставить иначе:

Где сейчас находится ближайшая разумная точка изменения системы?

После выбора такой точки AI может посмотреть на весь граф и ответить:

• какие существующие задачи относятся к этому месту;
• что можно закрыть одним изменением;
• что имеет смысл сделать попутно;
• что станет значительно дешевле после этого изменения;
• какие старые задачи потеряют актуальность;
• какие решения нужно принять человеку до начала работы.

Тогда единицей планирования становится не случайная карточка из backlog, а осмысленный пакет связанной работы вокруг конкретной точки системы.

AI должен не только создавать задачи, но и пересобирать их

Сейчас AI чаще используется в начале процесса:

идея → обсуждение → декомпозиция → задачи

Но гораздо важнее второй цикл:

изменилось состояние проекта
        ↓
AI анализирует весь task graph
        ↓
обновляет связи и группировку
        ↓
показывает человеку новую общую картину

Например, после внедрения новой системы окружений AI обнаруживает, что:

• две задачи фактически выполнены;
• три теперь являются одной;
• старый эксперимент больше не нужен;
• четыре задачи стало выгодно выполнить вместе;
• появилась новая ближайшая точка развития.

И человеку не приходится перечитывать весь backlog и вручную восстанавливать историю проекта.

Это особенно важно для вайб-кодинга

Вайб-кодинг резко снизил порог создания программных систем. Но вместе с этим он снизил и порог создания сложности.

Можно очень быстро получить работающий код, новые функции и новые идеи. Через несколько месяцев возникает проект, в котором было принято множество локально разумных решений.

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

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

Как выполнить эту задачу?

Но и на вопрос:

Как эта задача связана со всем остальным, что мы собирались сделать?

Для собственника бизнеса это ещё важнее. Ему вообще не нужен список из 300 технических карточек. Ему нужно понимать несколько вещей: куда развивается система, какие крупные проблемы сейчас существуют, где находится ближайшая полезная точка приложения усилий и какие последствия будет иметь выбранное изменение.

Не меньше идей, а лучшее управление ими

AI делает генерацию идей, исследований, экспериментов и декомпозицию чрезвычайно дешёвыми. Ограничивать этот поток — значит бороться с преимуществом новой технологии.

Нужен другой подход.

Пусть AI создаёт много вариантов и подробно исследует пространство решений. Но все возникающие задачи должны попадать не просто в бесконечный список, а в единый граф работы.

AI постоянно поддерживает этот граф: ищет связи, объединяет дубли, замечает устаревшие предположения, пересматривает структуру после изменений и сворачивает сотни деталей до картины, которую способен понять человек.

А человек уже делает то, в чём он действительно остаётся узким и важным звеном: видит общую картину и выбирает, куда двигаться дальше.

Возможно, следующий шаг после AI, который умеет писать код, — это не AI, который умеет создавать ещё больше задач.

Это AI, который умеет сделать огромный объём возможной работы снова обозримым для человека.