Как жить с AI-пиарами в опенсорсе

Бедные опенсорс-проекты: туда сейчас заносят какое-то бесконечное количество AI-слопных PR. Поэтому всё актуальнее вопрос – как с этим жить и как такое правильно мейнтейнить? Полностью запрещать использование AI – ну очень топорно и тупо.

Ребята из Rust тоже столкнулись с этой проблемой. В статье о новых правилах использования LLM при контрибьюте в rust-lang/rust они делятся своим заходом.

Какие вообще проблемы появились:
– Аккуратно оформленный PR больше ничего не доказывает. Раньше, если пиар сделан по всем правилам, скорее всего, человек явно постарался и приложил усилия. Теперь за таким PR может не стоять ни особых усилий, ни понимания, как, что и зачем сделано.
– Узкое место опенсорса – ревью. Тут история такая, что сейчас кодогенерация ничего не стоит. Бац-бац, пиар. А ревьюеру потом сиди, разбирайся, что к чему, а самое главное – нужно ли вообще это тащить в проект.
– Копипаст ответов LLM ломает коммуникацию. Авторы пиаров иногда просто копируют комментарии ревьюера в LLM, а ответ модели – обратно в GitHub. Получается какая-то шляпа. Для ревьюера это бессмысленный прокси-слой: если бы ему было нужно мнение модели, он мог бы спросить её сам.

Чтобы как-то направить этот поток AI-пиаров, ребята зафиксировали несколько правил:
– использовать LLM никто не запрещает: ресерчить, анализировать и проверять код, искать варианты решения и делать ревью – пожалуйста; ограничения начинаются там, где модель уже сама генерирует код для PR
– исключение – заранее согласованные некритичные изменения: сгенерированный код должен быть качественным, покрытым тестами и предварительно отревьюенным, а использование LLM нужно явно указать
– публичный LLM-текст нужно маркировать
– человеческое ревью и самостоятельная проверка остаются обязательными

Мне кажется, это неплохое начало: Rust пытается задать некую канву, не запрещая всё подряд. Насколько эти правила будут соблюдаться – отдельный вопрос: проверить, что код не AI-слопный и человек понимает, что принёс, достаточно трудоёмко.

#ai