AI Vibe Craft
← Назад к AI Vibe News

Редакция 29 июня 2026 г.

Разборы

Scratchpad для coding agents: скорость без мусора в Git

Scratchpad для coding agents: скорость без мусора в Git.

Coding agents успевают навести беспорядок быстрее, чем вы просмотрите diff: один промпт оставляет debug-скрипты, JSON-дампы, заметки и stack traces прямо в рабочем дереве. Паттерн agent scratchpad предлагает отвести агенту видимую временную зону в репозитории — с локальным игнором Git, структурой evidence и правилами промоушена в основной код.

Почему агенту нужна отдельная зона, а не корень репозитория

Агентам нужно место думать, тестировать гипотезы и собирать доказательства; репозиторию — чистые границы между экспериментом и production. Типичный антипаттерн: после задачи в корне лежат scripts/test_sync.py, response.json и notes.md — ревьюер не отличает фичу от одноразового эксперимента агента.

Scratchpad должен быть видимым для редактора и локальных AI-инструментов, локально исключённым из Git и разложенным по назначению. Автор называет каталог temp/, scratch/ или .agent-scratch/; предпочитает короткое и очевидное имя temp/.

Временные файлы агента — не «мусор за дверью», а рабочий материал. Вопрос в том, куда их складывать и как не пустить в tracked source.

Локальный exclude вместо общего .gitignore

Механизм — .git/info/exclude, а не командный .gitignore. Exclude ведёт себя как ignore-файл, но действует только в локальном клоне и не меняет правила для команды, CI и общего репозитория.

После создания дерева temp/ в exclude добавляют комментарий и путь:

# Local AI/developer scratchpad
temp/

Проверка — git status --short: scratchpad не должен появляться в статусе. Класть temp/ в общий .gitignore заманчиво, но это может скрыть полезные соглашения от других контрибьюторов; для персональной scratch-работы безопаснее локальный exclude.

Важный нюанс для agent-assisted workflow: Git ignore не мешает редактору и локальным AI-инструментам читать файлы в temp/. Игнорирование — не сокрытие от агента; видимый локальный scratchpad как раз и нужен, чтобы инструкции и контекст оставались на месте.

Структура temp/: от одноразовых скриптов до traces агента

Практическая раскладка подпапок:

Подпапка Назначение
scripts/ одноразовые отладочные и migration-хелперы
dumps/ JSON, CSV, логи, ответы API, вывод бенчмарков
drafts/ черновики спек, заметки к промптам, планы реализации
traces/ трассы агента, сводки tool-call, eval-output
fixtures/ временные тестовые данные, не готовые к коммиту
screenshots/ UI-доказательства и снимки браузера
review-notes/ человекочитаемые сводки «что изменилось и почему»

В корне temp/ — README.md с правилами: не хранить секреты; не зависеть от файлов scratchpad в production-коде; осознанно промотировать полезное в репозиторий; чистить папку перед крупными merge.

Создание дерева одной командой:

mkdir -p temp/{scripts,dumps,drafts,traces,fixtures,screenshots,review-notes}

Для evidence приводится пример набора: temp/review-notes/fix-summary.md, temp/traces/test-run.txt, temp/screenshots/settings-page-after.png — с краткой review-заметкой: какие изменения внесены, какие тесты прогнаны, что не промотировано (например, reproduction-script только для локальной отладки). В команде — task-specific подпапки вида temp/tasks/billing-retry/, чтобы артефакты разных агентов не смешивались.

Инструкции агенту: куда писать и что не трогать

Конкретную IDE или коммерческий coding-agent автор не называет; речь о coding agents в общем. Инструкции для агента кладут в зависимости от стека — AGENTS.md, CLAUDE.md, .cursorrules или другой файл проектных правил.

В блоке guidance для агента стоит явно указать:

  • использовать temp/ для временных скриптов, логов, дампов API, трасс и черновиков;
  • не создавать случайные временные файлы в корне репозитория;
  • не хранить секреты и приватные данные в temp/;
  • перед завершением задачи кратко резюмировать важное в temp/review-notes/.

Так scratchpad становится частью промптового контракта с агентом, а не только договорённостью между людьми.

Review gates, промоушен и защита от «утечки» в production

Под leak в этом материале имеется в виду утечка временных файлов агента в production или tracked source, а не security-инцидент вроде breach или CVE. Риски: шумный git status приучает игнорировать изменения; скрытые правила ignore могут убрать полезный контекст из редактора; debug-скрипты и JSON dumps рядом с production-кодом снижают качество review и доверие к AI-workflow.

Review gates — не один pre-commit hook, а набор практик. Перед промоушеном файла из temp/ — четыре вопроса:

  1. Есть ли долгосрочная ценность для продукта, тестов, docs или ops?
  2. Нет ли секретов и приватных данных?
  3. Понятно ли имя файла?
  4. Убраны ли «одноразовые» допущения эксперимента?

Промоушен — как code review, не слепой mv. Пример из материала: перенос отладочного скрипта в регрессионный тест с доработкой:

mv temp/scripts/repro-billing-sync.ts tests/regression/billing-sync-retry.test.ts
# доработать в настоящий тест, затем git add

Секреты: не класть .env и дампы с реальными customer records; маскировать токены в API-ответах; локально проверять rg -n "(api_key|secret|token|password|BEGIN PRIVATE KEY)" temp/; для усиления — secret scanner в pre-commit и CI (промотированные файлы проходят обычные проверки).

Cleanup: скрипт scripts/clean-scratchpad.sh удаляет содержимое temp/ с сохранением только README.md, затем пересоздаёт подпапки; альтернатива — trash вместо rm -rf. Правило: review перед delete — в scratchpad может остаться полезное evidence после сложной отладки или eval.

Solo, команда и eval-артефакты агента

Solo-workflow: (1) в начале задачи указать агенту temp/; (2) держать production-изменения вне temp/ минимальными; (3) summary в temp/review-notes/; (4) тесты и git diff; (5) промоушен только полезного; (6) cleanup после merge.

Team-workflow: те же границы плюс документированный путь scratchpad, обязательный review перед промоушеном, сканирование промотированных артефактов, очистка task-папок перед merge длинных веток.

Для eval и agent harnesses scratchpad служит временным хранилищем в temp/traces/ — например, temp/traces/rag-answer-regression-raw.json с последующим решением, что войдёт в evals/fixtures/ или evals/rubrics/. Паттерн не заменяет observability и eval tooling в production; это локальный workflow на этапе разработки.

Чеклист внедрения из материала — восемь пунктов: создать temp/ с подпапками; добавить в .git/info/exclude; написать temp/README.md; обновить agent instructions; подготовить cleanup-скрипт; напоминания secret-scan перед промоушеном; review notes для сложных задач; промоушен только стабильных тестов, docs, fixtures и scripts.

Источники