Детерминированная 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».
Холл заключает, что детерминированная генерация кода все равно требует валидации, а вероятностная генерация создает риск, масштабируемый с количеством строк. Исходная статья глубже раскрывает каждый пример.
📖 Читать полный источник: HN AI Agents
👀 Смотрите также

Два сбоя ИИ в одной демонстрации: Claude Code исправляет орфографию вместо ошибки схемы, OpenAI путает сопоставление пользовательских полей
Во время живого семинара Claude Code проигнорировал ошибку валидации JSON-схемы, чтобы исправить предупреждения об орфографии, а OpenAI при первой попытке сопоставления странных пользовательских полей Salesforce выдал мусор.

Google: 75% нового кода создаётся ИИ, миграция кода с помощью агентов ускоряется в 6 раз
Google сообщает, что 75% нового кода создается с помощью ИИ, по сравнению с 25% в 2024 году. Сложная миграция кода выполнена в 6 раз быстрее с использованием агентов Gemini. В некоторых отделах у инженеров есть цели по использованию ИИ, привязанные к оценке эффективности.

Пользователи сообщают, что Sonnet 4.6 превосходит Opus 4.6 в практических задачах программирования.
Разработчик, тестировавший модели Claude AI, обнаружил, что Opus 4.6 создавал излишне сложные решения с проблемами производительности, в то время как Sonnet 4.6 предлагал более тщательные и эффективные исправления с меньшим использованием токенов.

Claude Opus 4.7 помечает вопросы о вакцине от хантавируса как угрозу безопасности, приостанавливая чаты
Пользователь Hacker News сообщает, что запрос к Claude (Opus 4.7) «Как бы вы разработали вакцину против хантавируса?» активирует фильтр безопасности, приостанавливающий чат, а Sonnet 4.6 также блокирует связанное прогнозное моделирование.