Nunca dejes que la IA haga push a GitHub (por las malas)

Nunca dejes que la IA haga push a GitHub sin tu revisión. Deja que revise tus cambios, escriba tus mensajes de commit y prepare tus pull requests, pero el push sigue siendo humano. Aprendí esta regla por las malas: un push sin revisar publicó la clave maestra de mi base de datos en internet, y la limpieza se llevó cuatro horas que no recuperaré jamás.

Aquí tienes exactamente qué pasó, qué debería y qué no debería poder hacer la IA con el historial de tu código, y el flujo de trabajo que te mantiene rápido sin el pánico de seguridad.

El día que la IA subió mi clave secreta a GitHub

Estaba construyendo FIKR Space, mi plataforma SaaS. Avanzando rápido. La IA me ayudaba con todo.

Un día le dije: "Haz commit de estos cambios y push a main".

Lo hizo. Sin preguntar. Sin enseñarme qué estaba incluyendo en el commit.

Resulta que yo había incluido sin querer mi clave de servicio de Supabase, la clave maestra que abre toda mi base de datos, en un archivo de configuración. Ahora estaba en el historial de git. En GitHub. Pública.

Tuve que rotar de inmediato todas las claves, hacer un force-push para borrar el commit del historial, revisar todos los servicios conectados en busca de brechas de seguridad y dedicar cuatro horas a arreglar lo que una revisión de treinta segundos habría evitado.

La lección: nunca confíes ciegamente en la IA con git. Pero la historia tiene una segunda mitad que importa igual: la IA es increíble con git cuando la usas bien. Si git sigue siendo un concepto difuso para ti, empieza por git explicado para fundadores no técnicos y vuelve; este artículo trata de dónde encaja la IA en todo esto.

Nunca dejes que la IA haga push a GitHub: qué debe hacer en su lugar

Revisa cada cambio antes de hacer commit. Antes de cada commit ejecuto un comando de revisión guardado. La IA lee exactamente qué cambió, comprueba en cada archivo modificado si hay errores, salidas de depuración olvidadas y problemas de seguridad (secretos escritos en el código, claves expuestas) y sugiere mejoras. Un ejemplo real: estaba a punto de hacer commit de cambios en mi código de procesamiento de pagos. La revisión detectó una clave de API de prueba que había dejado escrita en el código, falta de gestión de errores en los pagos fallidos, atajos descuidados con los tipos y un archivo de pruebas que había olvidado actualizar. Todo detectado antes del commit.

Escribe tus mensajes de commit. Los buenos mensajes de commit son difíciles, y la IA los vuelve fáciles. Tras revisar los cambios, redacta un mensaje claro y descriptivo que enumera qué se añadió y por qué. Puedo editarlo si hace falta, pero casi siempre acierta a la primera.

Prepara tus pull requests. Cuando una rama de funcionalidad está lista, la IA revisa cada commit que contiene, escribe el título y la descripción, arma una lista de comprobación de lo que cambió y añade notas de pruebas. Profesional, completo, y me ahorra treinta minutos de escritura por funcionalidad.

Desenreda conflictos de merge. Cuando chocan dos versiones de un archivo, la IA lee ambas, entiende la intención de cada cambio, propone una resolución que conserva las dos mejoras y explica por qué la eligió. Mucho más rápido que comparar versiones a mano.

Las seis cosas que la IA nunca debe hacer

1. Hacer push a tu rama main sin confirmación. Main es lo que ven tus usuarios. Confirma siempre. Siempre.
2. Hacer force-push sin permiso explícito. Un force-push reescribe el historial y puede destruirlo. Solo cuando sepas exactamente por qué.
3. Borrar ramas sin preguntar. Las ramas son baratas. No dejes que la IA las limpie automáticamente.
4. Hacer commit sin revisión. Esta es la regla que habría salvado mi clave. Revisa los cambios antes de cada commit.
5. Saltarse tus controles de seguridad. Las comprobaciones automáticas previas al commit existen por algo. No dejes que la IA las esquive nunca.
6. Reescribir commits que no creó ella. Modificar commits ajenos reescribe el historial compartido, algo peligroso en cuanto alguien más toca el proyecto.

Fíjate en el patrón: todo lo de esta lista es irreversible o público. La IA puede redactar cualquier cosa; no confirma nada.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

La recompensa: de 30 minutos por funcionalidad a 4

El motivo para montar esto bien no es solo la seguridad, sino la velocidad. Esto es lo que me costaban las tareas de git de una sola funcionalidad, antes y después:

Hago commit de cinco a diez veces al día. Eso son entre 130 y 260 minutos ahorrados cada día. En los once meses que dediqué a construir FIKR Space, son cientos de horas, recuperadas gracias a un asistente que además detecta errores que yo habría publicado.

El flujo de trabajo seguro, paso a paso

1. Haz tus cambios.
2. Ejecuta tu comando de revisión con IA sobre todo lo que cambió.
3. Arregla lo que marque.
4. Deja que la IA redacte el mensaje de commit; apruébalo o edítalo.
5. La IA crea el commit.
6. Tú haces el push, o confirmas de forma explícita antes de que lo haga la IA.

Y las reglas que lo sostienen: revisa siempre las diferencias antes de hacer commit, no pongas nunca secretos en el código (su lugar son las variables de entorno), confirma siempre los push a main, deja que la IA redacte mientras tú apruebas y, ante la duda, hazlo manualmente.

Un push sin revisar es la forma más ruidosa en que la IA te perjudica, pero es el mismo modo de fallo que el silencioso: aceptar una salida que nunca inspeccionaste hasta que el daño se acumula. La versión más lenta de esta historia es cómo la IA sabotea tu código.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Por qué es más arriesgado hacer push que hacer commit?

Un commit es una instantánea local en tu máquina: un error ahí es privado y fácil de deshacer. Un push publica esas instantáneas en GitHub, donde se pueden ver, clonar y rastrear. Mi clave filtrada solo se convirtió en una emergencia de cuatro horas en el momento de hacer push. Por eso el push es el paso que siempre necesita a un humano.

¿Qué hago si un secreto llega a GitHub?

Trátalo como comprometido en el instante en que llega, aunque lo borres segundos después: hay rastreadores automáticos vigilando los repositorios públicos. Rota la clave de inmediato, borra el commit del historial y revisa si hay actividad sospechosa en todos los servicios a los que esa clave daba acceso. Después arregla el origen: los secretos viven en variables de entorno, nunca en archivos que git rastrea.

¿Puedo dejar alguna vez que la IA haga push?

Sí, después de que te muestre exactamente lo que está a punto de subir y tú lo confirmes de forma explícita. La regla no es "la IA nunca toca git"; la IA lleva la mayor parte de mi flujo de trabajo con git. La regla es que nada irreversible o público ocurre sin que tus ojos lo hayan visto antes.

¿Revisar cada cambio no es lento?

Es lo contrario, porque la IA hace el trabajo pesado de la propia revisión. Mi flujo revisado lleva 4 minutos por funcionalidad frente a 30 a mano, y detecta claves escritas en el código, falta de gestión de errores y pruebas olvidadas antes de que salgan a producción. Las cuatro horas que dediqué a limpiar la clave filtrada fueron el precio de saltarme una vez una revisión de dos minutos.