Саймон Уилсон, автор Datasette и обозреватель инструментов для разработчиков и LLM, 6 сентября 2026 года опубликовал комментарий к обсуждению технического долга на Lobste.rs. Поводом стала распространённая идея: если старая система стала слишком сложной, её следует «сжечь» и переписать с нуля.
Уилсон считает, что на практике такой сценарий редко приводит к полной замене легаси. Чаще компания получает новую систему, которая постепенно строится рядом со старой, продолжает поддерживать обе и рискует в итоге остаться с двумя кодовыми базами вместо одной.
Для команд, разрабатывающих AI-агентов, RAG-сервисы и внутренние платформы автоматизации, это не абстрактная проблема. Быстро меняющиеся модели, API и фреймворки действительно провоцируют желание начать проект заново, но именно в таких системах поведение старой версии часто оказывается плохо описанным и зависит от множества неформализованных исключений.
Почему старая система продолжает усложняться
По сценарию, который описывает Уилсон, сначала команда объявляет текущий продукт безнадёжно перегруженным техническим долгом и создаёт отдельную группу для разработки замены. Новая работа стартует в удобных условиях: чистая кодовая база, современные библиотеки и возможность заново выбрать архитектуру.
Старая система при этом никуда не исчезает. Она продолжает обслуживать основные бизнес-процессы, поэтому в неё по-прежнему нужно добавлять функции, исправлять ошибки и адаптировать её к новым требованиям. У разработчиков поддержки может снижаться мотивация вкладываться в долгосрочное качество, если им постоянно напоминают, что код скоро будет выброшен.
В результате технический долг не замораживается на время миграции, а продолжает расти. Новая команда рассчитывает заменить старый продукт, но старый продукт остаётся движущейся целью: его поведение меняется одновременно с разработкой будущей версии.
«Зелёное поле» не знает всех правил легаси
Главный риск полной перезаписи связан не только с оценкой сроков. Команда должна восстановить неформализованные правила, на которых держится старая система: редкие сценарии, исторические исключения, зависимости между сервисами и ожидания пользователей.
Уилсон отмечает, что если бы поведение старого продукта было хорошо документировано и покрыто тестами, необходимость в его замене могла бы вообще не возникнуть. Поэтому команда, начинающая проект с чистого листа, часто обнаруживает масштаб задачи только после начала разработки.
Через месяцы или годы без заметной для бизнеса поставки возникает давление выпустить хотя бы часть новой системы. Её могут запустить для ограниченного набора функций или для новой возможности, которую было трудно реализовать в старом продукте. Такой запуск формально создаёт прогресс, но не решает задачу замены.
В продакшене появляются две системы: старая, которую уже не хотят активно развивать, и новая, где работает лишь часть запланированных сценариев. Остальной код может оставаться заделом на будущее. В исходном комментарии Уилсон описывает этот объём как примерно 80% неактивного кода, предназначенного для последующей замены старой системы.
Смена приоритетов может закрепить неудачный компромисс
Пока обе системы существуют параллельно, проект миграции зависит от продолжительного финансирования и стабильных приоритетов компании. Если бизнес потеряет терпение или решит направить ресурсы на другую задачу, полная замена может остановиться.
Тогда организация останется с легаси-продуктом, который опасно менять, и новой системой, которая покрывает только часть функций. Изначальная цель — уменьшить сложность — превращается в дополнительный операционный и архитектурный груз.
Это особенно чувствительно для AI-инфраструктуры. Один сервис может отвечать за маршрутизацию запросов к моделям, другой — за хранение контекста, третий — за оценку качества или вызов инструментов. Если переписывать такую платформу без поэтапного переключения трафика, команда рискует получить две версии логики, два набора интеграций и расхождения в результатах. При этом изменение модели или внешнего API может потребовать срочных исправлений сразу в обеих системах.
Вместо перезаписи — тесты и управляемая миграция
Собственная рекомендация Уилсона — сначала укрепить старую систему автоматизированными тестами, а затем проверить, можно ли привести её к нужному состоянию точечными рефакторингами. Он считает, что такой путь во многих случаях надёжнее привлекательной идеи начать с полностью чистого проекта.
В качестве дополнительного материала Уилсон называет статью Уилла Ларсона «Migrations: the sole scalable fix to tech debt» — разбор поэтапных миграций. Логика этого подхода отличается от большой замены одним запуском: систему разделяют на части, постепенно переводят ответственность на новые компоненты и сохраняют возможность отката.
Для AI-команды практический порядок может выглядеть так:
Зафиксировать внешнее поведение сервиса тестами, включая не только успешные запросы, но и ошибки, тайм-ауты, повторные вызовы и редкие ветки.
2. Отделить реальную проблему от неудобной реализации. Медленный модуль, например, не всегда требует переписывания всей платформы.
3. Выбрать один ограниченный контур — конкретный тип запросов, провайдер модели или этап пайплайна — и переводить его отдельно.
4. Сравнивать старую и новую реализацию на одинаковом наборе входных данных, проверяя не только ответ модели, но и стоимость, задержку, использование инструментов и обработку отказов.
5. Удалять старый код только после того, как новая реализация покрывает подтверждённый набор сценариев и выдерживает эксплуатационную нагрузку.
Такой процесс не делает миграцию дешёвой автоматически. Он лишь уменьшает размер каждого изменения и позволяет доставлять пользу до завершения всей программы.
Что проверить перед решением о переписывании
Комментарий Уилсона — это его профессиональное наблюдение, а не сравнительное исследование всех проектов по модернизации. В доступном материале нет статистики, по которой можно было бы измерить, как часто переписывание с нуля терпит неудачу. Его вывод следует воспринимать как предупреждение о типовом организационном и техническом риске, а не как запрет на новые реализации.
Перед запуском проекта стоит проверить три вещи: какие функции старой системы действительно используются, какие из них не описаны тестами и можно ли переключать отдельные участки независимо. Для AI-продукта к этому добавляются метрики качества ответов, задержки, стоимости инференса и доли неудачных вызовов инструментов.
Если команда не может надёжно описать текущее поведение сервиса и не умеет сравнить две реализации на одном наборе сценариев, начинать с полной замены особенно рискованно. В такой ситуации тестирование и небольшая миграция дадут больше информации о реальном устройстве системы, чем ещё один архитектурный документ для проекта с чистого листа.
О работе Уилсона и проекте Datasette можно узнать из его исходного комментария и официального сайта Datasette.