Vibe coding: ¿realmente es tan malo?

Hasta donde recuerdo, mi primera experiencia programando fue con BASIC en un Atari XE, en algún momento de los años ochenta.

Lo hacía como hobby. En aquellos días, al menos en México, programar una computadora era más una curiosidad que un potencial perfil profesional.

Mis primeras sesiones consistieron en poco más que transcribir, carácter por carácter, las interminables listas de código que aparecían en el manual del propietario del Atari. En ese momento, no entendía qué significaban aquellos comandos ni por qué debían escribirse exactamente de esa manera.

Pero al final, tecleabas RUN y la magia sucedía.

De aquel montón de números, letras y símbolos aparentemente sin sentido nacía un pequeño juego. Era algo primitivo, por supuesto. Pero verlo aparecer en la pantalla después de haberlo escrito con tus propias manos, era fascinante.

De ahí nació una tenue pero firme afición por las computadoras.

En la preparatoria tuve mi primera experiencia un poco más formal programando en Turbo Pascal para MS-DOS. Después, ya en la universidad, vinieron Borland C, C++, Delphi, Visual Basic 6 y algunos otros lenguajes y herramientas de la época.

Mención honorífica para Assembly x86, que probablemente fue responsable de más de una noche sin dormir.

El tiempo pasó y, por azares del destino, nunca me dediqué profesionalmente al desarrollo de software. Fuera de algunos pequeños sistemas construidos en Visual Basic 6 para comunicarse con Wonderware —software HMI ampliamente utilizado en ambientes industriales—, mi carrera tomó otro rumbo.

Me fui por el área de infraestructura: redes, perímetro, servidores, datacenter, seguridad y operación. Ya saben, el fierro.

Años después, como fundador y director de IT Experts, de vez en cuando aparecía algún cliente con un requerimiento de desarrollo. Cuando sucedía, buscábamos resolverlo en conjunto con algún partner estratégico.

Casi siempre salía bien.

Casi.

Como es de esperarse, resulta complicado depender de terceros para resolver componentes importantes de un proyecto. Los tiempos, las prioridades y los estándares de calidad no siempre coinciden. Un cambio aparentemente sencillo podía convertirse en una cadena de reuniones, correos, cotizaciones, aclaraciones, límites de alcance y retrabajos.

Por esa razón, aunque existían oportunidades, nunca empujamos demasiado esa línea de negocio.

El tiempo siguió pasando.

Llegó 2026.

Los agentes de inteligencia artificial comenzaron a reclamar su protagonismo y muchos de mis conocidos que llevan años dedicándose profesionalmente al desarrollo empezaron a observarlos con cierta preocupación.

Yo los vi, nuevamente, con curiosidad.

La misma curiosidad con la que veía BASIC en aquel Atari XE.

Después de darle muchas vueltas, decidí emprender un proyecto serio apoyado únicamente en mi dirección, mi experiencia y múltiples agentes de IA.

No se trataba de construir una landing page, una demostración desechable o una aplicación que solamente funcionara bien durante una presentación. El objetivo era desarrollar un sistema real: con frontend, backend, base de datos, RBAC, sistema de notificaciones, integraciones vía API con otros sistemas, seguridad, telemetría, ambientes separados y una ruta formal hasta producción.

Tampoco utilicé a las diferentes inteligencias artificiales como una colección de chatbots intercambiables. A cada una le asigné una función, responsabilidades y límites, como lo haría con los integrantes de un equipo humano.

Funcionó endemoniadamente bien.

Pero hay una precisión importante: no funcionó porque la inteligencia artificial haya convertido mágicamente una idea en software.

Funcionó porque hubo dirección.

Antes de implementar se definió qué debía construirse. Se especificó la arquitectura, se modelaron los datos, se establecieron responsabilidades y se discutieron las decisiones importantes. Durante el desarrollo hubo revisión cruzada, pruebas, criterios de aceptación y control de cambios.

También existieron ambientes de QAS y preproducción. Los hallazgos regresaban al proceso de implementación, se corregían y se volvían a validar. Ningún agente tenía autoridad para decidir por sí mismo que el sistema estaba listo para producción.

La IA escribía código, proponía soluciones y encontraba problemas. La responsabilidad seguía siendo humana.

En ese sentido, el proyecto no eliminó la ingeniería de software. Por el contrario, nos obligó a ejercerla con bastante disciplina.

El resultado llegó a producción en menos de tres semanas.

Tradicionalmente, un proyecto de esa naturaleza habría requerido tranquilamente dieciocho meses: contratación y coordinación de especialistas, innumerables reuniones en Teams, cientos de cadenas de correo, minutas, dependencias entre equipos, malentendidos, cambios de alcance y el inevitable retrabajo que termina convirtiéndose en un dolor de cabeza para cualquier Project Manager.

En este caso, el tiempo entre una decisión y su implementación podía medirse en minutos.

Una observación arquitectónica podía convertirse en una tarea concreta; la tarea podía implementarse, probarse y regresar para revisión durante la misma sesión de trabajo. Si una propuesta no cumplía con el objetivo, se descartaba sin semanas de desgaste político ni reuniones para justificar el cambio.

La velocidad no surgió únicamente de que la IA pudiera escribir código rápidamente. Surgió de reducir drásticamente la fricción de coordinación.

Eso me llevó a pensar en el concepto de vibe coding y en la reputación, no siempre favorable, que ha adquirido.

Y algo de razón existe.

El vibe coding puede ser peligroso cuando nadie entiende realmente qué se está construyendo. Cuando se acepta cualquier respuesta porque «parece funcionar». Cuando no existen arquitectura, pruebas, controles de seguridad, revisión del código ni una persona capaz de determinar si el resultado es correcto.

Una aplicación puede verse muy bien y, al mismo tiempo, ser una bomba de tiempo.

Pero utilizar inteligencia artificial para desarrollar software no implica necesariamente abandonar las buenas prácticas. La IA también puede trabajar dentro de un proceso formal, con responsabilidades definidas, revisión cruzada, control de calidad y autoridad humana.

Eso ya no se parece demasiado a pedirle a un chatbot que improvise una aplicación.

Se parece más a dirigir un equipo de ingeniería extraordinariamente rápido.

En los años ochenta yo no entendía todavía todo lo que escribía en aquel Atari, pero aprendí a reconocer el momento en que la magia sucedía.

En 2026 la sensación fue extrañamente parecida, con una diferencia fundamental: esta vez tenía casi treinta años de experiencia profesional para distinguir entre una demostración vistosa y un sistema capaz de llegar a producción.

¿Mi conclusión?

No hay que tener miedo de las nuevas tecnologías.

Hay que tener miedo de no desarrollar el criterio necesario para utilizarlas.

La inteligencia artificial no reemplazó la ingeniería de software. Nos permitió ejercerla con una velocidad que hace apenas unos años habría parecido absurda.

El vibe coding puede ser peligroso cuando nadie sabe qué se está construyendo, cómo validarlo o cuándo detenerse. Pero cuando detrás existen experiencia, arquitectura, controles y responsabilidad, quizá ya no deberíamos llamarlo vibe coding. ¿Alguien recuerda las herramientas CASE?

Quizá simplemente sea la nueva manera de hacer ingeniería. Y ya sea que nos guste, o no nos guste, esto llegó para quedarse.