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)
| Git | GitHub (o GitLab, Bitbucket) | |
|---|---|---|
| Qué es | Un programa que instalas en tu computador | Un servicio web que guarda copias de tus repositorios en la nube |
| Dónde vive | En tu máquina, funciona sin internet | En internet |
| Para qué sirve | Llevar el historial de tu proyecto | Compartir, 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 IA | Sin Git | Con Git |
|---|---|---|
| El agente “mejoró” el código y rompió todo | Rezar y pedirle que lo arregle (a veces empeora) | Vuelves al último commit en un comando |
| Quieres saber qué cambió la IA | Revisar archivo por archivo a ojo | git diff te muestra cada línea agregada y eliminada |
| Quieres probar dos enfoques distintos | Duplicar la carpeta del proyecto | Una rama por experimento |
| Funcionaba ayer y hoy no | No sabes qué cambió entre ayer y hoy | git log y comparas versiones |
| Publicar tu proyecto | Subir archivos a mano por FTP | Haces 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
| Área | Qué es | Analogía |
|---|---|---|
| Directorio de trabajo | Los archivos de tu carpeta, como están ahora mismo | Tu escritorio, con todo regado |
| Staging | Los cambios que elegiste para el próximo commit | La caja donde metes lo que vas a enviar |
| Repositorio | El historial de todos los commits | El 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 |
|---|---|
update | fix: corregir validación del correo en el registro |
cambios | feat: 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
- Antes de pedirle algo grande a la IA, haz commit. Ese es tu punto de guardado.
- Pide un cambio a la vez. “Agrega el login” es mejor que “agrega login, pagos y rediseña el menú”.
- Revisa con
git diffqué modificó el agente. Si tocó archivos que no tenían nada que ver, pregúntale por qué. - Prueba que funcione. Si funciona,
git addygit commitcon un mensaje claro. - 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
- Pro Git (libro oficial, gratuito y en español): git-scm.com/book/es/v2.
- Documentación oficial de Git: git status, git add, git commit, git diff, git restore y gitignore.
- GitHub Docs: Eliminar datos sensibles de un repositorio.
- GitHub: Colección de plantillas .gitignore.
- Conventional Commits: Especificación 1.0.0 en español.
- Stack Overflow Developer Survey 2022: resultados de sistemas de control de versiones.
- Artículos relacionados en este blog:
Ideas, sistemas y lecturas de diseño web que merecen ser probadas
Segunda parte de la guía de Git para vibe coders: qué son las ramas y cómo usarlas para cada experimento con IA, cómo resolver un conflicto de merge y cuándo usar git restore, reset, revert o reflog para deshacer errores sin perder trabajo.
Aprende a diseñar la arquitectura de tu sitio web: silos temáticos, profundidad de clics vs URLs, navegación facetada sin problemas de indexación y migas de pan con Schema.
Análisis sencillo del paper Transformer de 2017: qué problema resolvió, cómo funciona la atención (Query, Key, Value), por qué cambió la IA y cinco formas prácticas de aprovechar ese conocimiento para escribir mejores prompts.
