Quiero ser muy claro sobre algo antes de empezar.
Guarda esto :)
No soy desarrollador. Nunca lo he sido. No tengo un título en ciencias de la computación. No tomé ningún bootcamp de programación. No puedo leer la mayoría del código y decirte qué hace.
Pero el fin de semana pasado subí una aplicación web funcional a internet. Usuarios reales se registraron. Datos reales se almacenaron. Funciones reales funcionaron.
Construí todo con Claude Code en dos días. Y te voy a contar la verdad sobre cómo fue esa experiencia. No la versión curada. La realidad desordenada, frustrante y llena de avances.
Porque cada historia de "creé una app con IA" en internet suena sencilla. No lo es. Pero es muy, muy posible.
Sábado por la mañana: La idea
Quería construir una herramienta simple. Un calendario de contenidos 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 #1: Empezar sin un plan
Mi primer prompt para Claude Code fue:
Créame una aplicación de calendario de contenidos
Claude generó un montón de archivos. Algo apareció en la pantalla. Parecía un calendario de contenidos 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 qué trabajar.
Lo que debería haber hecho:
Debería haber empezado en el Modo Plan. Presiona Shift + Tab en Claude Code para cambiar del Modo Act al Modo Plan. En el Modo Plan, 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 contenidos. Antes de escribir código, planifiquemos esto.
La aplicación necesita:
- Una vista semanal con 7 columnas (lunes a domingo)
- La posibilidad de añadir publicaciones con 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 respondió con 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: Siempre empieza en Modo Plan. Siempre describe lo que quieres en detalle. Los 5 minutos que dediques a planificar te ahorrarán 2 horas de reconstrucción.
Error #2: Intentar construir todo de una vez
Después de planificar, me emocioné. Le dije 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 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 construir todo a la vez, nada funcionaba.
Lección aprendida: Una conversación por función. Nunca mezcles varias funciones en la misma sesión de Claude Code.
Error #3: No crear un archivo [CLAUDE.md](http://claude.md/)
Para el sábado por la tarde 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 solo quería un try-catch simple. Agregaba bibliotecas de animación cuando 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 contenidos simple. Mantén todo al mínimo.
- Usa Next.js 14 con App Router
- Usa Tailwind CSS para todo el estilo. Ningún otro framework de CSS.
- Usa SQLite con Prisma ORM para la base de datos
- Mantenlo simple. Sin abstracciones ni patrones de diseño innecesarios.
- Cuando diga "haz que se vea bien" me refiero a: espaciado limpio, fuentes legibles, efectos hover sutiles, esquinas redondeadas
- Nunca 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 sobreingenierizar. Dejó de agregar bibliotecas aleatorias. Dejó de reestructurar cosas que no le había pedido tocar.
Cada vez que Claude hacía algo que no quería, añadía una nueva regla a [CLAUDE.md](http://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](http://claude.md/) el primer día. Actualízalo constantemente. Es la herramienta más poderosa en Claude Code.
Error #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, 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 feedback visual. Siempre pega imágenes en lugar de describir lo que ves.
Domingo: Todo se juntó
Para 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 laptop. Hora de desplegar.
Error #5: Tener miedo al despliegue
El despliegue sonaba aterrador. Servidores. Dominios. DNS. Archivos de configuración.
Casi me detengo. Casi decido "ejecutarlo localmente es suficiente."
Pero seguí adelante y le pregunté a Claude:
Quiero desplegar esta aplicación en vivo en internet. Quiero usar Vercel porque escuché 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)
- Registrarme en Vercel (gratis)
- Conectar Vercel con 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 hubiera gustado saber antes de empezar
Todo lo que aprendí en dos días, comprimido en reglas:
Regla 1: Empieza siempre en Modo Plan. Shift + Tab. Piensa antes de construir.
Regla 2: Una conversación por función. Un contexto nuevo es un mejor contexto.
Regla 3: Crea CLAUDE.md el primer día. 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 la versión más simple primero. 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. "Crea una página de inicio de sesión" da basura. "Crea 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 envío azul y una redirección a /dashboard al tener éxito" 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 funcional. 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. Dile "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. Inicia una conversación nueva. Pega solo el archivo relevante y una descripción clara del problema.
Regla 12: Lánzalo 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 onboarding para 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
Todavía no puedo leer la mayor parte del código. Todavía no entiendo el 80% de lo que pasa en los archivos. Pero puedo describir lo que quiero con la suficiente claridad para que Claude lo construya. Puedo depurar problemas mostrándole el error a Claude. Puedo desplegar productos funcionales en internet.
Eso es vibe coding. No eres el programador. Eres el gerente de producto. Claude es el programador. Tu trabajo es saber qué construir y comunicarlo con claridad.
La mayoría de la gente seguirá diciéndose a sí misma que necesita aprender a programar antes de poder construir algo.
Los que abran su terminal este fin de semana tendrán una aplicación funcional para 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. Nuevo contenido cada semana.
Espero que te haya sido útil, Khairallah ❤️
