Quiero ser muy claro sobre algo antes de empezar.
Guarda esto :)
No soy desarrollador. Nunca he sido desarrollador. No tengo un título en ciencias de la computación. No hice ni un solo bootcamp de programación. No puedo leer la mayoría del código y decirte qué hace.
Pero el fin de semana pasado lancé una aplicación web funcional a internet. Usuarios reales se registraron. Datos reales se almacenaron. Funciones reales funcionaron.
Construí todo el proyecto con Claude Code en dos días. Y te voy a contar la verdad sobre cómo fue realmente esa experiencia. No la versión curada. La realidad desordenada, frustrante y llena de avances.
Porque cada historia de "construí una app con IA" en internet parece effortless. No es effortless. Pero es muy, muy posible.
Sábado por la mañana: La idea
Quería construir una herramienta simple. Un calendario de contenido que te permita planificar tus publicaciones en varias plataformas, arrastrarlas entre días y marcarlas como publicadas. Nada revolucionario. Pero algo que realmente necesitaba para mi propio flujo de trabajo.
Abrí Claude Code en mi terminal por primera vez a las 9 a. m. del sábado.
A las 9:15 a. m. ya había cometido mi primer error.
Error n.º 1: Empezar sin un plan
Mi primer prompt para Claude Code fue:
Créame una aplicación de calendario de contenido
Claude generó un montón de archivos. Algo apareció en la pantalla. Parecía un calendario de contenido diseñado por alguien que nunca había visto un calendario.
Aquí es donde el 90 % de la gente se rinde. Escriben un prompt vago, obtienen un resultado vago y concluyen que el vibe coding no funciona.
El problema no era Claude. El problema era yo. No le había dado nada con lo que trabajar.
Lo que debería haber hecho:
Debería haber empezado en Plan Mode. Presiona Shift + Tab en Claude Code para cambiar de Act Mode a Plan Mode. En Plan Mode, Claude piensa antes de construir. Hace preguntas. Traza la arquitectura. Te muestra lo que planea crear.
Volví atrás y lo hice bien:
Quiero construir una aplicación web de calendario de contenido. Antes de escribir cualquier código, planifiquemos esto.
La aplicación necesita:
- Una vista semanal con 7 columnas (lunes a domingo)
- La capacidad de añadir publicaciones con un título, plataforma (Twitter, LinkedIn, Instagram) y estado (borrador, programado, publicado)
- Arrastrar y soltar para mover publicaciones entre días
- Un diseño simple y limpio usando Tailwind CSS
- Datos almacenados en una base de datos local para que persistan entre sesiones
¿Qué stack tecnológico deberíamos usar? ¿Cuál es la estructura de carpetas? Explícame la arquitectura antes de construir nada.
Claude devolvió un plan detallado. Next.js como framework. SQLite para la base de datos. Tailwind para el estilo. Una estructura de carpetas limpia, archivo por archivo.
Lección aprendida: Empieza siempre en Plan Mode. Describe siempre lo que quieres en detalle. Los 5 minutos que inviertes planificando te ahorran 2 horas de reconstrucción.
Error n.º 2: Intentar construirlo todo a la vez
Después de planificar, me emocioné. Le pedí a Claude que construyera todo de una sola vez.
El resultado fue un desastre. Algunas funciones funcionaban. Otras estaban a medio implementar. El arrastrar y soltar no funcionaba. La base de datos no guardaba correctamente. No tenía ni idea de por dónde empezar a arreglarlo.
Lo que debería haber hecho:
Construir una función a la vez. Esta es la regla de oro del vibe coding.
Empecé de nuevo y seguí este orden:
Sesión 1: Solo el diseño básico de la página. Siete columnas. Sin funciones. Sesión 2: Añadir la capacidad de crear una publicación (solo un formulario simple). Sesión 3: Mostrar las publicaciones guardadas en la columna del día correcto. Sesión 4: Añadir la funcionalidad de arrastrar y soltar. Sesión 5: Añadir la función de estado (borrador/programado/publicado). Sesión 6: Hacer que se vea bien.
Cada función tuvo su propia conversación. Contexto nuevo. Tarea clara. Resultado limpio.
Cuando construía una función a la vez, cada una funcionaba perfectamente. Cuando intentaba construirlo todo a la vez, nada funcionaba.
Lección aprendida: Una conversación por función. Nunca mezcles múltiples funciones en la misma sesión de Claude Code.
Error n.º 3: No crear un archivo CLAUDE.md
El sábado por la tarde ya tenía un diseño básico funcional y estaba emocionado. Pero seguía encontrándome con los mismos problemas:
Claude añadía complejidad innecesaria. Creaba sistemas elaborados de manejo de errores cuando yo solo quería un try-catch simple. Añadía librerías de animación cuando yo solo quería una transición limpia. Reestructuraba todo mi sistema de carpetas cuando le pedía un pequeño cambio.
Estaba corrigiendo las mismas cosas una y otra vez.
Entonces recordé haber leído sobre CLAUDE.md.
Creé un archivo en la raíz de mi proyecto:
CLAUDE.md
Reglas del proyecto
- Esto es un calendario de contenido simple. Mantén todo al mínimo.
- Usa Next.js 14 con App Router
- Usa Tailwind CSS para todo el estilo. Sin otros frameworks CSS.
- Usa SQLite con Prisma ORM para la base de datos
- Mantenlo simple. Sin abstracciones ni patrones de diseño innecesarios.
- Cuando digo "haz que se vea bien" me refiero a: espaciado limpio, fuentes legibles, efectos hover sutiles, esquinas redondeadas
- No añadas nuevas dependencias sin preguntarme primero
- Pregunta antes de refactorizar cualquier código existente
Estilo de código
- Código simple y legible. Un principiante debería poder entenderlo.
- Nombres de variables claros. Sin abreviaturas.
- Comentarios solo para lógica no obvia
Después de crear este archivo, la experiencia cambió drásticamente. Claude dejó de sobrediseñar. Dejó de añadir librerías aleatorias. Dejó de reestructurar cosas que no le había pedido que tocara.
Cada vez que Claude hacía algo que no quería, añadía una nueva regla a CLAUDE.md. Para el domingo por la noche, este archivo tenía más de 30 reglas y Claude las seguía todas perfectamente.
Lección aprendida: Crea CLAUDE.md desde el día uno. Actualízalo constantemente. Es la herramienta más poderosa de Claude Code.
Error n.º 4: No usar capturas de pantalla
Sábado por la noche. La aplicación funciona funcionalmente pero se ve fea. Escribí esto:
Haz que el diseño sea más moderno y profesional
Claude cambió cosas. Se veían diferentes. No mejores, solo diferentes.
Estaba intentando describir problemas visuales con palabras. Eso es increíblemente ineficiente.
En lugar de eso, empecé a tomar capturas de pantalla de sitios web cuyo diseño me encantaba. Las pegué directamente en Claude Code:
[captura de pantalla de una interfaz de calendario limpia]
Quiero que mi calendario se vea así. Específicamente:
- Este tono exacto de gris para el fondo
- Estas tarjetas redondeadas para cada publicación
- Esta cantidad de espaciado entre elementos
- La forma en que el día activo se resalta en azul
Claude igualó el diseño casi perfectamente. Al primer intento.
Luego, cuando algo se veía mal, en lugar de describirlo, tomaba una captura de pantalla, rodeaba el área problemática, la pegaba y decía "este espaciado está mal" o "esta fuente es demasiado pequeña".
Lección aprendida: Las capturas de pantalla son 10 veces mejores que las palabras para la retroalimentación visual. Pega siempre imágenes en lugar de describir lo que ves.
Domingo: Todo encajó
El domingo por la mañana tenía una aplicación funcional con diseño limpio, arrastrar y soltar, datos persistentes y una base de datos operativa. Había construido todo sin entender la mayor parte del código.
Pero solo existía en mi portátil. Hora de desplegar.
Error n.º 5: Tener miedo al despliegue
El despliegue sonaba aterrador. Servidores. Dominios. DNS. Archivos de configuración.
Casi me detengo. Casi decido "con que funcione localmente es suficiente".
Pero seguí adelante y le pregunté a Claude:
Quiero desplegar esta aplicación en vivo en internet. Quiero usar Vercel porque he oído que es lo más fácil. Explícame los pasos exactos.
Claude me dio siete pasos:
- Subir el código a GitHub (Claude me ayudó a configurar Git)
- Registrarse en Vercel (gratis)
- Conectar Vercel a mi repositorio de GitHub
- Configurar las variables de entorno para la base de datos
- Hacer clic en desplegar
- Esperar 90 segundos
- Obtener mi URL en vivo
Seguí los pasos. Tres minutos después mi aplicación estaba en vivo. Envié la URL a cinco personas. La abrieron. Funcionó.
Lección aprendida: El despliegue no da miedo. Es solo una lista de verificación. Claude te guiará en cada paso.
Las 12 reglas que me habría gustado saber antes de empezar
Todo lo que aprendí en dos días, resumido en reglas:
Regla 1: Empieza siempre en Plan Mode. Shift + Tab. Piensa antes de construir.
Regla 2: Una conversación por función. Un contexto nuevo es un contexto mejor.
Regla 3: Crea CLAUDE.md desde el día uno. Cada corrección se convierte en una regla permanente.
Regla 4: Usa capturas de pantalla para cada problema visual. Rodea el problema. Pégalo directamente.
Regla 5: Construye primero la versión más simple. Añade complejidad solo después de que la versión simple funcione.
Regla 6: Describe lo que quieres en detalle. Cuanto más específico sea tu prompt, mejor será el resultado. "Construye una página de inicio de sesión" da basura. "Construye una página de inicio de sesión con campos de correo electrónico y contraseña, un enlace de 'olvidé mi contraseña' debajo, un botón de enviar azul y una redirección a /dashboard al iniciar sesión correctamente" da exactamente lo que pediste.
Regla 7: Usa /compact cuando las conversaciones se alarguen. La calidad de Claude baja cuando el contexto se llena.
Regla 8: Haz commit a Git después de cada función que funcione. Claude puede ayudarte con esto. Si algo se rompe, puedes revertirlo.
Regla 9: Cuando algo se rompa, copia el mensaje de error y pégalo en Claude. Di "Diagnostica la causa raíz antes de arreglar nada". Claude casi siempre encuentra el problema al instante.
Regla 10: No intentes entender cada línea de código. Entiende qué hace cada archivo y cómo se conectan. Eso es suficiente para dirigir a Claude de manera efectiva.
Regla 11: Cuando Claude se atasque en un bucle arreglando lo mismo una y otra vez, para. Empieza una conversación nueva. Pega solo el archivo relevante y una descripción clara del problema.
Regla 12: Publícalo antes de que sea perfecto. La versión uno no necesita ser hermosa. Necesita funcionar. Siempre puedes mejorarla en la versión dos.
Lo que he construido desde ese fin de semana
Eso fue hace tres semanas. Desde entonces he construido:
- Un portal de registro de clientes con inicio de sesión y carga de archivos
- Un panel interno que rastrea mis métricas de contenido
- Un generador de facturas simple que crea facturas en PDF a partir de un formulario
- Un gestor de marcadores que guarda y organiza enlaces por tema
Sigo sin poder leer la mayor parte del código. Sigo sin entender el 80 % de lo que ocurre en los archivos. Pero puedo describir lo que quiero con la suficiente claridad como para que Claude lo construya. Puedo depurar problemas mostrándole el error a Claude. Puedo desplegar productos funcionales en internet.
Eso es el vibe coding. Tú no eres el programador. Tú eres el product manager. Claude es el programador. Tu trabajo es saber qué construir y comunicarlo con claridad.
La mayoría de la gente seguirá diciéndose que necesita aprender a programar antes de poder construir nada.
Los que abran su terminal este fin de semana tendrán una aplicación funcionando el lunes por la mañana. Lo sé porque eso es exactamente lo que me pasó a mí.
Sígueme @eng_khairallah1 para más cursos, herramientas y flujos de trabajo sobre IA. Contenido nuevo cada semana.
Espero que te haya sido útil, Khairallah ❤️
