Rust и AI код: моделът проверява, но не създава

8.08

време за четене: 3 мин.

Проектът Rust записа правилото в едно изречение: езиковите модели може да отговарят на въпроси, да анализират, прецизират, проверяват и рецензират, но не и да създават. Политиката влезе в сила на 5 август и се отнася за основното хранилище на езика.

Хуманоиден робот държи лупа над отворена книга, а ръката му, посегнала към писалката, е спряна от полупрозрачна преграда

Разделителната линия минава през създаването

Формулировката в документа е кратка: „It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create." Втората опорна мисъл е също толкова пестелива: моделите работят най-добре като инструмент, с който се пише по-добре, а не по-бързо.

Разкриването на употребата е задължително и обхватът му изненадва. Покрива машинния превод от родния език, поправките на правопис, откриването на грешки и рецензирането на чужда работа. Самото разкриване се пише саморъчно, а автоматичните бележки, които някои инструменти добавят към записа за промяна, изрично не се броят за разкриване.

Авторите на политиката признават, че част от клаузите са неприложими на практика. Целта им е формулирана открито: не да се хване всяко нарушение, а да отпадне възможността за правдоподобно отричане. Остава изборът между спазване и съзнателно нарушаване, без сива зона между тях.

Защо AI код се държи на по-висок стандарт

Приетият режим за AI код стъпва на пет условия и всяко от тях стеснява прохода. Рецензентът трябва да е поел ангажимент предварително. Промяната трябва да е извън критичните за коректността части. Тестовете са задължителни, като документът не оставя пролука: ако за даден участък няма тестове, авторът или пише нови, или затваря заявката.

Забранените зони са изброени поименно. Текстовете на диагностичните съобщения, публичните коментари към документацията и бележките за безопасност се пишат от човек. Критерият при съмнение е формулиран практично: там, където грешният код не изглежда грешен, машинно генериран принос не се допуска.

Има и предпазен механизъм срещу обратния сценарий. Ако за шест седмици повече от половината слети заявки са машинно създадени, приемането им спира до връщане под този дял, с най-малко десет дни изчакване. Поводът за целия документ е прозаичен: към момента на писането в хранилището чакат 1281 отворени заявки, а рецензентите не смогват.

Обратът, който данните на curl върнаха

Очакваният разказ е, че машинно генерираните приноси заливат отворения код. През 2025 г. той беше верен. Даниел Стенберг от проекта curl описа около 20% от подадените доклади за уязвимости като машинна безсмислица, а делът на потвърдените падна под 5%. През януари 2026 г. програмата за парични награди беше закрита след 87 потвърдени уязвимости и над 100 000 щатски долара изплатени.

През април 2026 г. същият автор публикува обратното. Делът на потвърдените уязвимости се върна на нивото отпреди появата на тези инструменти, някъде към 15-16%, при два пъти повече подадени доклади. Почти всеки доклад вече минава през AI в някаква степен.

Тоест правилата на Rust не отговарят на въпроса дали моделите пишат добър код. Те отговарят на друг въпрос: кой носи отговорността и кой може да обясни какво е свършено.

Какво е преносимо в един фирмен правилник

Rust не е първият. Ядрото на Linux допуска подобни приноси, но изисква етикет за използвания инструмент и забранява на агента да подписва удостоверението за произход, защото това може да направи само човек. QEMU и NetBSD отказват такъв код изцяло. Fedora го допуска при задължително разкриване.

Преносимото ядро са три въпроса, на които всяка организация може да отговори още тази седмица. Кои части от системата остават извън обхвата, защото грешката там не се вижда. Кога употребата се обявява и пред кого. Кой поема ангажимента, че разбира резултата и може да го защити пред колега.

Разграничението между проверка и създаване е по-полезно от списък с разрешени инструменти, защото не остарява при всяка нова версия на модела.

Заключение

Правилото на Rust не е за качеството на машинния изход, а за проследимостта на отговорността. Организация, която не може да каже кой разбира даден код, има проблем с управлението, а не с инструмента.

Помагаме на български организации да въведат ясни правила за употребата на AI в ежедневната работа - от вътрешен правилник до практическо обучение на екипите. Услугите ни покриват одит, оценка на готовност, обучение на екипи и имплементация на специализирани AI автоматизации за всяка организация. Препоръчваме консултация при екипи, които вече ползват AI помощници, но нямат записано правило кой отговаря за резултата. [Свържете се с нас за консултация: academy@razvivai.se]