Vim připouští kód z LLM, dva forky ukazují, jak těžká bude údržba

Správci hlavního Vimu šli jinou cestou než autoři nových forků. V CONTRIBUTING.md mají pravidlo pro příspěvky vytvořené s pomocí AI: použití má být přiznané, kód má odpovídat stylu Vimu a změny mají být otestované. V repozitáři leží také soubor AGENTS.md s instrukcemi pro AI agenty při práci na kódu. Popisuje sestavení, testy, styl C i Vim9 a v části o formátu commitů výslovně uvádí, že přiznání spoluautorství je přijatelný způsob, jak transparentně uvést AI asistenci. Vim tím z LLM asistence dělá popsaný pracovní postup, nikoli mlčky tolerovaný soukromý nástroj přispěvatele.

Vim připouští LLM, pokud je podíl přiznaný

Podle LWN se spor rozběhl už před úpravou pravidel, kdy Brian Carbone tvrdil, že některé starší příspěvky mohly být připraveny s pomocí LLM. Správce Vimu Christian Brabandt tehdy tuto interpretaci nepovažoval za objektivní. Spor ale skončil pravidlem, že asistence LLM je pro projekt přijatelná, pokud je transparentně uvedená, výsledná změna zapadá do stylu Vimu a je řádně otestovaná.

Pravidlo se pak objevilo i u konkrétních změn. V pull requestu #19144, který upravoval runtime soubor pro Sieve, autor napsal, že změnu připravil a otestoval s pomocí nástroje Claude Code 2.1.2 s modelem Claude Opus 4.5. Brabandt ji tentýž den přijal a uzavřel commitem fc00006.

Hlavní projekt dál vyvíjí editor a neudržuje jen starý kód. Řada Vim 9.2 mezitím přinesla další rozšíření Vim9 skriptu, vylepšený diff režim, změny v doplňování, experimentální podporu Waylandu, úpravy pro Windows GUI a nový :Tutor. Fork se v takovém prostředí rychle dostane od otázky původu kódu ke kompatibilitě, testům a přípravě balíčků. Každý rozdíl proti hlavnímu Vimu se časem projeví v opravách, balíčcích a kompatibilitě pluginů.

Změna s LLM asistencí způsobila regresi

Spor by byl jednodušší, kdyby bylo možné ukázat, že kód s LLM je vždy špatný a kód bez LLM je bezpečný. Jenže takhle chyby v editoru nevznikají. Lepší argument proti lehkému přijímání asistence LLM proto není obecná obava, ale doložená regrese.

Hlášení #20041 ve Vimu popisuje chybu po commitu 9e55474, tedy záplatě 9.2.0224, která byla označena spoluautorstvím Claude Sonnet 4.6. Změna rozbila některé víceřádkové výstupy channel callbacků a projevila se například ve vim-fugitive, kde se výstup :Git status spojil do jednoho řádku. Ohlašovatel v hlášení přímo píše, že podobné případy vysvětlují obavu z kódu generovaného LLM, zvlášť když v původním pull requestu není vidět mnoho revize.

Záplata 9.2.0412 chybu odstranila, ale sama je označena spoluautorstvím Claude Opus 4.7. Regresi tedy způsobila změna s přiznanou asistencí LLM a odstranila ji jiná změna se stejným typem přiznání.

Z dostupných údajů neplyne, že chybu způsobil samotný model. Chyby se do editorů dostávaly dávno před LLM. Slabina přijaté politiky leží jinde: pokud se změny s AI asistencí slučují stejně hladce jako drobné lidské opravy, musí projekt přidat na testech, regresních scénářích a odpovědnosti autora. Přiznané spoluautorství s Claudem samo o sobě není technická kontrola, ale značka původu.

Hlavní Vim má v této chvíli pravidla popsaná jasněji než oba mladé forky. Veřejně sepsal pravidlo v CONTRIBUTING.md a navazující pracovní instrukce v AGENTS.md. U EVi a Vim Classic je deklarované odmítnutí jasné. V odkazovaných veřejných podkladech ale zatím není stejně konkrétně popsáno, jak se má původ změn dokládat, co se považuje za porušení důvěry, jak se bude rozhodovat o přebírání oprav z hlavního Vimu a kdo ponese odpovědnost za bezpečnostní zpoždění.

EVi chce novější Vim bez kódu od LLM

EVi vzniklo jako přímá reakce na používání Claude Code u Vimu. Zakladatelský text The Story of EVi popisuje osobní impuls: mít vlastní kopii Vimu bez „AI slop“. Chce pokračovat ve Vimu bez změn, které považuje za kontaminované asistencí LLM.

Výchozí verze se během prvních dnů měnila. Projekt původně vycházel z v9.1.0, později se objevovala úvaha o novější revizi před prvním problematickým commitem, následně se EVi vrátilo zpět k v9.1.0, protože i pozdější verze začala být pro část komunity podezřelá.

Verze 9.1 drží EVi blízko modernímu Vimu, ale zároveň zvyšuje tlak na průběžné vybírání oprav. Z hlediska pluginů, runtime souborů a uživatelských očekávání je to menší skok než návrat do éry před Vim9. Blízkost hlavního Vimu ale znamená, že každou změnu z původního projektu je nutné posoudit technicky i podle původu.

EVi tím naráží na problém, který samotný zákaz LLM neřeší. Údržba začíná ve chvíli, kdy dorazí oprava pádu nebo bezpečnostní chyby, jejíž původní commit má v metadatech uvedeného Claude. Převezme se změna, když ji člověk zkontroloval? Přepíše se od nuly podle popisu chyby? Počká se na jiného přispěvatele? V těchto detailech se z postoje stává proces údržby.

Vim Classic se vrací před Vim9

Vim Classic volí ostřejší řez a vydání verze 8.3 popisuje fork Vim 8.x pro dlouhodobou údržbu a uvádí výchozí verzi 8.2.0148, tedy poslední stav před příchodem Vim9. Drew DeVault tím záměrně snižuje rozsah toho, co chce projekt udržovat. Vim9 považuje za příliš velký závazek pro malý fork, který nechce jen kopírovat dnešní hlavní Vim.

Technicky je to poctivější než představa, že malý tým bez dalších nákladů udrží celý moderní Vim. Současně tím vzniká jiný problém. Vim Classic se vědomě vzdává části kompatibility s novějšími pluginy a funkcemi. Projekt sám píše, že některé pluginy s Vim Classic kompatibilní nebudou. Jestliže část uživatelů používá Vim hlavně jako stabilní terminálový editor s vlastním .vimrc, nemusí je to mrzet. Kdo má konfiguraci postavenou na novějším runtime a Vim9 skriptu, dostane jiný editor, byť se jmenuje skoro stejně.

Nejvážnější je otázka bezpečnosti. Oznámení Vim Classic přiznává, že správci posuzovali opravy CVE mezi verzí 8.2 a dnešním Vimem, ale nemohou zaručit, že zachytili všechny použitelné a prakticky zneužitelné opravy. Je to férové sdělení a zároveň přesné pojmenování rizika, které nese každý konzervativní fork aktivního projektu.

Fork je závazek k údržbě

Historie open source zná úspěšné forky, které začínaly politickým nebo technickým nesouhlasem. LibreOffice má za sebou instituci, Devuan si vymezil jasnou hranici kolem systemd a Neovim si postupně vybudoval vlastní směr, pluginový svět i očekávání uživatelů. Spojuje je hlavně to, že nezůstaly jen u nesouhlasu s původním projektem.

EVi a Vim Classic jsou zatím v jiné fázi. Podle LWN mělo EVi krátce po vzniku 13 přispěvatelů a 86 commitů za měsíc, což je dobrý start, ale ne důkaz dlouhé životnosti. Vim Classic už mezitím vydal verzi 8.3.0, zveřejnil tarball i podpis a posunul se za fázi oznámení v draftu. Jenže fork pořád není jen repozitář s novým jménem.

Pro dlouhodobou důvěru nestačí pravidla proti LLM. Fork aktivního editoru musí mít pravidelná vydání, podepisování tagů, přebírání bezpečnostních oprav, jasnou matici podporovaných systémů, viditelný seznam nepřevzatých bezpečnostních oprav a lidi, kteří rozumějí starému C kódu Vimu i jeho runtime souborům. Bez toho může být „bez LLM“ hlavně varianta s pomalejšími opravami.

Praktický dopad na uživatele Vimu

Běžný uživatel Vimu z toho zatím nemusí vyvozovat nutnost okamžitě měnit editor. Hlavní Vim má přiznanou politiku a aktivní vývoj. Kdo odmítá asistenci LLM z principu, dostal dvě možnosti, ale musí počítat s jejich cenou. EVi může být přijatelnější pro ty, kdo chtějí novější Vim a zároveň odmítají změny s původem v LLM. Vim Classic dává větší smysl pro uživatele, kteří chtějí konzervativní editor blízký Vimu 8.x a nevadí jim slabší kompatibilita s novějšími pluginy.

Pro správce distribucí a balíčků je otázka složitější. Zařadit fork odmítající LLM do repozitáře znamená sledovat, zda projekt přebírá bezpečnostní opravy, zda jsou vydání podepsaná, zda se dá sestavit na běžných platformách a zda má někdo ve forku kapacitu reagovat na chyby. Pokud projekt neumí transparentně říct, které opravy z hlavního Vimu nepřevzal a proč, bude se v distribucích udržovat hůř než původní Vim, i kdyby byl ideově přijatelnější.

Vim v této debatě řeší dvě odpovědnosti: revizi kódu s přiznanou asistencí LLM a dlouhodobou údržbu forků, které ji odmítají. Přijetí takových změn zvyšuje nároky na revizi a regresní testy. Odmítnutí zvyšuje riziko zpožděných oprav a nejasné bezpečnostní podpory. U editoru, ve kterém část lidí tráví každý pracovní den, budou za rok důležitější regresní testy, podepsaná vydání a rychlost oprav CVE než dnešní prohlášení.