GitHub перестроила runtime, лежащий в основе GitHub Copilot CLI, приложения Copilot и Copilot SDK. Ранее он опирался на TypeScript, Node.js и движок V8. Согласно материалу, опубликованному в блоге GitHub, результатом стали более 800 000 строк специализированного производственного кода на Rust. Большая часть работы была выполнена с помощью агентов искусственного интеллекта через 128 запросов на слияние, которые постепенно интегрировались в основную ветку.
Автор утверждает, что работа завершилась за несколько месяцев при участии в основном одного разработчика, параллельно с продолжением разработки возможностей runtime и расширением сферы его использования остальной командой. GitHub сообщает, что после перехода производительность улучшилась «на порядки», однако в доступной части материала не приводит подробных показателей для количественной оценки этого улучшения.
Проблема заключалась не только в интерфейсе командной строки
Copilot runtime не ограничивается запуском CLI. Это общий слой, используемый несколькими версиями и продуктами, включая GitHub Copilot CLI, приложение Copilot и Copilot SDK, а также VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio и приложения Excel, Outlook, PowerPoint и Word.
В прежней архитектуре runtime и интерфейс CLI были тесно связаны. Когда продуктам требовался программный доступ, SDK фактически строился поверх CLI: запускался отдельный процесс Node.js, с которым велось взаимодействие через JSON-RPC. Такой подход был быстрым и гибким, но создавал эксплуатационные издержки для каждого приложения-потребителя.
Создание нового CopilotClient означало запуск дополнительного процесса, размещавшего Node.js и V8, разбор JavaScript-кода, сгенерированного из TypeScript, и выделение памяти, связанной с движком. Кроме того, сбои в Node.js могли завершить сеанс, а приложениям приходилось отслеживать как минимум два процесса. Согласно материалу, SDK-пакеты, написанные на C#, TypeScript, Python, Rust, Go и Java, использовали около 100 мегабайт рабочего набора памяти только для дополнительного runtime, даже когда Node.js не требовался им для других задач.
Почему была выбрана Rust?
GitHub сформулировала чёткие цели для нового слоя: отделить runtime от TUI, сократить зависимости и эксплуатационные издержки, обеспечить встраивание непосредственно в процесс, а также улучшить масштабируемость и надёжность. Кроме того, требовался интерфейс C ABI, позволяющий использовать runtime из шести версий SDK посредством различных механизмов FFI.
В статье говорится, что Rust помогла достичь этих требований, а также предоставила инструментарий с поддержкой более современного режима безопасности, снижением рисков цепочки поставок и более широкими возможностями для корректного по замыслу кода. Вместе с тем подчёркивается, что этот опыт не является рекомендацией переводить каждый крупный проект на TypeScript на Rust: выбор был обусловлен конкретными требованиями к времени запуска, памяти, встраиванию и предсказуемости потребления ресурсов.
Постепенная замена вместо полной переписи
GitHub не реализовывала проект через долгоживущую ветку или единовременное преобразование в конце пути. Был выбран подход внутри основной ветки: каждый компонент на TypeScript заменялся компонентом на Rust отдельно. Каждый запрос на слияние добавлял тонкий связующий слой, вызывающий Rust, и в том же изменении удалял старую реализацию, благодаря чему ветка оставалась пригодной для выпуска, а новый код сразу тестировался внутри системы.
- Обычная работа остальных разработчиков продолжалась без остановки проекта.
- Каждое изменение было меньше и проще для проверки, чем полная перепись.
- Сквозные тесты CLI и SDK запускались на каждом этапе.
- Регрессии выявлялись и исправлялись во время миграции, а не откладывались до момента окончательного перехода.
GitHub также отказалась надолго сохранять две параллельные версии каждого компонента. В репозитории еженедельно появлялись сотни запросов на слияние, и поддержка двух реализаций на разных языках и двух наборов зависимостей увеличила бы сложность. Сравнение двух версий становится ещё труднее в компонентах, управляющих изменяемым состоянием, например в форматировании сеансов, поскольку они обрабатывают обратные вызовы и взаимодействуют с широкими участками системы.
О чём говорят цифры?
Первоначальная оценка в мае 2026 года составляла около 130 000 строк TypeScript, но она не отражала фактический объём работы. Компоненты, ранее относившиеся к слою TUI, позднее были перенесены в runtime, а новый код на TypeScript продолжал поступать одновременно с миграцией. Поэтому в процессе переноса фактически оказалось около 430 000 строк TypeScript.
За тот же период в проект добавили около 300 000 производственных строк TypeScript и удалили около 430 000, тогда как на Rust добавили около 1 200 000 строк и удалили около 365 000. Эти цифры показывают, что неизменный видимый объём TypeScript в репозитории не означал отсутствия прогресса, а скрывал масштабное добавление, удаление и перераспределение ответственности.
Почему эта новость важна?
Практическая ценность этого опыта заключается не только в использовании Rust, но и в способе управления переписыванием базового слоя, общего для большого числа продуктов. Атомарная замена каждого компонента при сохранении пригодности ветки для выпуска и постоянном запуске тестов снижает риски «большого перехода» и делает откат или поиск места сбоя более понятными.
При этом материал не доказывает, что такой подход подходит каждой организации, и не показывает, что агенты искусственного интеллекта сами по себе способны гарантировать качество переписывания такого масштаба. Доступная часть статьи также не содержит опубликованных измерений потребления ресурсов до и после перехода и не раскрывает подробные трудозатраты на проверку, тестирование или исправление регрессий. Поэтому наиболее очевидный вывод связан с постепенной инженерией и разделением слоёв, а не с тем, что Rust или агенты являются универсальным решением для любых миграций.