Безопасное удаление выдуманных функций из AI‑сгенерированных репозиториев

Что такое халлюцинаторные функции (и почему они вредят)

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

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

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

Призрачные фичи повышают риск и стоимость, потому что они:

• Добавляют шум при отладке и скрывают настоящую проблему.
• Увеличивают поверхность для атак через лишние эндпоинты, недоделанные проверки аутентификации и небезопасные значения по умолчанию.
• Замедляют изменения, потому что страшно ломать неизвестные зависимости.
• Вводят в заблуждение продуктовые решения, потому что репо якобы показывает возможности, которых у вас нет.
• Увеличивают объём поддержки (тесты, миграции, рефакторинг) для того, чем никто не пользуется.

Обычно такие функции появляются от AI‑скелетонов, сгенерировавших «стандартные» модули, скопированных шаблонных сниппетов или цепочек запросов, где фичу начали, но не довели до конца. Иногда идея была обоснована, но она так и не была подцеплена к реальному пользовательскому пути.

Цель проста: оставить то, что поддерживает реальных пользователей, и удалить то, что не нужно, не сломав при этом критические потоки. Типичный сценарий — AI‑собранный MVP с тремя разными экранами входа, двумя админ‑дашбордами и схемой биллинга, которая ничего не делает. Очистка упрощает защиту и уменьшает стоимость изменений.

Три основных типа: мёртвые страницы, неиспользуемые API, фиктивные таблицы

При удалении халлюцинаторных функций основной риск концентрируется в трёх местах. Они тихо сидят в репо, но увеличивают поверхность для атак, путаницу и будущую работу по поддержке.

1) Мёртвые страницы (недостижимые маршруты)

Мёртвые страницы — это экраны, которые есть в маршрутизаторе, но до которых реальные пользователи не добираются. Часто это заброшенные потоки типа «Team Settings», «Billing» или «Admin», сгенерированные в начале и затем забытые.

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

2) Неиспользуемые API (эндпоинты без реальных вызовов)

Неиспользуемые API — это серверные маршруты, к которым нет реальных фронтенд‑вызовов, либо которые вызывает только оставшаяся тестовая страница или примерный скрипт. Такие эндпоинты легко случайно деплоить, особенно когда всё лежит в одной общей папке api.

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

3) Фиктивные таблицы (пустые структуры в базе)

Фиктивные таблицы выглядят как прогресс, но чаще всего это пустые оболочки: общие колонки, без ограничений, без индексов и без реальных чтений или записей в приложении.

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

Другие сигналы халлюцинаторных фич: модули, состоящие в основном из TODO, демо‑админки, обходящие права, мок‑аутентификация, принимающая любой email, и конфиги для сервисов, которыми вы не пользуетесь.

Прежде чем удалять: решите, что значит «безопасно» для вашего приложения

Удалять код безопасно только если вы договорились, что нельзя менять.

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

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

Простое правило принятия решений предотвращает долгие споры:

• Удалять сейчас: нет пользователей, нет ссылок, явный плейсхолдер или риск.
• Архивировать: может пригодиться позже, но не должно запускаться в продакшене.
• Оставить и пометить: используется сегодня, но требует владельца или переписывания.

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

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

Как найти мёртвые страницы и сиротские маршруты

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

Начните с того, по чему пользователь действительно может кликнуть. Откройте каждое меню навигации, хедер, футер, сайдбар и профильный дропдаун и выпишите URL‑адреса назначения. Сравните это с конфигом маршрутов (файлы роутера, папки pages, массивы роутов). Всё, что есть в маршрутах, но недостижимо из навигации, — кандидат на проверку.

Быстрые места для поиска:

• Маршруты, на которые никогда не ссылается компонент меню.
• Страницы/компоненты, которые появляются только в комментариях, мок‑JSON или сид‑данных.
• «Временные» пути вроде /admin, /debug, /test, /demo, /old, /v2, /settings-2.
• Маршруты, защищённые условиями, которые не могут выполниться (флаг всегда false, роль, которой никогда не присваивают).

Если у вас есть аналитика или серверные логи — используйте их как реальный индикатор. Маршрут с нулевыми заходами за несколько недель — сильный сигнал, особенно если это не админский поток. Без логов делайте ручной обход: пройдите основные сценарии, затем попробуйте несколько вероятных URL напрямую.

Пример: AI‑собранный MVP мог включать /team/invite и /billing/upgrade, потому что в подсказке упоминался «SaaS». Если у этих страниц нет ссылок, нет тестов и нет бэкенд‑связки, обычно их безопасно удалить или пометить изолированными.

Как найти неиспользуемые или рискованные API‑эндпоинты

AI‑сгенерированные репо часто содержат эндпоинты, которые звучали полезно на этапе прототипирования, но не стали частью продукта. Начните с инвентаризации, затем докажите, кто вызывает каждый эндпоинт.

Сначала перечислите все эндпоинты на бэкенде (файлы роутера, контроллеры, serverless‑функции и любые папки api). Просканируйте конфиги на предмет переадресаций, которые могут открывать обработчики.

Затем отследите вызовы. Ищите fetch или axios во фронтенде, проверьте фоновые задачи и очереди, и ищите вебхуки, которыми пользуются третьи стороны. Если есть логи — ищите пути эндпоинтов за последние 7–30 дней. Отсутствие трафика не даёт 100% гарантии, но это веский намёк.

Перед удалением пометьте рискованные эндпоинты. Частые тревожные признаки: отладочные маршруты доступные в продакшене, обходы аутентификации (захардкоженные админ‑токены, userId в query), широкие CORS на чувствительных маршрутах, отсутствие валидации и эндпоинты, возвращающие секреты или подробные внутренние ошибки.

Для каждого эндпоинта выберите одно из действий: удалить, заблокировать (убрать публичный роутинг, ограничить доступ) или оставить и исправить должным образом — добавить аутентификацию, валидацию и rate‑limit.

Как заметить фиктивные таблицы и «фейковую» структуру БД

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

Начните с перечисления всех таблиц и колонок, затем проследите, что действительно их трогает. Таблица обычно считается реальной, если приложение читает её, пишет в неё и у неё есть явные связи с базовыми таблицами (users, orders, projects). Если таблица есть только в миграции и нигде больше — считайте её подозрительной.

Признаки, что таблица — плейсхолдер

Надёжные сигналы:

• Имена вроде sample_*, demo_*, temp_*, test_*, mock_*, staging_*, placeholder_*.
• Нет внешних ключей и индексов, хотя они должны быть.
• Общие колонки вроде data JSON, value TEXT, meta TEXT, notes TEXT без ясного смысла.
• Внешне фейковые данные (lorem ipsum, фейковые email, фиксированные id вроде user_id = 1).
• Дубликаты (две версии «subscriptions», «payments» или «profiles»).

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

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

Шаг за шагом: удаляем халлюцинаторные функции, не ломая приложение

Удаление неверного элемента может сломать вход, права или биллинг. Относитесь к каждому подозрительному элементу как к небольшому change request, даже если вы уверены, что это фикция.

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

Низкорисковая последовательность действий:

• Сначала удаляйте скрытые страницы и неиспользуемый UI.
• Затем удаляйте неиспользуемые обработчики API (и вспомогательные модули, существующие только для этой фичи).
• В самом конце чистите базу данных (миграции, ORM‑модели, cron‑задачи).

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

Частые ошибки, приводящие к поломкам или проблемам с безопасностью

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

Одна ловушка — удалить страницу или кнопку, но оставить API. Админ‑экран исчезает, но эндпоинт всё ещё принимает запросы. При слабой авторизации он становится лёгкой мишенью.

Ещё одна ошибка — считать эндпоинт неиспользуемым, потому что он не связан с UI. Фоновые воркеры, планировщики и интеграции могут всё ещё вызывать его. Пример: вы удаляете /api/email/weekly-summary, потому что она не на страницах, но ночная задача всё ещё её вызывает — она начинает падать и генерировать ретраи и шум в логах.

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

Прежде чем удалять, перепроверьте:

• Вы удалили доступ, а не только UI (контроллеры/роуты не доступны публично).
• Вы искали использование в задачах/воркерах и внешних интеграциях.
• У вас есть бэкапы и проверена последовательность миграций.
• Вы убрали отладочные маршруты, тестовые ключи и временные админ‑логины из продакшена.

Быстрый чеклист перед удалением

Перед удалением кода убедитесь, что вы не убираете что‑то, что по‑тихому держит поток целым.

Начните с достижимости. Если обычный пользователь не добирается до страницы обычными кликами (а не вводя скрытый URL), это сильный кандидат. Но убедитесь, что вы не отрезаете побочный путь, например онбординг, сброс пароля или админскую настройку.

Быстрые проверки:

• Может ли обычный пользователь добраться без специальных URL, тестовых аккаунтов или dev‑тумблеров?
• Если это API, защищён ли он (аутентификация) и есть ли базовая валидация и лимиты, или он открыт?
• Если затрагивает данные, можно ли найти реальный путь чтения/записи этой таблицы в проде?
• Не изменятся ли роли, права, приглашения, доступ к биллингу или шаги онбординга при удалении?
• Убрали ли вы секреты, примерные ключи и тест‑конфиги, которые могли идти вместе?

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

Пример: очистка AI‑собранного MVP с лишними фичами

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

Первый шаг — доказать, что это халлюцинация, а не просто скрытая фича. Ищите признаки реального использования:

• Нет навигационных ссылок или кнопок на страницы (только прямой URL работает).
• Бэкенд‑логи не показывают вызовов соответствующих эндпоинтов в реальных сессиях.
• Фронтенд никогда не вызывает API.
• Таблицы в БД пусты или содержат только сид‑данные.
• В коде много «TODO», «Coming soon» или фиктивных тарифных планов.

Когда уверены, удаляйте поверхность шагами: сначала UI, потом API, затем схему. Если вы не готовы всё удалять, оставьте ясно помеченный стаб (например страница «Billing пока недоступен») и не оставляйте полусобранные эндпоинты или записи в БД.

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

Следующие шаги: поддерживайте чистоту репо и снижайте риск со временем

Удаление халлюцинаторных функций — это победа. Но не допустить их возвращения — ещё важнее.

Держите небольшой бэклог очистки для всего, что вы не удалили. Запишите, почему элемент остался ("может пригодиться позже", "нужна продуктовая веха", "заблокировано отсутствием тестов") и укажите одно следующее действие. Так временный каркас не станет постоянным риском.

Несколько лёгких правил помогают:

• Проваливать CI при очевидных плейсхолдерах (TODO маршруты, тестовые ключи, демо‑флаги).
• Требовать для каждой новой страницы и эндпоинта заметку об использовании или тест.
• Регулярно просматривать неиспользуемые маршруты/эндпоинты в staging.
• Вести короткий allowlist реальных таблиц и миграций, и отмечать всё, что вне него.

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

Если вы унаследовали AI‑сгенерированный прототип и хотите структурированный план демонтажа, FixMyMess (fixmymess.ai) фокусируется на диагностике и ремонте AI‑построенных кодовых баз, включая выявление мёртвых страниц, рискованных эндпоинтов и плейсхолдерной схемы перед тем, как вы что‑то удалите.