Зміст
Коротко
У 2000 році Джоел Спольскі назвав переписування з нуля найгіршою стратегічною помилкою. Есе на Dev.to розбирає перенесення ядра Bun з Zig на Rust: близько 535 тисяч рядків за 11 днів силами десятків агентів Claude. Автор не кличе всіх «переписати прод», а пропонує переглянути правило як заморожену оцінку вартості, а не вічну істину.
Що сталося
Джарред Самнер задумав прибрати витоки пам’яті та помилки use-after-free і переніс ядро середовища виконання на Rust, де частину гарантій дає компілятор. Далі на репозиторій спрямували агентів: до 50 автоматичних сценаріїв, на піку чотири робочі дерева Git паралельно, у кожному до 16 агентів Claude. Вони самі закрили понад 16 тисяч помилок компіляції.
Цифри з есе: 535 496 рядків Zig, понад мільйон рядків Rust, 6 778 комітів, близько 6,6 млрд токенів і близько 165 тисяч доларів на API. На піку — 64 агенти, старт–фініш — 11 днів. Для порівняння автор наводить Turborepo: три–п’ять інженерів і 14 місяців на перехід з Go на Rust.
Результат у Bun 1.4.0 виглядає переконливо і водночас брудно. На тесті з 2 000 паралельних збірок пам’ять упала з 6,7 ГБ до 609 МБ, закрили 128 старих помилок, розмір бінарника на Linux і Windows скоротився приблизно на 20%, пропускна здатність HTTP зросла на 2–5%. З іншого боку з’явилися 19 відомих дефектів, близько 4% коду лишається в unsafe, а творець Zig Ендрю Келлі назвав проєкт «непереглянутою кашею». Цей закид автор просить не відмахувати: мільйон рядків без людської перевірки — окремий ризик, навіть якщо порівняльні тести зелені.
Чому це важливо
Правило Спольскі трималося на економіці: люди заново виводять крайові випадки, уже «зашиті» в старих латках, а продукт рік нічого не постачає. Коли крива вартості ламається, порада перестає бути універсальною. Це не означає «завжди переписуй»: означає, що догму треба перераховувати так само, як залежності.
Три позиції можуть бути правими одночасно. Спольскі правий для своєї моделі витрат. Келлі правий про борг перевірки. Bun правий у тому, що збірка вийшла і на частині навантажень стала легшою. Цікаве саме це напруження, а не перемога однієї сторони.
На практиці
- Перед «ніколи не переписуємо» запишіть, яка вартість і який строк стояли за цим «ніколи» п’ять років тому — і що змінилось у інструментах.
- Не порівнюйте агентне перенесення з ручним рік за роком без однієї метрики: гроші, календар, відомі дефекти, частка непереглянутого коду.
- Закладіть бюджет рев’ю окремо від бюджету генерації: 165 тисяч на API не оплачують уважне читання мільйона рядків.
- Тримайте старий контур живим, поки новий не пройде ті самі сценарії, що захищали прод роками.
- Якщо мета — безпека пам’яті, рахуйте не лише «перейшли на
Rust», а й часткуunsafeі набір тестів, які ловлять регресії середовища виконання.
Підсумок
Урок есе не «завжди переписуйте з нуля», а «інженерні заборони часто маскують стару арифметику». Коли арифметика змінюється, заборону потрібно переглянути, а не повторювати як заклинання. Питання не в тому, чи вміє модель перенести код, а в тому, чи лишилась чинною причина, з якої ви відмовлялись раніше.