No es vibe coding: es diseño asistido por IA

No es vibe coding: es diseño asistido por IA

En los últimos meses he visto a muchos programadores —especialmente desarrolladores con trayectoria— posicionarse abiertamente en contra del llamado vibe coding. La crítica suele ser dura y, en muchos casos, legítima. Sin embargo, creo que gran parte del debate parte de una confusión conceptual.

Llevo más de media vida programando y, lejos de sentirme desplazado por la IA, la uso de forma activa todos los días. No como sustituto, sino como amplificador de mi trabajo. Y la diferencia está en el rol que uno asume.


Programar nunca fue solo escribir código

Desde hace años dejé de ver la programación como un ejercicio de teclear líneas. Mi valor —y el de muchos ingenieros senior— está en:

  • diseñar soluciones,
  • modelar dominios,
  • evaluar trade-offs,
  • anticipar problemas,
  • tomar decisiones técnicas.

El código es una consecuencia de esas decisiones, no el objetivo final.

Por eso, cuando uso IA, no le pido que piense por mí. Yo defino:

  • qué se quiere construir,
  • cómo debe hacerse,
  • bajo qué restricciones,
  • y por qué ciertas decisiones son mejores que otras.

La IA ejecuta, propone alternativas, acelera. Pero la dirección sigue siendo humana.


El problema no es la IA, es la delegación del criterio

Gran parte del rechazo al vibe coding nace al ver prácticas como:

  • copiar y pegar código sin entenderlo,
  • aceptar sugerencias sin cuestionarlas,
  • construir sistemas sin modelo mental previo.

Eso no es ingeniería asistida por IA. Es ausencia de diseño, con o sin IA.

Cuando alguien escribe:

“Hazme un backend completo en X”
y lo sube a producción sin comprenderlo, el problema no es la herramienta. El problema es haber delegado decisiones que no deberían delegarse.


Delegar ejecución ≠ delegar decisión

Para mí, la línea es clara:

  • La decisión es mía.
  • La responsabilidad es mía.
  • El diseño es mío.

La IA:

  • acelera la implementación,
  • ayuda a explorar ideas,
  • reduce fricción mecánica,
  • propone variantes que puedo aceptar o descartar.

Pero nunca actúa como arquitecto principal.

Dicho de forma simple:

Delego ejecución, no criterio.


Por qué a algunos programadores sí les incomoda

Creo que hay varias razones, y no todas son técnicas:

  1. Identidad profesional
    Durante años, el valor estuvo en memorizar APIs, sintaxis y patrones. La IA reduce esa ventaja.
  2. Miedo a la degradación del oficio
    Ver código funcionando sin entendimiento real genera alarma. Con razón.
  3. Experiencias pasadas con “soluciones mágicas”
    Frameworks, generators, low-code… ya hemos visto este ciclo antes.

Pero ninguna de esas razones invalida el uso responsable de IA por parte de ingenieros que sí saben diseñar.


Contexto importa

La IA funciona muy bien para:

  • prototipos,
  • exploración,
  • scripts,
  • automatizaciones,
  • acelerar boilerplate.

Y requiere mucho más cuidado en:

  • sistemas críticos,
  • backends complejos,
  • concurrencia,
  • seguridad,
  • compliance,
  • arquitectura a largo plazo.

Negar cualquiera de los dos extremos es simplificar demasiado el problema.


Conclusión

No todo uso de IA es vibe coding.
No toda crítica a la IA es resistencia al cambio.

La postura más sólida hoy no es binaria, sino ingenieril:

La IA no sustituye al diseñador. Potencia al que ya lo es.

Si tu valor está en pensar sistemas, la IA no te quita espacio.
Te da velocidad.

Y eso, bien usado, es una ventaja real.

I'm a Full Stack Engineer with more than 10 years of experience. I love Statistics 📊, Tacos 🌮 and Pizza 🍕. My favorite programming language is Python 🐍 and i have a passion for Finance specifically with Algorithmic Trading.