16 000 строк на Rust написал Claude — автор ни одну из них не читал

Переписывание, к которому человек не притронулся

PostHog транслирует пользовательский SQL в ClickHouse SQL и при этом применяет контроль доступа. Старый движок — C++-парсер на базе ANTLR, обходящий дерево, построенное из грамматики, в рантайме и платящий за эту гибкость производительностью. Переписанный вариант от Robbie Coomber — 16 000 строк Rust плюс 5 000 строк инструментария, и формулировка прямая: «Я не написал ни строчки кода вручную».

Метод — замкнутый цикл. Существующий парсер служит оракулом: любой SQL, в котором старый и новый дают разный результат, — это баг, который нужно исправить. Кастомный генератор, построенный на грамматике ANTLR, порождает тесты на основе свойств, фаззер постоянно работает в фоне и записывает неудачи в файл, а боевые логи поставляют реальные запросы. Claude потребляет неудачи и переписывает парсер. Шло непросто: он «много ошибался, постоянно сомневался, вообще возможна ли такая переписывание», и одним из самых действенных приёмов оказалось сказать ему «хорошенько подумать об угловых случаях» в фоновом агенте. Результат: 70x на ноутбуке, 454x в проде, ноль расхождений после примерно 50 тыс. запросов в тестах и миллионов в теневом режиме.

Это модель AI-инженерии — или умный компилятор, который мы отказались написать?

В треде это воспринимают как шаблон, а не трюк. Инженер, строящий такие же стенды для ПО управления энергосетями, объяснил, почему оракул делает результат надёжным.

«У меня очень хорошие результаты в похожих схемах, где есть какой-то «оракул» и можно сгенерировать огромные корпусы тестовых данных — настолько, что реально доверяешь коду LLM на ожидаемых входах.» — инженер, ранее строивший базы данных в Neo4j

Комментатор, предсказавший в прежнем треде, что программирование превратится в строгий вайб-кодинг, увидел в этом подтверждение.

«Глубокая техническая экспертиза по-прежнему нужна, но она смещается от работы с кодом напрямую к созданию специализированных механизмов валидации вокруг него... если вайб строго выверен, это ещё вайб?» — комментатор, предсказавший этот сдвиг в раннем треде

Самое острое возражение переформулировало весь эксперимент как ошибку категории. Мейнтейнер sql.js спросил, почему вообще не взять готовый быстрый парсер, а другой разработчик развил вопрос дальше.

«У вас есть файл грамматики на формальном языке, и вы хотите получить более быстрый парсер на другом формальном языке. Что не так с... достаточно умным компилятором из исходного языка в целевой?» — разработчик, сравнивший это с заменой GCC фаззером

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