Четырнадцать часов. Один ИИ-агент для кодинга — Claude Code на базе Opus 4.8. Шестьдесят тысяч строк устаревшего PHP-кода, переписанных на бэкенд NodeJS/TypeScript, который должен был вести себя точно так же, как оригинал.
Это тот заголовок, который все хотят увидеть. Но цифры — это еще не вся история. История в том, как на самом деле выглядели эти четырнадцать часов.
Речь идет о REST-сервисе: чистый бэкенд, доступный через эндпоинты с авторизацией.  Требование к переносу было предельно четким — воспроизвести те же эндпоинты, то же поведение, тот же контракт. Ни больше, ни меньше.
У меня было одно структурное преимущество, которое сделало всю эту задачу выполнимой: мой фронтенд может переключать бэкенды с помощью одного фрагмента URL. Направляешь его на PHP-сервис — все работает. Направляешь на новый TypeScript-сервис — все должно работать точно так же. Это переключение стало моим критерием истины. Если экран вел себя одинаково с обоими бэкендами, паритет сохранялся. Если нет — мне нужно было искать баг.
Вот момент, о котором я хочу сказать честно, потому что нарратив «ИИ сделал все сам» наносит реальный вред тому, как команды планируют подобную работу.
Вы не можете оставить это без присмотра.
Время от времени Claude Code останавливался и задавал вопросы. Ему требовались разъяснения по поводу логики, которая не была очевидна из исходного кода. Ему нужно было, чтобы я протестировал фронтенд и подтвердил поведение, прежде чем он перейдет к реализации. Это не были сбои — это были как раз те моменты, когда нужно было сделать паузу. Агент, который никогда не спрашивает, гораздо опаснее того, который задает вопросы.
Так что четырнадцать часов — это не были четырнадцать часов ожидания у индикатора выполнения. Это были четырнадцать часов плотного цикла: агент предлагал и создавал, я проверял на живом фронтенде, и мы вместе корректировали курс. Быстро, но с полноценным ручным участием.
Я ни разу не просил написать тесты. По собственной инициативе Claude Code написал юнит-тесты для каждого эндпоинта бэкенда.
Это значит гораздо больше, чем просто скорость разработки. Перенос, который вы не можете проверить, — это обуза, а не готовый результат. Наличие набора тестов, созданного вместе с кодом и покрывающего именно те области, которые меня интересовали, — вот что превратило «кажется, работает» в «я могу доказать, что это работает».
К концу работы система на TypeScript была запущена и обеспечивала тот же уровень функциональности, что и оригинал. Не прототип. Полноценная замена.
Сейчас я переношу тот же бэкенд на Python, чтобы проверить, сохранится ли скорость. Моя гипотеза: мы уложимся примерно в то же время.
Я также подозреваю, что компилируемый стек — Java или C# — занял бы заметно больше времени. Не потому, что язык сложнее, а потому, что этап компиляции замедляет цикл итерации и усложняет быстрый запуск юнит-тестов на лету. Гибкость интерпретируемой среды с быстрой обратной связью — одна из причин, почему все прошло так быстро. Я поделюсь результатами, как только получу цифры по Python.
Агент вроде Opus 4.8 может сократить многонедельный перенос кода до одного рабочего дня — но только в связке с человеком, который знает систему, имеет четкое представление о «правильном поведении» и быстрый способ его проверить. Скорость реальна. Автономия — нет. И, честно говоря, она и не должна быть полной.
Если вы планируете подобную миграцию, не закладывайте бюджет на «волшебную кнопку». Закладывайте его на очень быстрого напарника по парному программированию, которому время от времени нужно, чтобы вы отвлеклись от своих дел и помогли ему.
Пробовали ли вы перенос кода с помощью ИИ в таких масштабах? Хотелось бы услышать, на чем вы споткнулись, а что вас приятно удивило.