С AI проще форкнуть, чем договориться?

С AI небольшую правку в чужой библиотеке иногда быстрее сделать, чем оформить для неё хороший issue.

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

Обычно дальше следует возражение: свою версию придётся поддерживать. Но AI помогает и с обновлениями. Если это тоже становится проще, зачем тратить силы на согласование правки с авторами оригинала?

Мне интересен именно этот выбор. Что мы получаем вместе с общей версией и в какой момент своя доработка становится разумнее ожидания? Начну с небольших библиотек с несколькими нужными изменениями. Под форком здесь понимаю версию зависимости, которую мы оставляем в продукте и дальше сопровождаем.

Код готов, а решение ещё не принято

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

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

У tldraw ограничили приём внешних PR. Команда объяснила это ростом сгенерированных изменений с неполным контекстом и недостаточным участием отправителей в дальнейшем обсуждении. Issues и сообщения об ошибках остались открыты. Для сопровождающих даже формально корректный код создавал работу.

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

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

Если агент умеет обновлять форк

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

Инструменты этого процесса опубликованы в cohere-ai/vllm-skills. Это набор инструкций для агента: auto-rebase находит новый релиз оригинала, запускает перенос собственных коммитов, разрешение конфликтов и повторные проверки с исправлениями. Человек задаёт проверки и подтверждает обновление. Набор рассчитан на vLLM; для другого проекта потребуется адаптация под его окружение и проверки.

При этом тесты, проверки производительности и качества у Cohere существовали заранее. У агента был способ обнаружить поломку и проверить исправление. Человек смотрел итог. Подготовка такой проверки тоже входит в цену сопровождения.

Есть и подробный разбор сопровождения форка OpenResearch на Хабре. Автор описывает обновления вместе с Claude и ошибки, проявившиеся у других пользователей. Каждую сборку он проверял сам на Windows с настоящими аккаунтами. Автоматизация переноса изменений и проверка продукта в реальном окружении остаются разными частями работы.

Если мы умеем проверять нужное поведение после обновлений, запрет на форк «потому что потом замучаемся» уже требует объяснения. Возможно, несколько своих изменений действительно проще поддерживать, чем большой обход вокруг чужого API.

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

Сценарии, о которых мы не подумали

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

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

Агент тоже может предложить дополнительные сценарии. Мне всё равно важно понимать, на чём основана уверенность, что мы охватили нужные случаи. Зелёные тесты отвечают на те вопросы, которые в них заложили.

Поправили таблицу и сломали соседнюю строку

В pyinfra строки с китайским, японским и корейским текстом сбивали выравнивание таблицы в терминале. Код считал количество символов, хотя широкие символы занимают по две экранные позиции.

В разборе Lawrence Liu агент исправил подсчёт ширины. Нужные строки выровнялись. Зато строки с составными emoji, включающими оттенок кожи, стали отображаться хуже: новая логика завышала их ширину. Автоматическое ревью эту регрессию пропустило.

Автор обнаружил её перед отправкой изменения в оригинальный проект. Решение переработали с использованием готовой функции из rich, добавили проверки. История первой версии и финальное исправление описаны в принятом PR.

В итоге исправление вместе с проверками вошло в общую ветку проекта. Другие пользователи смогут получить его вместе с обновлением библиотеки.

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

Что я бы оставил у себя

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

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

Собственное исправление известного бага вполне может сделать нашу версию надёжнее. Решение о форке для меня зависит от конкретной пользы и от работы, которую мы готовы за неё взять.

5 вопросов перед своим форком

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

• Можно ли решить задачу настройкой или расширением? Если нужен форк, что именно в нём будет отличаться?

• Какие соседние сценарии может задеть правка? Чем проверим их после обновлений и сколько будет стоить поддержка этих проверок?

• Кто отвечает за обновления и ошибки нашей версии? Какую часть работы уже можно поручить агенту?

• При каких условиях мы удалим свой патч? Можно ли предложить его оригиналу и приемлем ли для нас отказ?

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

Пока мы обсуждаем несколько правок в библиотеке. Но мне кажется, со временем тот же вопрос станет привычным для целых систем: оставить свою версию открытой CRM или собрать сервис под процессы команды вместо подписки на SaaS.

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

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

Ближайший практический шаг здесь гораздо меньше: проверить, действительно ли нужная функция требует своей версии библиотеки. В «НейроCTO» продолжу на конкретном примере: как мы с агентом проверили недостающую функцию в mitt на 3 версиях и обошлись без изменения самой библиотеки.