Introducción al vibecoding · Lección 3 de 5 · 13 min
Lo que conviene saber antes
Contenido de la lección
Para hacer vibecoding no hace falta ser programador. Pero sí conviene saber unas pocas cosas, igual que para conducir no hace falta ser mecánico y sí saber qué significa la luz del aceite.
Con ellas entenderás lo que te dice el asistente, sabrás qué preguntarle y te ahorrarás los disgustos más comunes: perder en un minuto lo que funcionaba, una aplicación que se apaga con tu ordenador o una factura que no esperabas porque alguien encontró tu clave.
Son cuatro: leer código lo justo, guardar versiones, saber dónde se ejecuta lo que haces y tratar con cuidado los datos y las claves. Al final prepararás dónde vas a guardar y probar tu herramienta antes de escribir nada.
Si alguna te suena a chino, no pasa nada: el asistente te la puede explicar las veces que haga falta, y en cada caso verás qué preguntarle.
Leer código lo justo
No tienes que escribir código, pero sí puedes mirarlo. Leer lo justo es saber orientarte:
- Qué archivos hay y para qué es cada uno. Pídeselo al asistente: «Explícame en dos líneas qué hace cada archivo, como si no supiera programar».
- Dónde hay algo que parece una contraseña: una cadena larga de letras y números junto a palabras como key, token o secret.
- Adónde envía datos: direcciones de internet que empiezan por «https://».
- Qué ha cambiado desde la última vez, que muchas herramientas enseñan marcado en colores.
Cuando no entiendas algo, pregunta. Es la forma más barata de aprender y de pillar a tiempo lo que no debería estar ahí.
Guardar versiones
Un control de versiones guarda fotos de tu proyecto en cada paso, con una nota de qué cambió. Si un cambio lo rompe todo, vuelves a la última foto buena. La herramienta más usada se llama Git, y GitHub es uno de los sitios donde se guardan esas copias en internet.
No hace falta dominarlo. Basta con una regla: cada vez que algo funcione, guarda una versión antes de pedir el siguiente cambio. Pídele al asistente que te ayude a prepararlo la primera vez y que te recuerde guardar.
Las plataformas que hacen la aplicación en el navegador suelen tener su propio historial o puntos de restauración. Busca dónde está antes de necesitarlo, no después.
Y una copia no es una copia si solo está en un sitio. Si tu proyecto vive solo en tu ordenador o solo en una plataforma, guarda también una copia fuera.
Dónde se ejecuta
Lo que haces tiene que funcionar en algún sitio, y cambia mucho cuál:
- En tu ordenador. Solo lo usas tú, y se apaga con él. Para herramientas propias suele bastar.
- En la plataforma donde lo creaste. Cómodo para probar, pero depende de sus condiciones, de sus precios y de que siga existiendo.
- En un servidor en internet. Funciona siempre y lo puede usar otra gente. A cambio, cuesta dinero, a veces según el uso, y alguien tiene que mantenerlo y protegerlo.
Además, conviene separar dos sitios: un entorno de pruebas, donde rompes sin miedo, y lo que usa la gente, que en el oficio se llama producción. Los cambios se prueban en el primero y pasan al segundo cuando funcionan.
Datos y claves
Una base de datos es donde se guarda la información para que siga ahí cuando cierras la aplicación: tus registros, los usuarios, los pedidos. Mientras pruebas, usa siempre datos inventados, nunca los de personas reales.
Una clave de API es una contraseña que demuestra a un servicio que puedes usarlo: un modelo de IA, un mapa, un sistema de pagos. Quien la tenga lo usará a tu nombre, y la factura llegará a ti.
Por eso las claves no van nunca dentro del código, ni en nada que llegue al navegador, ni en un proyecto público. Se guardan aparte, en lo que se llama variables de entorno o en el gestor de secretos de tu plataforma, y el código las lee desde ahí.
Si el asistente te escribe una clave dentro del código, pídele que la saque. En la lección 4 lo verás a fondo.
Seis piezas de una aplicación a la izquierda y, a la derecha, para qué sirven, desordenadas. Se empareja cada una y se comprueba.
- Control de versiones → Volver a un punto que funcionaba. Guarda fotos del proyecto en cada paso: si algo se rompe, vuelves atrás.
- Base de datos → Guardar los datos al cerrar. Es donde se quedan los datos entre una vez y la siguiente.
- Clave de API → Usar un servicio a tu nombre. Es como una contraseña: quien la tenga usa el servicio a tu nombre.
- Variable de entorno → Una clave, fuera del código. La clave vive en el servidor o en tu equipo, no en los archivos que se comparten.
- Servidor → Funcionar con tu equipo apagado. Es un ordenador en internet que la tiene siempre en marcha.
- Entorno de pruebas → Probar sin tocar lo de verdad. Una copia aparte para romper sin miedo.
Hazlo: prepara dónde vas a guardar y probar
- Decide con qué herramienta vas a trabajar y dónde se ejecutará tu herramienta de la lección 1: en tu ordenador, en la plataforma o en un servidor.
- Prepara cómo guardar versiones. Si usas una plataforma, busca su historial. Si trabajas en tu ordenador, pide a tu asistente: «Ayúdame a guardar versiones de este proyecto con Git, paso a paso».
- Prepara unos datos inventados para probar.
- Si vas a necesitar alguna clave, apunta dónde la guardarás, fuera del código.
Todavía no hace falta que funcione nada. Con esto, cuando empieces a pedir cambios, cada paso quedará guardado y nada real estará en juego.
Se guarda solo en este navegador y no sale de él.
Comprueba lo que has aprendido · 3 preguntas
1El asistente acaba de romper algo que funcionaba. ¿Qué te salva?
No es esa. La correcta es «Una versión guardada de cuando funcionaba». Con una versión guardada vuelves al punto bueno en un momento y pruebas el cambio de otra forma. Sin ella, dependes de que el asistente acierte.
2¿Dónde no debe estar nunca una clave de API?
No es esa. La correcta es «En el código que se descarga en el navegador». Lo que llega al navegador lo puede leer cualquiera que abra la página. Con tu clave, usaría el servicio a tu nombre, y la factura sería tuya.
3Tu aplicación tiene que funcionar aunque tu ordenador esté apagado. ¿Qué necesita?
No es esa. La correcta es «Un servidor o alojamiento en internet». Si solo se ejecuta en tu ordenador, se apaga con él. Un servidor la mantiene en marcha, y ahí empiezan los costes y la responsabilidad de cuidarla.
Antes de empezar: guarda versiones, sabe dónde se ejecuta, prueba con datos inventados y nunca dejes una clave en el código.
Fuentes
Los datos y las fechas de la lección se comprobaron en estas fuentes el 15 de octubre de 2026. Las que están en inglés son los textos originales.
