Vibe‑кодинг в масштабе: риски, технический долг, сложность, избыточная уверенность

Что означает «vibe-кодинг», когда вы масштабируетесь

«Vibe-кодинг» — это подход, где на первом месте интуиция и скорость: вы идёте по потоку, принимаете быстрые решения и продолжаете выпускать изменения, не останавливаясь, чтобы формализовать каждое требование, крайний случай или архитектурный выбор. Обычно он опирается на опыт разработчиков, приём «копипаст», лёгкое тестирование и оптимизм «потом всё починим».

Такой подход действительно полезен при исследовании идей, валидации прототипа или поиске product–market fit. Главное — считать код средством быстрого обучения, а не долговременным контрактом.

Почему всё меняется при росте команды и кодовой базы

На небольшом этапе тот же человек (или маленькая команда) держит в голове большую часть контекста. Когда что‑то ломается, обычно понятно, где смотреть. При масштабировании контекст распределяется: приходят новые разработчики, систем становится больше, и «неписаные правила» перестают быть общим знанием.

Тогда vibe-кодинг перестаёт быть личным стилем и становится организационным поведением. Цена незадокументированных решений растёт, быстрые фиксы превращаются в зависимости, а приёмы‑шорткаты копируются, потому что «кажется, работают».

Три риска, к которым мы будем возвращаться

По мере роста кодовой базы часто появляются три режима отказа:

• Технический долг, который бесшумно множится: маленькие хаки закрепляются в структуре кода.
• Скрытая сложность и неожиданные зависимости: изменение в одной области ломает другую способами, которых никто не предвидел.
• Командная привычка к избыточной уверенности: быстрая доставка воспринимается как доказательство здоровья системы.

Речь не о борьбе со скоростью. Цель — сохранить преимущества скорости, добавив ограждения, чтобы продукт мог масштабироваться без превращения каждого релиза в русскую рулетку.

Почему это кажется быстрым (и почему это может вводить в заблуждение)

Vibe-кодинг даёт ощущение скорости, потому что оптимизирует поток: вы быстро принимаете решения, сокращаете церемонии и следуете интуиции вместо чек‑листов. Это создаёт настоящий импульс — особенно когда вы начинаете с нуля и каждый коммит заметно меняет продукт.

Короткосрочные выигрыши реальны

Когда цель — обучение, а не идеал, vibe-кодинг может быть суперсилой. Вы выпускаете сырые прототипы, исследуете идеи и поддерживаете высокий уровень креативности. Команды часто получают:

• Быстрые прототипы, которые дешёво валидируют (или отбрасывают) идею
• Скорую обратную связь от пользователей, потому что есть что попробовать
• Чувство прогресса, которое мотивирует команду

Эта скорость полезна, когда неопределённость высока, и стоимость ошибки должна быть низкой.

Ранний успех может скрывать слабые основания

Ранний софт прощает многое. При маленькой кодовой базе, одном разработчике и низком трафике многие проблемы просто не проявляются. Отсутствие тестов пока не кусает. Неочевидные имена живут «в вашей голове». Хардкод работает, потому что на него никто не опирается.

Но эти основания закладываются, пока вы бежите быстро. Позже, при добавлении фич, при онбординге новых людей или интеграции сторонних сервисов те же шорткаты превратятся в трение — и «быстро» начнёт давать более медленные результаты.

Ловушка «работает один раз»

Обычная схема: что‑то сработало один раз, и команда предполагает, что так будет всегда. Так разовые фиксы копируются, а хитрые хаки тихо становятся «тем, как мы делаем». Скорость превращается в привычку, привычка — в культуру.

Где это действительно полезно

Vibe-кодинг хорош для спайков, прототипов и короткоживущих экспериментов — там, где важнее скорость обучения, а не поддерживаемость. Ошибка — позволить эксперименту стать продуктом без осознанного перехода к инженерным практикам, которые поддерживают масштаб.

Риск №1: технический долг, который бесшумно множится

Технический долг — это цена «потом починим», которую вы платите, выбирая самый быстрый путь вместо самого ясного и безопасного. При vibe-кодинге это часто выглядит как релиз фичи с минимальными тестами, неясными именами или временным патчем, который работает для текущего демо, но не рассчитан на следующие три запроса.

Как долг проявляется в реальном коде

Пара примеров:

• Шорткаты в логике: дублирование валидации в трёх местах вместо централизации
• Отсутствие тестов: нет автоматических проверок для крайних случаев, обработки ошибок или прав доступа
• Неочевидный код: «магические» переменные, смутные имена функций и комментарии вроде “TODO: cleanup”, которые так и не закрывают
• Хардкод: пороги цен, флаги фич или региональные правила прямо в коде
• Хлам в моделях данных: поля, добавленные ad hoc («temp2», «status_v3»), непоследовательные enum’ы или смешанные смыслы в одном столбце

Почему маленькие шорткаты множатся

Один шорткат может быть приемлем для одного человека в одном файле. В масштабе он распространяется: разные команды копируют работающие паттерны, сервисы интегрируются с неописанными допущениями, и один «быстрый фикс» реализуется по‑разному в нескольких местах. Результат — не один крупный провал, а тысяча маленьких несовпадений.

Кривая затрат: быстро становится дорого

Долг меняет характер работы. Простые изменения начинают занимать больше времени: инженерам приходится распутывать побочные эффекты, дописывать тесты постфактум и заново изучать незадокументированные решения. Ошибки становятся чаще и хуже воспроизводимы. Онбординг тормозит, потому что новые люди не понимают, что намеренно, а что случайно.

Долг остаётся невидимым — пока не всплывёт

Технический долг часто прячется в «работающих» системах. Он даёт о себе знать при больших изменениях: редизайне, требовании соответствия, оптимизации производительности или новой интеграции. Тогда тихие шорткаты требуют оплаты, обычно с процентами.

Риск №2: скрытая сложность и неожиданные зависимости

Vibe-кодинг оптимизирует «работает на моей машине». В маленьком масштабе это чаще проходит. В большом — сложность прячется между модулями: интеграции, крайние случаи и реальный путь данных через систему.

Где на самом деле живёт сложность

Большинство сюрпризов исходят не из функции, которую вы поменяли, а из того, что она затрагивает.

Интеграции вводят невидимые правила: капризы API, повторные попытки, лимиты запросов, частичные отказы и «успешные» ответы, которые на самом деле означают проблему. Крайние случаи скапливаются в продакшн‑данных: отсутствующие поля, неожиданные форматы, события вне порядка или старые записи, созданные до появления правила валидации.

Потоки данных — главный множитель сложности. Малое изменение в том, как вы пишете поле, может сломать downstream‑джоб, аналитическую панель или выгрузку для биллинга, которая полагается на старое значение.

Неизвестные зависимости (то, о чём никто не помнит)

Скрытое сцепление проявляется как:

• Модули, которые делят одну таблицу БД (или столбец) без явного контракта
• Общие конфиги и флаги фич, используемые для несвязанных поведений
• «Утилитарные» библиотеки, которые тихо становятся сборной кучей и используются везде

Когда зависимости неявные, вы не можете рационально оценить влияние — только обнаружить его постфактум.

Разрыв «кажется — делает» в продакшне

Изменение может проходить локальные тесты, но вести себя иначе под реальной конкурентностью, ретраями, кэшированием или многопользовательскими данными.

AI‑помощники могут усугубить это: сгенерированные абстракции скрывают сайд‑эффекты, непоследовательные паттерны усложняют будущие правки, а разная обработка ошибок создаёт странные режимы отказа.

Простая история

Разработчик «просто» переименовал статус для ясности. UI продолжает работать. Но webhook‑консьюмер фильтрует по старому статусу, ночная синхронизация пропускает записи, а отчётность по финансам теряет доход за день. Ничего не «упало» — но повсюду тихо стало неправильно.

Риск №3: избыточная уверенность как командная привычка

Избыточная уверенность при vibe-кодинге — это не просто вера в себя. Это доверие интуиции больше, чем доказательствам по мере роста ставки: выпускать, потому что «так ощущается правильно», а не потому что это проверено.

Ранние успехи побуждают к этому. Быстрый прототип работает, метрики радуют, и команда делает опасный вывод: ревью, тесты и дизайн — «опциональны». Всё, что тормозит, начинает выглядеть бюрократией — даже если именно это предотвращает будущий пожар.

Как ранние успехи оборачиваются пропуском дисциплины

Vibe-кодинг часто начинается с настоящего импульса: меньше встреч, меньше документов, быстрее коммитов. Проблема — в образующейся привычке:

• Pull request’ы становятся формальностью («выглядит ок, выпускаем»)
• Тесты откладываются («потом добавим покрытие»)
• Архитектурные решения происходят в голове одного человека, а не в общем контексте

Это проходит при одном человеке и маленькой базе. Ломается, когда несколько людей должны безопасно менять одни и те же системы.

«Героическое кодинг» не масштабируется

Избыточная уверенность порождает паттерн героя: один человек делает огромные изменения ночью, спасает релизы и становится неформальным владельцем всего. Это кажется продуктивным — пока этот человек не уходит в отпуск, не увольняется или не выгорает.

Риск решений: оптимистичные сроки и игнор миграций

С возрастанием уверенности оценки сжимаются, риски обесцениваются. Миграции, рефакторинги и изменения данных воспринимаются как простая переработка, а не как координированный проект. Команды начинают назначать даты релизов, предполагая, что всё пройдёт гладко.

Как это распространяется культурно

Если скорость вознаграждается сильнее, чем обучение, команда подражает поведению. Люди перестают просить доказательства, перестают делиться неопределённостью и перестают поднимать проблемы. Здоровый инженерный процесс — не про медлительность, а про создание доказательств до того, как продакшен сделает это за вас.

Качество и надёжность: дрейф по мере роста кодовой базы

Vibe-кодинг может ощущаться как постоянный прогресс — пока кодовая база не достигает размера, при котором малые изменения начинают рябить по всему. Качество не рушится одномоментно: оно дрейфует. Надёжность становится «в целом ок», затем «иногда странно», потом — «боимся деплоить в пятницу».

Типичные режимы отказа

С ростом поверхности самые частые поломки не драматичны, но шумны:

• Регрессии: фиксы в одной области тихо ломают другую.
• Флейки: одно и то же действие иногда работает, иногда нет (тайминги, кэш, гонки, непоследовательные допущения в данных).
• Несогласованный UX: похожие экраны ведут себя по-разному, потому что паттерны не стандартизированы (валидация, ошибки, индикаторы загрузки, пустые состояния).

Почему ручное тестирование перестаёт работать

Ручные проверки плохо масштабируются при высокой частоте релизов. Каждый релиз имеет меньше времени на аккуратную проверку, и подход «протестируем всё быстро» превращается в семплинг. Это создаёт провалы, особенно в крайних случаях и при взаимодействиях между функциями. С течением времени команды начинают полагаться на отчёты пользователей — дорого, медленно и вредно для доверия.

Сигналы деградации качества (как это проявляется)

Дрейф качества можно измерить, хоть он и ощущается субъективно:

• Бэклог багов растёт быстрее, чем закрывается
• Повторяющиеся инциденты с похожими корневыми причинами
• Культура хотфиксов: частые «маленькие экстренные выкаты» после релизов
• Больше обращений в поддержку по «раньше работало»

Что означает «готово» в масштабе

При масштабе «готово» не может означать «работает на моей машине». Разумное определение включает:

• Автотесты для критичных путей (а исправления сопровождаются регрессионными тестами)
• Базовая документация для неочевидного поведения и решений
• Хуки мониторинга: логи/метрики вокруг ключевых действий и точек отказа

Скорость без качества превращается в замедление позже — каждая новая правка дороже проверять, дольше дебажить и сложнее объяснить.

Риски безопасности, приватности и соответствия

Скорость — это фича, пока вы не пропустили «скучные» шаги, которые предотвращают утечки. Vibe-кодинг часто отдает приоритет заметному прогрессу (новые экраны, эндпоинты, быстрые интеграции), минуя моделирование угроз, базовый security‑ревью и даже простые вопросы: что случится, если ввод окажется вредоносным или аккаунт будет скомпрометирован?

Частые разрывы, которые проявляются позже

Шаблоны, которые часто всплывают при быстром движении без оград:

• Секреты в коде: ключи API, пароли БД и токены, залитые в репозиторий, вставленные в тикеты или попавшие в фронтенд
• Отсутствие валидации входящих данных: эндпоинты принимают unchecked ID, загрузки файлов или произвольный JSON, который позже становится вектором инъекции
• Небезопасные привилегии: сервисы с широкими ролями в облаке, общие админ‑аккаунты или «временный» доступ, который становится постоянным

Эти дыры могут тихо существовать, пока кодовая база не вырастет так, что никто не вспомнит, почему шорткат появился.

Приватность и соответствие: риск увеличивается с объёмом данных

Как только вы храните пользовательские данные — письма, метаданные платежей, геолокацию, данные о здоровье или аналитическое поведение — вы несёте ответственность за сбор, хранение и шаринг. Быстрая итерация может привести к:

• Сбору больше данных, чем нужно (труднее защищать и обосновать)
• Неясной политике хранения («потом почистим»)
• Случайному раскрытию через логи, выгрузки или плохо ограниченные внутренние дашборды

Если вы подпадаете под GDPR/CCPA, SOC 2, HIPAA или отраслевые требования, «мы не знали» — не защита.

Риск цепочки поставок от быстрых добавлений зависимостей

Быстрое добавление библиотек — особенно для аутентификации, криптографии, аналитики или билд‑тулов — может внести уязвимости, нежелательную телеметрию или несовместимые лицензии. Без ревью одна зависимость может сильно расширить поверхность атаки.

Безопасные дефолты, которые сохраняют импульс

Используйте автоматизацию и лёгкие барьеры вместо надежды на человеческую память:

• Автосканирование: поиск секретов, скан зависимостей/уязвимостей и SAST в CI
• Принцип наименьших привилегий для ролей облака, сервисных аккаунтов и доступа к прод‑данным
• Гейты ревью для чувствительных областей (auth, платежи, PII, права, шифрование) с коротким чек‑листом и обязательными ревьюверами

При правильной настройке эти ограждения сохраняют скорость и предотвращают необратимый security‑долг.

Операции: когда продакшен становится проверкой реальности

Vibe-кодинг часто «работает» там, где он создан: на ноутбуке разработчика с кешированными учётками, семплированными данными и прощающей средой выполнения. Продакшен убирает эти подушки. «Работает на моей машине» становится дорогим, когда каждое несоответствие превращается в фейлы деплоя, частичные аутейджи или баги, видимые пользователям, которые трудно быстро воспроизвести.

Отсутствующий уровень: наблюдаемость

Когда скорость важнее структуры, команды часто пропускают «трубы», которые объясняют, что делает система.

Плохие логи — вы не ответите «что случилось?» после сбоя.

Нет метрик — вы не увидите, как деградирует производительность, пока она не пересечёт критический порог.

Нет трейсинга — вы не увидите, где тратится время по сервисам, очередям или внешним API.

Слабая отчётность об ошибках — исключения копятся в темноте, превращая реальные инциденты в догадки.

Операционный долг проявляется как хрупкая доставка

Операционный долг — это разрыв между «приложение запускается» и «приложение можно безопасно эксплуатировать». Он выглядит как хрупкие деплои, фиксы для конкретного окружения, неясные шаги отката и скрытые ручные действия («после деплоя запусти этот скрипт», «перезапусти того воркера, если зависнет»). Рунбуки либо отсутствуют, либо устарели и принадлежат «тому, кто последний раз это трогал».

Симптомы, которые вы почувствуете сначала

• Response на инцидент занимает больше времени, потому что никто не видит корень
• Неясна ответственность: алерты срабатывают, но команда не берёт ownership
• Алерты шумные или бессмысленные, их игнорируют
• Деплои требуют племенного знания и правил «не трогать в пятницу»

Небольшие привычки, которые предотвращают хаос

Начните рано с лёгких операционных рутин: страница runbook на сервис, несколько дашбордов, связанных с пользовательским влиянием, автоматические отчёты об ошибках и короткие постмортемы с одним‑двумя конкретными исправлениями. Это не «лишний процесс» — это способ сохранить скорость, не делая продакшен вашей бесплатной тестовой средой.

Разлад в команде и процессах при масштабировании

Vibe-кодинг кажется коллаборативным в начале, потому что все «просто выпускают». Но по мере роста командами интерфейс между людьми — это кодовая база — и несогласованность превращается в трение.

Дрифт стиля замедляет сотрудничество

Когда каждая фича следует своему паттерну (структура папок, нейминг, обработка ошибок, менеджмент состояния, вызовы API), инженерам приходится больше переводить, чем строить. Ревью превращаются в споры о вкусе, а мелкие изменения занимают больше времени, потому что никто не уверен, какой паттерн «правильный» для этой области.

Результат — не только замедление доставки, но и неравномерное качество. Некоторые части хорошо протестированы и читаемы, другие — хрупки. Команды начинают направлять работу к тем, кто «знает ту часть», создавая узкие места.

Онбординг превращается в догадки

Новые инженеры нуждаются в предсказуемости: где живёт бизнес‑логика, как проходят данные, как добавить эндпоинт, куда класть валидацию, какие тесты писать. В vibe‑кодовой базе ответы зависят от фичи.

Это увеличивает стоимость онбординга двумя способами:

• Новичкам требуется больше времени от сениор‑разработчиков поддержка
• Они вносят «разумные» изменения не в то место, создавая регрессии или дублирование логики

Издержки координации проявляются как дубли и конфликты

При параллельной работе непоследовательные допущения порождают переработку:

• Два инженера создают похожие утилиты, потому что не нашли существующую
• Фичи конфликтуют, потому что один модуль зависит от побочных эффектов другого
• Увеличиваются конфликты слияний, потому что общие файлы становятся свалкой

В итоге команда замедляется не потому, что кодинг стал сложным, а потому что координация стала сложной.

Долг решений заменяет архитектуру

Если пропускать явные выборы — границы, ownership, API‑контракты, «одно верное решение для X» — вы накапливаете долговременные решения. Каждое следующее изменение заново открывает старые вопросы. Без ясных швов никто не уверен в рефакторинге, и всё становится взаимосвязанным.

Простые инструменты выравнивания, которые сохраняют скорость

Вам не нужен тяжёлый бюрократизм. Несколько лёгких «примитивов выравнивания» изменяют многое:

• Конвенции: нейминг, структура папок, обработка ошибок, логирование
• Шаблоны: скелеты сервисов/модулей, настройка тестов, чек‑листы PR
• Golden paths: рекомендованный путь для типовых задач (добавление API‑роута, создание background job, новая UI‑страница)

Эти инструменты уменьшают издержки координации и делают кодовую базу предсказуемой — так команда продолжает двигаться быстро, не наступая себе на ноги.

Предупреждающие знаки: метрики и запахи, за которыми стоит следить

Vibe-кодинг может выглядеть нормально — пока однажды не перестаёт. Хитрость в том, чтобы поймать сдвиг от «временной неразберихи» к «системному долгу, который продолжает распространяться». Смотрите и на цифры, и на поведение команды.

Измеримые индикаторы (цифры не врут)

Несколько метрик обычно меняются первыми:

• Время цикла растёт: мелкие изменения занимают больше времени неделя к неделе
• Частота дефектов растёт: больше багов на релиз, больше обращений от пользователей, больше хотфиксов
• Ролбеки увеличиваются: релизы чаще откатывают или деплои ставят на паузу из‑за кажущейся рискованности
• Частота/тяжесть инцидентов растёт: больше пэйджей, дольше восстановление, повторяющиеся инциденты

Качественные «запахи» (что люди начинают говорить)

Они часто приходят раньше графиков:

• «Не трогайте этот файл — он ломает всё.»
• «Только Алекс понимает эту часть.»
• Фичи выпускаются, а потом переписываются каждые несколько недель, потому что предыдущая версия тяжело расширяема.
• PR разрастаются, потому что команды избегают частых интеграций.

Временная грязь vs системный долг

Временная грязь — намеренная и с дедлайном (например, быстрый эксперимент с явным тикетом на очистку и владельцем). Системный долг — поведение по умолчанию: шорткаты без плана, разбросанные по модулям и замедляющие дальнейшие изменения.

Лёгкие способы аудита реальности

• Создайте простую карту зависимостей (хотя бы диаграмму), чтобы обнаружить неожиданные сцепления
• Отслеживайте тенденцию покрытия тестами со временем (важна динамика, больше чем абсолютное число)
• Проводите быстрые ревью инцидентов, чтобы выявить повторяющиеся причины, а не разовые исправления

Делайте риск видимым

Используйте «реестр долгов» и ежемесячные проверки техздоровья: короткий список топ‑долгов, их влияние, владелец и целевая дата. Видимость превращает расплывчатые тревоги в управляемую работу.

Практические ограды, которые сохраняют скорость без хаоса

Быстрая разработка остаётся быстрой, если вы определите, что значит «безопасная скорость». Цель — не тормозить людей, а сделать быстрый путь предсказуемым.

Определите workflow «безопасной скорости»

Держите изменения малыми и с владельцем. Предпочитайте PR, который делает одно дело, имеет явного ревьювера и легко откатывается.

Простое правило: если изменение нельзя объяснить в пару предложений — вероятно, его нужно разбить.

Лёгкие гейты перед слиянием

Ограждения лучше работают, когда они автоматические и предсказуемые:

• Нормы код‑ревью: минимум один ревьювер не‑автор, и стандартный вопрос «что может сломаться?»
• CI‑гейты: сборка должна проходить, тесты запускаться, и ошибки блокируют слияние
• Линтинг/форматирование: автоматическое приведение стиля, чтобы не тратить время на споры
• Политика зависимостей: документировать процесс одобрения новых библиотек, обновлений версий и владельцев критичных зависимостей

Слои тестирования (простым языком)

Думайте слоями, чтобы не пытаться тестировать все одинаково:

• Unit‑тесты: быстро проверяют маленькие куски логики
• Интеграционные тесты: убеждаются, что компоненты работают вместе (БД, очереди, внешние сервисы)
• End‑to‑end: имитируют реальные пользовательские пути; таких тестов немного и они высокого значения
• Контрактные тесты: валидируют «рукопожатие» между сервисами/пользователями API, чтобы изменения не удивляли других

Документация, которая масштабируется

Пишите меньше, но нужное:

• ADR (Architecture Decision Records): короткие заметки о принятом решении и почему
• Мини‑дизайн‑ноты: страница перед крупной работой для выравнивания объёма и рисков
• Рунбуки: пошаговые инструкции для типичных продакшен‑ситуаций и процедур деплоя/отката

Где AI‑инструменты уместны (а где нет)

Используйте AI для черновиков: первый вариант кода, каркасы тестов, предложения по рефакторингу и наброски документации. Но ответственность остаётся за человеком: ревьювер отвечает за слияние, команды — за выбор зависимостей, и никто не должен принимать сгенерированный код, который не может объяснить.

Практический путь: стандартизировать передачу из чата‑построенных прототипов в поддерживаемые системы. Например, если вы пользуетесь платформой вроде Koder.ai для быстрого разворачивания веб‑приложений (React), бэкендов (Go + PostgreSQL) или мобильных приложений (Flutter) из чата, относитесь к результату как к обычному инженерному артефакту: экспортируйте исходники, пропустите через CI‑гейты и требуйте тестов + ревью перед широким использованием. Фичи вроде снэпшотов/откатов и планировочного режима помогут двигаться быстро, сохраняя аудируемость и обратимость изменений.

Когда vibe‑кодить можно (а когда нельзя)

Vibe‑кодинг — разумный выбор, когда нужно быстро учиться, валидировать идею или разблокировать команду. Это плохая ставка, когда скорость незаметно заменяет ясность, и код считается «достаточно хорошим» для долгосрочного использования.

Критерии решения (быстрый чек)

Используйте vibe‑подход, когда большинство из следующих истинны:

• Уровень риска: низкий (ошибка раздражает, но не катастрофична)
• Урон пользователям: ограниченный радиус поражения (малый ко́хорт, внутренние пользователи или фича‑флаг)
• Чувствительность данных: нет регламентированных или чувствительных данных
• Горизонт времени: можно заменить скоро, или план есть — упрочить

Избегайте для платежей, auth, прав, ключевых рабочих процессов или всего, что стыдно объяснять на инцидент‑ревью.

Думайте в «зонах»

• Зона экспериментов: прототипы, throwaway‑скрипты, демо. Vibe‑кодинг подходит.
• Зона критичных систем: пути монетизации, данные клиентов, общие библиотеки. Vibe‑кодинг допустим только для спайков — потом нужно рефакторить.
• Зона регулирования: здравоохранение, финансы, продукты с высокой приватностью. Не выпускайте vibe‑код в прод.

Простой плейбук: быстро сначала, затем упрочнять

1. Прототипируйте быстро за флагом или в песочнице.
2. Назовите это прототипом (лейбл в тикете, README, дата истечения).
3. Упрочните перед широким применением: тесты, упрощение зависимостей, документация, ревью.
4. Выпуск или удаление: либо сделать поддерживаемым, либо убрать.

Чек‑лист, который можно использовать на следующей неделе

• Есть явный владелец и дата истечения для этого кода?
• Выпущено ли это за фич‑флагом или в безопасной зоне?
• Есть ли базовые тесты для критического пути?
• Зависимости минимальны и обоснованны?
• Обрабатываются ли ошибки и крайние случаи предсказуемо?

Возьмите одно ограждение, чтобы внедрить первым: «Прототип не попадает к 20% пользователей без тестов и ревью.» Согласуйте это в команде — и вы сохраните скорость, не унаследовав хаос.