Claude помог довести форк OpenResearch до стабильности
После релиза OpenResearch разработчикам пришлось почти сразу заняться поддержкой форка: исправлять ошибки, о которых сообщили читатели, догонять upstream и подстраивать интеграцию ZCode под новые версии. За три недели Claude помог выпустить восемь обновлений и заметно ускорил эту рутину.
Что случилось после первого релиза
Первая версия форка с тремя новыми coding-агентами вышла 25 сентября вместе с релизом v0.3.2. Но на этом работа не закончилась: проект нужно было поддерживать, а значит — быстро реагировать на баги, синхронизироваться с основной веткой OpenResearch и исправлять то, что ломалось из-за обновлений ZCode.
Особенно показательной стала обратная связь от читателя, который написал, что форк не может пройти выбор модели в ZCode. Эта короткая жалоба помогла найти проблему, которая в первой версии проявлялась только у автора проекта.
Почему ZCode пришлось переделывать несколько раз
Дальше началась серия доработок вокруг ZCode. Сначала в форке появился отдельный вход из дашборда, понятные сообщения об ошибках и кнопка Sign in, которая запускает вход через zcode login. Потом выяснилось, что у ZCode есть несколько разных сценариев авторизации, а некоторые планы вообще работают только внутри приложения.
Проблемы оказались не только в логике входа. Оркестратор научился разбирать credentials.json, отличать чужой ключ от настоящего входа и просить пользователя авторизоваться заново, если данные не совпадают. Позже пришлось отдельно чинить выбор модели для каждого чата, чтобы параллельные сессии не перетирали настройки друг друга.
Самым неприятным сюрпризом стала версия ZCode 3.15. После обновления вход снова перестал работать, и Claude пришлось разбираться уже в изменившемся поведении самого рантайма. В итоге поддержку авторизации переписали с учётом новой схемы auth-source и особенностей запуска ZCode в Windows.
Что это даёт обычным пользователям и командам
Если смотреть практично, история показывает простую вещь: даже удачный форк быстро превращается в живой продукт, который надо сопровождать почти как полноценный сервис. Для пользователей это означает меньше сбоев, понятные ошибки и более предсказуемую работу с агентами.
Для разработчиков и небольших команд здесь важен другой вывод: ИИ может не только писать код, но и помогать тащить долгую рутину сопровождения — искать причину поломок, обновлять интеграции, править тесты и сравнивать поведение разных версий. В этом кейсе Claude за три недели сделал 33 коммита, добавил 28 тестов и помог пройти через четыре слияния с upstream.
Ещё один полезный момент — экономика. Авторы проекта посчитали, что реальные расходы составили $32, а при обычных API-ценах такая работа стоила бы больше $230. Для тех, кто ведёт продукт, это хороший пример того, как ИИ-инструмент может сильно сократить стоимость поддержки, если правильно организовать проверку и ревью.