Vibe Coding vs. Ingeniería: Dónde Trazo la Línea

Andrej Karpathy acuñó el término “vibe coding” en febrero de 2025, describiendo un estilo de desarrollo en el que el programador “se entrega completamente a las vibraciones, abraza las exponenciales y se olvida de que el código siquiera existe.”¹

Lo leí y pensé: eso es la mitad de mi flujo de trabajo. La otra mitad es lo opuesto.

TL;DR

Construyo con Claude Code todos los días. Parte de ese trabajo es puro vibe coding: describo lo que quiero, acepto el resultado, sigo adelante. Otra parte pasa por 86 hooks, un guardián de seguridad de git, una protección contra recursión y un sistema de control de calidad que bloquea commits con marcas de IA o voz pasiva. La línea entre ambos no es arbitraria. Los prototipos reciben vibraciones. La producción recibe ingeniería. Lo difícil es saber cuándo un prototipo cruza esa línea.

---

Mi Flujo de Trabajo Real

El Lado Vibe

Cuando estoy explorando una idea, hago vibe coding sin disculpas. Mi aplicación iOS Ace Citizenship comenzó como un experimento de fin de semana: “Construir un quiz de repetición espaciada para preguntas de educación cívica del USCIS.” Claude Code generó las vistas iniciales de SwiftUI, el banco de preguntas y el algoritmo de programación. No leí cada línea. Lo ejecuté, lo probé manualmente e iteré describiendo lo que se sentía mal.

Los componentes interactivos de este blog (el árbol de decisión de RAG, la calculadora de interés compuesto) comenzaron de la misma manera. “Construir un árbol de decisión que guíe a los usuarios entre RAG y fine-tuning con transiciones animadas.” Aceptar, probar, ajustar. El radio de impacto de un error en un widget del blog se limita a una sola página.

El Lado de Ingeniería

Mi arquitectura de hooks de Claude Code es lo opuesto al vibe coding. Cada hook existe porque algo salió mal.

git-safety-guardian.sh existe porque Claude hizo un force-push a main durante una sesión temprana. El hook ahora intercepta cada comando de git, compara patrones contra una tabla de severidad (CRITICAL: force push a main; HIGH: agregar archivos .env; MEDIUM: –no-verify), e inyecta una advertencia antes de la ejecución.

recursion-guard.sh existe porque un subagente generó hijos infinitos. El hook rastrea el linaje de agentes en un archivo JSON, impone límites de profundidad y administra un modelo de presupuesto de generación que previene cadenas descontroladas de agentes mientras permite trabajo paralelo legítimo.

blog-quality-gate.sh existe porque la prosa generada por IA suena como prosa generada por IA. El hook bloquea commits en content/blog/ si detecta rayas largas, voz pasiva o palabras como “delve,” “crucial,” o “landscape.”

Ninguno de estos hooks fue creado con vibe coding. Cada uno fue escrito línea por línea, probado contra escenarios reales de falla y revisado antes de su implementación. Los 86 hooks representan colectivamente la frontera entre vibrar e ingeniería.

---

Dónde Cae Realmente la Línea

Vibe: Prototipos Desechables

Hago vibe coding con cualquier cosa que podría descartar. Un script de transformación de datos que ejecutaré una sola vez. Una herramienta CLI para uso personal. Una prueba de concepto para verificar si una API hace lo que la documentación afirma. El costo de un error en código desechable es mi propio tiempo, y la ganancia en velocidad supera el riesgo de depuración.

Vibe: Exploración Creativa

Cuando estoy explorando una dirección de diseño, el vibe coding me permite probar patrones de interacción más rápido que Figma. “Construir un modal de búsqueda con navegación por teclado, resaltado de resultados y activación con Cmd+K” produce un prototipo funcional en minutos. Evalúo la sensación, no el código.²

Ingeniería: Todo lo que Toca a los Usuarios

En el momento en que el código sirve a alguien que no soy yo, cruza la línea. Mi blog pasa por un linter de 12 módulos que verifica citas, jerarquía de encabezados, nivel de legibilidad, texto alternativo de imágenes, densidad de enlaces internos y profundidad de contenido. El linter tiene 77 pruebas. El blog tiene 29 publicaciones. El linter tiene más pruebas que contenido tiene el blog.

Ingeniería: Todo lo que Persiste

Esquemas de bases de datos, contratos de API, configuraciones de hooks y manifiestos de despliegue reciben tratamiento completo de ingeniería. Estas decisiones se acumulan. Un esquema diseñado en una sesión de vibraciones se convierte en una pesadilla de migración cuando tres años de datos se acumulan sobre él.³

Ingeniería: Todo lo Relacionado con Seguridad

El código generado por IA refleja la postura de seguridad de sus datos de entrenamiento, que incluyen tutoriales y respuestas de Stack Overflow que rutinariamente omiten autenticación, validación de entrada y manejo de errores por brevedad.⁴ Mis hooks capturan parte de esto (el guardián de seguridad de git señala adiciones de .env, archivos de credenciales y force pushes), pero el código crítico para la seguridad recibe revisión manual de todas formas.

---

El Problema de la Brecha de Comprensión

El patrón más peligroso del vibe coding no es el código malo. Es el código que funciona hasta que deja de funcionar.

Generé una capa de caché para mi sistema de traducción i18n. Funcionó perfectamente para contenido en inglés. Cuando agregué coreano y chino tradicional, la generación de claves de caché produjo colisiones silenciosamente para ciertos puntos de código Unicode. La depuración tomó cuatro horas porque nunca había leído la función de generación de claves de caché. El código era correcto para ASCII, que es todo lo que los datos de entrenamiento enfatizaban.⁵

La lección: los sistemas creados con vibe coding fallan en los bordes que los datos de entrenamiento subrepresentan. Si sus usuarios operan en esos bordes (scripts no latinos, alta concurrencia, condiciones de red inusuales), las implementaciones con vibe coding conllevan riesgos ocultos.

---

La Puerta de Revisión

Cada pieza de código destinada a producción en mi sistema pasa por una puerta de revisión, ya sea que lo haya escrito yo o Claude Code:

1. Leer cada línea. El código generado es un pull request de un colaborador no confiable. Revíselo como tal.
2. Verificar el manejo de errores. Compruebe que las rutas de error reflejen requisitos del dominio, no patrones genéricos de try-catch.
3. Auditar dependencias. La IA resuelve cada prompt de forma aislada, importando cualquier librería que resuelva la solicitud inmediata. Después de 50 prompts, podría tener tres librerías de fechas y dos clientes HTTP.
4. Agregar pruebas. El código generado rara vez cubre casos límite específicos de su dominio.
5. Verificar la seguridad. Ejecute análisis estático. Verifique autenticación, autorización y validación de entrada.⁶

La puerta de revisión no es opcional. Es la diferencia entre usar la IA como un multiplicador de fuerza y usarla como una muleta.

---

La División de la Industria

La ingeniería de software se está dividiendo en dos niveles. El primero usa la IA como un multiplicador de fuerza: generando código repetitivo, explorando espacios de solución y acelerando la implementación de patrones bien comprendidos mientras mantiene estándares de comprensión y calidad. El segundo genera aplicaciones completas sin entender el resultado, intercambiando velocidad a corto plazo por fragilidad a largo plazo.⁷

La división refleja el desarrollo web temprano. Los constructores de plantillas como Squarespace democratizaron la publicación web y produjeron millones de sitios funcionales. El desarrollo web profesional persiste porque los sistemas de producción requieren calidad, seguridad y mantenibilidad que las plantillas no pueden proporcionar.

Opero en ambos niveles deliberadamente. Mi sistema de hooks y puertas de calidad existe específicamente para capturar el momento en que el trabajo del segundo nivel necesita graduarse a los estándares del primer nivel. Los 86 hooks no son burocracia. Son el sistema inmunológico que me permite hacer vibe coding libremente mientras evita que el trabajo creado con vibraciones llegue a producción sin revisión.

---

Conclusiones Clave

Para ingenieros que usan IA a diario: - Trace una línea explícita entre exploración y producción; haga vibe coding libremente con trabajo desechable, pero aplique puertas de revisión antes de que cualquier cosa toque a los usuarios o persista - Construya protecciones automatizadas (hooks, linters, puertas de calidad) en lugar de depender solo de la disciplina; la disciplina falla a las 2 AM, los hooks no

Para gerentes de ingeniería: - Establezca límites claros entre código con calidad de prototipo y código con calidad de producción; los prototipos creados con vibe coding que se filtran a producción crean una nueva categoría de deuda técnica - Evalúe la productividad por resultados (funciones entregadas, errores por función, satisfacción del usuario) en lugar de métricas de velocidad; el vibe coding infla el conteo de líneas sin mejorar proporcionalmente los resultados

---

Referencias