Die Demo zeigt diesen Teil nie. Ein Vibe-Coding-Tool erzeugt in einem Prompt einen glatten „Google Calendar verbinden“-Button, und es wirkt fertig. Was die Demo auslässt, ist alles zwischen dem Klick auf diesen Button und dem tatsächlichen Sync des Kalenders: eine in der Konsole des Anbieters registrierte Entwickler-Anwendung, konfigurierte OAuth-Credentials, gesetzte Redirect-URIs und in manchen Fällen ein Schritt zur Domainverifizierung, der nichts mit der Logik deiner App zu tun hat und alles damit, zu beweisen, dass dir die Domain gehört, auf der du baust.
Das ist der Teil des Vibe Coding, für den es keinen Prompt gibt. Man kann sich nicht daran vorbeireden, weil der Anbieter (Google, Slack, Stripe, wer auch immer) von einem Solo-Builder dieselben Registrierungsschritte fordert wie von einem ganzen Engineering-Team.
Was „verbinde deinen Kalender“ wirklich erfordert
Bei einer Integration wie Google Calendar gibt es keinen API-Key, den man einfach in ein Einstellungsfeld einfügt. Der generierte Code braucht eine echte, beim Anbieter registrierte Identität, bevor er überhaupt jemanden um Autorisierung bitten kann. In der Praxis bedeutet das:
- Eine Entwickler-Anwendung anlegen in der Konsole des Anbieters (Google Cloud Console, Slacks App-Dashboard, das Stripe-Entwicklerportal).
- OAuth-Credentials konfigurieren für diese Anwendung: eine Client-ID und ein Secret, die deine App beim Anbieter identifizieren.
- Redirect-URIs festlegen, die exakt dem Ort entsprechen, an den der Anbieter den Nutzer nach der Autorisierung zurückschicken soll, bis hin zum Protokoll und dem abschließenden Slash.
- Domainverifizierung abschließen, sofern der Anbieter einen Nachweis fordert, dass du die Domain kontrollierst, auf der die App läuft, bevor er Zugriff auf Produktionsebene freigibt.
- Scopes auswählen und anfragen, die konkreten Berechtigungen, die die App verlangt, die dann geprüft werden (mal vom Anbieter, mal einfach von der Person, die die App in Eile baut).
Nichts davon ist App-Logik. Es ist Kontoverwaltung auf der Plattform eines anderen, und sie muss korrekt erledigt sein, bevor auch nur ein einziges Kalenderereignis in der generierten UI auftaucht.
Zwei Arten, Scopes falsch zu setzen, beide schlecht
Bei Scopes hört das Ganze auf, bloß mühsam zu sein, und wird riskant. Verlegt man sich in die eine oder die andere Richtung, sieht das Scheitern völlig anders aus.
Zu viele Scopes ist der Sicherheitsfehler. Vollen Drive-Zugriff anzufragen, obwohl das Feature nur lesende Calendar-Events brauchte, ist keine Abkürzung, sondern ein dauerhaftes Risiko: Jede Datei in diesem Konto ist jetzt über eine Berechtigung erreichbar, die die App nie brauchte. Das liegt still da, bis irgendwann ein Token leakt oder eine Session kompromittiert wird, und dann entspricht der Schaden dem vollen gewährten Scope, nicht dem tatsächlich gebauten Feature. Das ist dieselbe Art von Problem wie bei den 45 % KI-generiertem Code mit OWASP-Klasse-Schwachstellen: Der Code läuft einwandfrei und demot perfekt, während die Exposition darunter liegt, unsichtbar, bis etwas schiefgeht.
Zu wenige Scopes ist der stille Fehlermodus. Fehlt ein einziger benötigter Scope, wirft die Integration keinen klaren Fehler, sie funktioniert einfach auf eine Weise nicht mehr, die schwer zu diagnostizieren ist. Ein Kalender-Sync, der nichts zurückgibt, eine Slack-Benachrichtigung, die nie gesendet wird, ein Stripe-Webhook, der auslöst, dessen Handler aber das benötigte Feld nicht lesen kann. Ein nicht-technischer Builder, der auf ein leeres Ergebnis starrt, hat keine Möglichkeit zu wissen, ob der Fehler im generierten Code, in der Scope-Konfiguration oder auf Seiten des Anbieters liegt, und die KI kann die OAuth-Freigabe nicht inspizieren, um es ihm zu sagen.
Die Scope-Liste exakt richtig zu bekommen und sie jedes Mal neu zu prüfen, wenn sich der Feature-Umfang ändert, ist eine spezifische, enge Fähigkeit. „Beschreib, was du willst“-Prompting deckt das nicht ab, weil die KI, die den Integrationscode generiert, nicht kontrolliert, was die Konsole des Anbieters tatsächlich autorisiert.
Wo die Credentials am Ende landen
Sobald der OAuth-Tanz funktioniert, müssen Client-ID, Secret und alle entstehenden Access-Tokens irgendwo leben. Dieses „Irgendwo“ ist eine echte Architekturentscheidung, kein Detail. Die Integration lokal zu testen bedeutet, dass die App Umgebungsvariablen braucht, die auf echte Credentials zeigen, und nicht-technische Builder, die nicht wissen, wie man .env-Dateien richtig verwaltet, schreiben diese Werte regelmäßig stattdessen direkt hart in den Code. Hartcodierte Secrets, die versehentlich in ein öffentliches GitHub-Repository gepusht werden, passieren oft genug, dass es ein dokumentierter, benannter Fehlermodus der ganzen Kategorie ist, keine seltene Panne. Sobald ein Secret einmal in der Historie eines öffentlichen Repos steckt, ist es rotieren und sicherstellen, dass niemand das Zeitfenster ausgenutzt hat, eine eigene Aufräumaktion zusätzlich zur Integration, die man eigentlich liefern wollte.
Verkabelung, kein Produkt
Man sollte es beim Namen nennen: Infrastrukturarbeit, nicht das Feature, das man eigentlich bauen wollte. Niemand wacht mit dem Wunsch auf, eine Redirect-URI zu konfigurieren. Der geschäftliche Bedarf war „zeig die anstehenden Termine des Kunden“ oder „benachrichtige das Team in Slack, wenn ein Deal abgeschlossen wird“. Die OAuth-Konsole, die Scope-Liste und die Credential-Speicherung sind die unvermeidbaren Kosten, um dort auf einer Plattform anzukommen, auf der jede Integration von null aufgebaut wird, und diese Kosten skalieren mit der Anzahl der Drittanbieter-Dienste, die die App berührt, nicht mit dem Feinschliff des Features.
Genau hier ist eine Plattform wie Softr das richtige Werkzeug für den Job und kein Workaround. Ihre nativen Connectoren für Google Calendar, HubSpot, Stripe und ähnliche Business-Tools sind vorab verifizierte, bereits genehmigte OAuth-Anwendungen: Ein Builder autorisiert sein Konto in einem Login-Flow, und die Scopes sowie die Credential-Speicherung werden serverseitig gehandhabt, komplett abseits des Clients, weil Softr die Konsolenregistrierung bereits einmal für alle erledigt hat. Aber für ein Kundenportal oder ein internes Tool, dessen Aufgabe größtenteils „einen Kalender syncen und in Slack posten“ ist, ist die Integrationssteuer die Art von Verkabelung, die günstiger als Plattform-Infrastruktur zu kaufen ist, als sie pro Projekt neu zu erfinden.
Dieser Tausch macht in dem Moment keinen Sinn mehr, in dem die Integration selbst das Produkt ist. Wenn du einen Anbieter anbindest, für den niemand einen Connector hat, oder Kontrolle über Token-Refresh und Error-Handling brauchst, willst du den OAuth-Flow selbst besitzen statt ihn von jemand anderem zu erben. Das ist Entwicklerarbeit, und sie gehört in Entwicker-Tools: Cursor in einer echten Codebasis, in der du lesen kannst, was die Credentials tatsächlich tun, oder Replit, wo Umgebungsvariablen und Secrets-Management erstklassig sind statt nachträglich angeflanscht. Keins von beiden nimmt dir die Konsolenregistrierung ab, weil das nichts tut. Sie bringen dich nur in die Position, die Scopes bewusst richtig zu setzen, statt sie durch Trial-and-Error zu entdecken.
Die Fix-Loop macht das mit der Zeit schlimmer, nicht besser. Jede Scope-Anpassung oder neue Integration ist eine weitere Runde Konsolenkonfiguration, eine weitere Redirect-URI, die exakt stimmen muss, und eine weitere Chance, zu viel oder zu wenig zu gewähren. Es sind Kosten, die sich mit jedem hinzugefügten Feature summieren, genau die Form des Day-Two-Problems: Die App, die am ersten Tag makellos demot hat, erzeugt bei jedem Wachstumsschritt neue Verkabelungsarbeit.