Rust приймає формальну політику щодо LLM для свого головного репозиторію

П’ять команд у проєкті Rust прийняли офіційну політику, що регулює, як великі мовні моделі можуть використовуватись під час внесення змін до rust-lang/rust, головного монорепозиторію проєкту, Джинн Нельсон, автор політики, оголосив у блозі Inside Rust 5 серпня 2026 року. Політика (затверджена командами компілятора, бібліотек, типів, rustdoc та bootstrap) замінює те, що Нельсон називає неопублікованим «дико‑західним» підходом до модерації, публічним, письмовим набором правил.

Політика не є загальним позиціонуванням проєкту щодо ШІ і це чітко зазначено. Вона застосовується лише до репозиторію rust-lang/rust і лише до команд, які її ратифікували. Проте в межах цього діапазону вона проводить чітку межу: LLM‑и вітаються як інструменти для мислення, а не як його заміна.

Що саме говорить політика

Документ підсумовує себе в одному реченні:

Дозволено використовувати LLM‑и для відповіді на питання, аналізу, уточнення, вдосконалення, перевірки, пропозицій, рев’ю. Але не для створення.

На практиці це створює три рівні. Дозволено без обмежень: будь‑яке приватне використання, коли лише автор бачить результат — задавання питань щодо коду, підсумовування обговорення, приватне рев’ю власного коду. Дозволено за умови обов’язкового розкриття: машинний переклад, тривіальні зміни типу виправлення помилок, допомога LLM у виявленні багів та боти‑рев’ю, які мають працювати з окремих, чітко позначених облікових записів GitHub, які індивідуальні користувачі можуть блокувати. Заборонено: коментарі, документація та діагностика компілятора, створені LLM; будь‑який процес, що вимагає виконання LLM; а також розгляд LLM‑рев’ю як достатньої підстави для злиття або відхилення зміни.

Найбільш суворі вимоги містяться в механізмі виконання. Навмисне приховування використання LLM вважається порушенням Кодексу поведінки проєкту — на тому ж рівні, що й домагання — і передбачає попередження, а при повторних порушеннях — блокування. У документі явно зазначено, що багато його пунктів практично не підлягають примусовому виконанню, і це навмисно: «Наша мета не в тому, щоб спіймати кожне порушення… Натомість ми прагнемо усунути можливість виправдовувань, змусивши вибирати між дотриманням політики та навмисним її порушенням».

Обмежений експеримент щодо коду, написаного LLM

Код, створений LLM, не заборонений одразу. Він обмежений експериментом з суворими умовами входу: зміни мають бути попередньо узгоджені з названим рев’юером, не критичними для коректності компілятора, добре протестованими та ретельно переглянутими, причому розкриття має бути вказано у кожному випадку. Нові учасники не можуть відкрити pull‑request, створений LLM, без попереднього затвердження рев’юера. Якщо для зміненого коду немає тестового набору, автор зобов’язаний написати його або закрити PR. Виключень немає.

Експеримент має власний «аварійний вимикач». Якщо більше половини PR‑ів, злитих за шести‑тижневий період, створені LLM, злиття таких PR‑ів припиняються, доки частка не впаде нижче 50 %, з мінімальним охолодженням у десять днів. Цей період збігається з шести‑тижневим циклом випуску Rust. Усі такі PR‑и отримують нову мітку ai-assisted і публікуються у приватному каналі Zulip, метою якого є збір даних (чи навчаються, повертаються та створюють корисну роботу учасники, які користуються LLM), а не контроль доступу.

Чому саме зараз

Оголошення Нельсона описує три тиску, які спонукали команди перейти від неформальної модерації до письмових правил. Відполіровані pull‑request’и більше не сигналізують про зусилля чи розуміння, що підриває довіру, на якій базується культура рев’ю проєкту. Дешевша генерація коду посилює вже існуючу нестачу пропускної здатності рев’ю: у репозиторії зараз 1 281 відкритий PR, а обмеженим ресурсом завжди була оцінка рев’юера, а не код. І учасники, які відповідають на коментарі рев’ю, копіюючи їх у LLM і вставляючи отриманий результат назад, за словами Нельсона, «витрачають час усіх» і руйнують припущення, що рев’юер спілкується з реальною людиною.

Тло — це справжній розкол всередині проєкту. У розділі «Мотивація» політики зазначено, що в Rust немає консенсусу, «і, ймовірно, його ніколи не буде», щодо того, коли інструменти на базі ШІ є прийнятними, причому учасники коливаються від щоденних користувачів до тих, хто вважає будь‑яке використання неприйнятним. Тому документ спроектовано так, щоб його можна було змінювати: великі ревізії вимагають підпису кожної ратифікуючої команди, а політику можна повністю скасувати цими командами або замінити проєкт‑широкою комісією LLM, яку зараз розглядає радова рада керівництва.

Дрібний шрифт

Обсяг обмеженіший, ніж заголовок натякає. Політика не охоплює інші репозиторії в організації rust-lang, роботу language‑team, таку як відстеження проблем і звітів про стабілізацію, стиль‑гід або команди, які її не ратифікували. Кожна з них вільна встановлювати власні правила. Члени організації rust-lang звільнені від обмеження «не критичний» щодо коду, створеного LLM, хоча політика наполягає, що це виключення слід уникати, і PR‑и, написані до набрання політики чинності, також звільнені. Пряме залякування учасника за використання LLM заборонено, незалежно від того, чи порушило це політику.

Що буде далі

Приватний канал Zulip починає збирати дані про PR‑и, створені LLM, одразу після того, як мітка ai-assisted почне використовуватись, а перший шести‑тижневий «аварійний вимикач» покаже командам, чи експеримент переважає чергу злиття. Пропозиція радовиці керівництва щодо створення спеціальної комісії LLM, якщо вона буде сформована, матиме перевагу над цією політикою і може розширити правила на весь проєкт, охоплюючи чати, форуми та репозиторії, які сьогодні зовсім не мають політики. Пост Нельсона аргументує саме такий результат, позиціонуючи цю політику як перший крок, а не остаточну відповідь.