El día 1 de construir algo con IA se siente increíble: pides una idea, en minutos tienes una página funcionando, la subes y ya está en internet. El problema no es el día 1. Es el día 30, cuando ese mismo proyecto tiene bugs que nadie explica, una llave de API expuesta en el código, cero autenticación en donde debería haberla, y nadie (ni tú, ni la IA) recuerda bien cómo se armó todo.
Nada de esto pasa por usar IA para construir. Pasa por no tener una forma ordenada de publicar y proteger lo que construyes. Esa parte no depende de saber programar. Depende de seguir un proceso. Esta guía es ese proceso, en lenguaje simple.
1
Deja de subir archivos a mano
Si cada vez que cambias algo tienes que arrastrar una carpeta a tu proveedor de hosting (Netlify, Vercel, etc.), estás construyendo sobre una base frágil: no hay historial de qué cambió, no hay forma fácil de deshacer un error, y es cuestión de tiempo antes de que subas la carpeta equivocada o pises un cambio de otra persona.
La alternativa: conecta tu proyecto a un repositorio de código (GitHub es el más común) y configura tu hosting para que publique automáticamente cada vez que subes un cambio. Esto se llama despliegue continuo. Tú solo trabajas en tus archivos y avisas "esto ya está listo": el resto pasa solo.
2
Tu repositorio es privado, siempre
Un repositorio público significa que cualquier persona en internet puede ver tu código, tus notas, tus prompts internos y cualquier dato que hayas dejado ahí sin darte cuenta. Márcalo como privado desde que lo creas. Si ya existe uno público con contenido sensible, cámbialo a privado ahora mismo: no puede esperar al final de la lista.
3
Protege la cuenta que controla todo
Tu cuenta de GitHub (o el proveedor que uses) es la llave maestra de todos tus proyectos. Si alguien entra a esa cuenta, entra a todo. Tres cosas no negociables:
- Verificación en dos pasos (2FA) activada.
- Códigos de recuperación guardados en un lugar seguro (no en el mismo dispositivo que usas todos los días).
- Passkey configurada si la plataforma lo permite, es más resistente a phishing que una contraseña.
4
Acceso limitado a las integraciones, nunca acceso total
Cuando conectas tu hosting a GitHub (o cualquier otra app a tu cuenta), casi siempre te va a preguntar: ¿acceso a todos los repositorios o solo a algunos seleccionados? Elige siempre la segunda opción y marca únicamente los repositorios que esa integración necesita.
Esto importa porque si esa integración es comprometida algún día (le pasa a las plataformas más grandes también), el daño queda contenido a los proyectos que le diste, no a todo lo que has construido en tu vida.
5
Un proyecto, un repositorio
Es tentador tener una sola carpeta gigante en tu computadora con "todo" adentro: proyectos activos, ideas viejas, borradores, de todo. El problema aparece cuando esa carpeta gigante también es un repositorio de git y adentro metes OTRO proyecto que también tiene su propio repositorio. Git no sabe qué hacer con eso: a veces lo registra como una referencia rota que después hace fallar tu publicación sin ninguna explicación clara del porqué.
La regla simple: cada proyecto que se publica por separado vive en su propio repositorio, independiente. Tu carpeta de trabajo personal puede seguir teniendo de todo, pero lo que se conecta a un hosting en producción, aislado.
6
Ten un archivo que le diga a git qué ignorar
Todo repositorio necesita un archivo .gitignore desde el primer día. Sin él, terminas subiendo archivos que no deberían estar ahí: configuraciones locales, archivos temporales del sistema operativo, carpetas de dependencias pesadas, y en el peor caso, archivos con contraseñas o llaves.
Si no sabes qué poner, pide plantillas estándar según el tipo de proyecto (la mayoría de las herramientas de IA para programar las conocen de memoria).
7
Las llaves y contraseñas nunca van dentro del código
Si tu proyecto usa una llave de API (para IA, para pagos, para lo que sea), esa llave no va escrita directamente en tus archivos. Va en variables de entorno, un lugar separado que tu hosting mantiene en secreto y que nunca queda expuesto públicamente ni sube a tu repositorio.
Una llave expuesta en un repositorio público es de las formas más comunes en que a la gente le vacían cuentas de servicios de pago por uso.
8
Deja un mapa de cómo funciona todo
El día que necesites resolver algo sin ayuda de una IA (porque falló, porque cambiaste de herramienta, porque simplemente quieres entender) vas a necesitar un mapa. Ese mapa es un archivo README dentro de cada proyecto que explique, en tu propio idioma:
- Qué hace este proyecto y dónde vive publicado.
- Cómo se sube un cambio (los comandos exactos, paso a paso).
- Qué NO se debe tocar sin pensar dos veces.
- Qué hacer si algo se rompe.
Esto no es un lujo de equipos grandes. Es lo que te permite seguir adelante el día que la IA que te ayudó a construirlo no está disponible.
Si nunca le dices a git quién eres, cada commit queda firmado con un correo que tu computadora inventa sola (algo como tuusuario@Nombre-De-Tu-Mac.local). Ese correo queda en el historial para siempre y no identifica a nadie real.
Antes de tu primer commit en cualquier proyecto, ejecuta una sola vez:
git config --global user.name "Tu Nombre o el de tu Empresa"
git config --global user.email "tu@correo-real.com"
Si trabajas con un correo de servicio (uno genérico de tu empresa en vez de tu correo personal), úsalo aquí. Es una línea de identidad que aparece en cada cambio que hagas, mejor que sea la correcta desde el principio.
Repositorio (repo): la carpeta de tu proyecto, pero con historial de cada cambio guardado.
Commit: una "foto" de tus archivos en un momento dado, con un mensaje explicando qué cambiaste.
Push: subir tus cambios guardados (commits) al repositorio en línea.
Deploy / despliegue: el proceso de publicar tu proyecto para que sea visible en internet.
Despliegue continuo: cuando publicar pasa automáticamente cada vez que subes un cambio.
2FA: un segundo paso de seguridad al iniciar sesión, además de tu contraseña.
Variables de entorno: un lugar separado y protegido donde guardas datos sensibles como llaves de API.
.gitignore: una lista de archivos que le dices a git que nunca suba al repositorio.
Esta guía nace de resolver, en la práctica, los mismos errores que describe: un repositorio mezclado, referencias rotas y despliegues manuales que fallaban sin explicación. Documentarlo fue lo que permitió corregirlo, y esa es exactamente la idea que queremos compartir.