Искусственный интеллект сделал код дешевым настолько, что старое правило «проще поправить, чем переделывать целиком» теперь работает не всегда. Однако возникла проблема: техническая возможность переписать продукт еще не означает, что это действительно необходимо.
По данным июньского исследования GitLab и The Harris Poll, 85% опрошенных считают, что ИИ уже перенес основное узкое место разработки с написания кода на его проверку и подтверждение качества. Еще 78% говорят, что разработчики стали отдавать код гораздо быстрее.
Это хорошо описывает изменение самой экономики разработки. Обсудим, когда правда разумнее собрать продукт заново, почему старый код становится источником требований — и как не превратить переписывание в новую разновидность техдолга.
Код больше не самое дорогое место разработки
Условно можно сказать, что этап написания кода внутри жизненного цикла разработки стал обходиться «почти бесплатно». Не буквально, конечно — модели, инфраструктура и специалисты по-прежнему стоят денег. Просто количество созданного кода все слабее связано с количеством человеко-часов.
В качестве примера возьмем задачу переноса мобильного приложения в веб. Агентная система воплощала эту идею в жизнь около 20 часов. Инженер в это время занимался другими тикетами и созвонами — но периодически возвращался к агентам и проверял работу, корректируя результат. По сути он скорее дирижировал системой, нежели писал что-то сам.
Здесь хорошо видно, почему ускорение написания кода не означает, что вся разработка тоже ускоряется. Новый продукт все равно нужно придумать: поговорить с владельцем, собрать требования, устранить противоречия, определить ограничения. И этот разговор по-прежнему занимает полтора часа. Его можно сделать предметнее с помощью прототипа — однако кратно ускорить получение бизнес-контекста гораздо сложнее.
Да, ИИ резко удешевил один участок процесса. Но не нужно думать, что это произошло с остальными его участками.
У старого продукта есть преимущество: он уже объясняет, что нужно построить
Тут переписывание существующего продукта оказывается в крайне выгодной позиции. И вот почему: если система работает много лет, требования к ней уже где-то зафиксированы.
При идеальном раскладе сохранились документация, задачи и описания процессов. Но, даже если ничего этого нет, остается кодовая база. Современный агент может использовать ее как источник фактических требований: он разберется, какие сценарии существуют, какие компоненты связаны, что происходит после конкретного действия и какие предусмотрены исключения.
То есть старый продукт — это своеобразный архив собственных требований.
При разработке с нуля обязательно нужно спросить специалиста: «Как это должно работать?» При переписывании можно сначала задать существующей системе вопрос: «Как ты работаешь сейчас?» — и только после этого определять, что поменять, а что сохранить.
Когда переписывание имеет смысл
У программистов есть нерушимое правило: «работает — не трогай». Искусственный интеллект сделал обход этого правила дешевле.
Снижение стоимости нового кода влияет на границу между рефакторингом и полной переработкой, но здравого смысла не отменяет. Причина для переписывания должна отвечать на простой вопрос: «Чтобы что?»
Например:
● система перестала выдерживать нужную нагрузку;
● существующая архитектура не масштабируется;
● продукт радикально меняет назначение;
● новый функционал невозможно нормально встроить в исходную конструкцию;
● развитие старой системы обходится дороже, чем замена проблемной части.
Любопытный пример: в базе данных кандидатов для отдела рекрутмента со временем почти перестал работать поиск — а контактов накопилось очень много. Ситуация дошла до того, что кандидата было легко найти, только если помнишь его фамилию. Нормально отфильтровать базу по стеку и другим параметрам уже не получалось. Можно было и дальше ремонтировать старое приложение, но проблема стала системной.
Команда сохранила существующую структуру данных, а агенты проанализировали старый продукт, его зависимости и запросы пользователей. Затем поверх той же базы собрали новую реализацию. Данные и работающая бизнес-логика остались на месте — заменили только деградировавший слой приложения.
Это важное отличие от подхода «выбросить все и начать с чистого листа». Переписывать можно не все и вся — только ту часть, которая и впрямь нуждается в обновлении.
С новой дрелью хочется пересверлить полдома
Важный нюанс в том, что дешевизна нового кода снижает психологический порог для таких решений. Представьте, что приобрели новую дрель, которая идеально лежит в руках — с новым инструментом сразу хочется пересверлить полдома. Не потому, что стены требуют ремонта — просто работать стало легко и приятно.
С ИИ похожая история. Команда видит, что агенты могут за несколько дней сделать то, на что прежде ушли бы недели или даже месяцы — и начинает искать задачу под новые возможности.
Однажды дошло до смешного: после изменений в компании две продуктовые команды оказались сильнее в технологических стеках друг друга. Разумно было бы поменять их местами. Вместо этого оба продукта переписали под более подходящие специалистам технологии.
Вот только «можно быстро переписать» — не бизнес-требование. Если в старый продукт надо добавить одну функцию и сделать это можно безопасно для архитектуры, переписывание лишь увеличит область изменений. Примером может служить система, которую прежде развивали несколько разных команд. Код был далеко не идеальным, но объективной причины менять весь продукт не существовало. В итоге агент добавил нужную функцию прямо в существующую реализацию.
Можно ли было поступить иначе? Да. Но тогда переписывание стало бы не модернизацией, а использованием новой игрушки ради самой игрушки.
Самая опасная часть старого продукта — то, о чем все забыли
У наследуемых систем есть еще одна особенность: внутри часто живет функциональность, которой нет ни в документации, ни в памяти текущей команды. Причем забывают обычно именно о том, что исправно работает.
Например, в одном из старых внутренних сервисов обнаружили скрипт, который автоматически ставил служебную маркировку на корпоративные файлы. По смыслу он вообще не был связан с этой системой — просто оказался там исторически.
Если бы просто собрали требования у основных пользователей, никто не рассказал бы про этот скрипт. Старую систему отключили бы, потеряв с ней рабочую функцию. А так агент обнаружил зависимость при анализе кода, и механизм перенесли в более подходящий сервис.
Такие ситуации можно связать с восходом солнца: оно каждый день поднимается на востоке, и никто не пишет отдельное требование «солнце должно продолжать вставать». Вспомнят об этом только в тот день, когда рассвет почему-то не наступит.
Именно поэтому переписывание с нуля порой куда опаснее, чем переписывание по фактическому поведению старой системы.
Старый продукт можно превратить в исполняемую спецификацию
До большого переписывания существующий продукт можно максимально покрыть автоматическими тестами: пользовательскими, интеграционными, сквозными. Причем сами тесты тоже помогают готовить агенты.
Дальше старая реализация становится эталоном поведения. Команда создает новую версию и запускает на ней те же проверки. Схема получается такой: «существующий код — восстановленные требования — автоматические тесты — новая реализация — те же тесты». Если проверка падает, возникает конкретный вопрос: это новая система что-то сломала, или старая работала не так, как думала команда?
По сути, здесь соединяются принципы SDD (разработки от спецификации) и TDD (разработки через тесты). Сначала команда восстанавливает из существующей системы спецификацию — что продукт должен делать, какие сценарии и рамки сохранять. Затем это поведение фиксируется автотестами, которые становятся проверяемыми требованиями к новой реализации.
Получается двойная страховка: спецификация объясняет, что нужно сохранить, а тесты позволяют проверить: правда ли новое решение это сохранило.
Тесты могут рассказать о продукте больше, чем документация
Особенно интересны упавшие проверки. Они способны обнаружить скрытое поведение, исключения и исторические решения, о которых команда уже не помнит. Иногда даже выясняется, что годами система работала не так, как предполагали владельцы продукта.
Причем не каждое отличие новой версии нужно автоматически исправлять. Если тест обнаружил неожиданное поведение старой системы, стоит сначала выяснить, действительно ли его надо воспроизводить. Возможно, команда просто впервые увидела старое ограничение или ошибку — и переписывание дает возможность осознанно от них отказаться.
В этом смысле падающий тест становится и сигналом «мы что-то сломали», и источником нового знания о собственном продукте.
Так переписывание превращается не просто в техническую операцию. Можно улучшить не только архитектуру и другие нефункциональные характеристики, но иногда и саму функциональность — если стало понятно, что прежнее поведение больше не имеет смысла.
Прежде чем все переписать: памятка
Искусственный интеллект сделал полное переписывание доступнее — и именно поэтому решение о нем надо принимать строже. Перед стартом полезно пройти несколько шагов:
1. Ответить на вопрос: «Чтобы что?» Зафиксировать конкретную проблему: скорость, нагрузку, архитектурное ограничение, стоимость изменений или смену назначения продукта.
2. До начала переписывания максимально покрыть существующую систему автоматическими тестами. С помощью ИИ можно быстрее подготовить пользовательские, сквозные, интеграционные и другие проверки. Важно, чтобы они проходили на старом продукте и фиксировали его фактическое поведение.
3. Попросить агентов разобрать существующую систему и восстановить спецификацию: компоненты, зависимости, сценарии и скрытые функции, которые могли не попасть в документы. Причина переписывания тоже должна стать частью требований к новой версии.
4. Разделить то, что обязательно нужно сохранить, и то, что команда намеренно хочет изменить. Новая реализация должна воспроизвести нужное поведение, но не обязана копировать старую архитектуру и ее ограничения.
5. Собрать новую версию и запускать на ней тот же набор тестов. Продолжать до тех пор, пока обязательные проверки не перестанут падать, а каждое оставшееся расхождение не будет объяснено.
6. Не исправлять отклонения автоматически. Падение теста может означать как ошибку новой версии, так и неожиданное или уже ненужное поведение старой системы.
7. Только после этого выключать старую реализацию. Генерация новой версии может занять часы, тогда как последствия потерянной зависимости способны проявиться через месяцы.
Что в итоге
ИИ действительно меняет старый выбор между рефакторингом и переписыванием. Там, где цена полной переработки прежде останавливала команду, технический барьер стал значительно ниже.
Однако это не меняет стоимости неправильного решения. Новый код можно сгенерировать очень быстро — гораздо сложнее восстановить десятилетие бизнес-логики, скрытые зависимости и поведение, к которому привыкли пользователи.
Главный эффект ИИ здесь в том, что старую систему теперь можно быстрее разобрать, превратить ее поведение в спецификацию и осознанно собрать новую — только там, где это правда имеет смысл.
