Детерминированная vs вероятностная генерация кода: почему конверсия Bun в Rust через Vibe-Coding вызывает тревогу

Ной Холл, пишущий для The Tech Enabler, проводит четкую границу между детерминированной и вероятностной генерацией кода. В качестве предостережения он использует недавнюю конвертацию миллионной кодовой базы Bun с Zig на Rust, выполненную в стиле «vibe coding». Его главный аргумент: детерминированные системы дают согласованные, проверяемые результаты; LLM вносят неопределенность, делающую проверку кода в масштабе невозможной.

Детерминированная генерация кода

Холл указывает на устоявшиеся детерминированные инструменты: Python 2to3 для миграции с Python 2 на 3, и транспиляторы для таких языков, как Elm, PureScript и TypeScript, которые всегда выдают одинаковый JavaScript. Его собственный язык Derw может выводить JavaScript, TypeScript или английский; Tegan выводит JavaScript или Go; Mojie нацелен на JavaScript, Python или английский. Все они основаны на AST-to-AST трансформации — при одинаковом входе вы всегда получаете одинаковый выход. Согласованность имеет значение: «Если баг согласован, мы можем его исправить. Если баг несогласован, его исправление становится экспоненциально сложнее».

Вероятностная генерация кода

LLM каждый раз выдают разный результат — иногда A, иногда B. Три года назад Холл создал neuro-lingo как пародию: люди пишут только сигнатуры функций и комментарии, а LLM генерируют реализацию заново при каждой компиляции. Пример:

function add(a: number, b: number): number {
  // Сложить два числа
}
function main() {
  // Вывести "Hello World" в консоль
  // Вывести результат add(2, 3)
}

«Каждый раз, когда компилируется neuro-lingo, код генерируется заново LLM. Он каждый раз немного отличается. Иногда вносит баги. Иногда он чистый и простой. Иногда хаотичный». Холл утверждает, что полностью управляемые ИИ потоки кода делают именно это, но отправляют в продакшн с ответственностью на человеке.

Ловушка «у нас есть тесты»

Одних тестов недостаточно для гарантии качества. Холл приводит SQLite как самую протестированную кодовую базу: 155,8 KSLOC кода на C против 92 053,1 KSLOC тестового кода (в 590 раз больше). Несмотря на 100% покрытие ветвей, миллионы тестовых случаев и обширные обвязки, SQLite все равно полагается на проверку человеком. «Невозможно проверить 1 миллион строк изменений за 9 дней. Bun не проверял код, который они слили в master».

Холл заключает, что детерминированная генерация кода все равно требует валидации, а вероятностная генерация создает риск, масштабируемый с количеством строк. Исходная статья глубже раскрывает каждый пример.