La demo nunca muestra esta parte. Una herramienta de vibe coding genera en un solo prompt un botón pulido de “Conecta tu Google Calendar”, y parece terminado. Lo que la demo omite es todo lo que hay entre hacer clic en ese botón y que el calendario realmente sincronice: una aplicación de desarrollador registrada en la consola del proveedor, credenciales OAuth configuradas, redirect URIs definidos y, en algunos casos, un paso de verificación de dominio que no tiene nada que ver con la lógica de tu app y todo que ver con demostrar que eres dueño del dominio sobre el que estás construyendo.
Esta es la parte del vibe coding para la que no existe ningún prompt. No puedes describir tu forma de evitarla, porque el proveedor (Google, Slack, Stripe, el que sea) exige los mismos pasos de registro a un creador solo que a un equipo de ingeniería.
Lo que realmente exige “conecta tu calendario”
Para una integración como Google Calendar no existe una API key que simplemente se pueda pegar en un campo de configuración. El código generado necesita una identidad real, registrada ante el proveedor, antes de poder pedirle a nadie que autorice nada. En la práctica eso significa:
- Crear una aplicación de desarrollador en la consola del proveedor (Google Cloud Console, el panel de apps de Slack, el portal de desarrolladores de Stripe).
- Configurar credenciales OAuth para esa aplicación: un client ID y un secret que identifican tu app ante el proveedor.
- Definir redirect URIs que coincidan exactamente con el lugar al que el proveedor debe devolver al usuario tras autorizar, hasta el protocolo y la barra final.
- Superar la verificación de dominio, cuando el proveedor exige demostrar que controlas el dominio en el que corre la app antes de conceder acceso de nivel producción.
- Seleccionar y solicitar scopes, los permisos concretos que pide la app, que se revisan (a veces por el proveedor, a veces solo por quien esté construyendo la app con prisa).
Nada de esto es lógica de la app. Es administración de cuenta en la plataforma de otro, y hay que hacerlo correctamente antes de que un solo evento de calendario aparezca en la interfaz generada.
Dos formas de equivocarse con los scopes, ambas malas
Los scopes son el punto donde esto deja de ser meramente tedioso y empieza a ser arriesgado. Equivocarse en cualquiera de las dos direcciones produce un fallo completamente distinto.
Demasiados scopes es el fallo de seguridad. Pedir acceso completo a Drive cuando la función solo necesitaba eventos de Calendar en modo lectura no es un atajo, es un riesgo permanente: cada archivo de esa cuenta queda ahora accesible mediante una credencial que la app nunca necesitó tocar. Se queda ahí, en silencio, hasta el día en que se filtra un token o se compromete una sesión, y en ese momento el radio de impacto es todo el scope concedido, no la función que realmente se construyó. Es el mismo tipo de problema que el 45% del código generado por IA con vulnerabilidades de clase OWASP: el código funciona bien y hace una demo perfecta mientras la exposición queda debajo, invisible hasta que algo falla.
Demasiado pocos scopes es el modo de fallo silencioso. Falta un solo scope requerido y la integración no lanza un error claro, simplemente deja de funcionar de una forma difícil de diagnosticar. Una sincronización de calendario que no devuelve nada, una notificación de Slack que nunca se envía, un webhook de Stripe que se dispara pero cuyo handler no puede leer el campo que necesita. Un creador no técnico frente a un resultado vacío no tiene forma de saber si el fallo está en el código generado, en la configuración de scopes o en el lado del proveedor, y la IA no puede inspeccionar la concesión OAuth para decírselo.
Acertar exactamente con la lista de scopes, y revisarla cada vez que cambia el conjunto de funciones, es una habilidad específica y estrecha. No la cubre el prompting de “describe lo que quieres”, porque la IA que genera el código de integración no controla lo que la consola del proveedor va a autorizar realmente.
Dónde terminan viviendo las credenciales
Una vez que el baile de OAuth funciona, el client ID, el secret y cualquier token de acceso resultante tienen que vivir en algún lugar. Ese “algún lugar” es una decisión de arquitectura real, no un detalle. Probar la integración en local significa que la app necesita variables de entorno que apunten a credenciales reales, y los creadores no técnicos que no saben gestionar bien los archivos .env acaban rutinariamente escribiendo esos valores directamente en el código, en duro. Los secrets escritos en duro que terminan subidos por accidente a un repositorio público de GitHub ocurren con la frecuencia suficiente como para ser un fallo documentado y con nombre propio de toda la categoría, no un error raro. Una vez que un secret queda en el historial de un repositorio público, rotarlo y confirmar que nadie explotó esa ventana es un trabajo de limpieza aparte, encima de la integración que se intentaba entregar.
Fontanería, no producto
Vale la pena llamarlo por su nombre: trabajo de infraestructura, no la función que intentabas construir. Nadie se despierta con ganas de configurar un redirect URI. La necesidad de negocio era “mostrar las próximas reuniones del cliente” o “avisar al equipo en Slack cuando se cierre un trato”. La consola OAuth, la lista de scopes y el almacenamiento de credenciales son el coste inevitable de llegar hasta ahí en una plataforma donde cada integración se construye desde cero, y escalan con el número de servicios de terceros que toca la app, no con lo pulida que se vea la función.
Este es exactamente el terreno donde una plataforma como Softr es la herramienta adecuada para el trabajo, no un parche. Sus conectores nativos para Google Calendar, HubSpot, Stripe y herramientas de negocio similares son aplicaciones OAuth ya verificadas y aprobadas de antemano: un creador autoriza su cuenta en un flujo de inicio de sesión, y los scopes y el almacenamiento de credenciales se gestionan en el servidor, completamente fuera del cliente, porque Softr ya hizo el registro en consola una vez para todos. Pero para un portal de cliente o una herramienta interna cuya tarea es sobre todo “sincronizar un calendario y publicar en Slack”, el impuesto de la integración es el tipo de fontanería que resulta más barato comprar como infraestructura de plataforma que reinventar proyecto por proyecto.
Ese intercambio deja de tener sentido en el momento en que la integración en sí es el producto. Si estás conectando un proveedor para el que nadie tiene un conector, o necesitas control sobre la renovación de tokens y el manejo de errores, quieres ser dueño del flujo OAuth en lugar de heredar el de otro. Eso es trabajo de desarrollador, y pertenece a herramientas de desarrollador: Cursor dentro de una base de código real donde puedas leer lo que realmente hacen las credenciales, o Replit, donde las variables de entorno y la gestión de secrets son de primera clase en lugar de algo que se añade después. Ninguna de las dos elimina el registro en consola, porque nada lo hace. Simplemente te colocan en posición de acertar los scopes de forma deliberada en lugar de descubrirlos por ensayo y error.
El bucle de arreglos empeora esto con el tiempo, no lo mejora. Cada ajuste de scope o nueva integración es otra ronda de configuración en consola, otro redirect URI que hay que dejar exactamente bien, y otra oportunidad de conceder de más o de menos. Es un coste que se acumula con cada función añadida, que es exactamente la forma de el problema del Día Dos: la app que hizo una demo impecable el primer día sigue generando nuevo trabajo de fontanería cada vez que crece.