Riesgos de la programación en Vibe: seguridad, facilidad de mantenimiento y preparación para la producción

Una aplicación creada pidiendo a un agente de IA que genere código puede parecer totalmente terminada y, aun así, plantear riesgos reales de seguridad, como una comprobación de autenticación que nunca se haya escrito o un secreto almacenado en un archivo de configuración. Nada de eso se aprecia en la demostración. Solo sale a la luz cuando alguien con malas intenciones le echa un vistazo.

La seguridad de la programación «vibe» es el riesgo más evidente, pero no es el único. La misma rapidez que hace atractivo el «vibe coding» no se detiene a comprobar si una aplicación puede funcionar correctamente y seguir siendo mantenible una vez que la persona que la ha creado deja el proyecto.

Este artículo aborda las comprobaciones que conviene realizar antes de que una aplicación creada mediante «vibe coding» gestione datos reales o asuma responsabilidades empresariales, tres ejemplos de dónde surge el riesgo y las opciones disponibles una vez realizada la revisión.

¿Cuándo se convierte un prototipo creado mediante «vibe coding» en un riesgo empresarial?

La programación «vibe» es el proceso de dar instrucciones a un agente de programación basado en IA hasta que una aplicación haga lo que se desea, con muy poca programación manual, a diferencia de lo que requiere el desarrollo de software tradicional. Sin embargo, lo que realmente importa en cuanto al riesgo no es cómo se ha creado la aplicación, sino lo que cambia una vez que deja de ser una demostración.

Imagina tres ejemplos, cada uno de ellos de bajo riesgo al principio:

• Una maqueta que utiliza datos de muestra para mostrar cómo podría ser un nuevo panel de control. El punto de inflexión se produce cuando empieza a incorporar datos en tiempo real en lugar de muestras.
• Un formulario de solicitud interno que permite a los empleados presentar solicitudes de permisos, que al principio solo se registran en una hoja de cálculo. El punto de inflexión se produce cuando obtiene permiso para actualizar realmente los registros de la empresa.
• Un portal para clientes que muestra el historial de pedidos y los detalles de la cuenta. El punto de inflexión se produce cuando se abre a clientes reales en lugar de a un puñado de probadores internos.

Ninguno de estos proyectos es peligroso al principio. Lo que cambia en cada uno es que lo mismo aparece de forma diferente, ya sean datos reales, permisos reales o usuarios reales que sustituyen a un sustituto seguro.

Lo que realmente importa son los usuarios de una aplicación, su acceso a los datos, con qué está integrada y en qué medida depende ahora de ella un flujo de trabajo, no si la demostración parecía pulida. Una herramienta interna tampoco es automáticamente de bajo riesgo. Manejar datos confidenciales o realizar cambios en registros importantes puede conllevar tanto riesgo como cualquier cosa dirigida a los clientes.

¿Qué deben comprobar los equipos antes del lanzamiento?

Tanto los desarrolladores profesionales como los aficionados utilizan ahora herramientas de programación basadas en IA para convertir indicaciones en lenguaje natural en software funcional mediante iteraciones rápidas, a menudo sin la supervisión humana que los equipos de seguridad esperarían normalmente. Se trata del desarrollo asistido por IA en su máxima velocidad, y la rapidez no se detiene para realizar las comprobaciones habituales.

La velocidad a la que la IA genera código comprime los procesos de seguridad tradicionales —como la redacción, la revisión y el lanzamiento— en un único ciclo de programación «vibe». Eso significa que los problemas que un proceso más lento detectaría normalmente, como fallos de seguridad o casos extremos que se pasan por alto, pueden llegar directamente a producción. Las herramientas tradicionales de AppSec (seguridad de aplicaciones) siguen siendo útiles, pero no se diseñaron para el ritmo al que avanzan ahora las herramientas de «vibe coding ». Además, pueden pasar por alto fallos lógicos que solo salen a la luz una vez que alguien comprende qué se supone que debe hacer realmente una función.

Asegurar el resultado del «vibe coding» empieza por las mismas cinco preguntas que cualquier aplicación en producción debería responder.

1. ¿A qué datos puede acceder la aplicación y quién puede utilizarlos?

Empieza por la sensibilidad de los datos, las credenciales, la autenticación, los controles de seguridad y los permisos. ¿Se ha sometido esto realmente a una revisión humana, como la revisión de código en una solicitud de incorporación de cambios (pull request), o solo a comprobaciones automatizadas? ¿Se ha probado el acceso para los usuarios que no deberían poder ver o modificar algo, y no solo para los usuarios que se supone que sí deben hacerlo?

La sensibilidad de los datos tampoco es solo una cuestión de criterio interno. Una aplicación que maneje historiales médicos, datos de pago o información personal puede estar sujeta a normativas como la HIPAA, la SOX o el RGPD , y cumplirlas puede requerir cambios arquitectónicos reales, más allá de marcar una casilla en una política.

El código de ejemplo copiado del primer borrador de una indicación no es, por sí mismo, código seguro. El código inseguro vinculado a la lógica de autenticación es uno de los aspectos que más fácilmente se pasan por alto en una revisión rápida. Los modelos de IA entrenados con enormes cantidades de datos de entrenamiento pueden reproducir patrones inseguros y otras vulnerabilidades de seguridad sin que nadie lo pretenda.

Un estudio de la NYU ampliamente citado reveló que GitHub Copilot generaba errores explotables o fallos de diseño relevantes para la seguridad en aproximadamente el 40 % de los casos de prueba, y la prueba de rendimiento BaxBench descubrió que el 62 % de las soluciones, incluso las del modelo con mejor rendimiento, eran incorrectas o contenían una vulnerabilidad de seguridad. Considerar que el código generado por IA es seguro simplemente porque funciona es la forma en que esos patrones pasan desapercibidos.

Documenta a qué datos y sistemas puede acceder la aplicación, qué roles tienen permiso para utilizarla y qué resultados arrojaron las pruebas de acceso.

2. ¿Gestiona correctamente las reglas de negocio y los fallos?

Probar la ruta prevista solo te muestra el caso ideal en el que la lógica de negocio funciona. Prueba también entradas inválidas, información que falte, acciones conflictivas y solicitudes fallidas. En condiciones de uso previstas, incluyendo acciones simultáneas o un pico de tráfico cuando sea relevante, ¿sigue comportándose la aplicación como debería?

Los defectos de software y la lógica insegura ocultos en el interior de una función que, por lo demás, funciona correctamente, rara vez salen a la luz hasta que alguien prueba las rutas que a nadie se le había ocurrido probar. Una función generada por IA puede superar todas las pruebas que alguien se haya ocurrido escribir y, aun así, fallar en aquella que nadie probó.

Piensa detenidamente en lo que ocurre si el resultado es simplemente erróneo, especialmente en todo lo relacionado con el procesamiento de pedidos, aprobaciones o cambios en las cuentas. Anota qué escenarios se han probado y qué fallos siguen sin resolverse. «Funciona» y «produce el resultado correcto de forma consistente» son dos conclusiones muy diferentes, y es fácil confundir una con la otra.

3. ¿Qué ocurre cuando falla una integración?

Identifica todos los sistemas de los que la aplicación lee o en los que escribe, incluidos los recursos en la nube que pueda crear, modificar o eliminar durante el proceso. Busca actualizaciones incompletas, acciones duplicadas, datos incoherentes y mensajes de error que realmente ayuden a comprender qué ha fallado. ¿Puede el equipo detectar un fallo en la integración y recuperarse de él de forma segura?

Documenta las propias integraciones, qué revelaron las pruebas de fallo en los entornos de prueba y cómo corregiría o revertiría el equipo una acción que solo se completó parcialmente.

4. ¿Puede otra persona encargarse de su mantenimiento?

La forma en que se ha creado el código generado por IA es tan importante como el hecho de que funcione. Una aplicación generada por IA que nadie puede explicar es más difícil de mantener que el código existente o el código escrito por personas que ya ha pasado por el proceso habitual de un equipo.

El control de versiones que realiza un seguimiento de cada ronda de generación de código proporciona al futuro encargado del mantenimiento un historial documentado que las indicaciones por sí solas no ofrecen, y cada nuevo lote de código generado por IA debería contar con alguien responsable de revisarlo antes de su lanzamiento.

Alguien, además del creador original, debe ser capaz de explicar las rutas de código importantes, las dependencias y las decisiones de diseño, y no limitarse a recordar a grandes rasgos lo que se suponía que debía hacer una indicación o un conjunto de herramientas de desarrollo. Busca pruebas que hagan que los cambios futuros sean más seguros, y un responsable que se encargue realmente de mantener la aplicación en funcionamiento.

Verifica que tanto el responsable como al menos otro miembro cualificado del equipo sean capaces de averiguar cómo modificar la aplicación sin depender de la memoria del creador original ni del historial de indicaciones. Una revisión manual por parte de alguien que no esté familiarizado con el proyecto es una buena prueba de ello.

5. ¿Puede el equipo dar soporte a la aplicación tras su lanzamiento?

Confirma quién recibe realmente las alertas, investiga los incidentes, aprueba los cambios y gestiona las actualizaciones una vez que la aplicación esté en producción. ¿Dónde se ejecutará?, ¿cómo llegarán realmente los cambios a los sistemas de producción? y ¿cómo identificaría el equipo y revertiría una versión defectuosa? La visibilidad en tiempo de ejecución —es decir, poder ver realmente lo que hace la aplicación una vez que está en producción— es tan importante aquí como lo fue durante las pruebas.

Comprueba si el equipo puede restablecer el servicio tras una interrupción, no solo detectar que se ha producido. Anota quién es el responsable del soporte, la configuración de las alertas y los pasos de lanzamiento y recuperación. El soporte continuo debe formar parte de la preparación para el lanzamiento desde el principio, no ser una tarea que alguien asigne tras el primer incidente.

¿Qué debes hacer tras la revisión de riesgos?

La revisión de ingeniería no siempre implica pequeñas correcciones. Puede dar lugar a cambios reales, a una reconstrucción sustancial o a cambiar por completo a un enfoque de implementación diferente.

No existe una puntuación de riesgo rígida que haga que esta decisión sea automática. Lo que importa es contar con pruebas reales que respalden la opción elegida y con alguien que realmente la apruebe. El responsable de la aplicación debe recurrir a revisores de ingeniería y seguridad cuando el nivel de riesgo de la aplicación así lo requiera.

¿Qué papel puede desempeñar Liferay DXP en esta decisión?

Cuando una revisión apunta a crear algo diferente en lugar de parchear lo existente, la siguiente pregunta es sobre qué base construirlo. Gran parte de lo que realmente señala una revisión —una propiedad de los datos poco clara, pasos de aprobación que faltan, permisos que nadie ha definido por completo— son lagunas que una plataforma gobernada está diseñada para subsanar de forma predeterminada, no problemas que un equipo tenga que diseñar y validar por su cuenta.

Liferay DXP aborda esto mediante:

• Objetos que dotan a los datos estructurados de una forma definida, un propietario y un historial desde el principio
• Formularios que recogen la información introducida con validación y permisos ya incorporados
• Flujos de trabajo que canalizan las aprobaciones a través de pasos que el equipo puede ver y auditar
• Roles y permisos que controlan el acceso a nivel de la plataforma, sin quedar ocultos en el código de la aplicación
• API e integraciones que se conectan a los sistemas existentes a través de una ruta compatible y probada

Nada de esto elimina la necesidad de ejercer el criterio. El equipo sigue teniendo que decidir qué es lo que realmente debe estar en la plataforma y qué es lo que realmente requiere un desarrollo a medida, y cualquier elemento personalizado sigue necesitando la misma revisión y las mismas pruebas que el resto. Lo que cambia es el punto de partida. En lugar de tener que demostrar desde cero que los permisos, las aprobaciones y las integraciones funcionan, un equipo que desarrolle aquí parte de algo que ya ha superado ese umbral.

Tomar la decisión de puesta en producción de forma deliberada

La verdadera cuestión no es si una aplicación parece terminada. Es qué condiciones deben cumplirse para que esta aplicación en concreto sea lo suficientemente segura como para confiar en ella. El camino adecuado depende de su finalidad, a qué está expuesta y cuánto tiempo se espera que permanezca en funcionamiento, no de cómo se construyó originalmente.

Explora las capacidades «low-code» de Liferay DXP si una base de aplicaciones regulada te parece la opción adecuada para lo que viene a continuación.

Preguntas frecuentes sobre los riesgos de la codificación por vibración

¿Puede una aplicación interna programada con Vibe seguir siendo de alto riesgo?

Sí. El hecho de que sea interna solo limita quién puede acceder a la aplicación, no lo que esta puede hacer una vez que alguien la está utilizando. Una herramienta interna que maneje datos confidenciales o modifique registros importantes puede entrañar tanto riesgo como cualquier otra herramienta orientada al cliente, a veces incluso más, ya que las herramientas internas suelen estar sometidas a un menor escrutinio.

¿Significa una revisión de seguridad que una aplicación programada con Vibe está lista para su puesta en producción?

No por sí sola. La seguridad es solo una parte del conjunto, independientemente de las herramientas de IA que hayan ayudado a crear la aplicación. Una aplicación también debe gestionar correctamente los fallos, superar los problemas de integración, poder ser mantenida por alguien distinto de su creador original y contar con un plan de soporte real tras su lanzamiento.

¿Y si una aplicación programada «a ojo» ya tiene usuarios?

Realiza las mismas comprobaciones en esa aplicación programada «por intuición», pero con mayor urgencia. Los usuarios existentes no hacen que una aplicación sea más segura. Simplemente significan que las consecuencias de una brecha ya se están manifestando. Da prioridad a las comprobaciones relacionadas con los datos o procesos de negocio con los que la aplicación interactúa actualmente.

¿Es necesario que todos los prototipos programados «a ojo» se conviertan en aplicaciones en producción?

No. Muchos prototipos creados con asistentes de programación basados en IA cumplen su función respondiendo a una pregunta o validando una idea, y luego se retiran. La presión para formalizar algo suele surgir solo cuando la gente empieza a depender de ello, que es precisamente el momento en el que este tipo de revisión cobra mayor importancia.