Кудзу завезли в США из Восточной Азии, чтобы остановить эрозию почвы. Растение оказалось агрессивнее задачи: оно заплетает тротуары, фундаменты и деревья, и единственный способ с ним справиться — стричь его постоянно и всем вместе. В сентябре 2026-го Vicki Boykis написала эссе «Bad Code Is Kudzu», где перенесла эту метафору на код: фича, однажды добавленная в проект, удаляется невероятно тяжело, а поверх неё люди пишут новый код. Разбираем её аргументы, дополняем разбором Simon Willison и показываем, что делать вместо «снести и переписать».
Метафора кудзу: что она объясняет
Boykis формулирует проблему через движение, а не через размер. Дело не в том, что в проекте много строк. Дело в том, что сложность растёт сама, даже когда никто не принимает решения её добавить:
«An app feature, once added to a codebase, can be extremely hard to remove. Even simple features become very sticky because not only do you have to remove the code, but what’s worse is that people start writing code on top of your code, and before you know it, you are two years deep into an implemented feature no one wants.» — Vicki Boykis, «Bad Code Is Kudzu»
Перевод: «Фичу в кодовой базе бывает крайне тяжело удалить. Даже простые фичи становятся очень липкими, потому что удалить нужно не только код — хуже то, что люди начинают писать код поверх вашего, и прежде чем вы это заметите, вы на два года вглубь ушли в реализованную фичу, которая никому не нужна».
Второй слой метафоры — экономический. Удаление кода невидимо и не вознаграждается:
«Deleting code is hard, particularly because it’s a thankless task that usually doesn’t go on promo packets, which is why we end up shipping hundreds of thousands of lines of sparkle emoji magic wand AI features, but deleting code is silent.» — там же
Перевод: «Удалять код тяжело ещё и потому, что это неблагодарная задача, которая обычно не попадает в пакет на повышение, — поэтому мы выпускаем сотни тысяч строк «магических палочек» и сверкающих эмодзи, а удаление кода проходит молча».
Отсюда её главный вывод про эпоху агентов: если раньше «кудзу» росла от действий людей, то теперь её можно наращивать быстрее, чем успевать стричь.
Почему «снести и переписать» почти всегда провал
Simon Willison в комментарии к обсуждению «There’s No Limit to How Bad Code Can Get» (06.09.2026) разбирает большой рефакторинг как сценарий с предсказуемым финалом. Он отвечает на реплику «сжечь дотла и начать с нуля»:
«You announce the old thing is irrecoverably drowning in tech debt. You spin up a team to rewrite it from scratch. Work begins. Meanwhile the old thing remains a moving target: it’s running the core business, so changes are still necessary.» — Simon Willison
Перевод: «Вы объявляете, что старое необратимо тонет в техническом долге. Создаёте команду на переписывание с нуля. Работа начинается. А старое остаётся движущейся целью: оно держит основной бизнес, поэтому изменения всё равно нужны».
Дальше работает эффект демотивации. Разработчики на старом коде знают, что его «скоро выкинут», и перестают вкладываться:
«The developers working on it know that it’s going to be made obsolete by the new thing soon, so they don’t have any incentive to go beyond the smallest effort possible to add the new features. Technical debt continues to mount.» — там же
Перевод: «Разработчики знают, что новое скоро сделает их код устаревшим, поэтому у них нет стимула прикладывать хоть немного больше минимальных усилий. Технический долг продолжает копиться».
Список причин, который складывается из двух источников:
- Цель движется. Старая система продолжает обслуживать бизнес и меняется, пока идёт переписывание.
- Мотив падает. Команда на старом коде теряет смысл вкладываться — качество проседает.
- Логику никто не знает. «Если бы её хорошо документировали и покрывали тестами, её не нужно было бы заменять», — пишет Willison. Значит, новую систему проектируют вслепую.
- Давление «выпустить». После месяцев без поставленной ценности новый код выкатывают на подмножество старых функций.
- Два прода вместо одного. Итог — «кривая старая система, к которой никто не хочет прикасаться, и новая, которая закрывает лишь несколько функций прода и на 80% состоит из неактивного кода».
Агент, который умеет переписать проект за вечер, эту механику не отменяет. Он снижает стоимость набора кода — и ровно поэтому делает пункт про «кудзу» острее: наращивать сложность стало дешевле, чем её убирать.
Что делать вместо: стратегии пошаговой замены
Против «большого взрыва» индустрия предлагает Strangler Fig — постепенную замену, при которой новое растёт рядом со старым, а фасад решает, куда идёт запрос (Martin Fowler, Strangler Fig). Willison прямо рекомендует: укрепить старую систему тестами и посмотреть, доведут ли точечные рефакторинги её до нужной формы.
| Стратегия | Когда применять | Риск |
|---|---|---|
| Strangler Fig (фасад + фича за фичей) | Есть живой трафик и нельзя останавливать бизнес | Долго; нужен фасад и дисциплина удаления старого |
| Точечный рефакторинг с тестами | Логика стабильна, надо укрепить ядро | Тесты закрепляют и баги, если писать их бездумно |
| Инкапсуляция «кудзу» | Часть системы трогать нельзя | Legacy остаётся, но перестаёт заражать новый код |
| Полное переписывание | Редко: система мертва или изолирована | Обычно два прода и брошенная замена |
Инкапсуляцию Boykis описывает через собственный бытовой пример. Летом она добавила в свой блог фичу «хэштег-пузыри» на машинном обучении, оставила на несколько месяцев и проверила аналитикой Plausible: фича не попала в топ-30 страниц за три месяца. Не потому что плохая — а потому что ею не пользуются, а поддерживать её дорого:
«So, it’s time to prune the kudzu, in much the same way it was so easy to create.» — Vicki Boykis
Перевод: «Значит, пора стричь кудзу — так же легко, как её было вырастить». Она честно приводит коммиты удаления рядом с коммитом добавления: 91b6fde — Remove tag sidebar and tag bubbles, 85000e2 — Move search bar back to the header, 77e2c5a — Changelog entry. Удаление в её кейсе дешевле, чем разработка, но только потому, что у неё есть план отката.
Реальный скриншот первоисточника:
Как использовать агента в легаси-проекте
Агент плохой кандидат на «перепиши всё», но хороший — на рутину вокруг постепенной замены. Ниже порядок, который повторяет и Willison, и практика Strangler Fig.
- Зафиксировать поведение тестами до изменения. Пока старый код не покрыт, любая правка — лотерея. Агент быстро генерирует characterization-тесты и golden master по описанию ожидаемого поведения.
- Инкапсулировать, а не удалять. Обернуть «кудзу» фасадом, чтобы новый код не зависел от её внутренностей.
- Менять по одной фиче. Агент берёт одну фичу, человек проверяет контракт.
- Удалять старый кусок только после проверки. Стрижка — обязательный шаг, иначе кудзу вырастет обратно.
- Документировать контракты. Границы между старым и новым должны быть описаны явно.
Рабочий промпт для безопасного шага выглядит так.
Задача: перенести аутентификацию на новый сервис по шагам.
Контекст: legacy/auth.py (~900 строк), тесты в tests/test_auth.py, ~40% покрытия.
Шаги (по одному коммиту на шаг):
1. Добавь characterization-тесты на текущее поведение: успех, неверный пароль,
истёкший токен, блокировка после N попыток. Ничего не меняй в legacy-коде.
2. Покажи список тестов, которые подтверждают поведение, и найди непокрытые ветки.
3. Только после моего подтверждения — вынеси интерфейс auth в адаптер.
Ограничения: не трогать БД-схему, не менять публичный API, покажи дифф целиком.
Реальный скриншот комментария Willison:
Метрики: как понять, что долг уходит
Стрижка должна измеряться, иначе её не защитить перед бизнесом. Что стоит держать на дашборде:
- Доля кода под тестами в модуле, который трогаете: растёт → меняете безопаснее.
- Размер диффа на фичу. Если правка на одну фичу трогает двадцать файлов в разных слоях — граница протекла.
- Число удалённых фич за квартал. Удаление должно быть в отчётности, иначе в «пакеты на повышение» попадут только новые фичи.
- Возраст последнего изменения в «неприкасаемом» модуле. Если ядро не менялось годами, трогать его без тестов нельзя.
Индустриальный обзор практик миграции — у Will Larson в «Migrations: the sole scalable fix to tech debt»: он настаивает, что для долгих миграций нужна не команда на замену, а сквозная ответственность и метрика прогресса.
Российские реалии
- Легаси-стек. В РФ классическое легаси — это долгие 1С-конфигурации с доработками, старые Java/PHP-монолиты и самописные интеграции. Стрижка «кудзу» здесь упирается не в инструмент, а в закрытость: у 1С логика часто в конфигурации и внешних обработках, которые агент не видит как обычный код.
- Оплата ИИ-инструментов. Агенты для рефакторинга (Claude Code, Cursor, Codex) биллятся за рубежом; российские Visa и Mastercard не принимают, «Мир» за рубежом не работает. Схемы оплаты и их комиссии — vc.ru и Klerk.
- Опыт в рунете есть, и хороший. Тезис «не удаляй работающее» разобран на Habr в статье «Let well alone»: почему в больших проектах мы перестали удалять код (пример кода NASA, летавшего на зонде). Управляемое переписывание легаси разложено на параллельные потоки «археология / соответствие старому поведению / изменение / исправление» в статье «Рефакторинг и реинжиниринг легаси». Оба материала прямо совпадают с выводами Boykis и Willison.
- Зарубежные SaaS для рефакторинга. Специализированные сервисы «AI-миграции» недоступны для корпоративных аккаунтов из РФ напрямую; практика сводится к локальным агентам (Claude Code, Codex CLI, OpenCode) и открытым моделям, работающим на своём железе.
Ограничения
- Метафора убеждает, но не доказывает. «Кудзу» — образ, а не измерение. Boykis не приводит статистики по удалению фич в индустрии; пример с блогом — один личный случай.
- Willison описывает механику, а не замер. Это опыт и рекомендация, а не исследование с цифрами. Успешные «большие переписки» существуют — просто о них реже пишут.
- Агент всё меняет по обе стороны. Он ускоряет и стрижку, и рост кудзу. Вывод «он делает проблему острее» — интерпретация авторов источников, а не факт бенчмарка.
- Один кейс не правило. То, что удаление дешевле разработки в блоге Boykis, не значит, что так же выйдет в монолите с десятью командами.
- Ссылки на 10.09.2026. Тексты источников и внешние ссылки актуальны на дату публикации; даты у эссе и комментария — 01.09 и 06.09.2026.
Вывод
Кудзу не побеждают одной большой прополкой — её стригут постоянно и сообща. Переписывание с нуля обещает чистый лист, но оставляет движущуюся цель, демотивированную команду и в итоге два прода вместо одного. Агент, умеющий сгенерировать код за вечер, делает рост кудзу дешевле — и потому стрижку нужно встроить в процесс, а не откладывать. Начните с тестов на старое поведение, инкапсулируйте «кудзу» и меняйте по одной фиче. Кто не удаляет код, того код и поглощает.
Связанные статьи
- ИИ для рефакторинга легаси-кода — что агент делает хорошо, а что ломает
- Кейс: переписывание легаси с ИИ — реальный опыт миграции
- Тесты с ИИ: pytest и Playwright — как покрыть код до изменения
- ИИ для документации кода — README, changelog и контракты
Читайте также: Вайб-кодинг: что это и как работать с ИИ-агентом на ощущениях · ИИ-агенты: примеры того, что агент реально делает в 2026
