Попросите Astra найти код, который вашему проекту больше не нужен

Если вы собирали проект с ИИ, дайте Astra пересмотреть один его участок. Начните с вопроса: что здесь можно убрать, сохранив нужное поведение?

Такую ревизию предлагает Vox в оригинальном посте. Ниже — последовательность запросов для Codex.

Сохраните пост, чтобы потом открыть свой проект и пройти шаги по очереди. Подставьте свои данные в квадратные скобки.

1. Объясните, что должно продолжать работать

Выберите одну функцию или папку. Например: форму записи на консультацию.

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

Прочитайте ответ. Если Codex упустил важное поведение — дополните список перед следующим шагом.

2. Найдите кандидатов на удаление

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

Ищите конкретное объяснение: «эту функцию вызывает только старый тест, рабочий сценарий использует другую». Формулировки «выглядит лишним» недостаточно.

3. Проверьте и примените одно изменение

Выберите один понятный пункт и подставьте его номер:

Подготовь и выполни только изменение №[номер] в отдельной рабочей копии проекта. Сохрани мои текущие изменения. Сначала запусти относящиеся к нему проверки, чтобы зафиксировать состояние до правки. Если проверки уже падают или зависимости остаются неясными — остановись и объясни проблему. Затем внеси минимальную правку и повтори проверки. Не удаляй и не ослабляй тесты только ради успешного результата. Не меняй данные, публичные интерфейсы и настройки рабочего сервиса. Не делай merge, push или публикацию. Покажи diff, результаты до и после и способ точечного отката.

Если проверить изменение нечем, сначала попросите Codex предложить проверку нужного поведения. Переходить к удалению стоит после того, как понятно, чем подтвердить результат.

4. Проверьте глазами пользователя

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

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

Если результат не совпал с ожидаемым:

Проверка [сценарий] дала [фактический результат] вместо [ожидаемого]. Не продолжай очистку. Найди связь с внесённой правкой. Если для исправления потребуется расширить согласованный объём, сначала покажи предложение. Сохрани возможность отменить только это изменение.

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

Связанные материалы

• Вайбкодинг без бардака: правила, которые действительно экономят часы
• Одна строчка в промпт, которая спасает вайб-кодинг от самописных костылей
• Codex App — единый справочник по среде от OpenAI

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov