El vibe coding no es desarrollo de software

5 min de lectura

La demo funciona. El sistema no.

13.04.2026, Por Stephan Schwab

El vibe coding parece magia en una demo y falla con sistemas reales. El problema no es la IA. El problema es que una persona no técnica no puede distinguir de forma fiable entre "corrió" y "va a seguir corriendo". El hype vende la fantasía de saltarse el desarrollo de software. El miedo vende la idea de que los desarrolladores ya no hacen falta. Las dos cosas son falsas.

El vibe coding no es desarrollo de software

“Vibe coding” es el apodo nuevo para un impulso viejo: describes lo que quieres, aparece código, lo ejecutas, lo envías.

Cuando sale bien, se siente como trampa. Cuando sale mal, sale mal con ruido.

El patrón es predecible: alguien no técnico confunde un prototipo que funciona con un sistema que aguanta. Luego descubre por qué existe el desarrollo de software como disciplina.

Qué es realmente el vibe coding

"Un prototipo responde: ¿se puede? Un sistema responde: ¿podemos vivir con esto?"

Vibe coding es desarrollo guiado por prompts. Dices el comportamiento. La IA escribe código. Lo ejecutas. Ajustas el prompt hasta que la pantalla “se ve bien”.

No es una tontería. Es una forma rápida de explorar. También es una forma rápida de crear código sin columna vertebral.

La mayoría de las demos famosas pasan en un entorno seguro:

  • Una máquina.
  • Un camino feliz.
  • Un conjunto de datos.
  • Un usuario.
  • Un momento.

Los sistemas reales no te dan ese lujo.

Por qué se siente como magia

La IA es buena escribiendo el tipo de código que los desarrolladores escriben todos los días:

  • Código pegamento.
  • Endpoints CRUD.
  • Estructura de UI.
  • Tests como punto de partida.
  • Refactors razonables.

La IA también es, en términos prácticos, una herramienta de reconocimiento de patrones. Tiende a seguir patrones que vio en su material de entrenamiento. Puede extrapolar, y cada vez lo hace mejor, pero su salida por defecto se parece a lo que es común.

Eso importa porque lo difícil suele ser elegir qué patrón encaja con tu sistema. Esa elección es diseño de sistemas: decidir tradeoffs, pensar en modos de fallo y definir qué optimizas. La mayoría de las personas no técnicas nunca han hecho ese trabajo, así que no pueden detectar de forma fiable cuándo la IA eligió un patrón plausible y popular que no sirve para sus restricciones.

Usada por un desarrollador, acelera. Quita fricción. Acorta el ciclo de feedback. Eso es progreso.

Pero no elimina la necesidad de juicio. Elimina la necesidad de teclear.

Para más contexto: Why We’ve Tried to Replace Developers Every Decade.

Dónde se rompe para personas no técnicas

El enfoque “vibe” se rompe siempre en los mismos sitios. La lista no es glamorosa. Ese es el punto.

1) Requisitos no son un prompt

Un prompt es un deseo. Un requisito es un acuerdo.

“Haz un login” suena simple hasta que respondes preguntas básicas:

  • ¿Email o usuario?
  • ¿MFA?
  • ¿Política de bloqueo?
  • ¿Recuperación de contraseña?
  • ¿Duración de sesión?
  • ¿Auditoría?

Un desarrollador no solo implementa respuestas. Un desarrollador arrastra esas preguntas a la mesa antes de que cuesten caro.

2) El diseño de sistemas se esconde hasta que pega

Los prototipos funcionan porque ignoran arquitectura. Producción te castiga.

Modelo de datos. Límites transaccionales. Caché. Trabajos en background. Rate limits. Idempotencia. Separación por cliente. Nada de eso aparece en una demo de UI.

Si quieres un recordatorio corto de por qué las organizaciones terminan construyendo sistemas que reflejan su estructura de comunicación, lee el texto original de Melvin Conway: “How Do Committees Invent?”

Por eso “funciona en mi máquina” existe. Y por eso sigue pasando.

3) Manejo de errores no es decoración

El código “vibe” suele clavar el camino feliz. Los bordes se convierten en corrupción silenciosa.

  • El proveedor de pagos responde tarde.
  • Se cae la red después del cobro.
  • Dos usuarios guardan a la vez.
  • Alguien reintenta porque el spinner se quedó colgado.

Si no sabes cómo se ve una tormenta de reintentos, vas a construir una.

4) La seguridad no se anuncia

Una persona no técnica no puede hacer threat modeling de su propio sistema. No por falta de inteligencia. Por falta de checklist.

SQL injection. Control de acceso roto. Secretos en logs. SSRF. Riesgos de dependencias.

Los fallos de seguridad parecen éxito hasta el momento en que alguien con habilidades rompe el juguete.

Un punto de partida útil es la página de OWASP Top 10:2025.

5) Mantener el código es el producto

Cuando un prototipo se usa, deja de ser un juguete. Se convierte en responsabilidad.

Las dependencias se actualizan. Los bugs se priorizan. Alguien recibe alertas. El sistema necesita monitoreo, backups, migraciones y una forma de desplegar sin rezar.

Para una visión clara de sostenibilidad: The Engine of Predictable Software Delivery.

El ciclo de hype y miedo

Los proveedores venden hype porque la esperanza compra más rápido que la verdad.

Algunos líderes venden miedo para justificar recortes. Algunos desarrolladores venden miedo para proteger estatus. Todos ganan a corto plazo. La organización pierde a largo plazo.

La IA cambia el mercado. Cambia cómo se hace el trabajo. No borra la naturaleza del trabajo.

Fred Brooks lo dijo hace décadas: la complejidad accidental puede bajar; la esencial se queda. Sigue siendo el marco correcto.

Vale la pena leer el original: Frederick P. Brooks, “No Silver Bullet” (PDF).

Cómo usar vibe coding sin incendiar la casa

Si lideras un equipo y quieres los beneficios, deja de intentar convertir a gente no técnica en desarrolladores instantáneos. Usa IA para quitar fricción, no responsabilidad.

  • Declara el límite: prototipo vs producto. Los prototipos tienen fecha final. Los productos tienen dueños.
  • Acompaña el trabajo con un desarrollador: el prompt se vuelve especificación, el código se vuelve revisable.
  • Tests como puerta: si no hay tests, no hay afirmación de corrección.
  • Pipeline temprano: “lo metemos a CI después” es la frase más cara del desarrollo.
  • Instrumenta la realidad: logs, métricas, trazas. Sin visibilidad no hay gobernanza.

Aquí también importa la gobernanza ligera. No se trata de microgestionar. Se trata de hacer visible la realidad. Ver How to Govern Without Control.

Si quieres mantener a liderazgo cerca de la realidad sin ahogar a todo el mundo en reuniones, Caimito Navigator hace la parte aburrida: bitácoras diarias, síntesis semanal y señales sobre las que puedes actuar.

La idea central

El vibe coding es excelente para explorar. Es pésimo para fingir que el desarrollo de software es opcional.

Usa las herramientas. Disfruta la velocidad. Mantén la disciplina.

Contacto

Hablemos de tu situación real. ¿Quieres acelerar la entrega, quitar bloqueos técnicos o validar si una idea merece más inversión? Escucho tu contexto y te doy 1-2 recomendaciones prácticas. Sin compromiso ni discurso comercial. Confidencial y directo.

Empecemos a trabajar juntos

Newsletter: Sin teatro metodológico. Sin relleno.
Ideas reales sobre entrega de software y liderazgo.

×