VibeCoders vs Software Engineers: la diferencia aparece en producción

Hace tres años, mostrar una aplicación funcionando en dos días era una señal de talento. Hoy es una tarde con un modelo bien preguntado. La demo dejó de ser evidencia de nada, y eso cambia la pregunta que un cliente debería hacer al contratar software.

La pregunta ya no es si alguien puede construirlo. Es quién responde cuando falle.

Qué es en realidad el vibe coding

El término se volvió popular para describir una forma de trabajo: le describes a un modelo lo que quieres, aceptas lo que produce, lo pruebas por encima y sigues. No lees el código con detalle. Confías en que el resultado se ve bien y hace lo que pediste en el camino feliz.

Y funciona. Funciona sorprendentemente bien para prototipos, para scripts internos, para validar una idea un sábado. No tenemos ningún interés en despreciar eso: nosotros mismos trabajamos así cuando estamos explorando y todavía no hay nada que sostener.

El problema no es la herramienta. El problema es cuando ese modo de trabajo se factura como si fuera ingeniería, y el cliente se entera de la diferencia seis meses después.

Dónde se rompe

El código generado sin criterio no falla en la demo. Falla en los bordes, y los bordes son justo donde vive el negocio.

En la concurrencia. Un endpoint que descuenta inventario se ve correcto cuando lo pruebas tú solo. Con doscientas peticiones simultáneas en una promoción, vendes lo que no tienes. Nadie lo detecta leyendo el código rápido, porque el código “se ve bien”: el bug está en lo que no se escribió, en la transacción y el bloqueo que faltan.

En el dinero. Un cobro sin idempotencia procesa dos veces cuando el cliente pierde señal y reintenta. En una demo es invisible. En producción es una devolución, un chargeback y una conversación incómoda.

En los datos. Un modelo genera con gusto una consulta que trae todo y filtra en memoria. Con mil registros vuela. Con dos millones tumba el servidor, y para entonces ya hay clientes encima.

En la seguridad. El caso más común no es una inyección exótica: es un endpoint que confía en el identificador que manda el cliente y devuelve datos de otra empresa. Funciona perfecto en todas las pruebas, porque todas las pruebas se hicieron con un solo usuario.

Ninguno de estos errores lo comete la IA por ser mala escribiendo código. Los comete porque nadie le hizo la pregunta correcta, y para hacer la pregunta correcta hay que haber estado antes en el incidente.

El trabajo que ocurre antes de la primera línea

Aquí está la parte que el vibe coding no se salta por descuido, sino porque su promesa es justamente saltársela: con un modelo tienes código en segundos, así que empezar a construir se vuelve más barato que pensar qué construir.

En un proyecto serio, antes de escribir código pasan cuatro cosas.

Discovery. Sentarse con quien vive el problema y entender la operación real, no la que está en el organigrama. Quién hace qué, dónde se traba el proceso, qué se resuelve hoy a mano. La mitad de los requerimientos que un cliente trae al inicio cambian cuando alguien pregunta por qué.

Levantamiento de requerimientos. Convertir “necesitamos un módulo de pedidos” en algo ejecutable: qué estados tiene un pedido, quién puede cambiarlos, qué pasa con una devolución parcial, qué se hace si el cliente cancela después de despachado. Estas preguntas no son burocracia. Son el 80% de la complejidad del sistema, y si no se responden ahora se responden solas, mal, dentro del código.

Planeación. Qué se construye primero y por qué. Un plan por fases donde cada una deja algo funcionando en producción, no seis meses de trabajo invisible que se integran al final. Con estimaciones que alguien sostiene, no un número puesto para ganar la propuesta.

Diseño. Flujos y pantallas conectados a un sistema, no pantallas sueltas. Y diseño técnico: el modelo de datos, los límites entre módulos, qué se expone como API, cómo se maneja el estado. En un proyecto de software a la medida esto es la mitad del trabajo real. Estas decisiones se toman una vez y se pagan durante años.

Un modelo de lenguaje puede ayudar en cada una de estas etapas, y lo usamos ahí también. Lo que no puede es tenerlas por ti. Si le pides código sin haber hecho este trabajo, te va a dar código: coherente, ordenado y construido sobre supuestos que nadie validó.

Cuando el proyecto se cae a los seis meses, casi nunca es por una mala línea de código. Es porque nadie definió qué pasaba con la devolución parcial.

La seguridad no se autocompleta

Este es el punto donde más nos preocupa la diferencia, porque las fallas de seguridad no se manifiestan como un error. Se manifiestan como nada, hasta que alguien las encuentra.

Un modelo genera código funcionalmente correcto y silenciosamente inseguro con la misma facilidad, porque nadie le dijo cuál es el modelo de amenazas. Y el modelo de amenazas no sale del código: sale de entender qué datos manejas, quién los quiere y qué pasa si se filtran.

Lo que revisamos, siempre, y no se delega:

• Autorización, no solo autenticación. Saber quién eres es lo fácil. Lo difícil es verificar en cada operación que ese usuario puede tocar ese recurso, incluso cuando el identificador viene del cliente. La mayoría de las filtraciones reales que hemos visto son esto, no criptografía rota.
• Datos personales con criterio. Qué se guarda, por cuánto tiempo, quién lo consulta y qué queda registrado. En Colombia hay una ley de protección de datos que aplica desde el primer usuario, y en los sectores en los que trabajamos eso no es una casilla: es una auditoría.
• Secretos y configuración. Credenciales fuera del repositorio, rotación posible, permisos mínimos por servicio. Suena obvio y sigue siendo el hallazgo más común cuando revisamos un proyecto heredado.
• Dependencias. Cada paquete que entra es código de terceros con acceso a lo mismo que tu aplicación. Revisamos qué se instala y por qué, y mantenemos un inventario de lo que hay que actualizar cuando salga un CVE.
• Registro y trazabilidad. Si algo pasa, tiene que quedar rastro suficiente para reconstruir qué ocurrió y quién lo hizo. Sin eso, un incidente es una discusión de opiniones.
• Revisión adversarial antes de producción. Alguien mirando el cambio con la pregunta “¿cómo abuso de esto?”, que es una pregunta distinta a “¿esto funciona?”.

Nada de esto es exótico ni caro. Es rutina para un equipo que ha trabajado en salud y en el sector financiero, y es parte de cómo abordamos cualquier proyecto de software empresarial, y es exactamente lo que no aparece cuando el software se construye a punta de aceptar sugerencias.

La diferencia real: quién carga con el riesgo

Un ingeniero de software no es alguien que escribe código mejor que un modelo. En muchos casos ya no lo escribe mejor, y pretender lo contrario es negar lo evidente.

Lo que hace un ingeniero es otra cosa:

• Decide lo difícil de revertir. Si la base de datos se aísla por fila, por esquema o por instancia. Si el estado se deriva de eventos o se guarda en un campo. Estas decisiones no se cambian con un prompt seis meses después: se cambian con una migración cara.
• Sabe qué preguntar antes de construir. Cuántas transacciones por segundo el peor día, qué pasa si el proveedor de pagos no responde, quién puede ver los datos de quién. La calidad del software depende más de estas preguntas que del lenguaje elegido.
• Reconoce lo que no ve. La experiencia sirve para desconfiar de lo que parece terminado. Un desarrollador con años en sistemas transaccionales lee un flujo y sabe dónde va a doler, porque ya le dolió.
• Responde por la entrega. Cuando algo se cae un viernes a las seis, la herramienta no contesta el teléfono. Contesta una persona, y esa persona tiene que entender lo que se desplegó.

Entonces, ¿usamos IA?

Todos los días, y bastante.

La usamos para el código repetitivo, para explorar tres alternativas de diseño en una hora en vez de en una semana, para ampliar la cobertura de pruebas y encontrar casos borde, para documentar y refactorizar código legado. Nos hace mucho más rápidos en la parte mecánica del trabajo.

Lo que no hacemos es dejarle las decisiones. La arquitectura la definimos nosotros y te explicamos por qué. Todo lo que llega a producción pasa por revisión humana, sin excepción. Las reglas de negocio críticas y el manejo de datos sensibles se diseñan, no se autocompletan. Y si algo falla, respondemos nosotros.

Esa frontera no es purismo. Es la única forma de que la velocidad de la IA no se pague después con intereses.

La deuda que no se ve en la factura

Hay un patrón que estamos viendo repetirse en clientes que llegan después de un proyecto barato: el software existe, se ve bien y hace lo que prometía. Pero nadie sabe por qué está construido así, no hay pruebas, las decisiones no están documentadas y cada cambio nuevo rompe dos cosas viejas.

Reconstruir eso cuesta más que haberlo hecho bien la primera vez. No porque el código generado sea malo, sino porque no hubo nadie detrás sosteniendo la coherencia del sistema mientras crecía.

El ahorro fue real. La deuda también.

Cómo elegir con quién construir

Si estás evaluando a quién contratarle software, estas preguntas separan rápido:

1. ¿Qué decisiones de arquitectura tomaron y por qué? Si no hay respuesta, no hubo decisión.
2. ¿Qué pasa cuando la carga se multiplica por diez? Debería haber un número, no un “escala bien”.
3. ¿Cómo se revisa lo que llega a producción? Que exista un humano en el circuito, con nombre.
4. ¿De quién es el código y qué pasa si me voy? Si la respuesta es incómoda, ya sabes.
5. ¿Qué van a hacer con IA y qué no? Que lo digan de frente. Nosotros lo tenemos escrito en la landing.

Ninguna de estas preguntas es sobre el lenguaje, el framework o la herramienta. Son sobre criterio, y el criterio es lo que todavía se contrata.

Lo que creemos

La IA no reemplaza la ingeniería de software: reemplaza la parte de la ingeniería de software que nunca fue lo valioso. Escribir la línea siempre fue el medio. Lo valioso era saber cuál línea, por qué, y qué se rompe si cambia.

Somos rápidos porque usamos estas herramientas. Somos confiables porque llevamos más de una década construyendo sistemas que no se pueden caer, en telco, en salud y en el sector financiero, donde un error no es un ticket sino una consecuencia real.

Las dos cosas juntas son la propuesta. Ninguna de las dos sola sirve de mucho.