Предпосылки: почему был создан Nuanced
Ещё в начале года казалось, что планирование станет самой критичной частью разработки ПО с помощью AI. Убежденность в этой идее была настолько сильна, что на её основе было создано целое приложение для кодирования на рабочем столе. Nuanced мотивировалось наблюдением: AI радикально ускорил генерацию кода, но интерфейсы для работы в таком темпе отстали.
Approach Nuanced с фокусом на планирование не сработал, но открыл важное: план-режимы в целом теряют полезность. Исторически они решали две задачи: (1) предоставляли инструкции, достаточно точные для агента, и (2) помогали людям понять, что они строят.
По мере улучшения моделей первая задача становится неактуальной. Вторая остаётся критичной, но план-режимы — неправильная абстракция для неё, особенно когда параллельно работает множество агентов.
Проблема: человеческое понимание отстаёт от кода
Главный вопрос, который мотивировал разработку Nuanced, и который остаётся релевантным: как люди поддерживают когнитивное согласованное представление о системе, пока машины изменяют её быстрее, чем человек может проверить изменения?
Модели могли написать тысячи строк кода за минуты. Перед тем как осознать, что строится и зачем, разработчик наследовал огромный объём работы по поддержке. Это затрудняло понимание поведения и отладку ошибочных предположений, которые преждевременно превратились в код.
Лёгкость генерации кода срабатывала как допамин, но скрывала неудобную работу: понимание, почему что-то вообще нужно строить, действительно ли это нужно, и строгую оценку решений по продукту, дизайну и инфраструктуре. Часто продукт оказывался готов до того, как были сознательно приняты хоть какие-то продуктовые решения. Если архитектура специфицирована недостаточно, агент сам заполнял пробелы, и его способ провести границы абстракций мог создавать проблемы позже. Неправильные предположения о поведении и дизайне распространялись по файлам, зарываясь далеко под поверхность чата, и легко теривались.
Это ощущение было психологически странным — словно отключённость и зомби-подобное состояние, особенно когда приложения вроде Conductor и Codex позволили запускать агентов параллельно. Казалось, невозможно достичь глубокого понимания работы, как раньше. Это также затруднило проверку корректности результатов.
Отсутствовало ясное, интерпретируемое соединение: промпт пользователя → решение агента → код → поведение продукта. Не хотелось возвращаться к просмотру строк кода или файлов. Рассуждение о идеях на естественном языке ощущалось проще и эффективнее. Требовалось уверенно парить над кодом, не жертвуя пониманием того, как система работает.
Существующие план-режимы не ощущались достаточно совместными
Хотя план-режимы существовали, правильной абстракции для хорошего планирования не было. При переходе от Claude Code CLI к Conductor, а затем к Codex, постоянно приходилось кропотливо формировать и отшлифовывать планы без чёткого места для их итерации. Это делалось через чат: копировались куски плана в новые сообщения для редактирования (до функций аннотаций в Codex). Этот workflow копирования-вставки был неуклюжим и сложным для проработки идей при отслеживании текущего плана.
Хотелось дать планам «дом», закрепить их в рабочем процессе и превратить из мимолётных текстовых блобов, исчезающих в бэкскроллом при развитии беседы, в живой, дышащий, постоянный документ. План-режим должен был стать первоклассным примитивом, ведущим разработку, по нескольким причинам:
- нужно было понять, что делать;
- нужно было убедиться, что описание достаточно точное;
- нужно было понять, что было сделано;
- нужно было понять, когда что-то пошло не так и почему.
Реализация мечты
Представили идеальный workflow и решили воплотить его в продукт. Nuanced позволял создавать потоки (threads), где каждый поток — это чат-беседа. Пользователи обсуждали, что хотят построить, система выявляла неоднозначности и решения, требующие участия, и вместе приходили к постоянному плану перед началом реализации. Затем Nuanced реализовал план, убеждаясь, что сгенерированный код соответствует требованиям. Целью был сквозной pipeline от намерения к реализации, проверке и верификации. Это воспринималось как протез для человеческого разума (особенно для ADHD-разума), а не просто ещё одно приложение для кодирования — спроектировано было одновременно и для обучения, и для отслеживания происходящего.
Где ошибка?
Дело не в том, что идеи о пробелах в существующих инструментах или об изменении SDLC были неверны. Реализация просто не дала ожидаемое решение. Причины:
- спутали планирование с планом;
- модели стали действительно хороши;
- никто не хочет читать AI-сгенерированный текст;
- разделили планирование и построение так, что это было разрушительно.
Планирование ≠ План
Первое открытие: спутали планирование с планом. Это не одно и то же. Предположение было, что пространство для тщательного обдумывания перед реализацией ценно. Также казалось ценным сохранить это обдумывание в большом структурированном артефакте по мере развития проекта. Но ранние пользователи проявили удивительно мало аппетита к такой спецификации.
Модели стали действительно хороши
По мере улучшения моделей в понимании больших кодовых баз через контекст и память они преуспевали в исследовании репозитория и разумных предположениях. Необходимость явно инструктировать их на тщательно продуманный результат сократилась.
Изначально не рассматривалось улучшение возможностей модели как конкуренцию дизайну лучшего интерфейса для человеческого мышления, но во многом это была конкуренция. Каждое решение, которое модель могла надёжно принять самостоятельно, — это одно решение меньше, которое нужно было выявлять.
AI-сгенерированный текст мучительно читать
Спецификация содержала больше информации, но не создавала больше ясности. Спецификации были длинными. Они фиксировали важные решения и содержали много контекста, казалось полезного. Проблема: они были сгенерированы AI. Что-то в темпе и чрезмерной структурированности AI-текста делает его очень сложным для чтения. Глаза постоянно расфокусировались.
Вместо отказа от спецификации, была построена «Spec Tour», чтобы решить проблему. Идея: вместо усвоения всего документа, Spec Tour проведёт через важные части. Но это добавило слой сложности, ещё больше текста на экране, требующего внимания. Если нужно было сгенерировать краткое представление спецификации, чтобы она стала полезной, в чём смысл полного документа?
Разделили процесс, который должен быть непрерывным
Workflow был слишком линейным и последовательным:
чат → уточнение вопросами → генерация спецификации → проверка спецификации → редактирование → одобрение → реализация → проверка кода
Реальное мышление не происходит так. Разделение между этапами ощущалось искусственным и навязанным. Обычно понимаешь часть проблемы, пробуешь что-то, начальная генерация учит чему-то новому, что может заставить изменить мнение и попробовать иначе. Каждый шаг обнажает новый вопрос. Планирование и построение переплетены и возникают органичнее, чем позволяют план-режимы, особенно как они были реализованы в Nuanced. Интерфейс заставлял пользователей преждевременно «закончить думать», чтобы начать строить. После начала реализации возврат к более ранней логике в чате казался шагом назад. Не было пути обратно вверх по водопаду.
Когда смотришь, как сейчас работает Codex, граница между планированием и выполнением исчезает — они коллапсируют в одно. Ранее агенты кодирования выигрывали от workflow, где люди действовали так:
план → одобрение → выполнение
Тогда стоимость неправильного направления была значительно выше. Но по мере того как агенты лучше разбирались в системах, они также лучше действовали автономно и проверяли собственную работу. Они хороши и в пересмотре подхода после проверки результата. Это включает другой цикл:
понимание → действие → проверка → уточнение → корректировка → действие снова
Огромное количество планирования происходит внутри этого цикла, но это не обязательно должно появляться как документ под названием «план». Главная ошибка была в превращении плана в артефакт вместо проектирования процесса для улучшения человеческого понимания.
План-режим и режим построения — странное разделение
В Nuanced были план-режим и режим построения, и пользователи могли начать с любого. План-режим всегда производил спецификацию, а режим построения не заставлял в спецификацию и мог использоваться для меньших задач. Но разделение между режимами было неловким и требовало от пользователя задавать себе мета-вопрос, заслуживает ли задача планирования, а затем помнить, чтобы активировать план-режим через кнопку или горячую клавишу. Это казалось тем, что AI должна решать на основе имеющегося контекста, а необходимость помнить, какой режим нужен, добавляла когнитивной нагрузки.
Это озарение вызвало чувство, как в мемчике про midwit: простота чат-интерфейса, где планирование происходит по мере необходимости, а не по умолчанию, была действительно хороша.
Проблема понимания остаётся нерешённой
Обдумывание того, что строить, почему это важно, и оценка решений остаются критичными. Люди должны построить согласованное представление о происходящем, но большое тело AI-сгенерированного текста — неправильный интерфейс для этого. Проработка решений в чате ощущается интуитивнее, но поддержание этого понимания в актуальности по мере изменения системы — открытая проблема.
Проблема усугубляется при масштабировании от пяти агентов к сотням. Отслеживание не может означать чтение каждой беседы и просьбу объяснить каждое изменение кода. Агенты должны выявлять минимальное количество мест, где человеческое внимание может иметь наибольшее влияние, и выявлять достаточно контекста, чтобы это внимание было полезно.
Остаётся нерешённым, как помочь людям ориентироваться, пока сотни всё более способных агентов одновременно изменяют систему. Но более глубокая проблема — как люди понимают системы, навигируют сложные информационные иерархии и используют мощные инструменты — это вечная. Интерфейсы меняются вместе с поддерживающей их технологией; необходимость сделать сложность понятной остаётся.
