Еженедельная уборка репозитория для команд с большим объёмом AI за 30 минут

Почему репозитории с AI быстро захламляются

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

Промптовая работа усугубляет ситуацию, потому что люди часто тестируют вне обычного потока. Они сохраняют куски в случайных markdown‑файлах, текстовых файлах, ноутбуках или в папках с названиями "temp" и "misc". В тот момент это кажется безобидным. Через неделю никто не понимает, какой промпт ещё нужен, а какой провалился с первой попытки.

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

Имена дрейфуют, когда люди работают быстро. Файл начинается как "draft_prompt.md", становится "draft_prompt_v2.md", затем превращается в "final_prompt_new.md." То же происходит с папками, флагами фич и экспериментальными ветками. Через какое‑то время репозиторий перестаёт рассказывать понятную историю.

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

Короткая еженедельная уборка решает это, прежде чем превратится в трение. В репозиториях с большим количеством AI энтропия — это норма. Проблема начинается, когда устаревшие файлы выглядят так же правдоподобно, как и те, которыми команда пользуется каждый день.

Что укладывается в 30 минут

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

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

Проход прост:

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

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

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

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

Еженедельная рутина

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

Первые пять минут потратьте на просмотр недавних коммитов, открытых pull request'ов и верхнеуровневых папок. Ищите свежий мусор: скопированные промпты, экспортированные тесты, загадочные скрипты и файлы с именами, которые имели смысл только во вторник.

Следующие десять минут используйте для работы с именами. Переименуйте папки, файлы промптов и вспомогательные скрипты с неясными метками вроде test3, new-prompt или tmp-run. Если имя не объясняет, что делает файл, исправьте это сейчас.

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

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

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

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

Исправляйте имена в первую очередь

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

Имена вроде test2, final, new или prompt_latest устаревают за считанные дни. Чёткое имя должно объяснять, что это за файл и что он делает. lead_scoring_prompt_v3.md не идеал, но намного лучше, чем newprompt.md.

Названия папок важны не меньше. Папка misc превратится в ящик для хлама. Если там лежат eval‑скрипты — назовите её evals. Если это архив экспериментов, используйте что‑то простое вроде archive/2025-04. Скучная ясность всегда лучше умного названия.

Используйте один паттерн именования для промптов, скриптов и вспомогательных файлов. Команды часто смешивают стили без осознания: fixBug.py, prompt-final.md, run_eval_NEW.ts, stuff/. Это замедляет всех.

Простой шаблон достаточен:

• промпты: task_audience_goal.md
• скрипты: verb_object.py
• папки: prompts, evals, scripts, docs
• архивы по датам: archive/YYYY-MM

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

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

Обрезайте старые ветки и эксперименты

Большая часть загромождения не от релизной работы. Она от побочных ответвлений, за которые никто больше не отвечает: test-rag-v4, agent-prompt-fix-final, new-eval-maybe. В репозиториях с AI такие ветки появляются быстро, потому что люди запускают больше мелких тестов и бросают их, как только один путь кажется достаточным.

Начните с вмерженных веток. Если работа уже попала в main, закройте ветку сразу. Старые вмерженные ветки делают список бесполезно громоздким, и люди тратят время, проверяя, важна ли старая ветка.

Затем посмотрите на ветки, к которым давно никто не притрагивался. Задайте простой вопрос: "Откроет ли кто‑нибудь это снова в следующий понедельник?" Если нет — удаляйте. Вы не стираете историю: git хранит коммиты, а всё полезное уже должно быть в main, теге или короткой заметке.

Перед удалением эксперимента сохраните только то, что заслуживает места:

• что вы тестировали
• что случилось
• почему это не прошло или почему выглядело перспективно
• что стоит попробовать дальше

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

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

Обращайтесь с экспериментами как с лабораторными заметками, а не с постоянным кодом. Сохраните результат, урок и удалите ветку.

Обрежьте куски промптов и одноразовые файлы

Промптовый мусор распространяется быстрее, чем кодовый. В AI‑репозиториях скапливаются скопированные файлы промптов, сырые экспорты моделей, наброски, логи одного дня тестов. Через неделю никто не понимает, какой промпт управляет рабочим процессом.

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

Простое разделение работает хорошо:

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

Это быстро экономит время. Когда кто‑то открывает prompts/, он должен видеть только актуальные файлы, а не prompt-final.md, prompt-final-v2.md и prompt-final-use-this.md. Выберите один файл, дайте ему понятное имя и позвольте Git хранить историю.

Будьте строги с сгенерированными остатками. JSON‑экспорты, CSV‑дампы, скриншоты, отладочные логи и примеры вывода модели часто попадают в коммиты, потому что лежат рядом с реальной работой. Если файл не поддерживает тест, ревью или реальный рабочий поток — ему не место в репозитории.

Эта часть уборки обычно занимает меньше десяти минут. Откройте папки с промптами, отсортируйте по дате изменений и задавайте для каждого файла один вопрос: использует ли кто‑нибудь это сейчас? Если нет — удаляйте.

Обновите доки, которые люди всё ещё читают

Начните с README. Если кто‑то открывает репо впервые, этот файл определяет первые десять минут. Исправить его обычно даёт наибольший эффект при минимальных усилиях.

Ищите шаги, которые больше не соответствуют коду. Старые команды установки, переименованные папки, мёртвые скрипты и устаревшие заметки о моделях быстро съедают время. Одна неверная команда в README может отправить коллегу в 20‑минутный пируэт.

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

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

Вам не нужны идеальные доки каждую неделю. Нужны доки, которым люди доверяют. Если секция незавершённа — пометьте её ясно: "Draft - steps may change" или "Not updated for the new eval flow yet." Это предотвращает использование старого текста как текущего процесса.

Если времени мало, сфокусируйтесь на доках, связанных с работой на этой неделе:

• README
• локальные заметки по настройке
• соглашения по промптам и eval'ам
• шаги развёртывания или релиза
• onboarding‑заметки для текущего рабочего процесса

Старые справочные страницы могут подождать. README — обычно не может.

Пример для маленькой команды

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

Фича‑работа путается так же. Одна ветка называется agent-memory-test, другая — memory-v2, и обе решают одну проблему. Инженер держит одну на всякий случай. Основатель держит другую из‑за правки промпта, которая казалась лучше во вторник. У обеих нет явного владельца, и обе кажутся наполовину законченными.

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

Короткая уборка может решить больше, чем ожидают. Команда выбирает одну ветку для сохранения и закрывает другую. Они перемещают выжившие промпты в одну папку с понятными именами вроде support-reply-draft.md, вместо того чтобы оставлять их в чатах и комментариях. Удаляют промптовые обрезки, которые никогда не шли в прод. Затем тратят пять минут на переписывание README, чтобы он соответствовал текущей модели и настройке.

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

Ошибки, которые съедают полчаса

Самый быстрый способ потерять 30 минут — относиться к уборке как к рефакторингу. Открыл репо, чтобы убрать пару вещей, а потом начал перерабатывать папки, переписывать промпты и трогать рабочий код. Теперь уборка превратилась в побочный проект.

Ещё одна частая ошибка — превращать именование в дебаты. Команды тратят десять минут на спор о паттерне, и ничего не переименовывают. В репозиториях с AI очевидные имена выигрывают у идеальных правил. Если test2_final_v3 сбивает с толку — переименуйте и двигайтесь.

Команды также оставляют слишком много экспериментов "на всякий случай". Старые ветки, брошенные eval‑скрипты, куски промптов и одноразовые ноутбуки быстро накапливаются. Через месяц никто не понимает, что актуально. Поиск шумит. Новые люди открывают не тот файл и теряют время.

Простое правило помогает: если никто не планирует использовать это на этой неделе и никто не хочет этим владеть — удалите или заархивируйте вне активного репо.

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

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

Если пункт требует встречи, переписывания или согласования трёх человек — он не для этого полчаса.

Быстрые проверки перед завершением

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

Перед закрытием репозитория выполните последний проход:

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

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

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

Сделайте это привычкой

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

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

Короткого списка достаточно:

• правила именования для веток, промптов и экспериментальных файлов
• доки, которые требуют быстрого обновления
• элементы уборки, которые не вошли в 30 минут

Передавайте еженедельный проход одному человеку. Владельца можно сменять раз в месяц, но каждый проход нуждается в чётком ответственном.

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

Если разрастание возвращается, внешний технический лидер может помочь установить правила и держать их практичными. Oleg Sotnikov at oleg.is работает со стартапами и небольшими командами как Fractional CTO, и такой лёгкий процесс уборки естественно вписывается в более широкий AI‑роадмап и автоматизацию.

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