commit-rewriter 0.1: la herramienta para limpiar commits de IA

Por qué Simon Willison creó commit-rewriter 0.1

Simon Willison, autor de Datasette y referente en herramientas para desarrolladores, publicó el 14 de septiembre la versión 0.1 de commit-rewriter, una pequeña aplicación web en Python pensada para reescribir los mensajes de commit de un repositorio Git sin tener que pelearse con la línea de comandos. Según explica en su blog, la construyó para preparar los commits de los parches de seguridad de Datasette de septiembre, cuyos mensajes originales estaban llenos de «restos» dejados por agentes de programación y referencias a IDs de issues del repositorio privado, lo que los hacía imposibles de publicar tal cual.

La motivación es exactamente el problema que sufren cada vez más equipos en 2026: los coding agents (Claude Code, Codex, Cursor, etc.) generan commits a gran velocidad, pero sus mensajes suelen incluir huellas de la sesión — referencias a issues internos, comandos del agente, mensajes truncados del propio modelo — que no deberían quedar en un historial público. Reescribirlos a mano, commit por commit, suele ser inviable.

Qué hace la herramienta y cómo se usa

El uso es deliberadamente simple. Desde una terminal:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

uvx commit-rewriter path/to/repo

Si se omite la ruta, la herramienta asume que estás dentro del directorio del repositorio. Al ejecutarse levanta una interfaz web local que muestra cada commit con su hash corto, autor, fecha y un área editable con el mensaje. Incluye:

Un panel lateral de navegación con los commits recientes.
Buscador por mensaje, autor o hash.
Un checkbox «Edited only» para filtrar los ya modificados.
Un botón «View full formatted diff» para revisar los cambios antes de confirmar.
Botones «Discard drafts» y «Rewrite commit messages» con contador de edits pendientes.

Antes de aplicar nada, la herramienta crea una rama con timestamp del estado actual del repositorio, de modo que si algo sale mal se puede volver atrás sin perder el trabajo. Después, reescribe todos los commits desde el primero que editaste hasta el más reciente, lo que la hace útil sobre todo cuando los mensajes problemáticos están al principio de la rama.

«When you submit your edits the tool creates a timestamped branch of your current repo state — to allow you to revert if you need to — and then rewrites every commit from the first one you edited to the most recent.» — Simon Willison

Por qué importa para developers y founders técnicos

La categoría de AI-assisted programming es, según las etiquetas del propio blog de Willison, la cuarta más usada de su sitio (407 entradas), solo por detrás de git (55), projects (553) y python (1.283). Eso refleja una tendencia de fondo: a medida que los coding agents se vuelven parte del flujo diario, los repositorios acumulan ruido generado por máquina — mensajes vagos, referencias internas, comentarios que eran instrucciones para el modelo — que después hay que limpiar.

Hasta ahora las opciones eran:

git rebase -i con reword, que funciona pero requiere editar cada commit uno a uno, en orden inverso, desde la terminal.
Reescribir todo a mano con git filter-branch o herramientas similares, frágil y propenso a errores.
Aceptar los mensajes malos y empujarlos igual, perdiendo trazabilidad y profesionalismo en el repo público.

commit-rewriter automatiza el paso más tedioso: presenta los commits en una UI visual, permite editar solo los que importan y deja un backup automático. Para un founder técnico que mantiene un repositorio open source como parte de su producto (SDK, librería, herramientas internas publicadas), esa diferencia entre un historial legible y uno lleno de ruido de agente es parte de la imagen profesional.

Además, el proyecto aprovecha el auge de uvx para distribuirse sin instalación tradicional: se ejecuta directamente con un solo comando, igual que ya ocurre con muchas herramientas modernas del ecosistema Python.

Cómo encaja en el stack de herramientas Git en 2026

La herramienta llega en un momento simbólico. La Wikipedia sobre Git recuerda que Git, creado por Linus Torvalds en abril de 2005 tras la caída de BitKeeper, sigue siendo el sistema de control de versiones dominante: según la Stack Overflow Developer Survey 2022, el 93,9% de los desarrolladores lo usan como su VCS principal. Eso significa que cualquier fricción en el flujo de commits — sobre todo la generada por agentes — afecta a una base instalada enorme.

El propio Git 2.55.0, anunciado por Junio Hamano el 29 de junio de 2026, y la preparación para Git 3.0 con el cambio de master a main como rama por defecto, son señales de que la capa base sigue evolucionando. commit-rewriter opera un nivel por encima: no toca el motor de Git, sino el flujo de trabajo alrededor de los mensajes.

Qué significa esto para tu startup

Si en tu equipo usáis coding agents a diario (Claude Code, Codex, Cursor, Copilot, Devin, etc.) y tenéis un repositorio público — SDK, open core, side project que queréis enseñar a inversores o candidatos — los mensajes de commit son parte de la primera impresión. Historias tipo «prompt: refactor utils» o «as requested by user» gritan «generado por IA» y bajan la percepción de calidad del proyecto.

Acciones concretas que puedes aplicar esta semana:

Audita los últimos 30 commits de tu repo público. Identifica los que tienen mensajes vagos, referencias a IDs internos o trazas del agente. Esos son los candidatos a reescribir.
Incorpora un hook de pre-push o un script de revisión que detecte patrones típicos de agentes (palabras como prompt, as requested, TODO from agent) y pida confirmación antes de subir al remoto público.
Separa la rama de trabajo de la rama publicable. Trabaja en una rama interna con commits crudos de agente y, antes de merge a main o de abrir PR, pasa por una limpieza tipo commit-rewriter para dejar un historial presentable.

Limitaciones y advertencias

Al ser una versión 0.1, conviene tener presente:

Reescribir historial en Git cambia los hashes de los commits afectados. Si la rama ya se ha compartido con colaboradores, hará falta un git push --force y coordinación con el equipo.
La herramienta no está pensada para repos compartidos con muchos colaboradores activos sin coordinación previa.
Requiere ejecutar con uvx (parte del ecosistema Astral/uv), por lo que el equipo necesita esa herramienta instalada.

Aún así, para el caso de uso que describe Willison — limpiar commits de un repositorio antes de hacerlos públicos — resuelve un dolor real que cada vez más developers hispanohablantes van a sentir en 2026.