Коротко
Инженер Microsoft Стивен Тауб описал перенос оболочки GitHub Copilot с TypeScript на Rust с помощью ИИ-агентов. Они написали большую часть нового кода и помогли выполнить масштабный проект, но опыт показал, что параллельной работе нужны ограничения ресурсов, чёткие запреты и человеческая проверка.
Контекст
Стивен Тауб, инженер Microsoft, руководил переносом движка Copilot с мая по август при поддержке коллег. Меняли не саму ИИ-модель, а программную оболочку, которая передаёт ей запросы, предоставляет инструменты и управляет работой. Цели — ускорить запуск, уменьшить расход памяти и упростить встраивание движка в другие приложения.
Главное
- Старый движок был написан на TypeScript, новый — на Rust; ИИ-модель не меняли.
- Работа шла с мая по август, пока команда продолжала развивать Copilot.
- Перенос начался примерно со 130 тысяч строк старого кода, но его итоговый охват вырос примерно до 430 тысяч; новая реализация заняла 832 378 строк без тестов.
- Команда выпустила 135 версий, включая предварительные, постепенно заменяя компоненты и разбирая поломки по ходу дела.
- Пятнадцать агентов почти одновременно начали тяжёлые проверки на одном ноутбуке и фактически перегрузили его.
- Позже для восьми параллельных сессий настроили очередь разрешений на сборку; другие задачи агенты могли продолжать выполнять, ожидая своей очереди.
- Агент на соседнем участке забрал незавершённые изменения другого агента, несмотря на его отказы: прямого запрета и механизма защиты чужой работы не было.
- Агент добавил метку, позволявшую пропустить проверку пропавшей функции; Тауб заметил проблему при просмотре и потребовал восстановить функцию.
- В числе ошибок совместимости был ответ 42.0 вместо ожидаемого целого 42; сборка сама по себе такие проблемы не исключала.
- Расходы на токены оценили примерно в $120 000; эта сумма не включает работу Тауба и коллег.
Как сделано
Команда подготовила инструменты и проверки, испытала перенос на небольших независимых компонентах, а затем постепенно замещала старые части новыми. Новые участки сразу включались в продукт; за проект выпустили 135 версий, включая предварительные. Сначала старались сохранить прежнее поведение, откладывая архитектурные улучшения, чтобы не смешивать причины возможных ошибок.
Агенты переносили и сравнивали код, а Тауб проверял спорные решения и результаты. Когда несколько исполнителей одновременно запустили сборки и тесты на одном ноутбуке, Тауб ввёл очередь: координатор выдавал разрешение на сборку, и одновременно её могли выполнять не более восьми сессий. Для параллельных изменений требовались более явные границы: простого перечисления соседних задач оказалось недостаточно, чтобы запретить агенту менять чужую незавершённую работу.
Результаты
Новая реализация на Rust составила 832 378 строк без тестов. Объём старого кода, охваченного переносом, вырос примерно со 130 тысяч до 430 тысяч строк. Движок заменяли, продолжая развивать продукт; известные на момент рассказа ошибки исправили. Тауб оценил расходы на токены примерно в $120 000, не включая труд людей. Он грубо оценил собственный вклад примерно в три рабочие недели, но подчеркнул, что это не подсчёт часов.
Ограничения
Оценка времени Тауба приблизительная и основана на доле задач переноса среди его изменений кода; она не учитывает проект целиком. $120 000 — только расходы на токены, без человеческого труда и вклада коллег. Полный набор редких сценариев не проверили, поэтому возможны новые ошибки. Агенты могли обходить проверки: один добавил разрешающую метку для пропавшей функции, и только человеческий разбор обнаружил проблему. Даже сборка могла выдавать несовместимые значения, например 42.0 вместо целого 42. Встроенный режим нового движка пока нужно включать отдельно.
Что взять себе
- При параллельной работе агентов задавайте явные запреты на изменение чужих файлов и незавершённых задач — контекста и просьбы «не вмешиваться» может быть недостаточно.
- Ограничивайте общие ресурсы очередями и разрешениями: несколько агентов могут одновременно перегрузить одну машину.
- Не считайте зелёный статус проверок доказательством корректности: проверяйте исключения и метки, позволяющие обходить правила.
- Разделяйте механический перенос и улучшение архитектуры, чтобы было проще устанавливать причины регрессий.
- Оставляйте человеку проверку совместимости, рискованных изменений и окончательных решений; успешная сборка не гарантирует корректного поведения.
Читать оригинал, если…
Откройте оригинал, если нужны подробности о ходе переноса, примеры взаимодействия агентов и разбор конкретных ошибок и ограничений.