En la portada de este sitio dice que no nos gusta el vibe coding. Aquí explico de dónde viene el término, por qué creo que es una mala práctica cuando se trata de software de negocio y cómo trabajo yo en su lugar.
Un poco de historia
El término lo popularizó Andrej Karpathy, cofundador de OpenAI y exdirector de IA en Tesla, en una publicación de febrero de 2025. Lo describió como una forma de programar en la que uno se deja llevar por la corriente: le pide cosas a un modelo, acepta lo que propone, ejecuta, y si hay un error, lo pega de vuelta y sigue, sin revisar el código a fondo. Él mismo lo presentó como algo útil para proyectos desechables de fin de semana.
La idea se volvió tan popular que a finales de ese año ya era una de las palabras del momento. El problema es que un término pensado para experimentos se empezó a usar para construir sistemas reales.
Qué es, en sentido estricto
Vibe coding no es "programar con ayuda de la IA". Es aceptar código generado por IA sin leerlo ni entenderlo. La diferencia importa: usar un asistente y revisar cada cambio es ingeniería; confiar en que funciona porque la pantalla se ve bien, no lo es.
Por qué creo que está mal
- Bugs sutiles. El código parece correcto y pasa la prueba rápida, pero falla en el caso límite: el redondeo de un impuesto, la devolución parcial, la fecha de cierre.
- Huecos de seguridad. Permisos que no se validan, datos que se exponen, consultas armadas con texto sin proteger. Un modelo no sabe qué es sensible en tu empresa.
- Deuda técnica. Cada fragmento aceptado a ciegas se suma a una base de código sin criterio común, difícil de cambiar y más difícil de migrar.
- Código que nadie sabe mantener. Si nadie lo entendió al escribirlo, nadie lo entenderá cuando haya que modificarlo.
- Nadie responde. Cuando algo falla en producción, no hay una persona que sepa por qué. Y entender el porqué es justo lo que se necesita para arreglarlo.
Qué implica en un ERP
Un ERP no es una página de prueba. Ahí viven tu inventario, tu facturación, tu contabilidad y los datos de tus clientes. Un error no se queda en la pantalla: se convierte en una existencia mal calculada, en una factura incorrecta o en un cierre de mes que no cuadra, y a veces nadie lo nota hasta semanas después.
Además, Odoo se actualiza de versión. Un módulo que nadie entiende es un módulo que hay que reescribir, o que bloquea la actualización, justo cuando más se necesita avanzar.
Mi postura: IA sí, pero con criterio
No estoy en contra de la inteligencia artificial. La uso todos los días y me hace más rápido. Lo que rechazo es soltar el control. Mi forma de trabajar es otra:
- Primero la especificación. Se acuerda qué debe hacer el módulo antes de escribir una línea (desarrollo guiado por especificaciones, o SDD).
- Pasos cortos. Los agentes analizan, programan y prueban en cambios pequeños que se pueden leer completos.
- Leo y entiendo cada cambio. Si no puedo explicar por qué funciona, no entra.
- Pruebas. Lo que importa del negocio queda cubierto por pruebas automatizadas, no por la fe en que "se veía bien".
- Respondo por cada entrega. Hay una persona que decide, revisa y da la cara.
La IA acelera el trabajo; no reemplaza el criterio ni la responsabilidad. Si quieres que revisemos juntos un proyecto de Odoo, con código que alguien entienda y pueda mantener, escríbeme.