Vibe coding: cuando el software llega al mercado antes que la ingeniería

El vibe coding ha reducido de manera radical la distancia entre una idea y una aplicación funcional. Una persona puede describir un problema, conversar con varios agentes, conectar una base de datos, desplegar una interfaz y publicar una primera versión en cuestión de días. Ese cambio no debe mirarse con desprecio. Muchas soluciones valiosas surgirán precisamente de profesionales que conocen profundamente una industria, pero que nunca habrían podido reunir el capital, el equipo o el tiempo necesarios para construir software por los medios tradicionales. La inteligencia artificial está permitiendo que conocimiento especializado, antes atrapado en una libreta o una conversación, se convierta en producto.

El problema aparece cuando esa velocidad modifica nuestra percepción de la madurez. Durante décadas, la complejidad de construir software actuó como una barrera imperfecta, pero útil. Para alcanzar una plataforma operativa, alguien debía resolver redes, identidad, persistencia, despliegue, monitoreo y recuperación. El proceso podía estar lleno de defectos, pero obligaba a atravesar disciplinas que dejaban conocimiento acumulado dentro del equipo. Hoy, una interfaz convincente, una API funcional y una arquitectura desplegada pueden aparecer antes de que exista una comprensión real de cómo se comportará el sistema bajo carga, cómo separará los datos de cada cliente o qué ocurrirá cuando una dependencia crítica deje de responder.

Existe un antecedente evidente. WordPress, Microsoft Access y, más tarde, las plataformas no-code y low-code permitieron durante años que personas sin una formación profunda en ingeniería construyeran aplicaciones útiles. Muchas resolvieron problemas reales. Otras crecieron como estructuras de Frankenstein: formularios, automatizaciones, plugins y bases de datos ensamblados hasta convertirse en sistemas críticos que nadie se atrevía a modificar. La diferencia es que aquellas herramientas trabajaban dentro de límites relativamente visibles. El usuario combinaba bloques, plantillas y componentes reconocibles. La precariedad podía quedar oculta, pero la herramienta rara vez fingía haber producido una arquitectura completa.

Los agentes alteran esa relación. No solo generan pantallas y flujos. Escriben backend, configuran redes, crean manifiestos de infraestructura, redactan pruebas, seleccionan bibliotecas y producen documentación que describe el conjunto como si hubiese existido una decisión arquitectónica coherente desde el inicio. La aplicación no parece construida mediante piezas limitadas. Parece haber sido diseñada por un equipo capaz de comprender cada capa.

Ese es el salto. El no-code ocultaba complejidad. El vibe coding puede simular que la complejidad fue comprendida.

La apariencia de madurez se ha vuelto barata. Una empresa recién creada puede mostrar una aplicación con estética impecable, documentación abundante y una lista de funciones propia de un proveedor consolidado. Esa empresa puede ser extraordinaria. También puede haber ensamblado una superficie comercial sobre una arquitectura que nadie dentro del equipo sabe explicar de extremo a extremo. Desde fuera, ambas realidades pueden resultar indistinguibles.

El vibe coding no está produciendo únicamente software inseguro. Está produciendo una población más difícil de evaluar: productos técnicamente sólidos, productos frágiles y productos que funcionan solo dentro de un rango estrecho de condiciones, todos revestidos por una calidad visual semejante. El comprador ya no puede inferir profundidad desde la experiencia de la demostración. Tampoco puede asumir que una interfaz refinada implica una ingeniería equivalente.

Ese desplazamiento cambia la pregunta central. Ya no importa solamente quién escribió el código o cuánto tiempo tomó construirlo. Importa si alguien comprende las propiedades que el sistema debe conservar cuando la realidad deja de parecerse al escenario preparado para venderlo.

La lógica del negocio no contiene todas las capas del sistema

Quien utiliza agentes para crear un producto suele partir desde una ventaja legítima: conoce el problema mejor que muchos equipos de desarrollo tradicionales. Un médico entiende las fricciones de una clínica, un operador logístico conoce los puntos donde se pierde trazabilidad y un profesional financiero distingue las excepciones que nunca aparecen en un diagrama genérico. Esa experiencia puede producir productos más cercanos a la realidad y más útiles que las plataformas diseñadas desde una sala de reuniones distante.

La dificultad comienza cuando el conocimiento del negocio se interpreta como sustituto de la ingeniería. Una persona puede describir con precisión que cada médico debe acceder únicamente a sus pacientes, que los administrativos pueden gestionar agendas y que la dirección necesita visibilidad global. El agente convierte esas reglas en pantallas, roles y botones. La aplicación parece obedecer correctamente.

Un arquitecto o programador experimentado observa otra dimensión. Verifica si el servidor valida permisos en cada solicitud, si un identificador puede modificarse manualmente, si la API devuelve información antes de comprobar la relación entre usuario y recurso, y si las cuentas internas poseen privilegios capaces de saltarse las restricciones. La interfaz puede ocultar una ficha y el sistema puede seguir entregándola a quien conoce el número correcto.

La lógica del negocio expresa una intención. La ingeniería debe transformarla en una propiedad que resista errores, abuso y evolución.

La misma distancia aparece en redes. Una persona puede creer que utilizar cifrado resuelve la seguridad de una conexión. Un ingeniero distingue confidencialidad, autenticidad, autorización, integridad y administración de claves. Puede reconocer que una conexión cifrada continúa siendo insegura si el sistema entrega información a la identidad equivocada. El modelo OSI, entendido como una forma de separar responsabilidades entre capas, sigue siendo relevante porque recuerda que una garantía en un nivel no corrige una falla en otro. El firewall no repara una consulta mal autorizada, la red privada no elimina privilegios excesivos y el cifrado no convierte en legítimo un acceso indebido.

En bases de datos, crear tablas y relaciones no equivale a comprender transacciones, bloqueo, consistencia o recuperación. En sistemas distribuidos, una operación puede repetirse, llegar fuera de orden o completarse solo parcialmente. En criptografía, una contraseña larga puede seguir siendo predecible si fue producida por un modelo probabilístico que favorece palabras, símbolos y estructuras recurrentes.

El agente trabaja dentro del modelo mental que recibe. Cuando ese modelo es sólido, amplifica criterio. Cuando es incompleto, puede convertir una premisa defectuosa en una solución coherente, ejecutable y comercialmente atractiva. La velocidad no corrige la ausencia de profundidad; simplemente reduce el tiempo disponible para descubrirla.

La arquitectura que se forma por acumulación

Muchos productos construidos con agentes no comienzan con una arquitectura. Comienzan con una necesidad inmediata. Primero aparece el registro de usuarios, después la agenda, más tarde los pagos, las notificaciones, el almacenamiento de archivos, los roles administrativos y la inteligencia artificial. Cada nueva capacidad responde a una conversación diferente, a un problema concreto y a una entrega que debe completarse rápidamente.

El producto crece por acumulación de soluciones locales. La arquitectura aparece como un sedimento.

Cada módulo puede ser razonable de forma aislada y, al mismo tiempo, incompatible con el resto. Una parte utiliza sesiones persistentes, otra tokens. Algunos flujos verifican permisos en el servidor y otros confían en información enviada desde el navegador. Ciertas operaciones conservan auditoría; otras modifican datos sin dejar evidencia suficiente. Las fechas se procesan de forma distinta según la biblioteca utilizada en cada momento. El sistema conserva coherencia visual, pero no necesariamente coherencia interna.

La arquitectura cumple una función que suele subestimarse. No consiste en producir diagramas elegantes, sino en preservar propiedades globales mientras el sistema cambia. Define dónde se encuentran los límites de confianza, cómo se separan los clientes, qué componentes pueden comunicarse, cómo se recupera una operación incompleta y qué decisiones no pueden ser reinventadas por cada nueva función.

Los agentes son especialmente eficaces resolviendo tareas acotadas. Pueden crear un módulo, corregir un error, generar pruebas y avanzar. La dificultad aparece al mantener invariantes durante meses de cambios. Un agente puede leer el repositorio completo y seguir sin distinguir entre una decisión deliberada y un accidente histórico. Si encuentra el mismo patrón varias veces, puede asumir que se trata de una convención, cuando quizá solo está observando un error repetido.

Esta dinámica adquiere gravedad cuando ningún humano posee una representación completa del sistema. El fundador conoce la visión, los agentes conocen fragmentos de contexto, un desarrollador externo entiende los módulos que ha modificado y la documentación describe una arquitectura idealizada que nunca llegó a existir. La aplicación continúa funcionando porque los defectos arquitectónicos rara vez se manifiestan en el camino feliz.

Aparecen con concurrencia, volumen, fallos parciales, abuso y tiempo. Un caché mejora el rendimiento hasta que devuelve información de otro cliente. Una cola evita bloqueos hasta que procesa una operación dos veces. Una cuenta administrativa simplifica soporte hasta que atraviesa restricciones pensadas para usuarios normales. Una contraseña generada por un modelo parece robusta hasta que miles de secretos comparten la misma gramática estadística.

La arquitectura no elimina los eventos inesperados. Reduce la probabilidad de que esos eventos destruyan las propiedades esenciales del producto.

Los riesgos que no aparecen en la demostración

Una demostración comercial recorre condiciones elegidas. Los datos son válidos, la red responde, las dependencias están disponibles y cada operación sucede en el orden previsto. El producto se comporta como fue diseñado para comportarse y esa normalidad transmite confianza.

La seguridad y la resiliencia viven fuera de ese escenario.

Un atacante modifica identificadores, altera parámetros, repite solicitudes, cambia el orden de los pasos y utiliza funciones legítimas de maneras que el creador no imaginó. Un entorno real agrega latencia, errores parciales, integraciones lentas, usuarios simultáneos y eventos duplicados. El producto deja de recorrer el guion y comienza a revelar su arquitectura.

Imaginemos una clínica pequeña que adquiere una plataforma para gestionar fichas, agenda, documentos y pagos. Durante la demostración, cada usuario ve únicamente los pacientes correspondientes a su organización. La separación parece correcta. Un especialista independiente modifica el identificador de una ficha dentro de una solicitud y recibe información perteneciente a otra clínica.

El sistema autenticaba al usuario. No comprobaba su autorización sobre cada recurso.

La falla no estaba visible en la interfaz. La conexión estaba cifrada, el inicio de sesión funcionaba y los roles parecían correctamente definidos. El defecto vivía en una capa que el comprador no podía observar y que el proveedor quizá nunca había probado.

Lo mismo puede ocurrir con capacidades más sofisticadas. Una plataforma puede prometer detección de amenazas mediante inteligencia artificial y limitarse a buscar términos dentro de registros. Puede hablar de análisis de comportamiento cuando en realidad cuenta eventos. Puede vender correlación mientras ejecuta consultas independientes sin relacionar evidencias. La salida parece inteligente porque el modelo redacta una explicación convincente. La capacidad técnica puede ser mucho más limitada.

Las contraseñas generadas por agentes representan otra variante de este fenómeno. Una cadena larga, con símbolos y números, puede parecer fuerte y seguir perteneciendo a una distribución estrecha de patrones. La forma cumple con el requisito visible. La propiedad real no ha sido demostrada.

La inteligencia artificial facilita construir resultados plausibles y también facilita construir un discurso plausible alrededor de esos resultados. Código, documentación y marketing pueden compartir la misma premisa incompleta.

La dificultad para el comprador consiste en determinar si la función presentada tiene profundidad técnica o solo una representación convincente. Esa diferencia rara vez se resuelve observando otra demostración.

Un mercado donde la legitimidad puede fabricarse rápidamente

El auge de los agentes está multiplicando la cantidad de empresas capaces de ofrecer productos tecnológicos. Esta expansión puede generar una de las etapas más fértiles de innovación de las últimas décadas. Problemas pequeños, verticales y geográficamente específicos pueden recibir soluciones que los grandes proveedores nunca habrían considerado rentables.

El mismo fenómeno reduce el costo de parecer un proveedor maduro.

Una empresa puede construir una identidad visual profesional, una aplicación funcional, documentación detallada, soporte automatizado y una presentación comercial durante sus primeras semanas. Ninguno de esos elementos demuestra por sí solo que exista aislamiento entre clientes, recuperación probada, capacidad para soportar carga o control sobre dependencias críticas.

El mercado empieza a mezclar productos brillantes con sistemas inmaduros bajo señales visuales semejantes. La trayectoria, el tamaño del equipo y el esfuerzo aparente dejan de servir como indicadores confiables. Un proveedor reciente puede superar técnicamente a una compañía consolidada. También puede no comprender las limitaciones de aquello que vende.

La situación se vuelve más delicada cuando la solución se adquiere directamente desde otro país, sin revendedor, integrador o representante local. La distancia no implica falta de calidad. La ausencia de responsabilidad práctica sí debe ser considerada.

Cuando el servicio falla, cambia sus condiciones o expone información, el cliente puede descubrir que la relación completa depende de una casilla de soporte y de términos sometidos a otra jurisdicción. La capacidad para recuperar datos, recibir ayuda durante un incidente o exigir cumplimiento puede ser mínima.

Las grandes organizaciones suelen contar con arquitectura empresarial, seguridad, legal, compras y riesgo de terceros. Esos procesos pueden ser lentos, pero introducen preguntas que la demostración no responde. Revisan integración, continuidad, jurisdicción, privacidad, soporte y mecanismos de salida.

Las empresas pequeñas enfrentan el mismo riesgo con muchos menos recursos. La persona responsable de tecnología puede administrar también dispositivos, conectividad y soporte a usuarios. En otros casos, ni siquiera existe ese rol. La decisión se toma observando funciones, precio y facilidad de implementación.

La asimetría es evidente. Los productos más accesibles, rápidos y atractivos llegan precisamente a quienes poseen menor capacidad para evaluar lo que compran.

El mercado no se vuelve peligroso porque aparezcan más startups. Se vuelve más difícil de leer porque la apariencia comercial dejó de revelar cuánto conocimiento, prueba y responsabilidad existen detrás.

El arquitecto como traductor de promesas

En este nuevo mercado, el arquitecto cumple una función que excede la construcción de sistemas. Convierte afirmaciones comerciales en propiedades observables.

Si un proveedor asegura que los datos de cada cliente están aislados, la afirmación debe transformarse en una prueba que intente atravesar ese límite. Si promete alta disponibilidad, hay que interrumpir una dependencia y medir el comportamiento. Si declara escalabilidad, la carga debe reproducir operaciones reales, volumen, concurrencia y tamaño de datos. Una cifra obtenida con conexiones vacías no demuestra capacidad operacional.

Las capacidades basadas en inteligencia artificial requieren el mismo rigor. Una demostración preparada no permite evaluar precisión. Se necesitan conjuntos independientes, casos ambiguos, falsos positivos, falsos negativos y condiciones en las que el sistema reconozca incertidumbre. Una respuesta bien redactada no equivale a una respuesta correcta.

El arquitecto también examina aquello que no aparece en la función principal. Quién administra las claves, qué cuentas poseen privilegios elevados, cómo se exportan los datos, qué dependencias pueden interrumpir el servicio y qué ocurre si el proveedor desaparece. Estas preguntas no buscan frenar una compra, sino entender el verdadero alcance del compromiso.

Antes de contratar una revisión técnica, el comprador puede realizar un filtro inicial bastante revelador. Debe solicitar un diagrama actualizado de arquitectura, una descripción del flujo de datos, evidencia de pruebas de carga, el procedimiento de recuperación y una explicación clara sobre aislamiento entre clientes. La incapacidad para entregar estos antecedentes, o la presentación de documentos genéricos que no coinciden con el producto mostrado, constituye una señal temprana de que la madurez comercial podría estar superando a la ingeniería.

Una empresa pequeña no necesita crear un departamento corporativo para cada adquisición. Puede contratar una revisión fraccional, limitada a las propiedades cuya falla destruiría el valor del producto. Un arquitecto, ingeniero senior o especialista independiente puede trabajar durante algunos días para identificar riesgos, diseñar pruebas y traducir los resultados a una decisión comercial.

Para una clínica, las propiedades críticas pueden ser aislamiento entre organizaciones, recuperación, exportación de datos y control de acceso. Para una empresa logística, continuidad, integridad de eventos y operación sin conectividad. Para una solución financiera, consistencia, trazabilidad, autorización y reversión.

El contrato debe acompañar esa evidencia. Las promesas importantes necesitan convertirse en compromisos medibles. Una capacidad declarada debe asociarse con una prueba, un plazo y una consecuencia. La ubicación de los datos, los subprocesadores, la notificación de incidentes y la asistencia para migrar deben existir fuera del lenguaje promocional.

También importa la reacción del proveedor. Una empresa seria puede no tener todas las respuestas, pero reconoce la legitimidad de las preguntas. Entrega evidencia, admite límites y explica qué controles están pendientes. La evasión, las afirmaciones absolutas y la incapacidad para describir la arquitectura son señales más útiles que cualquier sello comercial.

Un nuevo estándar de confianza

El vibe coding no desaparecerá y tampoco debería hacerlo. Está permitiendo que personas con experiencia de industria construyan productos que antes no habrían existido. Equipos pequeños pueden competir, experimentar y responder a necesidades que las grandes compañías ignoraron durante años.

La discusión madura no debe enfrentar código humano contra código generado. Debe examinar la calidad del proceso que convierte una intención en una capacidad confiable.

Un agente puede multiplicar el criterio de un arquitecto, ampliar la cobertura de un equipo de seguridad y acelerar el trabajo de un ingeniero de redes. También puede multiplicar los supuestos de una persona que desconoce las capas que está delegando. La tecnología es la misma. Cambian el conocimiento, la orquestación y las pruebas.

La producción de código deja de ser el principal cuello de botella. Comprender el sistema, conservar coherencia y demostrar propiedades adquiere más valor. Cuando escribir cuesta menos, los errores conceptuales pueden propagarse con mayor velocidad.

Las contraseñas predecibles, las autorizaciones incompletas, las dependencias privilegiadas y las arquitecturas sedimentadas forman parte del mismo fenómeno. Son decisiones que parecen suficientes dentro del contexto inmediato y fallan cuando se enfrentan a una realidad más amplia.

Para quien construye, la obligación consiste en mantener una arquitectura reconocible, separar responsabilidades, probar supuestos y responder por el resultado, aunque cada línea haya sido escrita por una máquina. La responsabilidad técnica no desaparece al delegar la implementación.

Para quien compra, la obligación consiste en abandonar la apariencia como evidencia. Una demostración confirma que el proveedor puede recorrer un escenario preparado. No demuestra aislamiento, resiliencia, precisión ni capacidad para responder durante un incidente.

La empresa pequeña necesita una defensa proporcional: solicitar primero la arquitectura, los flujos de información y las pruebas que el propio proveedor debería conocer; identificar después las propiedades irrenunciables; y contratar conocimiento especializado durante el tiempo necesario para verificar aquello que sostiene la decisión. No requiere una burocracia corporativa. Requiere criterio en el momento correcto.

El vibe coding ha democratizado la fabricación de software. La próxima etapa deberá democratizar la capacidad de inspeccionarlo antes de confiar. Los mejores productos de esta nueva generación no serán aquellos que agreguen más funciones en menos tiempo, sino aquellos capaces de demostrar qué propiedades conservan cuando la aplicación deja de comportarse como fue mostrada.

El software puede llegar al mercado en una semana. Convertirse en un producto digno de confianza sigue exigiendo conocimiento, pruebas y responsabilidad.