Contexto técnico
No confiaría en un solo prompt de sistema cuando se trata de Git. Cuando integro inteligencia artificial en el proceso de desarrollo, mi primera regla es aburrida pero salva los nervios: cualquier acción que no sea de solo lectura está prohibida hasta que la solicite explícitamente.
La razón es simple. Tanto Claude como Codex en sesiones paralelas pueden sobrescribir diligentemente los cambios en curso porque ven el directorio de trabajo local solo como una instantánea más del proyecto. Lo he visto más de una vez, y ahí es donde termina un prompt bonito y empieza la disciplina de ingeniería.
Normalmente codifico algunas reglas directamente en las instrucciones del agente: no hacer commit, push, rebase, eliminar ramas ni checkout con efectos secundarios sin confirmación; antes de cualquier cambio, mostrar qué se verá afectado; después de generar código, ejecutar primero las pruebas o la compilación. Si el proyecto es pesado, además prohíbo los commits sin aprobación, porque suele ser más rápido lidiar con el código de IA cuando los cambios permanecen sin commit.
De la práctica del equipo, también me gustan cosas más sencillas: un formato unificado de rama de funcionalidad con un ID de tarea, un enlace al PR en el tracker, una breve descripción del PR en lenguaje humano y un aviso en Slack o Telegram para la revisión de código. Esto no es burocracia, sino evitar que la IA convierta el historial de Git en un basurero sin contexto.
Y sí, si se necesita un control real, no me limitaría a los prompts. Las capas de seguridad externas para la CLI que requieren confirmación o bloquean comandos Git peligrosos son más fiables que cualquier "nunca hagas eso" en un prompt del sistema.
Lo que esto cambia para los negocios y la automatización
Aquí ganan los equipos donde varias personas y varias sesiones de IA tocan el mismo repositorio. Pierden aquellos que persiguen la velocidad y permiten que el agente haga commits de todo: al principio parece rápido, pero luego se pasa medio día averiguando quién rompió la rama y por qué desaparecieron fragmentos de código.
Para la implementación de IA, veo exactamente tres consecuencias. Primera: un ciclo un poco más lento, pero menos sobrescrituras accidentales. Segunda: revisiones más limpias y responsabilidad más clara en los PR. Tercera: es más fácil escalar la automatización con IA entre equipos porque las reglas se leen igual para humanos y agentes.
En Nahornyi AI Lab diseccionamos precisamente estos casos: dónde se le puede dar libertad al agente y dónde necesita una correa corta. Si tu IA ya escribe código pero el proceso empieza a romper ramas, revisiones y plazos, podemos mirar con calma tu flujo de trabajo y diseñar una automatización con IA que acelere el desarrollo en lugar de crear nuevos desastres.