Симон Уиллисон, автор Datasette и один из самых читаемых практиков в пространстве LLM-инструментов, опубликовал commit-rewriter 0.1 — небольшое веб-приложение для редактирования сообщений коммитов в браузере. Исходная проблема: коммиты для релизов безопасности Datasette были написаны coding-агентом и содержали «cruft» — агентский мусор и ссылки на приватные issue ID. Для публичного репо — непригодно.
Контекст
Datasette — популярный open-source инструмент для публикации и исследования данных через SQL, активно используемый в журналистике данных и научных проектах. Уиллисон давно и открыто работает с AI-агентами при разработке и регулярно пишет об этом опыте. Именно поэтому его инструмент симптоматичен: он решает проблему, с которой всё чаще сталкивается любая команда, практически использующая coding agents.
Проблема конкретна. Когда AI-агент пишет код и сам же формирует commit-сообщения, он делает это «с точки зрения процесса» — включает шаги рассуждений, ссылается на внутренний контекст, упоминает номера приватных задач. Для внутренней команды — иногда полезно. Для публичного репозитория — это или шум, или утечка внутренней структуры. Security releases особенно чувствительны: перед публичным disclosure принято давать чистую, понятную историю изменений.
commit-rewriter запускается командой uvx commit-rewriter path/to/repo (или просто uvx commit-rewriter внутри репо). Открывается веб-интерфейс для редактирования. При сохранении инструмент автоматически создаёт timestamped branch с текущим состоянием — страховка для отката. Затем переписывает историю начиная с первого изменённого коммита до самого свежего.
Аналитика
commit-rewriter — маленькая утилита, но за ней стоит нарастающая проблема отрасли. По мере того как Claude Code, Cursor и аналогичные инструменты берут на себя всё больше кода, паттерны git-истории меняются кардинально. Агент не думает о том, кто будет читать git log через полгода или кто будет проверять CHANGELOG при аудите. Он пишет commit-сообщения как след своей работы — verbose, технические, иногда с явными пометками «исправил согласно задаче».
Для публичных open-source проектов это создаёт три класса проблем: читаемость (журнал превращается в дневник агента), раскрытие внутреннего контекста (приватные ID, названия систем, фрагменты промптов), и несоответствие ожиданиям пользователей, которые смотрят changelog чтобы понять «что изменилось» — а не «что сделал агент и почему».
Показательно, что Уиллисон решил проблему инструментом, а не изменением процесса. Это реалистичный подход: требовать от агента идеальных commit-сообщений каждый раз — ненадёжно. Лучше иметь инструмент постобработки. Паттерн «агент работает → человек редактирует результат на финальном этапе» будет воспроизводиться в десятках других контекстов по мере роста agentic workflows.
Кейсы применения в бизнесе
B2B SaaS стартап с публичным API. Если changelog формируется из git-тегов, а разработка идёт через coding agents, история коммитов быстро превращается в агентский поток сознания вперемешку с внутренними ссылками. commit-rewriter позволяет перед каждым релизом привести в порядок сообщения, которые увидят партнёры и интеграторы, читающие GitHub. Особенно критично для версий с security fixes.
Команда с compliance-требованиями. Патчи безопасности и hotfixes часто проходят через AI-assisted code review. Перед публичным CVE-disclosure или передачей репозитория на аудит — массовая чистка истории через браузерный интерфейс быстрее, чем ручная работа с git rebase -i. Timestamped branch снижает риск ошибки до минимума.
SMB и локальный бизнес в КР/СНГ. Небольшие команды, открывающие компоненты в open-source или передающие репо клиенту, часто не думают о том, что git log раскрывает внутреннюю структуру задач и инструментов. commit-rewriter — быстрый способ подготовить репо к публикации без глубоких знаний git internals.
Кейсы в личной жизни
Разработчик, работающий с Claude Code или Cursor. Перед тем как открыть репозиторий для портфолио или отправить его работодателю — запустить commit-rewriter и убрать агентские следы. История коммитов — это тоже часть первого впечатления; «агент зафиксировал изменение согласно шагу 3» читается не так, как хотелось бы.
Фрилансер, сдающий проект клиенту. Клиент получает репо с историей. Если в ней читается внутренняя кухня агентского процесса — это выглядит непрофессионально и может вызвать лишние вопросы. Пять минут с commit-rewriter перед финальной передачей решают проблему.
Студент или независимый разработчик. При публикации учебного или pet-проекта на GitHub история коммитов — часть «подписи» автора. Чистые, понятные сообщения читаются как аккуратность. Агентский verbose-след — наоборот, особенно если видно что автор не отредактировал ни строки.
Как применить сегодня
- Установить uv (если нет) и запустить
uvx commit-rewriter .в корне репозитория — веб-интерфейс откроется автоматически в браузере. - Перед каждым публичным релизом или открытием репо — добавить commit-rewriter в release checklist отдельным шагом.
- Договориться с командой: коммиты от агентов помечать специальным prefix (например
agent:), чтобы сразу видеть что нужно чистить. - Использовать timestamped branch, который создаёт инструмент, как точку отката — удалять только после проверки что история выглядит правильно.
- Для крупных репозиториев начинать не с самого первого коммита, а с диапазона последнего релиза — это и быстрее, и безопаснее.