Vibe coding: usos y límites

Da espacio para crear

Un CTO de una gran empresa puede ayudar a más personas a convertir sus conocimientos en ideas de software. Invita a personas de finanzas, operaciones, ventas e ingeniería. Dales tiempo, datos sintéticos, API de pruebas y apoyo.

Permite que exploren con distintas herramientas, dentro de límites claros sobre instalaciones, cuentas y datos permitidos. Un constructor en el navegador, un asistente de programación o un agente local pueden servir para probar una idea. Elegir una herramienta no autoriza a subir información de la empresa ni a conectar un sistema real.

Define una vía sencilla para llevar un prototipo útil al equipo de ingeniería o de plataforma. Quien lo creó aporta el problema, un ejemplo del flujo de trabajo y el valor observado. No tiene que convertirse en el equipo de seguridad y operaciones del servicio.

Identifica qué necesitas aprender

El vibe coding suele empezar con una descripción del software que quieres. Aceptas código generado y usas el resultado visible para orientar el siguiente cambio. El término tiene distintos significados. En esta guía, quien dirige el trabajo no tiene por qué comprender cada decisión de implementación.

Este método puede ayudarte a aprender. Una interfaz sencilla puede mostrar que un proceso de aprobación tiene demasiados pasos. Un script temporal puede servir para evaluar un formato de archivo. Un prototipo ofrece un diseño concreto sobre el que conversar. Puedes conservar ese conocimiento aunque descartes el código.

Primero, formula una pregunta con una respuesta observable. Por ejemplo: «¿Puede un responsable de equipo entender este proceso de aprobación?». La pregunta tiene un alcance claro. Pedir un sistema de gastos también implica protección de datos, control de acceso, operación y responsabilidades.

El prototipo bancario del martes

Considera un ejemplo ficticio. El martes, una persona de finanzas usa Lovable para crear un panel con transacciones bancarias inventadas. El panel agrupa los gastos y muestra las facturas pendientes. El equipo ya puede examinar un flujo de trabajo útil.

Alguien propone conectar la cuenta bancaria de la empresa. Eso cambia las consecuencias, aunque la aplicación siga llevando la etiqueta de «prototipo».

Según la API, el acceso de lectura puede revelar saldos, historiales de transacciones, nombres de clientes o referencias de pagos. Si la conexión también permite pagar, un error puede mover dinero real. Confirma el alcance exacto de los permisos: una conexión bancaria no siempre incluye permiso para realizar pagos.

La demostración no prueba que cada usuario solo pueda consultar las cuentas para las que tiene autorización. Ocultar un botón no impone un permiso. OWASP explica cómo la falta de comprobaciones sobre cuentas o registros puede exponer los datos de otro usuario.

En las API de pagos, la idempotencia significa que repetir una solicitud no repite el efecto previsto. Stripe documenta una implementación. Comprueba el comportamiento, los límites y las reglas de reintento del proveedor concreto. Revertir una versión de la aplicación no anula un pago que el banco ya ha procesado.

Este ejemplo no demuestra un defecto de Lovable. La propia guía de seguridad de Lovable exige proteger los secretos, comprobar en el servidor, probar las políticas de datos y mantener una revisión continua. Aplica el mismo criterio de prueba a cualquier constructor, agente o aplicación escrita a mano.

Comprueba el acceso antes de conectar sistemas reales

Sigue probando el flujo de trabajo con datos sintéticos y cuentas de pruebas. Antes de conceder acceso real, las personas responsables del servicio, la seguridad y la plataforma deben verificar la aplicación y su entorno de operación.

Usa el flujo de conexión autorizado por el banco o proveedor. Concede únicamente acceso a las cuentas y los permisos necesarios. Guarda las credenciales privadas en un almacén de secretos autorizado, fuera de los prompts y del código del navegador. Cuando se necesiten pagos, asigna sus aprobaciones y límites. Verifica cómo revocar el acceso, investigar fallos y responder a actividad sospechosa.

Estas decisiones deben tomarse antes de introducir información confidencial o credenciales reales en el sistema. Esperar a una publicación formal en producción puede ser demasiado tarde. Continúa con los límites de los datos y la infraestructura empresarial.

Define las responsabilidades antes de ampliar el uso

Un experimento con datos inventados puede durar poco y tener pocos usuarios. Cuando otras personas dependan de la aplicación, define las responsabilidades de su uso.

1. Nombra a la persona responsable.
2. Identifica los usuarios y datos permitidos.
3. Define la respuesta ante un fallo.
4. Guarda el código fuente y la configuración en un repositorio.
5. Verifica que otra persona pueda inspeccionar y reproducir el sistema.

No todos los scripts necesitan una plataforma empresarial. Un formateador personal sin datos sensibles requiere menos controles que una aplicación de aprobación de pagos. Evalúa las consecuencias de un error. Comprueba si puedes detectarlo y revertir sus efectos.

Antes de ampliar el prototipo, separa lo aprendido sobre el problema de las pruebas sobre la implementación. Puedes conservar la interfaz y sustituir el código interno. Puedes restringir el uso previsto. También puedes mantener el prototipo como experimento temporal.

Prevé las vulnerabilidades después de la demostración

Una demostración satisfactoria puede ocultar una carencia grave de mantenimiento. Puede publicarse un nuevo aviso de vulnerabilidad sobre una dependencia sin que cambie tu código. Un análisis realizado al publicar solo describe un momento concreto.

Si la aplicación sigue en uso, alguien debe seguir detectando, evaluando y corrigiendo vulnerabilidades. La corrección debe llegar a producción y superar la verificación. Un escáner sin este proceso de respuesta deja la exposición sin resolver.

Comprueba qué ofrecen tu herramienta y tu configuración concretas. Más adelante, la gestión continua de vulnerabilidades explica el proceso completo, incluidos los fallos de los análisis y las versiones desplegadas.

Facilita la revisión del siguiente cambio

Encarga al agente un cambio pequeño con criterios de aceptación explícitos. Indica qué acciones puede realizar. Inspecciona el diff resultante. Ejecuta comprobaciones que puedan rechazar una implementación incorrecta. Mantén el despliegue como una decisión independiente hasta que las responsabilidades de publicación estén claras.

El Secure Software Development Framework de NIST describe prácticas más amplias de desarrollo seguro. Úsalo como referencia al evaluar los controles que faltan. No necesitas memorizar el marco. Necesitas identificar las pruebas que faltan antes de que el software afecte a otras personas.