Восемь секунд на слабом ПК. Это было время ожидания, пока мои два скрипта на Node.js 18 собирали информацию по проекту - обходили файлы, считали строки, агрегировали данные. Я никогда не писал на Rust. Но попросил Claude Code переписать их - и получил 5-10x ускорение без единой строки, которую бы написал сам.
Проблема, которая росла незаметно
Скрипты работали нормально, пока проект был небольшим. Потом файлов стало больше.
К осени 2024 года восемь секунд превратились из “терпимо” в “раздражает”. Особенно на рабочем ноутбуке с Intel Core i5-8265U, 8GB RAM - каждый запуск становился ощутимым ожиданием. Я посмотрел на код: там старый glob, не оптимизированный под большое количество файлов, и промисы, которые запускались последовательно там, где могли параллельно.
Исправить это на Node.js - задача понятная. Но я начал думать о другом.
Парадокс выбора инструмента
Раньше выбор языка был прост: пишу на том, что знаю. Node.js - потому что знаю JavaScript. Python - потому что скрипт читается. Rust - никогда.
Rust обещает серьёзное ускорение для CPU-bound и I/O-bound операций. Ripgrep и fd доказали это на практике - file traversal в 10-20x быстрее системных аналогов. Но Rust - это lifetime, borrow checker, совершенно другая модель памяти. Инвестиция в обучение, которую я не делал.
Логика простая: мне нужно ускорить два скрипта, а не стать Rust-разработчиком. Разные задачи. С Claude Code они наконец разделились.
Как это работало на практике
Я дал Claude Code оба скрипта и попросил переписать на Rust. Без долгих объяснений архитектуры - скрипты небольшие, задача очевидная.
Дальше произошло кое-что интересное. Claude Code сгенерировал код. Компилятор Rust 1.75 нашёл несколько проблем. Claude Code их исправил. Итеративно, без моего участия в отладке. Это одна из причин, почему Rust+AI работает лучше, чем ожидаешь: строгая система типов вынуждает генерировать корректный код или получать конкретные ошибки компилятора. Не размытые runtime-ошибки - чёткий сигнал. Что именно, где, почему.
Ревью заняло минут двадцать. Скрипты заработали.
Встал вопрос: как распространять? Rust-бинарники platform-specific, в git хранить неудобно. Я посмотрел на esbuild - npm-пакеты с platform-specific бинарниками для каждой платформы. npm install - и ты получаешь бинарник для своей ОС, без исходников, без тяжёлых файлов в репозитории. Сделал так же. Вышло аккуратно.
Результаты
5-10x ускорение на разных машинах - это то, что я увидел в реальной работе. На том же i5-8265U восемь секунд превратились в секунду-полторы. На MacBook M2 Pro разница менее ощутима - там и Node.js особо не тормозил.
Не уникальный результат. ccusage - CLI-утилита для Claude - показал 1000x ускорение в определённых операциях после переписывания с Node.js на Rust. Vjeux (Christopher Chedeau из Meta) переписал 100k строк TypeScript на Rust за месяц с Claude Code в 2025 году. Apache SkyWalking мигрировал 77 тысяч строк за пять недель. Другой масштаб, та же логика.
Мой случай скромный. Но предсказуемый: скрипты делали file traversal с glob и CPU-bound агрегацию - именно тот класс задач, где Rust выигрывает без хитростей.
Честный момент: не любой скрипт получит такой результат. Если узкое место - сеть или диск, а не CPU, выигрыш будет 1-3x или меньше. Профилируй перед тем, как переписывать.
Что это меняет
Я всё ещё не знаю Rust. Не читал книгу, не проходил курсы, borrow checker понимаю на уровне “примерно вот почему это не компилируется”. Но теперь у меня два рабочих скрипта на Rust, которые я могу читать и обслуживать через Claude Code когда нужно.
Это меняет уравнение. Раньше выбор языка ограничивался тем, что знаешь или готов учить. Теперь это выбор инструмента по задаче: нужна скорость и компилируемый бинарник - Rust. Нужно быстро прототипировать с богатой экосистемой - Node.js. AI убирает барьер входа, но не убирает необходимость понимать, зачем ты это делаешь.
Мои два скрипта - ничего грандиозного. Но это первый раз, когда я выбрал инструмент не потому что знаю его, а потому что он лучше подходит для задачи. AI просто убрал причину, по которой я бы раньше этого не сделал.