После обновления до rsync 3.4.3 у части пользователей перестали нормально работать инкрементные бэкапы, и история быстро вышла за рамки обычного баг-репорта. В центре спора оказался AI-код в rsync: пользователи нашли в истории проекта десятки коммитов с упоминанием Claude, а дальше началась вполне предсказуемая дискуссия о том, можно ли подпускать генеративные модели к инфраструктурному софту, на котором держатся резервные копии, NAS, скрипты и половина скучной, но критичной Unix-рутины.
О проблеме сообщает The Register. Издание пишет, что спор вспыхнул вокруг релиза rsync 3.4.3, выпущенного в 2026 году как security-focused обновление для исправления нескольких уязвимостей. Вскоре после апдейта пользователи начали жаловаться на регрессии: один из них описал ситуацию так, что его система резервного копирования фактически перестала работать на всем, кроме полного бэкапа. Для утилиты, которую десятилетиями ценят именно за предсказуемость, это уже неприятно. Но дальше стало интереснее: в истории коммитов заметили, что начиная с версии 3.4.1 у проекта накопились десятки изменений с подписью «tridge and claude».
Этого оказалось достаточно, чтобы обычный технический разбор превратился в публичную перепалку о том, как именно ИИ используется в open source. На GitHub появился пост с эмоциональным заголовком в духе «пожалуйста, не доломайте это ПО вайб-кодингом», а затем обсуждение переехало на Reddit и Hacker News. Сам по себе нерв понятен: rsync не похож на модный пет-проект, где неудачный эксперимент бьет только по локальной сборке автора. Это инструмент из 1990-х, встроенный в бесчисленные продукты, админские сценарии и корпоративные процессы. Когда в такой кодовой базе всплывает AI-код в rsync, реакция у сообщества куда жестче, чем в очередном AI-first стартапе.
Создатель rsync Эндрю Триджелл от критики не отмахнулся, но и обвинения в духе «отдали проект модели и пошли пить чай» тоже не принял. В посте с говорящим названием Rsync and Outrage он признал, что в rsync 3.4.3 действительно появились регрессии, затронувшие некоторые сценарии резервного копирования. По его словам, это были «валидные, но необычные» кейсы, которых не было в существующем наборе тестов. Триджелл извинился перед теми, кого задело поведение новой версии, но отдельно подчеркнул: речь не о бездумной генерации кода по промпту. Он прямо написал, что не просто «vibe-coded» перевод тестового набора на Python и напомнил, что занимается разработкой уже 40 лет.
Ключевой аргумент Триджелла в том, что наиболее заметная AI-часть работы относилась не к ядру rsync, а к переработке старого тестового хозяйства. По его версии, он сам спроектировал новый фреймворк, а Claude, OpenAI Codex и Gemini использовал для черновой и рутинной работы при переносе ветхого shell-based тестового набора на Python. Затем результат проверялся вручную. Это важная деталь, потому что она чуть охлаждает самый простой нарратив про «нейросеть сломала бэкапы». Формально претензия пользователей не в том, что AI-код в rsync писал основную логику синхронизации, а в том, что участие ИИ вообще появилось в проекте такого класса, да еще рядом с релизом, после которого поплыли рабочие сценарии.
Но защита у Триджелла не ограничивается рассказом о том, кто именно писал тесты. Он говорит и о другой стороне истории: сопровождать зрелый open source стало заметно тяжелее из-за лавины security-репортов, среди которых все больше AI-сгенерированных. Иначе говоря, генеративные модели уже меняют не только код, но и поток входящего шума, который разработчикам нужно фильтровать, перепроверять и разгребать. Для крупных open source-проектов это плохая комбинация. С одной стороны, ИИ обещает ускорить рутину. С другой, он же раздувает объем сомнительных сигналов, на обработку которых у мейнтейнеров и так не было лишних часов. На этом фоне желание использовать ИИ хотя бы для тяжелой, но механической работы выглядит уже не капризом, а способом вообще не утонуть.
Для разработчиков и ИТ-команд здесь важен не только моральный спор про «можно или нельзя», а вполне прикладной вывод. Чем критичнее софт, тем выше цена не самого факта применения ИИ, а непрозрачности процесса. Если инструмент лежит в основе бэкапов, CI-пайплайнов, NAS-устройств или внутренних операций, пользователям мало услышать, что «модель помогала». Им нужны понятные границы: где именно ИИ применялся, кто проверял результат, какие тесты покрывают нетиповые сценарии и как быстро мейнтейнеры реагируют на регрессии. История с rsync показывает, что доверие к инфраструктурному open source теперь надо поддерживать не только качеством кода, но и качеством объяснения, как этот код вообще появляется.
Триджелл, судя по его словам, от AI-инструментов отказываться не собирается и смотрит уже в сторону более крупного релиза rsync 3.5 с упором на безопасность. Заодно он уколол тех, кто на эмоциях заговорил о переходе на openrsync из OpenBSD: новая тестовая система rsync, по его словам, показывает у альтернативной реализации десятки падений. Это не отменяет сбой в 3.4.3, но задает неприятный для критиков вопрос: готовы ли они требовать полного отказа от ИИ в инфраструктурном ПО, если без него сопровождение такого кода становится еще медленнее и дороже. Похоже, следующий большой спор в open source будет уже не про сам факт использования моделей, а про правила допуска: где ИИ уместен, где нет, и кто берет на себя ответственность, когда после «черновой помощи» ломаются не демо, а реальные бэкапы.