Pasar a la acción gracias al AI Vibe Coding
La historia de cómo construí este sitio web sin escribir código, usando AI Vibe Coding a través de Cursor. Reflexión sobre cómo la IA me ayudó a superar el problema de la página en blanco y construir algo real.
Llevaba meses, si digo años no mentiría, queriendo crear mi sitio web personal. Tenía la idea clara, pero cada vez que abría el editor, me enfrentaba a la misma barrera: la página en blanco. No es que no supiera programar, con treinta años de experiencia, pero empezar desde cero requiere energía que escaseaba para proyectos personales.
Todo cambió cuando empecé a usar Cursor. En lugar de escribir todo el código, escribía lo principal y el resto me lo completaba. Ese cambio de mentalidad fue suficiente para romper la barrera. Este no es un tutorial sobre "vibe coding" (ya hay muchos de esos), sino una reflexión honesta sobre lo que aprendí: que no escribir código no significa código desordenado, y que usar IA requiere más juicio profesional, no menos.
1. El Problema de la Página en Blanco
Al empezar un proyecto desde cero, hay que tomar cientos de decisiones: ¿Qué framework? ¿Qué estructura? ¿Qué herramientas? Cada decisión parece importante y puede ser "incorrecta". Es fácil quedar paralizado, porque sabemos lo que implica querer cambiar luego esa decisión.
Ya había pasado por esto. Un sitio anterior con Jekyll funcionaba, pero mantenerlo era una carga. Esta vez quería algo simple, pero "simple" también es una decisión. La parálisis por análisis es real, y después de meses años sin hacer nada, me di cuenta de que necesitaba un empujón para empezar. Ese empujón llegó con Cursor.
La página en blanco no es falta de ideas. Es exceso de opciones sin un punto de partida claro.
2. AI Vibe Coding: Conversar en Lugar de Escribir
Cursor con el tiempo cambió mi enfoque. En lugar de "¿cómo escribo esto?", pensé "¿cómo describo lo que quiero?". Empecé describiendo: "Un sitio estático, simple, con Tailwind self-hosted, modo oscuro basado en preferencias del sistema."
Cursor generó código. Lo revisé, ajusté, y seguí describiendo. Cada iteración me acercaba más, y cada una requería decisiones sobre qué pedir. No era pasivo sino queestaba dirigiendo la generación.
Este proceso me obligó a ser más claro. Cuando escribo código, uno puede ser vago. Con IA, hay que ser específico. Y eso mejoró el resultado: terminé con un diseño más coherente y pensado.
Describir lo que querés requiere más claridad mental que escribir código. Y esa claridad se refleja en el resultado.
3. No Escribir Código No Significa Código Desordenado
Hay una idea errónea: si no escribo código yo mismo, será malo. Mi experiencia fue diferente. El código de Cursor no era perfecto, pero era más consistente que el que yo habría escrito manualmente. Cuando le pedía algo específico, aplicaba patrones consistentes.
El truco está en cómo podirlo. "Hacéme un botón" da un botón genérico. "Hacéme un botón que siga el sistema de diseño, con colores primarios, hover states, y accesible" da algo mucho mejor. Pero tenés que saber qué pedir, eso requiere criterio profesional.
La IA generó cosas que no necesitaba: scripts de Analytics, meta tags irrelevantes. Tuve que revisar y pedirle que los removiera. Ese proceso de revisión es crucial, es como code review, pero del código generado. Y requiere el mismo criterio profesional.
La calidad del código no depende de quién lo escribe, sino de quién lo revisa y refina.
4. Usar IA También Para Desplegar
Configurar deployment no es algo que hago todos los días (a veces pasan incluso meses sin hacerlo). Quería Nginx con Docker y Kamal, pero no tenía tanta experiencia con nginx como con Kamal. Normalmente, esto significaría horas leyendo documentación.
Con Cursor, le describí lo que quería: "Dockerfile con Nginx para archivos estáticos, configuración de Kamal, el sitio está ya pregenerado." Generó todo y funcionó a la primera. Luego refiné detalles: variables de entorno, dominio, headers de seguridad.
La IA también me explicó qué hacía cada parte. Eso me permitió aprender mientras construía. El deployment no fue perfecto porque tuve que ajustar cosas, pero el punto de partida fue mucho mejor que empezar desde cero.
La IA puede generar código que funciona, pero entender por qué funciona sigue siendo tu responsabilidad.
5. Lo Que Funcionó y Lo Que No
Lo que funcionó bien: Estructura inicial rápida y efectiva. Estilos consistentes aplicados automáticamente. Configuración de deployment que funcionó a la primera. Iteración rápida y cambios en segundos.
Lo que fue más difícil: La IA no puede tomar decisiones arquitectónicas, hay que saber lo que uno quiere antes o sino tocará aguantar una copia barata de lo más popular en internet. A veces requería varias iteraciones para llegar exactamente a donde quería. No siempre recordaba decisiones anteriores. Debugging era más difícil porque no había escrito el código yo mismo.
La lección: usar IA no elimina la necesidad de juicio profesional. Solo cambia dónde aplicás ese juicio, mientras describís lo que querés, y revisás lo que la IA generó.
6. Conclusión: El Juicio Profesional Sigue Siendo Clave
Hay una idea de que la IA va a reemplazar desarrolladores. Mi experiencia sugiere lo contrario: hace que el juicio profesional sea más importante. Cuando le pedís algo a una IA, tenés que ser específico y saber qué querés, pero eso requiere criterio profesional.
Este mismo post fue escrito con ayuda de IA. No por IA, sino con ayuda. Yo tenía las ideas y la experiencia. La IA me ayudó a estructurarlas y encontrar las palabras. Eso es poderoso: puedo mantener el sitio actualizado sin que sea una carga enorme.
El futuro no es sobre reemplazar desarrolladores, sino amplificar lo que pueden hacer. Eliminar fricción de tareas repetitivas y permitir enfocarse en lo que importa: resolver problemas reales y aplicar juicio profesional.
La IA no reemplaza el juicio profesional. Lo hace más visible y más importante.