Dejé el Vibe Coding y Construí una App Real. El Método que Nadie Enseña.

Le pediste a una IA que te construyera una app. Se ve bien y funciona. Casi. En el momento que tocas una funcionalidad, otra se rompe.

Cada vez que un usuario real la prueba, hay un bug. (No no, no hagas clic en eso.) El login no protege nada en realidad. Los clientes de un usuario aparecen en el dashboard de otro. La página de pagos recolecta la tarjeta de crédito pero nunca registra la transacción.

Tu proceso está roto. El código es solo el síntoma.

Construí una casa de fardos de paja con mis propias manos. Cinco años. El paralelismo con el software (llevo 30 años en IT) es asombroso: la misma necesidad de secuencia, la misma necesidad de entender cada especialidad sin convertirse en especialista. Convertí eso en un método para que puedas desarrollar tu app como un profesional.

La brecha de la que nadie habla

El vibe coding está roto. No las herramientas. No la IA. La forma en que la gente las usa.

Todos los tutoriales muestran lo mismo: escribes un prompt, obtienes una app, celebras. Y funciona, para una demo. Una pantalla con botones que se ven bien.

Luego necesitas que la app haga cosas reales. Múltiples usuarios que cada uno ve solo sus propios datos. Pagos que realmente se procesan. Una nueva funcionalidad que no rompe silenciosamente tres anteriores.

La IA optimiza para "funciona ahora mismo." Una app real necesita "sigue funcionando en seis meses." Esa brecha no es sobre calidad de código. Es sobre saber qué pedir, en qué orden, y cómo verificar que lo obtuviste.

El Método Blueprint

Ocho pasos. El mismo ciclo para cada funcionalidad, desde una simple lista de clientes hasta integración con Stripe.

1. Spec global. ¿Qué quieres, en lenguaje simple? "Quiero gestionar clientes." Vago a propósito. Solo lo suficiente para empezar.

2. Implicaciones. El paso que la mayoría omite, y el que te salva. Pregúntale a la IA: "¿Qué implica esto técnicamente? ¿Qué tablas, páginas, componentes necesito?" La IA desempaca tu solicitud en una lista de cosas concretas que necesitan existir. Algunas las esperabas. Otras (una columna ID, timestamps, reglas de validación) no las pensaste. Ahora ves el panorama completo antes de construir nada.

3. Spec detallada. Sé específico. Campos, tipos, validación, manejo de errores, qué pasa cuando algo sale mal. Aquí es donde "construyeme una lista de clientes" se vuelve utilizable.

4. Construir. Dale la spec detallada a la IA. Deja que construya.

5. Explicar. Pregúntale a la IA: "Explica lo que acabas de construir y por qué." No lees el código. Pero entiendes el flujo. Este entendimiento se acumula. Para tu décima funcionalidad, tienes un modelo mental rico de toda tu app.

6. Verificar. Revisa que funcione. No leyendo código. Usando la app, probando casos extremos, y preguntándole a la IA "¿qué podría salir mal con esto?"

7. Qué puede salir mal. Cada funcionalidad tiene trampas específicas. ¿Auth? La IA almacena contraseñas en texto plano. ¿Pagos? Ignora fallas de webhook. ¿Seguridad? Políticas demasiado permisivas. Nombra las trampas para atraparlas.

8. No regresión. Verifica que todo de funcionalidades previas siga funcionando. La falla más común del vibe coding: agregar algo nuevo que silenciosamente rompe tres cosas viejas.

La profundidad aumenta conforme avanzas. Tu primera spec son dos oraciones. Para cuando estés haciendo pagos, son dos páginas. Mismo método. Tu habilidad crece.

Un ejemplo concreto: autenticación

Aquí es donde el vibe coding falla más espectacularmente.

Antes.

"Agrega un login a mi app."

La IA construye una página con campos de email y contraseña, un botón, una redirección. Se ve como un login. La UI está bien. Pero auth no es una funcionalidad de UI. Auth es infraestructura. La página de login es el 10% visible. El otro 90% es gestión de sesiones, validación de tokens, protección de rutas, aislamiento de datos. La IA se salta todo eso porque no lo pediste.

Lo lanzas. Usuario A se loguea. Usuario B se loguea. Usuario B ve los datos de Usuario A.

Después.

Misma funcionalidad, con el método.

Paso 1 (spec global): "Cada usuario tiene su propia cuenta. Se loguean con email y contraseña. Una vez logueados, ven solo sus datos."

Paso 2 (implicaciones): le pides a la IA que explique qué significa esto técnicamente. Regresa con: autenticación vs autorización (dos cosas diferentes), sesiones, tokens, protección de rutas, y vincular datos a usuarios (cada registro necesita una columna user_id). No sabías que necesitabas la mitad de esto. Ahora sí. Antes de escribir un solo prompt para construir algo.

Paso 3 (spec detallada): registro con confirmación de email. Login con email y contraseña. Botón de logout. Sesión que expira automáticamente después de inactividad. Protección de rutas para TODAS las páginas excepto login y registro. Una columna user_id en cada tabla de datos. Filtrado automático por usuario en cada consulta.

Eso es un contrato. Cada expectativa declarada, cada comportamiento definido.

Luego construyes, verificas, nombras las trampas (sesiones que nunca expiran, user_id verificado en INSERT pero no en UPDATE o DELETE), y revisas regresión contra cada funcionalidad previa. Conoces el ciclo. Los mismos ocho pasos.

La diferencia entre "agrega un login" y esto es la diferencia entre una puerta que parece cerrada y una puerta que realmente lo está.

La secuencia de construcción

Construye en este orden:

• Setup y deploy (pon algo en vivo inmediatamente, aunque sea una página en blanco)
• Entiende los bloques de construcción (frontend, backend, base de datos, cómo se comunican)
• Diseña la interfaz antes de construirla (vocabulario + reglas de consistencia)
• Tu primera funcionalidad (CRUD simple, aprende el ciclo)
• Relaciones de datos (cosas que se conectan con otras cosas)
• Autenticación (quién eres)
• Aislamiento de datos (cada usuario ve solo sus propios datos)
• Testing (automatiza la verificación que has estado haciendo a mano)
• Dashboard y pulido (haz que se sienta como un producto)
• Pagos (la funcionalidad con los bugs más caros)
• Lanzar en serio (deploy de producción, dominio, monitoreo)

Cada paso se construye sobre el anterior. No puedes agregar autenticación antes de tener páginas que proteger. No puedes agregar pagos antes de tener usuarios a quienes cobrar. No puedes hacer testing efectivo antes de tener funcionalidades que probar.

Cada desastre de vibe coding que he visto sigue el mismo patrón: alguien construyó la funcionalidad genial primero (pagos, dashboards, UI fancy) y agregó las cosas aburridas después (auth, seguridad, manejo de errores). Las cosas aburridas nunca encajan bien porque nunca fueron parte de la arquitectura.

Saltarte pasos es como cablear electricidad en una casa sin paredes.

El ciclo de la muerte (y cómo escapar)

Viernes por la tarde. Solo quieres lanzar un arreglo más antes del fin de semana. El bug es pequeño. Le das un prompt a la IA. El arreglo funciona. Excepto que ahora la barra lateral está rota. Otro prompt. Barra lateral arreglada, pero el botón de guardar ya no envía. Un prompt más. Guardar funciona, barra lateral rota otra vez, y la página de login es una pantalla blanca.

Tu alberca te espera. Tus hijos preguntan cuándo terminas. Sigues con prompts. Hace tres rondas tenías un bug. Ahora tienes cuatro. 🫠

Ese es el ciclo de la muerte.

Cada parche arregla una cosa y rompe otra porque la IA sigue tratando síntomas. La causa raíz sigue ahí, enterrada bajo capas de arreglos rápidos. Ya no estás debuggeando. Lo estás empeorando con cada prompt.

La salida es siempre la misma. Dejas de hacer prompts. Reviertes a la última versión que funcionaba (para eso existe Git). Y regresas con un prompt diferente: "No arregles el síntoma. Explica qué significa este error en la raíz. He intentado arreglarlo dos veces y cada arreglo creó nuevos bugs."

A veces la funcionalidad está muy enredada para salvarla. Reviertes y la reconstruyes desde cero con una mejor spec. Suena doloroso. En realidad es más rápido que una sexta ronda de whack-a-mole.

Los equipos se quedan atascados en ciclos de la muerte por semanas. Por eso el diagnóstico en la crisis de productividad de coding con IA de Bloomberg estaba equivocado: midieron velocidad de output, no frecuencia de ciclos.

La calidad del spec lo es todo

Misma funcionalidad. Dos specs. Dos resultados.

Mal spec: "Construyeme una página de clientes."

La IA adivina todo. Layout, columnas, botones, qué pasa cuando no hay datos. El resultado es aleatorio. No especificaste nada, así que la IA llenó cada espacio en blanco con su propio juicio. Que a menudo está mal.

Buen spec: "Construye una página de lista de clientes con navegación lateral. En el área principal, una tabla con columnas: nombre, teléfono, email, ciudad. Una barra de búsqueda arriba de la tabla. Un botón 'Agregar cliente' que abre un modal de formulario. Cuando no hay clientes, muestra 'Aún no hay clientes, agrega el primero' con un botón. Estado de carga con un skeleton. Estado de error con un mensaje amigable para el usuario."

Cada elemento está especificado. El resultado es predecible. Y (esta es la clave) puedes verificarlo, porque sabes exactamente lo que pediste.

Mal spec = mal contrato. La IA llena los espacios con adivinanzas. Buen spec = buen contrato. Cada expectativa declarada, cada comportamiento definido. Construí el framework completo de contratos de prompts después de que suficientes funcionalidades se descarrilaran. Mismo principio: el spec es el producto.

Esto se puede aprender. Tu primer spec serán dos oraciones. Para el décimo, escribirás dos páginas sin pensarlo. El método te entrena, una funcionalidad a la vez.

Spec. Construir. Verificar. Repetir.

La IA escribe todo el código. Yo escribo cero. Pero especifico exactamente lo que quiero, entiendo lo que se construyó (sin leer código), y verifico todo sistemáticamente. Así es como lanzo apps de producción con usuarios reales, pagos reales, y aislamiento de datos que realmente se mantiene.

"Construir" y "lanzar" no son el mismo verbo.

Le pediste a una IA que te construyera una app. Ahora sabes cómo realmente lanzarla. Ocho pasos, mismo ciclo. Tedioso. No sexy.

Seguir hasta el final depende de ti.

(*) La portada es generada por IA. La casa de fardos de paja sí es real.