Vibe coding sin Git es manejar sin frenos: qué es un control de versiones y por qué lo necesitas

Vibe coding sin Git es manejar sin frenos: qué es un control de versiones y por qué lo necesitas

Le pides a la IA que agregue un botón de login. Funciona. Le pides que cambie el color del menú. Funciona. Le pides que “optimice un poquito el código”… y de repente nada funciona. El login se rompió, el menú desapareció y el agente, muy amable, te dice «¡Listo! He mejorado la estructura del proyecto».

Intentas pedirle que lo deje como estaba hace veinte minutos. Pero ya no se acuerda bien de cómo estaba. Tú tampoco.

Bienvenido al lado oscuro del vibe coding, el término que popularizó Andrej Karpathy a principios de 2025 para describir la forma de programar en la que le dices a la IA lo que quieres, aceptas lo que sale y sigues adelante sin mirar mucho el código. Es divertido, es rápido y está bien para prototipos. Pero tiene un problema: mucha gente llegó a programar por ahí sin conocer la herramienta más básica del oficio: un sistema de control de versiones.

Hace un tiempo escribí una serie de artículos sobre Git en mi blog anterior. Esta es la versión actualizada, pensada para quien construye con IA y nunca ha escrito un git commit.


¿Qué es un sistema de control de versiones?

Piensa en un videojuego. Antes de enfrentarte al jefe final, guardas la partida. Si pierdes, cargas el punto de guardado y vuelves a intentarlo, sin repetir todo el juego desde el principio.

Un sistema de control de versiones hace exactamente eso con tu proyecto. Cada vez que quieres, tomas una foto completa del estado de tus archivos y le pones un nombre. A esa foto se le llama commit. Después puedes:

  • Ver la historia completa: qué cambió, cuándo y por qué.
  • Comparar cómo estaba un archivo ayer con cómo está hoy.
  • Volver a cualquier punto anterior si algo se rompe.
  • Trabajar en paralelo con otras personas (o con varios agentes de IA) sin pisarse.

Git es el sistema de control de versiones más usado del mundo: en la encuesta de Stack Overflow de 2022, más del 93% de los desarrolladores dijo usarlo. Lo creó Linus Torvalds en 2005 (sí, el mismo de Linux) porque necesitaba manejar el código del kernel, y hoy es open source y el estándar de la industria.

Un detalle técnico que mucha gente explica al revés: Git no guarda “solo las diferencias” entre versiones. Conceptualmente guarda instantáneas (snapshots) completas del proyecto en cada commit; si un archivo no cambió, simplemente apunta a la versión que ya tenía guardada. Por eso viajar en el tiempo es tan rápido.

¿Y sin Git cómo se vive?

Así:

proyecto_final.zip
proyecto_final_v2.zip
proyecto_final_v2_ahora_si.zip
proyecto_final_v2_ahora_si_FINAL.zip
proyecto_final_v2_ahora_si_FINAL_no_tocar.zip

Ahora multiplica eso por cinco personas trabajando al mismo tiempo. Caos total.


Git no es GitHub (la confusión número uno)

GitGitHub (o GitLab, Bitbucket)
Qué esUn programa que instalas en tu computadorUn servicio web que guarda copias de tus repositorios en la nube
Dónde viveEn tu máquina, funciona sin internetEn internet
Para qué sirveLlevar el historial de tu proyectoCompartir, colaborar, hacer respaldo y desplegar (Vercel, Netlify y similares se conectan a tu repositorio)

Git es el motor; GitHub es el parqueadero donde guardas el carro y se lo prestas a otros. Puedes usar Git toda la vida sin GitHub, pero no al revés.


Por qué Git importa todavía más si programas con IA

Un agente de IA puede modificar diez archivos en cinco segundos. Eso es una maravilla… y un peligro. Sin control de versiones, no tienes forma de saber qué tocó ni de deshacerlo.

Situación típica con IASin GitCon Git
El agente “mejoró” el código y rompió todoRezar y pedirle que lo arregle (a veces empeora)Vuelves al último commit en un comando
Quieres saber qué cambió la IARevisar archivo por archivo a ojogit diff te muestra cada línea agregada y eliminada
Quieres probar dos enfoques distintosDuplicar la carpeta del proyectoUna rama por experimento
Funcionaba ayer y hoy noNo sabes qué cambió entre ayer y hoygit log y comparas versiones
Publicar tu proyectoSubir archivos a mano por FTPHaces push y la plataforma despliega sola

Y hay algo más profundo. Cuando aceptas código que no entiendes, vas acumulando lo que en La IA abarató el conocimiento, no el criterio llamamos deuda cognitiva: sistemas que funcionan, pero que nadie sabe por qué. Un historial de commits con buenos mensajes es la forma más barata de dejar escrito qué se hizo y por qué.


Primeros pasos: instalar y configurar Git

Verifica si ya lo tienes instalado:

git --version

Si te responde algo como git version 2.x, estás listo. Si no, descárgalo desde git-scm.com.

Ahora dile a Git quién eres. Esto se hace una sola vez por computador y queda grabado en cada commit:

git config --global user.name "Tu Nombre"
git config --global user.email "tu-correo@ejemplo.com"
git config --global init.defaultBranch main

La última línea hace que tus proyectos nuevos usen main como rama principal, que es la convención actual (antes se llamaba master). Puedes revisar tu configuración con git config --list.


Las tres áreas de Git: el concepto que lo explica todo

Aquí es donde la mayoría se confunde, así que vamos despacio. En Git, tus cambios pasan por tres lugares:

flowchart LR
    WD["<strong>1. Directorio de trabajo</strong><br/>Tus archivos tal como los ves<br/>(lo que edita la IA)"]
    ST["<strong>2. Staging</strong><br/>La caja donde preparas<br/>lo que vas a guardar"]
    REPO["<strong>3. Repositorio</strong><br/>El historial de commits<br/>(las fotos guardadas)"]
    WD -- "git add" --> ST
    ST -- "git commit" --> REPO
    REPO -- "git restore / git switch" --> WD
ÁreaQué esAnalogía
Directorio de trabajoLos archivos de tu carpeta, como están ahora mismoTu escritorio, con todo regado
StagingLos cambios que elegiste para el próximo commitLa caja donde metes lo que vas a enviar
RepositorioEl historial de todos los commitsEl archivo histórico, sellado con fecha

¿Para qué existe el staging? Para que tú decidas qué entra en cada foto. Si la IA modificó cinco archivos, pero solo tres tienen que ver con el login, puedes guardar esos tres en un commit y los otros dos en otro. Así cada commit cuenta una sola historia.


El flujo básico (el que vas a repetir mil veces)

1. Crear el repositorio

Dentro de la carpeta de tu proyecto:

git init

Esto crea una carpeta oculta llamada .git. Ahí vive toda la historia de tu proyecto. No la borres ni la edites a mano. Si la borras, pierdes todo el historial.

2. Ver qué está pasando

git status

Es el comando que más vas a usar. Te dice qué archivos son nuevos (untracked), cuáles cambiaron (modified) y cuáles están listos para el commit (staged). Ante la duda, git status.

3. Ver exactamente qué cambió

git diff

Te muestra línea por línea lo que se agregó (en verde) y lo que se eliminó (en rojo). Este es el comando que todo vibe coder debería ejecutar después de cada respuesta del agente. Es la diferencia entre aceptar cambios a ciegas y saber qué estás aceptando.

4. Preparar los cambios

git add login.js        # un archivo específico
git add .               # todos los cambios de la carpeta actual

5. Guardar la foto

git commit -m "feat: agregar formulario de login"

El -m significa message. Y aquí hay una regla de oro: escribe mensajes que tu yo del futuro entienda.

❌ Mensaje inútil✅ Mensaje útil
updatefix: corregir validación del correo en el registro
cambiosfeat: agregar botón de cerrar sesión en el menú
ahora sírefactor: separar la lógica de pagos en su propio módulo

El formato con prefijo (feat:, fix:, refactor:) se llama Conventional Commits y es una convención muy usada. No es obligatoria, pero ayuda mucho a leer el historial.

6. Ver la historia

git log --oneline
a3f9c21 feat: agregar botón de cerrar sesión en el menú
7be0d14 fix: corregir validación del correo en el registro
1c2e8f0 feat: agregar formulario de login

Ese código raro del inicio (a3f9c21) es el hash: el identificador único de cada commit. Con él puedes volver a ese punto exacto.

El ciclo completo

flowchart LR
    A["Editas o la IA<br/>edita archivos"] --> B["git status<br/>git diff"]
    B --> C["git add"]
    C --> D["git commit -m"]
    D --> A

¿Agregaste algo por error? Así se deshace

Si hiciste git add de un archivo que no querías incluir, sácalo del staging sin perder tus cambios:

git restore --staged archivo.js

Y si quieres descartar los cambios de un archivo y dejarlo como estaba en el último commit:

git restore archivo.js

⚠️ Este segundo comando borra tus cambios sin vuelta atrás, porque nunca fueron guardados en un commit. Úsalo con cuidado.

Para deshacer commits ya hechos, trabajar con ramas y entender la diferencia entre reset y revert, te armé la segunda parte: Ramas, reset y revert: cómo experimentar con IA sin miedo.


El archivo que te puede salvar de un desastre: .gitignore

Este punto es crítico para quien programa con IA. Muchos proyectos tienen un archivo .env con tus claves de API (OpenAI, Stripe, la base de datos…). Si haces git add . y lo subes a un repositorio público de GitHub, hay bots que escanean GitHub buscando claves expuestas. Te pueden vaciar la tarjeta en horas.

La solución es un archivo llamado .gitignore en la raíz del proyecto, que le dice a Git qué nunca debe guardar:

# Secretos
.env
.env.local

# Dependencias (se reinstalan con npm install)
node_modules/

# Archivos generados
dist/
.DS_Store

GitHub mantiene plantillas de .gitignore para casi cualquier lenguaje. Y si ya subiste una clave por error, cámbiala de inmediato: borrarla del repositorio no basta, porque sigue en el historial. GitHub tiene una guía para eliminar datos sensibles.


Una rutina sencilla para hacer vibe coding sin miedo

  1. Antes de pedirle algo grande a la IA, haz commit. Ese es tu punto de guardado.
  2. Pide un cambio a la vez. “Agrega el login” es mejor que “agrega login, pagos y rediseña el menú”.
  3. Revisa con git diff qué modificó el agente. Si tocó archivos que no tenían nada que ver, pregúntale por qué.
  4. Prueba que funcione. Si funciona, git add y git commit con un mensaje claro.
  5. Si no funciona y el agente no lo arregla en uno o dos intentos, vuelve al último commit en lugar de seguir pidiéndole parches sobre parches.

Es el mismo principio que te propuse en desarrollo modular con IA: trabajar en unidades pequeñas y verificables, y guardar cada una con su descripción. Git es la herramienta que hace posible esa disciplina.


En resumen

  • Git guarda fotos (commits) de tu proyecto para que puedas ver la historia y volver atrás.
  • GitHub es donde guardas y compartes esos repositorios en la nube.
  • Tus cambios pasan por tres áreas: directorio de trabajo → staging → repositorio.
  • El flujo diario es git status → git diff → git add → git commit.
  • Nunca subas tu .env: usa .gitignore.

La IA te hace ir rápido. Git hace que ir rápido no sea peligroso. Aprender Git no es opcional, es tu seguro de vida como desarrollador, y con la IA escribiendo código a mil por hora, más que nunca.


Fuentes y lecturas recomendadas

Ideas, sistemas y lecturas de diseño web que merecen ser probadas

EXPLORAR SILO COMPLETO→