Fade - терминальный инструмент для кодинга, который запускает двух AI-агентов одновременно. Один агент ведёт с вами диалог: читает проект, отвечает на вопросы и помогает планировать. Второй, Builder, пишет код в боковой панели рядом с чатом. Автор проекта - разработчик под ником MuzafferMahi, он выложил Fade на GitHub и описал его в посте на r/LocalLLaMA.
Ключевая идея проста: не ждать завершения хода. Пока Builder работает над одной задачей, можно планировать следующее изменение, задавать вопросы или менять решение. Всё, о чём вы договорились с диалоговым агентом, встаёт в очередь и будет подхвачено, когда Builder освободится.
Статус проекта - v0.5, лицензия MIT. Автор прямо называет его ранним и «сырым», так что это скорее площадка для эксперимента, чем готовый рабочий инструмент.
Что такое Fade и зачем он нужен
Привычные AI-ассистенты для кода работают в одном потоке: вы пишете запрос, ждёте ответ, проверяете результат, пишете снова. Fade разводит две роли по разным агентам и позволяет не простаивать во время генерации.
Два агента вместо одного: диалог и Builder
Диалоговый агент читает проект, отвечает на вопросы о коде и помогает планировать. Builder занимает боковую панель и пишет код. Оба работают одновременно в терминале, отдельного графического интерфейса нет.
Разделение даёт побочный эффект: пока Builder занят правкой одного модуля, диалог остаётся свободным. Можно спросить, как устроена конкретная функция, обсудить следующий шаг или переиграть решение. В обычном однопоточном ассистенте такой вопрос встал бы в конец очереди и ждал генерации кода.
Кому и зачем это может быть полезно
Инструмент рассчитан на разработчиков, которые уже используют AI-ассистентов и хотят попробовать open source AI-агента для кодинга с нестандартным рабочим процессом. Вторая группа - пользователи локальных моделей: Fade работает с любыми моделями, которые поддерживает Pi, включая запущенные через llama.cpp. Третья - те, кто встраивает AI-агентов в автоматизацию кодинга и ищет, как устроить очередь задач и машинные проверки.
Обещаний «ускорения в N раз» здесь нет и быть не может: независимых замеров продуктивности по Fade не публиковалось. Автор сам задаёт сообществу открытый вопрос о том, помогает ли такой режим в реальной работе.
Как работает режим «разговора во время работы»
Сценарий, вокруг которого построен Fade: Builder пишет код, а вы в это время продолжаете разговор. Можно планировать следующую функцию, спрашивать, как работает существующий код, или менять уже согласованное решение. Интерфейс не блокируется и не заставляет ждать ответа.
Очередь задач: как согласованное изменение попадает к Builder
Когда вы согласовали изменение в диалоге, задача встаёт в очередь. Builder подхватывает её автоматически, как только освободится от предыдущей. Деталей реализации очереди автор не раскрывает: неизвестно, как приоритизируются задачи и что происходит при конфликте двух правок в одном файле.
Практический смысл в том, что ввод и выполнение разведены по времени. Вы не простаиваете в момент генерации, а занимаетесь планированием. Похожие задачи решают оркестраторы, где сессии агента запускаются пачками: разбор оркестратора задач на git worktree и CLI-сессиях показывает, как выглядит такая схема в более крупном масштабе.
Когда Fade всё-таки прерывает пользователя
Fade прерывает только когда это нужно. Работа, которая прошла свои проверки, фиксируется самостоятельно, без остановки и подтверждений. Если тест не может решить вопрос, он приходит к вам одним простым вопросом. Пример из описания автора: «Does the help text feel friendlier?»
То есть машиночитаемые решения остаются машине, а вкусовые и продуктовые - человеку. Граница разумная, но на практике она зависит от того, насколько корректно Builder формулирует доказательства и что именно он считает проверяемым.
Доказательства, git-коммиты и автоматические проверки
Для каждого изменения Builder пишет «доказательство»: тест или команду. Fade коммитит изменение, а затем сам перезапускает эти проверки на этом коммите. Одна и та же проверка выполняется уже после фиксации, а не на промежуточном состоянии рабочей копии.
Что такое «доказательство» изменения
Доказательство - это тест или команда, которую Fade перезапускает на коммите. Формальной верификацией это не назвать: речь о практическом способе убедиться, что изменение не сломало ожидаемое поведение. Если готового теста нет, агент подбирает команду, которая подтверждает результат.
Подход опирается на простую мысль: машинная проверка каждого шага дешевле, чем разбор большого диффа руками. Почему проверка результата стала дороже самой генерации кода и как с этим работать, разбирается в материале о том, почему разработка с AI-агентами не ускорилась.
Что происходит при провале проверки
Если проверка не проходит, работа возвращается Builder вместе с реальным выводом ошибки. Это цикл обратной связи, а не молчаливый откат: агент видит текст падения и правит код с его учётом.
Каждое изменение - отдельный git-коммит, поэтому отмена работает всегда. Пользователю достаточно написать «undo that», «show me the diff» или «stop».
Модели: Pi, llama.cpp и разделение на диалог и сборку
Fade работает с любой моделью, которую поддерживает Pi, включая локальные через llama.cpp или иначе настроенные через Pi. Два агента могут использовать разные модели: диалоговому агенту и Builder можно назначить отдельные бэкенды.
Почему для диалога и сборки имеет смысл брать разные модели
Диалог требует понимания контекста проекта и планирования, поэтому сильная модель здесь оправдана. Сборка - более рутинная работа, и автор отмечает, что комбинация сильной модели для разговора и более дешёвой для сборки работает хорошо. Это наблюдение автора, а не результат замеров на бенчмарках.
Логика простая: платить за дорогую модель на каждой правке накладно, а ошибки планирования стоят дороже, чем лишний проход по коду. Насколько эта экономия ощутима на конкретном проекте, зависит от объёма правок и цены токенов у выбранного провайдера.
Локальный запуск через llama.cpp
Локальные модели через llama.cpp поддерживаются, если они доступны через Pi. Пошаговых инструкций по установке Fade и настройке Pi автор не даёт, и мы их не приводим: таких данных в источнике нет.
Есть ли смысл ждать от локальной модели того же качества, что от облачной, в контексте Fade - вопрос открытый. Сравнений качества работы Fade на локальных и облачных моделях не публиковалось. При этом опыт запуска 27B модели на двух GPU для агентского harness показывает, каких ресурсов требуют подобные сценарии локально: разбор марафона по кодингу на llama.cpp с tensor-split.
Управление без режимов и горячих клавиш
В Fade нет режимов и горячих клавиш, которые нужно заучивать. Управление - это обычный текст: «yes», «undo that», «show me the diff», «stop». Любое действие выражается фразой.
Порог входа получается низким: не нужно разбираться в комбинациях клавиш и состояниях интерфейса. Обратная сторона - необходимость понимать, что именно делает агент. Без явных переключателей между планированием и выполнением фазу работы приходится определять по контексту, а не по индикатору в статусной строке.
Ограничения и статус проекта: что важно знать до установки
Fade - версия v0.5 под лицензией MIT. Автор описывает проект как ранний и «сырой» (undercooked). На практике это означает возможные баги, нестабильность и отсутствие подробной документации. Ждать продакшн-готовности от v0.5 не стоит.
Данные о проекте взяты из поста автора. Независимой проверки нет, замеров продуктивности нет, roadmap и даты релизов автор не публикует.
Открытый вопрос автора: фокус или ожидание
MuzafferMahi прямо спрашивает сообщество: помогает ли разговор во время работы удерживать фокус и быть продуктивнее, или пользователи предпочли бы просто ждать. Это не риторическая фигура речи, а честно поставленный вопрос без ответа.
Отсюда практический вывод: режим «разговора во время работы» стоит проверять на своих задачах, а не принимать на веру. Тем, кто уже экспериментирует с оркестрацией агентов и структурой промптов, полезно сравнить подход Fade с более статичными схемами: методология, заменяющая оркестрацию структурой директорий решает ту же задачу удержания контекста другими средствами.
Стоит ли пробовать Fade: практический вывод
За Fade говорят открытый код под MIT, поддержка локальных моделей через Pi и llama.cpp, разделение моделей для диалога и сборки, автоматические проверки на git-коммитах и управление обычным текстом без режимов. Против: статус v0.5, признание автора в «сырости», отсутствие данных о реальной продуктивности и открытый вопрос о влиянии режима на фокус.
Перед установкой ответьте себе на несколько вопросов:
- Готовы ли вы работать с ранним инструментом и мириться с возможными багами?
- Нужен ли вам локальный запуск моделей через llama.cpp или Pi?
- Готовы ли вы разбираться в поведении агента без подробной документации?
- Есть ли у вас проект, где результат изменения можно описать тестом или командой?
- Готовы ли вы вместо ожидания переключаться на планирование следующего шага?
Если на большинство вопросов ответ «да», Fade имеет смысл поставить и попробовать на небольшом проекте, где цена ошибки невелика. Если нет, разумнее следить за развитием проекта и за тем, появится ли у режима «разговора во время работы» подтверждение практической пользы.