Agent Command Center легко принять за список чатов с агентами: открыл, посмотрел переписку, закрыл. Это первая ошибка масштаба. В Devin Desktop 2.0 Command Center - это Kanban-поверхность управления, которая собирает локальные и облачные сессии в колонки по статусу, и её задача не хранить разговоры, а показывать, где сейчас нужно решение человека. Пока вы видите в ней ленту чатов, вы пользуетесь очередью решений как мессенджером.
Наивный ход отсюда понятен: раз агентов можно запускать много, запускай много - board всё стерпит, а вы потом разберётесь. Инструмент этому подыгрывает: новую сессию завести дёшево, карточек помещается сколько угодно, и первое время кажется, что растущее число активных агентов и есть рост продуктивности. Ощущение обманчиво ровно потому, что дешевизна запуска ничего не говорит о цене проверки.
Ломается это на том, что доска устроена вокруг статуса, а не вокруг диалога. Документация прямо описывает раскладку по колонкам: агенты разложены так, чтобы с одного взгляда видеть, что сейчас в работе, что ждёт вашего внимания и что закончено. Значит, узкое место процесса - не сколько сессий запущено, а сколько из них одновременно стоит в колонке ожидания и требует решения, которое можете принять только вы. Board визуализирует именно это: очередь человеческих решений, а не список машинных разговоров.
Профессиональный механизм здесь - обращаться с доской как с очередью, а не с коллекцией. Пока агент работает, сессия заблокирована: она серая и read-only, пока агент не закончит, - то есть влезть в середину turn нельзя, и это защита от иллюзии контроля. Зато сообщение можно поставить в очередь и отредактировать до отправки (в Devin Local), а саму сессию - продублировать, чтобы проверить альтернативу, не теряя исходную. Sidebar фильтрует, сортирует и группирует сессии по workspace, у сгруппированных Spaces липкий заголовок, переименование - двойным щелчком. Всё это инструменты не общения, а диспетчеризации.
Почему так, а не одна вкладка на разговор. Агент работает асинхронно и подолгу, и держать по вкладке на каждую беседу бессмысленно: вы всё равно не следите за каждым символом. Единое нативное уведомление ОС приходит, когда сессия закончилась или ждёт ввода, - и именно оно, а не постоянный взгляд в окно, возвращает вас к нужной карточке в нужный момент. Доска существует, чтобы вы не сторожили агентов, а приходили к ним по сигналу. Поэтому Command Center и не пытается заменить редактор: закончив разбор карточки, вы возвращаетесь в код за ручной доводкой, а доска остаётся диспетчерской, а не рабочим местом.
Цена невнимания к этому различию конкретна и называется просто: concurrency без review capacity. Запустить десять агентов легко; принять десять готовых результатов с той же тщательностью, с какой вы проверяете один, - нет. Каждая непринятая, но готовая карточка - это не выполненная работа, а отложенный риск: непроверенный diff, который однажды придётся либо разобрать, либо влить вслепую. Склад таких карточек и есть настоящая стоимость избыточного параллелизма.
Оправдан параллелизм ровно до предела вашей способности проверять. Разумное число одновременно активных задач - это не сколько агентов тянет машина и не сколько колонок помещается на экране, а сколько результатов вы успеваете качественно закрыть в этом окне времени. Ниже предела board экономит переключения и держит картину целиком; выше - превращается в незаметно растущий долг.
Проверять пользу доски стоит не по числу активных сессий, а по состоянию колонки ожидания. Здоровый процесс - тот, где карточки не залёживаются в колонке внимания, а проходят в review и закрываются в темпе, с каким вы способны их читать. Признак болезни обратный: колонка готовых пухнет, а вы всё запускаете новое. Один взгляд на эту колонку честнее любого счётчика продуктивности.
Отсюда рабочий приём: у каждой карточки должно быть имя результата, а не имя сессии. Строка API pagination regression говорит, какое решение от вас ждут; New session не говорит ничего и заставляет открывать разговор, чтобы вспомнить, о чём он. Имя-результат превращает доску в читаемую очередь, где приоритет виден без входа внутрь. Это инженерный приём, а не требование продукта: система разрешает любое имя, полезным его делаете вы.
Типичный провал - мерить успех числом запущенных агентов и удивляться, что всё в работе, а ничего не готово. Симптом обычно один: колонка ожидания и колонка готовых растут быстрее, чем вы их разбираете, а новые сессии называются одинаково и неотличимы. Прежде чем добавлять ещё одного агента, посмотрите, сколько решений уже ждёт вас на доске, - чаще всего продуктивность там, чтобы закрыть очередь, а не удлинить её.