Contexto Histórico: De Assembly a Vibe Coding
🎓 De Assembly a Vibe Coding: 60 Años de Abstracción
👨🏫 Del Investigador: Como investigador en desarrollo de software con 10 años de experiencia, he observado cómo la programación ha evolucionado durante seis décadas. Desde mi perspectiva académica, SDD representa la siguiente abstracción lógica en la evolución del software.
💭 Mentalidad de Investigador: “Según la literatura histórica, cada paradigma de programación emerge de las limitaciones del anterior. La evidencia sugiere que SDD es la respuesta natural al caos del vibe coding.”
📜 La Evolución de la Abstracción
Timeline: 1950s - 2025
1957 → FORTRAN "El nuevo lenguaje de programación más popular"
1972 → C "Portabilidad y eficiencia"
1991 → Python "Legibilidad ante todo"
2023 → Prompt "El inglés es el nuevo lenguaje de programación"
2025 → Spec "La especificación es el nuevo código"
La Promesa de los Años 50
En los años 50 y 60, pioneros como John Backus (FORTRAN), Grace Hopper (COBOL) y Jean Sammet soñaban con un mundo donde:
“El programador describe QUÉ quiere, no CÓMO hacerlo”
Esta visión ha perseguido a la informática por 6 décadas.
🧠 SQL: El Caso de Éxito
SQL es el ejemplo perfecto de programación declarativa exitosa:
-- Describes QUÉ quieres, no CÓMO obtenerlo
SELECT name, email FROM users WHERE active = true;El motor de base de datos decide: - Qué índices usar - Cómo optimizar la consulta - Qué algoritmo de join aplicar
¿Por qué SQL funcionó?
| Factor | Explicación |
|---|---|
| Dominio específico | Solo para bases de datos |
| Resultado predecible | Mismo query → mismos resultados |
| Optimización madura | 40+ años de mejoras |
¿Por qué no se aplicó a todo?
Porque el dominio de “aplicaciones generales” es infinitamente más complejo que “consultar datos”.
🔮 Intentos Anteriores de Abstracción
Model-Driven Development (MDD)
En los años 2000, MDD prometía:
UML Models → Code Generation → Deploy
Problemas encontrados:
- Inflexibilidad: Los modelos eran rígidos
- Curva de aprendizaje: UML es complejo
- Generación pobre: Código mediocre
- Debugging imposible: ¿Dónde está el error?
Lecciones aprendidas:
“No puedes abstraer toda la complejidad. Necesitas flexibilidad.”
Low-Code / No-Code
Promesa: “Cualquiera puede crear aplicaciones”
Realidad:
- ✅ Funciona para casos simples
- ❌ Se rompe con lógica compleja
- ❌ Vendor lock-in
- ❌ Debugging es pesadilla
4GL (Fourth Generation Languages)
Ejemplos: PowerBuilder, Oracle Forms, ABAP
- Dominio específico: Aplicaciones de negocio
- Generación de UI automática
- Limitaciones severas de flexibilidad
🎭 El Fenómeno Vibe Coding
¿Qué es Vibe Coding?
Andrej Karpathy (febrero 2025):
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” [1]
Definición operativa:
Vibe Coding = Aceptar código generado sin entenderlo completamente
Diferencia Clave (Simon Willison)
| Actividad | ¿Es Vibe Coding? |
|---|---|
| Generas código con IA, no lo revisas | ✅ SÍ |
| Generas código, lo revisas, lo entiendes | ❌ NO |
| Generas código, lo pruebas, lo modificas | ❌ NO |
“If an LLM wrote every line of your code, but you reviewed it, tested it, and understood it all, that’s NOT vibe coding — that’s using an LLM as a writing assistant.” — Simon Willison [2]
Estadísticas Impactantes
| Métrica | Valor |
|---|---|
| Startups YC Winter 2025 con 95% código IA | 25% [3] |
| Tiempo para crear app “LunchBox Buddy” | ~1 hora |
| Calidad de código vibe-coded | Variable |
| Adecuado para producción | ⚠️ Riesgoso |
Ejemplo: LunchBox Buddy (Kevin Roose)
Prompt: "Crea una app que analice mi refrigerador
y sugiera qué preparar para almuerzo"
Resultado:
- App funcional en 1 hora
- Sin conocimientos de programación previos
- Bugs ocasionales
- No escalable
⚠️ Los Problemas del Vibe Coding
1. Alucinaciones de Código
// IA genera:
function calculateTotal(items) {
return items.reduce((a, b) => a + b);
}
// Problema: ¿Qué pasa si items está vacío?
// ¿Qué pasa si los items tienen propiedad .price?2. Inconsistencia
Mismo prompt → Diferentes resultados cada vez
Prompt: "Add user authentication"
Run 1: JWT + bcrypt
Run 2: Sessions + SHA256
Run 3: OAuth only
3. Falta de Trazabilidad
Pregunta: "¿Por qué usaste bcrypt?"
Respuesta IA: "No lo sé, el modelo decidió."
Problema: No hay documentación de decisiones.
4. Dificultad de Mantenimiento
Escenario: Bug en producción
Developer: "¿Dónde está el error?"
Código: Generado sin comentarios claros
Tests: No existen
Docs: Ninguna
Resultado: Reescribir desde cero
5. Caso Real: E-commerce Fake Reviews
Kevin Roose pidió: "Crea un sitio de reviews"
La IA generó:
- Reviews falsas automáticamente
- Sin verificar si era ético
- Sin validación de input
Resultado: Código que genera desinformación
📊 Vibe Coding vs Desarrollo Tradicional
| Aspecto | Tradicional | Vibe Coding |
|---|---|---|
| Velocidad inicial | Lento | Muy rápido |
| Calidad de código | Controlada | Variable |
| Mantenibilidad | Alta | Baja |
| Documentación | Explícita | Inexistente |
| Testing | Planificado | Olvidado |
| Trazabilidad | Git + docs | Solo código |
| Debugging | Conocido | Difícil |
| Uso recomendado | Producción | Prototipos |
🎯 ¿Cuándo Usar Vibe Coding?
✅ Apropiado
- Prototipos rápidos (< 1 día)
- Proyectos personales de fin de semana
- Exploración de ideas
- Demos para stakeholders
- “Software for one” (uso personal)
❌ No Apropiado
- Aplicaciones de producción
- Sistemas financieros
- Software médico
- Infraestructura crítica
- Código que otros mantendrán
La Regla de Karpathy
“Vibe coding is pretty good for weekend projects and it’s pretty fun.”
Implicación: No es para todos los casos de uso.
🔄 La Evolución: Vibe Coding → SDD
El Problema Central
Vibe Coding tiene un problema fundamental:
Falta una "visión completa" de QUÉ se está construyendo
La Solución: Specifications
Marc Brooker (Kiro/AWS) lo explica:
“A specification is the bigger picture. It’s what those prompts are driving towards, step by step. It is, at its core, the whole point of the program.”
Comparación
| Vibe Coding | Spec-Driven Development |
|---|---|
| Prompts ad-hoc | Especificaciones estructuradas |
| Sin memoria entre sesiones | Source of truth persistente |
| Resultados inconsistentes | Resultados reproducibles |
| Código como fin | Specs como fin, código como medio |
| Caótico | Organizado |
🧭 El Espectro de Desarrollo con IA
┌─────────────────────────────────────────────────────────────┐
│ ESPECTRO DE DESARROLLO IA │
├─────────────────────────────────────────────────────────────┤
│ │
│ Manual Copilot Vibe SDD │
│ Coding Asistido Coding │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │100│ │ 70│ │ 10│ │ 20│ │
│ │% │ ──────▶ │% │ ─────────▶ │% │ ──────▶ │% │ │
│ │humano │humano │humano │humano │
│ └───┘ └───┘ └───┘ └───┘ │
│ │
│ Control Balance Velocidad Estructura │
│ total máxima + calidad │
│ │
└─────────────────────────────────────────────────────────────┘
Diferencia Clave
Vibe Coding: El humano escribe código IA, acepta sin revisar
SDD: El humano escribe especificaciones, revisa, verifica
🎓 Síntesis de la Investigación
- 60 años de abstracción han llevado a la programación de assembly a specs
- SQL demostró que la programación declarativa funciona en dominios específicos
- MDD y 4GL fallaron por falta de flexibilidad según la literatura
- Vibe Coding presenta velocidad pero riesgo para producción [1]
- SDD es la evolución natural: especificaciones como “North Star” [4]
- No es binario: La evidencia muestra un espectro de opciones según el contexto
🚀 Siguiente Paso
Continúa con Módulo 1: Introducción a SDD para entender los fundamentos de Spec-Driven Development.
📚 Referencias
- Karpathy, A. (2025). “Vibe Coding” - X/Twitter
- Roose, K. (2025). “Not a Coder? With A.I., Just Having an Idea Can Be Enough” - NYT
- Brooker, M. (2025). “Kiro and the future of AI spec-driven software development”
- Willison, S. (2025). Definition of vibe coding - Ars Technica
- Mehta, I. (2025). Y Combinator statistics - TechCrunch
Módulo 0.1 | Duración: 45 min | Dificultad: 🟢 Básico
Módulo 00 | © Diego Saavedra