Клон pylint на Rust с побайтово идентичным выводом: почти весь написан ИИ-агентом

Линтер, который намеренно копирует баги pylint

prylint — это реализация pylint на Rust с необычной точкой продажи: он не пытается стать лучше, он пытается быть идентичным. Страница прямо об этом: «prylint не "вдохновлён" pylint» — это баг-за-багом порт. Где pylint выдаёт предупреждение, prylint выдаёт то же предупреждение. Где pylint падает, prylint сообщает то же сообщение об ошибке. Заявлен побайтово идентичный вывод, проверенный на 52 продакшн-кодовых базах и примерно 65 000 файлах Python.

Выигрыш — скорость. Диапазон в заголовке: 15–2300x, медиана около 85x, и на больших репозиториях это особенно ощутимо:

Ещё одна необычная деталь: инструмент создан Fable — агентной системой программирования — за месяцы итераций, а не написан человеком вручную. Именно эта деталь, а не цифры, взорвала тред.

Первый комментарий: «это вообще легитимный проект?»

Самый высоко оценённый ответ сразу открыл репозиторий.

«Смотрю на GitHub — все коммиты от Claude, при этом adamraudonis, похоже, не связан ни с кем другим… этот пост выглядит как SEO-мусор. Это вообще легитимный проект?» — комментатор, проверивший историю коммитов

Читатель с рейтингом 10 тысяч+ нашёл улику прямо в формулировках README:

«Как всегда, с третьей строки понимаешь, что документацию не писал (а может, и не читал) человек. Надоело это предательство доверия.» — давний читатель HN

«Ruff уже существует» — возражение об избыточности

Второй удар не имел отношения к тому, как был написан код. Проверки pylint уже есть в Ruff — быстром линтере на Rust, на который перешло большинство команд.

«Это просто ruff check --select=PL, но хуже во всём, причём поддерживаемый системой, которой уже нет? Он даже использует код Ruff под капотом.» — читатель HN с рейтингом 11 тысяч+

Сам Fable, как заметили несколько человек, уже недоступен, так что автор инструмента — система, которую сегодня даже не запустить.

Контраргумент: «результаты говорят сами за себя»

Затем последовал разворот. Разработчик оспорил саму постановку вопроса: код не может быть «запятнан» способом своего создания.

«Написание программного обеспечения — не спорт, где "читерство" с помощью инструментов делает результаты бесполезными… Если вы не можете привести падающий тест, ваши аргументы о том, "как" это написано, не имеют смысла.» — разработчик, создающий продукты с агентным кодированием

Его аргумент работает здесь сильнее, чем для большинства AI-проектов: у линтера есть детерминированный оракул. Если вывод расходится с реальным pylint — вот и баг. Верность можно проверить, а не просто почувствовать.

Весомое подтверждение пришло от того, кто делал похожее вручную. Инженер описал перенос заброшенного HTML/шаблонного линтера djlint на Rust с помощью LLM — не за один раз, но с побайтовой совместимостью:

«Python-версия была сильно основана на регулярках… В Rust-версии я переключился на полноценную токенизацию файлов с последующим проходом по правилам на AST за один проход… Python-версия работала около 4 минут; Rust-версия на том же коде работает долю секунды.» — инженер, перенёсший djlint на Rust

Другой читатель рассказал, как поручил Fable несвязанную миграцию — с nix+npm на docker+pnpm на стеке, который команда не понимала — и тот «почти за один раз» справился, а после недели стресс-тестирования нашлось мало ошибок.

Почему порты — лёгкий случай для агентов

Тихий главный вывод расположен между двумя лагерями. Несколько инженеров объяснили, почему этот класс задач так хорошо подходит агенту: существующая программа — точная спецификация, тесты — бесплатный оракул, а модель может итерировать до тех пор, пока diff не пустой. Это делает «переписать X на Rust» редкой AI-задачей, где скептицизм — кто написал? — снимается запуском тестов, а вопрос об избыточности — зачем, если уже есть Ruff? — оказывается тем, что на самом деле задевает.