Режим планирования мёртв

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

Эта идея захватила меня настолько, что я построил и запустил целое десктопное приложение для разработки вокруг неё. Nuanced появился из наблюдения: ИИ радикально увеличил скорость и объём генерации кода, но интерфейсы, необходимые для поддержки этого нового темпа работы, не успевали за ним.

Подход Nuanced к планированию провалился, но он также открыл мне глаза на то, что план-режимы в целом больше не так полезны. Исторически режим планирования служил двум целям: (1) он формулировал инструкции, достаточно точные для агента, и (2) помогал людям понимать, что именно они строят.

Думаю, пункт 1 стремительно устаревает по мере того, как модели становятся лучше. Пункт 2 важен как никогда, но режим планирования — это неверная абстракция для него, особенно по мере роста числа параллельно работающих агентов.

Почему я создал Nuanced

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

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

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

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

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

Было что-то в этом опыте, от чего я чувствовал себя умственно отключённым и зомбиподобным — особенно когда такие приложения, как Conductor и Codex, открыли возможность запускать больше агентов параллельно. Я ощущал, что не могу по-настоящему сосредоточиться и достичь той же глубины понимания того, над чем работаю, что была доступна раньше. Это также затрудняло проверку корректности сгенерированных результатов.

Не было никакой ясной, читаемой цепочки, показывающей связь между запросом пользователя → решением агента → кодом → поведением продукта. Это не означало, что я хотел вернуться к старым временам, когда нужно было смотреть на строки кода или на файлы. На самом деле рассуждать об идеях на естественном языке казалось мне проще и эффективнее. Я хотел уверенно парить над кодом, не жертвуя пониманием того, как устроена система.

Существующие режимы планирования не были достаточно совместными

Я чувствовал: режимы планирования существуют, но правильной абстракции для хорошего планирования нет. Переходя от Claude Code CLI к Conductor и наконец к Codex после его запуска, я обнаруживал, что методично вытачиваю и шлифую планы, не имея чёткого места для их итерации.

Я делал это через чат, а потом копировал фрагменты плана в новые сообщения для доработки (до появления функции аннотаций в Codex). Этот рабочий процесс «скопировать-вставить» казался неуклюжим и делал проработку идей мучительной, пока нужно было ещё и следить за актуальным планом.

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

1. Мне нужно было обдумать, что делать.

2. Мне нужно было убедиться, что я описал это достаточно точно.

3. Мне нужно было понимать, что было сделано.

4. Мне нужно было понимать, когда что-то пошло не так и почему.

Строим мечту

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

Затем Nuanced воплощал ваш план, следя за тем, чтобы сгенерированный код соответствовал вашим требованиям. Я хотел сквозной конвейер, начинающийся с намерения и проходящий весь путь до реализации, ревью и верификации. Я смотрел на это скорее как на протез для человеческого разума (или моего ADHD-разума), чем просто на очередное приложение для разработки: продукт был спроектирован так, чтобы одновременно инструктировать и помогать мне отслеживать, что происходит.

Почему я ошибался

Дело не столько в том, что мои идеи о пробелах в существующих инструментах или о том, как меняется SDLC, были неверными, — сколько в том, что наша реализация не дала ожидаемого решения. Причины:

• я перепутал планирование с планом

• модели стали очень хорошими

• никто не хочет читать текст, написанный ИИ

• мы разделили планирование и разработку так, что это стало разрушительным

1. Планирование ≠ план

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

2. Модели стали очень хорошими

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

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

3. Текст, написанный ИИ, тяжело читать

Спецификация содержала больше информации, не создавая при этом большей ясности. Наши спецификации были длинными. Они фиксировали важные решения и содержали много контекста, который казался полезным, — но проблема была в том, что они были написаны ИИ. Есть что-то в темпе и чрезмерно структурированной природе текста, написанного ИИ, что делает его очень сложным для чтения. Мои глаза раз за разом стекленели.

Вместо того чтобы отреагировать на это открытие, убив спецификацию, мы построили Spec Tour как решение. Мы думали, что вместо того, чтобы просить кого-то усвоить весь документ, Spec Tour проведёт его через важные части. Но это лишь добавило дополнительный слой сложности — ещё один текст на экране, требующий внимания.

Если нам нужно было создавать сокращённое представление спецификации, чтобы сделать её пригодной для использования, зачем вообще был нужен полный документ?

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

Наш рабочий процесс был слишком линейным и последовательным. Он выглядел примерно так:

чат → устранение неоднозначностей → генерация спецификации → ревью спецификации → доработка спецификации → согласование → реализация → ревью кода

Реальное мышление устроено иначе, и разделение между этими частями казалось искусственным и вынужденным. Обычно вы понимаете часть проблемы, пробуете что-то, начальная генерация учит вас чему-то новому, что может заставить вас передумать и попробовать что-то другое. Каждый шаг открывает новый вопрос. Планирование и разработка переплетены и возникают органичнее, чем позволяют план-режимы, — особенно в том виде, в котором мы реализовали это в Nuanced. Наш интерфейс вынуждал пользователей преждевременно «заканчивать думать», чтобы начать строить. После начала реализации возвращение к прежнему чат-рассуждению ощущалось как движение назад по рабочему процессу. Подняться обратно по водопаду было невозможно.

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

план → согласование → исполнение

Тогда цена движения в неверном направлении была значительно выше. Но по мере того как агенты лучше понимают системы, они также становятся лучше в автономных действиях и тестировании собственной работы. Они хорошо пересматривают свой подход, изучив результат. Это открывает другой цикл:

понять → действовать → проверить → уточнить → скорректировать → действовать снова

В этом цикле по-прежнему происходит огромное количество планирования, но оно не обязательно должно выглядеть как документ под названием «план». Думаю, самая большая ошибка, которую я совершил, — превратить план в артефакт вместо того, чтобы проектировать процесс для улучшения человеческого понимания.

5. Режим планирования и режим разработки — странное разделение

В Nuanced был режим планирования и режим разработки, и пользователи могли начинать с любого из них.

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

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

Это осознание заставило меня почувствовать себя персонажем мема «мидвит»: оказывается, простота чат-интерфейса, где планирование происходит по необходимости, а не по умолчанию, была на самом деле отличной.

Проблема понимания до сих пор не решена

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

Эта проблема усугубляется по мере перехода от пяти агентов к сотням. Не отставать не может означать чтение каждого диалога и попытку получить объяснение каждого изменения кода. Агенты должны находить те немногие точки, где человеческое внимание может принести наибольшую пользу, и выводить на поверхность достаточно контекста, чтобы это внимание было продуктивным.

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

Что дальше: треды и мультиагентность

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

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

Если вы раньше не слышали про OpenIDE, но пользуетесь IntelliJ IDEA, WebStorm, GoLand, PHPShtorm или PyCharm, попробуйте нашу мультиязычную IDE на базе IntelliJ Platform. В сборку OpenIDE Pro входит и наш AI-плагин для работы с разными агентами.