Skip to content

Совместное планирование человека и агента в Work Model Planning

Этот документ объясняет, почему этап Work Model Planning в среде U.L.I. лучше работает не как монолог человека и не как автономное проектирование со стороны агента, а как совместная форма планирования, где у человека и AI есть разные, но взаимодополняющие роли.

Короткая формула этого режима:

человек удерживает смысл и high-level решения -> агент переводит это в структуру, контракты и проверяемые deliverables

Зачем нужен такой режим

На этапе Work Model Planning проект ещё не стал кодом, но уже должен перестать быть просто набором мыслей. Именно здесь возникает риск двух крайностей:

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

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

Такой подход позволяет:

  • не терять исходный замысел проекта;
  • быстрее переводить идеи в Epic Issue, Work Package и Acceptance Tasks;
  • не смешивать продуктовые решения и low-level реализацию;
  • делать план проверяемым ещё до начала implementation;
  • уменьшать шум и лишние ветвления в коммуникации.

Какая роль у человека

На этом этапе человек не должен быть "ручным компилятором" структуры и не обязан сам раскладывать проект по папкам, пакетам, state-слоям и runtime-границам.

Сильная роль человека в другом:

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

Именно человек отвечает на вопросы уровня:

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

Какая роль у агента

Агент, наоборот, не должен перекладывать на человека low-level проектирование под видом "архитектурных вопросов".

Сильная роль агента на этапе Work Model Planning состоит в том, чтобы:

  • собирать контекст из кодовой базы, задач и канонических документов;
  • переводить сырой язык идей в рабочие формулировки;
  • выделять Work Packages и Acceptance Tasks;
  • предлагать placement в репозитории и логические границы модулей;
  • отделять проверяемые deliverables от размытой активности;
  • удерживать связность между Epic, Work Packages и будущим implementation.

Именно агент должен брать на себя вопросы уровня:

  • где в репозитории будет жить новая доменная модель;
  • как разложить новую логику по мозаическому подходу;
  • какой слой должен стать runtime, а какой release-layer;
  • как превратить идею в acceptance task, который можно выполнить и проверить.

Почему разделение ответственности критично

Если человек начинает отвечать за low-level topology, planning-сессия быстро перегружается деталями и теряет темп.

Если агент начинает сам решать high-level продуктовые вопросы, система может получить технически аккуратный, но смыслово неверный план.

Поэтому на этапе Work Model Planning важно удерживать простую границу:

high-level смысл, рамка и выбор направления -> человек
low-level структура, раскладка и перевод в рабочий контракт -> агент

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

Зачем нужны [USER]-subtasks

Практическим механизмом этой границы становятся [USER]-subtasks.

Они нужны не для того, чтобы дробить работу искусственно, а для того, чтобы явно отметить места, где агенту нельзя "молча додумать" за человека.

[USER]-subtask полезен, когда требуется:

  • утвердить high-level стратегию;
  • определить продуктовую или поведенческую границу;
  • выбрать между несколькими осмысленными вариантами;
  • зафиксировать критерий качества, зрелости или допустимости.

[USER]-subtask не нужен, когда вопрос относится к:

  • размещению кода по папкам;
  • внутренней структуре пакета;
  • техническому контракту модулей;
  • low-level runtime topology;
  • implementation detail, который можно разумно спроектировать без потери смысла.

Иными словами, [USER]-subtasks нужны не для всего непонятного, а только для смысловых решений владельца направления.

Как выглядит хороший цикл такой коммуникации

Хороший цикл совместного planning выглядит так:

  1. Человек приносит сырые мысли, наблюдения, идеи и ограничения.
  2. Агент читает код, задачи, историю и канонические документы.
  3. Агент предлагает первичную структуру Epic Issue и Work Packages.
  4. Там, где есть high-level развилка, агент не угадывает, а выносит её в [USER]-решение.
  5. После ответа человека агент дорабатывает структуру, уточняет acceptance tasks и убирает лишний шум.
  6. В результате появляется не просто список идей, а рабочая модель исполнения.

В этом режиме вопросы агента не должны быть хаотичными. Они должны быть:

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

Что даёт такой режим проекту

Когда такой способ работы применён правильно, проект получает несколько важных качеств ещё до начала implementation.

1. Смысл не теряется при структурировании

Исходная идея не размывается в технических деталях, потому что человек продолжает удерживать намерение проекта.

2. План становится проверяемым

Work Packages и Acceptance Tasks формулируются так, чтобы их можно было не только обсудить, но и реально выполнить и проверить.

3. Уменьшается ложная архитектурная нагрузка на человека

Человеку не приходится решать, в какую именно папку класть модуль или как назвать runtime-root, если это не влияет на high-level смысл проекта.

4. Уменьшается риск самовольных продуктовых допущений со стороны агента

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

5. Ускоряется переход к Implementation

Когда Work Model Planning прошёл в такой форме, implementation начинается уже не с тумана, а с ясной структуры ответственности и deliverables.

Почему это особенно уместно для U.L.I.

В среде U.L.I. человек и AI работают не как "заказчик и инструмент", а как разные формы интеллекта в одной операционной системе мышления и производства.

Человек удерживает:

  • смысл;
  • направление;
  • контекст ценности;
  • критерий того, зачем работа вообще нужна.

Агент удерживает:

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

Именно поэтому эта модель совместного planning не является просто удобной техникой. Она соответствует самой логике U.L.I., где человек и AI не подменяют друг друга, а усиливают разные стороны одного цикла.

Метафора кентавра

Для интуитивного понимания этот режим можно представить как кентавра.

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

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

Сила появляется не в одной из частей, а в их согласованной связке.

Граница документа

Этот документ объясняет почему совместное планирование человека и агента на этапе Work Model Planning работает как отдельный и полезный режим.

Он не задаёт:

  • обязательный стандарт оформления [USER]-subtasks;
  • жёсткий контракт Epic Issue;
  • правила implementation;
  • правила release fixation;
  • обязательную структуру всех planning-сессий.

Если со временем этот паттерн станет устойчивой нормой в нескольких проектах, он может стать основой для более строгого principles, how-to или standard документа. Но на данном этапе его задача - именно объяснить логику и ценность такого режима работы.

Связанные документы